Don’t sleep on the fundamentals of front-end

The term ‘front-end’ has changed significantly over the years. Due to the progress in technology and the massive power of Javascript, it has moved from a purely UI-based enhancement to a web page, to driving servers through Node (and Deno) and even being the only tool required to build and run a web app.

This creates an extensive set of skills in the front-end space. Where we used to only deal with HTML, (then) CSS and JavaScript to structure a web page, we can now write server code, native mobile and desktop apps, and good old-fashioned websites. But now, there are also many different types of websites. Is it a SPA? An MPA? Is it server-rendered? Client-rendered? Incrementally, statically rendered?

Impact of different frameworks

The advent of large JavaScript frameworks has helped increase this shift in front-end technology, and the major player, React, has significantly impacted how we write code today.

We can now write truly maintainable, DRY (Don’t Repeat Yourself) and testable code with relative ease. Not to mention the Node/npm ecosystem that allows you to pull in one of the millions of packages to help you do what you need to do.

However, these frameworks and packages can come with the following problems:

• Are they maintained?
• How long will they last?
• How do you continue if they aren’t kept up to date anymore?

When it comes to front-end, understanding the impact using these frameworks can have is an integral part of the craft.

React

React has a particular learning curve to it. The basics can be pretty simple if you know JavaScript, but if it is the first thing you learn, this knowledge gap can bring problems. Without knowing the fundamentals of Javascript and how it works and interacts with the DOM (web page), you can’t truly know what you are doing with React or any other framework.

Likewise, React is often the go-to tool to build something for the web. But is it really always needed?

Knowing all the options

Here at Code, we’ve looked at several frameworks and created a tier of frameworks based on the use case. Using React for a simple blog is overkill because it comes with a certain amount of overhead, including how much code you get (and so needs to be downloaded to see the page), performance, setup time and training. Many other, smaller and simpler frameworks do just as good a job at this. Or even not using a framework at all. It depends on what you are trying to do.

This is why having the fundamentals of front-end engineering is very important to us at Code. If you can build a huge React application that works seamlessly but isn’t performant, doesn’t consider accessibility or semantics and isn’t intuitive to the person using it, you’ve not covered the most important aspects of what it is to be a front-end engineer. And those are the things we look for.

Bootcamps aren’t always the answer

Bootcamps are great at teaching you various things, but they can’t cover the scope and breadth of the front-end. Not unless you start at the very beginning with HTML and work up. But those aren’t the courses that we find people take these days.

React is still the buzzword in the industry, and Bootcamps aim to get you to the end as quickly as possible, teaching you what you need to code in React. But time and time again, we see people who have missed out on the basics:

• The HTML
• The semantics you get from using the right tag for the right thing
• Plain old CSS
• Vanilla JavaScript and the fundamentals of using it before diving into a framework
• Performance (this is a big one because React makes it very easy to build poor-performing apps if you don’t understand those fundamentals)
• Accessibility (also a big one because there’s no point in building something if a proportion of your users can’t use it)

The other issue with learning a framework is that they don’t last forever. Without the fundamentals of JavaScript behind you, when that framework isn’t used anymore, you’re basically back to the start having to learn another framework. Sure, there’s always a learning curve, but it becomes much easier to learn when you understand why you have to do things the way you do when you use them.

What would we suggest?

Here at Code, our favourite type of Computerlover loves learning and growing and can work in a team to better themselves and everyone around them. We would always prefer to hire somebody who doesn’t know 100% of x framework but has a passion to learn, from the beginning, everything that is important to do the best job for themselves and the clients we work with.

These are the types of people we look for. This includes recruitment for our senior levels. We still ask for the same things and perform the same steps, whether we’re looking for a junior or a development lead.

It’s difficult for Bootcamp graduates to return to the start when they’ve spent so long learning — and these courses aren’t cheap — but to truly become a good front-end engineer, you need to do that.

Some courses teach the fundamentals, but we often get caught up in the front-end space with ‘buzzwords’ and ‘the big thing’ when most of these lack longevity, have a steep learning curve and aren’t necessarily required.

It certainly isn’t bad to do Bootcamp for specific things once you’ve got the basics down. At Code, we offer our Computerlovers a training budget to spend on whatever they feel they need to grow as professionals in their discipline. This includes training courses, and we fully encourage them to do so.

Learn the basics. Start with HTML and, most importantly, semantics. Semantics include the fundamentals of accessibility, and HTML can do a lot by itself. Then add CSS on top and enhancements with JavaScript. You’ll be surprised by how much you can do with those skills.