The Great Divide is one of the most iconic web development blog posts. It was well-received as it resonated with many web developers and it has a well-deserved spot on the list of fundamental web dev blog posts on esif.dev. While I recognise many of the symptoms it described, something always felt off about the essay.
The article describes an identity crisis in front-end web development and identifies a chasm between two groups of front-end web developers. In Chris’ own words:
On one side, an army of developers whose interests, responsibilities, and skillsets are heavily revolved around JavaScript. […] On the other, an army of developers whose interests, responsibilities, and skillsets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.
When it was published in 2019, I wrote a lot of JavaScript. The volume of JavaScript I wrote gradually, but drastically, increased after 2016, when my day-to-day work moved from building websites to building… websites of another kind. Instead of front-ends for the masse, I started to work on web-based software to simplify administration, enforce processes, and present real-time information for decision-making, usually behind an authentication wall — web applications, if you will.
While the team I was part of preferred developing lean and robust apps, we had to balance that with shipping features and ensuring our stack was ready for long-term ambitions. Sometimes, our .NET and vanilla JavaScript stack did get in our way of developing highly reactive interfaces. At some point, we dabbled with Node.js and Handlebars (and friends) to render templates server-side and client-side, which worked but had its issues. As front-end frameworks evolved and started to support server-side rendering instead of being mere SPAs, we felt comfortable to adopt them for projects where we anticipated a lot of reactivity.
With that background in mind, I suppose one of the two buckets Chris described in The Great Divide fits me very well — the JavaScript one — despite caring tremendously about HTML, CSS, design, interaction, patterns, accessibility, etc
.
I think Chris, and the people he quotes, accurately identified an identity crisis back then. He puts it eloquently:
The divide is between people who self-identify as a (or have the job title of) front-end developer, yet have divergent skill sets.
Later, in the “JavaScript dun got big” section1, Chris describes the emergence or growth of the JavaScript ecosystem and lists it as a potential cause. Attitude towards JavaScript does seem to be a very distinct difference between people who build public websites and those who do not, but I don’t think that’s the thing that divides us.
Web technologies broke out of the browser and enables us to develop websites, web apps, desktop applications, mobile applications, and more. On top of that, since JavaScript got non-browser runtimes, it’s become a popular general-purpose programming language, especially for software that orbits around websites and web applications, like server-side HTTP routers and REST APIs. While, historically, HTML, CSS, and JavaScript were synonymous with web development, not all website-esque software are websites nowadays. Moreover, the web isn’t the open and public space it used to be, and some websites serve small audiences in predictable conditions.
Each of the different things we’re building comes with its own challenges. Lightweight websites may outcompete those that are not. For many web apps, however, shaving off kilobytes won’t do as much as shipping features your users want and your competitors don’t have. Thus, for web apps, shipping often gets prioritized over optimising product rendering performance.
It’s important to acknowledge that there are some universal truths for all software based on web technologies. Semantic HTML and accessibility should always be up to par. Another principle is that more performant interfaces are always better, and eliminating client-side JavaScript is a reliable way to get there. The Microsoft Edge team is doing exactly that2 by ridding themselves of React. Despite that, we mustn’t forget that context matters in decision-making — I’m sure Microsoft Edge and your average SaaS startup don’t have the same resources and priorities, so where one company can afford to focus on optimizing rendering the performance, another may not.
As different developers face other challenges, it shapes their perspectives, skills and tangent knowledge. Someone who worked at B2B2E SaaS startups for years might be unaware of the best practices for websites. Instead, they apply standards and priorities that work for building web apps to something else. That’s how you get developers that don’t care about view-source — their code usually isn’t public, anyway. That’s how you get a website where client-side React blocks critical content — it’s their favourite hammer and the ramifications are less severe for their day-to-day work.
The idea that developers either gravitate towards JavaScript or other web technologies is an oversimplification to me. It might be true for some, but I believe that developers are also shaped by the goals they aim to achieve. It seems that the different kinds of software we can build with web tech are different enough to adopt very different beliefs.
A JavaScript-oriented back-of-the-front-end developer3 may have fewer skills in common with a front-of-the-front-end developer than with a Django or Rails developer. These roles use completely different programming languages, but the choices developers have to make and the skills required to make them are quite similar, indeed. If that doesn’t scream “the role front-end developer was blown into meaningless proportions,” then I don’t know what will. Just like Django developers and AI engineers aren’t referred to as Python developers on the basis that they use the same programming language, I don’t think everyone who writes HTML, CSS, and JavaScript is a front-end developer.
So, what should we split the title “front-end developer” into?
To me, front-end developers were and still are primarily (but not exclusively) client-side specialists in web development. Developers who use web technology for things that aren’t websites aren’t web developers. So when people who develop websites are web developers, and people who develop apps for smartphones and tablets are mobile app developers, then developers who build web apps must be… web app developers?
Perhaps I’m not the best person to propose job titles, but let it be known that I like goal-oriented names because they’re not verbose but explicit enough to understand what implicit knowledge is required. For example, web development often involves at least some knowledge about SEO, because it significantly influences the discoverability of a website. Similarly, mobile app developers probably need to know how apps are launched on app stores, and how to handle back-end communication for users with an older version of the app.
If a role happens to be platform-agnostic, because you’re using a rendering library that allows you to compile code for multiple platforms, we can think of matching names. Titles like product developer and UI engineer come to mind, though they could be a little more honest — React product developer and React UI engineer are probably more accurate.
We can split roles up beyond the type of software that developers work on. Brad Frost proposes this in his article, front-of-the-front-end and back-of-the-front-end web development. While he addresses web development specifically, I think this equally applies to non-web front-end roles. It’s not catchy, but I can think of some people who fit into a front-of-the-front-end web app developer role. Perhaps this is the level where, instead of trying to capture things in a role, we should be open about our preferences and knowledge so we can try to put complimenting developers together. As Chris puts it:
My hope is that the solution is writing more descriptive job postings. If clearly defined and agreed-upon job titles are too much of an ask for the industry at large (and I fear that it is), we can still use our words.
I believe the essay The Great Divide put too much emphasis on JavaScript being the thing that divided us. Instead, I think the chasm is caused by the diversification of developers using web technologies well beyond the browser. Some of these can be JavaScript-heavy with little to no consequence while doing the same for a public website is bordering on negligence.
Because the technologies used were historically used for front-end web development, we accidentally rebranded the title to capture many roles that involve writing HTML, CSS, and JavaScript, ignoring how widely applicable web technologies are and how diverse contexts are. Again, some contexts call for JavaScript-averseness, while it’s the bread and butter in others.
In 2019, the absence of boundaries was confusing. In the communities I’m active in, front-end web developers felt like JavaScript devs were intruding, and their response was often interpreted as gatekeeping. With companies and hiring managers being equally confused, developers who could’ve been complimenting each other were competing for the same job.
Since the essay was published, I do feel things have improved a bit. There’s now an implicit boundary that slowly becomes explicit — not everyone goes by front-end developer nowadays. Despite that, I regularly run into hostile front-end devs who shame anyone into submission who dares say JavaScript, and developers that objectively think SPA websites are great because everyone has JavaScript enabled and assets cached, so we still have a way to go in differentiating front-end-esque developers and teaching them when to apply which principles.
I think we can start to co-exist when we abandon views that the out-group is dogmatic, not goal-oriented, or harmful. Everyone is just trying to do the right thing, and sometimes they need a little help shifting perspectives to bring the right toolbox for the job. Sometimes the job requires you to finish early, sometimes it requires precision. As the web platform continues to evolve, and we find more uses for it, that toolbox grows and gets too big for us to master… again, which is why we needed better job titles back in 2019, and need them now.