Front-end developer
POSTED : octubre 11, 2019
BY : Concentrix Catalyst

The web as we know it is changing. The technologies, the software that they power and the talented minds that write them have all been experiencing a dramatic shift in the past few years. And as the technologies change, so does the role of the web front-end developer. 

This shift didn’t start accidentally. We certainly did this to ourselves. The human condition to want things faster, more engaging, and flashy has pushed web technology further than we ever thought possible in its humble beginnings. In fact, I can trace it back to the one day that brought us to where we are. 

It was a mild spring day: May 27, 2009. The economy had just taken one of the worst hits since the gas shortage of the 1970s. Nobody was in a particularly good mood to begin with when an unassuming repo on Github pushed a commit that said, “Major refactoring: program name now ‘node.'”

On that day, the infamous node.js was born. We figured out a way to trick Javascript into running a server for us. At the time, most of us didn’t see the storm approaching. 

Soon after, technical debt began to skyrocket with a little program called node package manager (NPM), which allowed developers to load libraries of code into their websites and deploy it all via a few simple commands on the terminal. 

This was also the start of something even more interesting. From here on out, the scope of a frontend developer (FED)’s job exponentially changed and expanded. 

It use to be, the role of the FED team was to take the comps or static wireframes from a designer and develop the interface with HTML/CSS and the occasional dash of presentational Javascript if the website called for it. However, over the past few years this has shifted as more and more backend technologies are being developed with traditional frontend code such as Javascript.

To illustrate, this is what I typically think of when it comes to the division of labor from ten years ago:

Front End Back End Design


Frontend architecture

Presentation Javascript

UX decisions (partially)

CMS setup

Hooking CMS into static Templates

Page routing


Initial design

Desktop mockup

Mobile mockup (maybe)


UX decisions (partially)

With the emergence of Javascript libraries such as React and Angular, frontend developers are now expected to have a much greater understanding of programming concepts than they are comfortable with, having originally been aligned with the design side of things, rather than the software side of web development.

This chasm that has been created not only puts veteran frontend developers at a loss, but blurs the line as to what is to be expected when in the job market for everyone. It’s typical for a FED to be asked to know HTML, CSS, React, redux, webpack, and deployment standards as well as current design and UX trends—not to mention the array of database architecture we are expected to know. At this point, many frontend developers are expected to be able to create a website from the ground up with little-to-no support from other departments. 

And yes, it’s definitely possible—we’ve built Javascript up to allow us to do that. But at what point should we abandon the title of frontend developer or the niche craft it came from and label things more appropriately? 

So what’s the solution? Code bootcamps these days pump out frontend devs loaded up with a deep understanding of React without the functional scaffolding of vanilla Javascript, HTML or CSS to carry them along. Are they really frontend developers if they can’t replicate a UI element in CSS?

On the other hand, you have senior FEDs struggling to adapt to a world of deep server-side Javascript and generated code, coming from a career that was built on clean functional HTML and CSS. We all know that technology evolves, and most of us got into this field knowing that we will have to continue learning to be employable. Sure, maybe today it’s not enough to just know CSS and HTML, but not having a concrete answer as to what is the entry-level bar is also a bad place to be. 

We’re getting to the point in this website-building paradigm shift where we need to take some responsibility in what types of demands we put on our developers. More specifically, we need to figure out our expectations of their roles when we hire them, as well as how we compose our project teams. 

Companies, decide on a tech-stack and stick with it. If you hire developers to fill those ranks, focus on the technology that you are using, or intending to use in the future. When writing job descriptions, ask your current dev team what is missing instead of listing the top 10 frameworks in the market. You will get a much better fit for the needs of the team with less surprises down the road. 

If you are smaller shop looking for a generalist, mention that. Focus less on naming tech and mention the need for a well-rounded developer who has functional experience with Javascript and other frontend technologies. You’re not looking for an expert at this point, you need a generalist, and there are many talented ones out there that are put off by needing 3+ years of experience with Angular. 

And remember, code is cheap—developers don’t get paid by the line. Having a great problem solver, no matter the proficiency level, will trump having an average developer any day of the week.

Etiquetas: , ,