The Frontend Split.

About a year ago, I wrote a post about how frontenders often find themselves with an identity crisis—the identities in question being web designers versus frontend developers. But recently, more and more I realize there’s another genre of frontend developers who are more engineers than designers and who likely have an identity crisis of their own: the frontend engineers, or the JS-only engineers.

Layout? What Layout?

I had a colleague who started out as a frontend developer in my team and eventually asked for a role change to backend engineer. In his opinion, he wasn’t equipped to develop frontend UI since he didn’t have an eye for the details.

In my experience, this friend of mine is not alone. I’ve known a frontend engineer who did not question the inconsistent margins of a carousel inside a PhotoShop file until I pointed it out in a code review. Apparently he didn’t think the inconsistency was unnatural and questionable—a web designer or web-designer-turned-frontend-developer would have noticed immediately and clarified with the graphic designer.

And then there’s the frontend engineers who hate coding CSS and would rather use frameworks like Bootstrap; the frontend engineer who couldn’t tell a left floated icon was misaligned with its right floated counterpart. And more frequently and disturbingly, frontend engineers who never, ever speak to the graphic designers. Except during lunch, maybe.

It seems the rise of importance of Javascript in frontend development is breeding a new class of frontend developers who love Javascript programming and coding up middleware and grappling with build tools but have no flair and/or interest in UI.

Middleware? What Middleware?

On the other hand, there are the frontend developers like myself who are likely not very concerned with best programming practices, Javascript frameworks, automation, unit testing, nor even performance.

I can already imagine the outrage of certain frontend developers: “How the **** do you call yourself a frontend developer when you don’t care about performance/Webpack/unit testing?” I can also imagine the job interviewer failing me in his mind the moment he hears my indifference towards React.

That’s the thing: it’s not that frontend developers like myself don’t care about robustness of code or the best practices, it’s that we’re more focused on striving towards the perfect design solution than the perfect coding construct. In many of our minds, I bet, the question is: what difference does it make to the end user what design pattern we use to write our Javascript?

What difference does it make to the end user what design pattern we use to write our Javascript?

The Ongoing Divide.

I think it’s clear from the above that there’s a divide going on within the frontend community: the ones striving towards robust, performant code versus the ones striving towards elegant, engaging interfaces.

And because the frontend side of web development is growing at such an incredible speed, it is becoming increasingly difficult for any one developer to be able to address both concerns at the same time. If one is spending half his time updating Webpack configurations and keeping up with best practices for restructuring Redux code, it is hard to imagine the same person refining the design by addressing both user engagement and accessibility—all while delivering the goods.

As the frontend web becomes more sophisticated and it becomes more and more of a challenge to pull ahead of competitors, I foresee an inevitable split into two distinct groups: the frontend engineers who will ensure the product is performant and robust, and the frontend designers who will focus on making the interface creative and engaging.

When the day comes—and I’m betting it will—I’ll be firmly in the camp of frontend designers, discussing animation and grid layouts with the UX/graphic designers over a cup of coffee while recalling in fondness the days when we could do it all.