The great(er) divide in front-end

Itā€™s been about a year since Chris Coyierā€™s post The Great Divide came out. The ā€œdivide,ā€ of course, being between 2 armies within front-end development that had been forming:

On one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript. On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.

If youā€˜re unfamiliar with what heā€™s talking about, Iā€™d read that post, but a quick-and-dirty history of front-end is that itā€™s a profession that was once a league of ex-designers muddling their way through code, thatā€™s recently transformed into a proper programming discipline (with some design skills remaining a part of the job requirement). Chrisā€™ post is somewhat of a flag post marking that slow, subtle shift that had been happening in the profession for years.

My initial reaction to this was to reject itā€”not that the divide wasnā€˜t happening, but the idea that these should be 2 different professions. To be blunt, I saw it as someone who made their career on CSS attacking the good work that JavaScript folks had been doing because it threatened his career (I say that as someone respects Chris immensely, but people are allowed to be wrong in blog posts). I even wrote an earlier draft of this post arguing that thereā€™s no divide; thatā€™s just how front-end is now. Get used to it. Git gud.

I now donā€™t see it that way, and I think Chris (rightly) was just pointing out a concern that he had about this divide forming.

As a result, I began to recognize my own limitations. I saw myself as someone that was good at both CSS and JS. But if Iā€™m being honest, Iā€™m not that good at CSS; I just am good enough at design where it seems like I am. Iā€™m also not that good at JS, as someone without a Computer Science background, I am not the master architect that well-educated CS students tend to be (to be clearā€”Iā€™m strongly in the ā€œyou donā€™t need a degree to be a devā€ camp as a member myself, but there is nonetheless a value in a CS education that I do not possess).

In short, the past couple months have been me coming to terms with not being able to do it all. And do it all well.

But all that musing aside, the core content of this blog post hasnā€™t changed, because it was drafted from notes I wrote to a coworker wanting to learn more about front-end, and as I was ennumerating all there is to learn today I noticed the knowledge started to pool into 3 rough areas of expertise, which I still stand by. Will these become 3 different jobs eventually? I donā€™t know. The older I get the less Iā€™m sure of. But I do know that each of these groups are substantial learning efforts each their own, and I do now think itā€™s impossible to master all three of them.

Treat this like a DnD skill tree or somethingā€”up to you to spread points evenly or be a glass cannon in one.

šŸ‘Øā€šŸŽØ I. Browser APIs & Rendering (HTML/CSS)

The area of expertise of Browser APIs & Rendering revolves around two central questions: On the web, how do I make things look like things? and How does a browser work to help me accomplish this?

At beginner levels, browser rendering involves understanding the fundamentals of HTML & CSS to get code to look like a design. At intermediate levels, this gets into animations, render profiling, and making interactive things perform adequately in a browser environment. At the highest levels, mastery of browser rendering means being able to describe in great detail how assets are requested and the priority of their loading, the browser paint API, and how to render anythingā€”even 3Dā€”at 60 frames per second (the maximum a browser will allow).

For the traditional CS student, the browser is something that often gets underestimated. This results in the common ā€œI donā€™t understand CSSā€ state of confusion that so many backend developers find themselves in. And it is confusing, until you treat the browser as the special, weird runtime environment that it is. Often times itā€™s what youā€™re fighting with hereā€”your own misconceptions of what the browser is doing.

Take the following with a grain of salt, but here is roughly how you might track growth of your knowledge in this area:

Beginner

SkillExample
Fundamentals of HTMLI understand what different HTML tags do
Fundamentals of CSSI understand how to use & apply CSS to HTML to style pages
Fundamentals of Browser ResourcesI understand where to put CSS & JS files and reference them in the HTML for them to show up

Intermediate

SkillExample
AccessibilityI can ensure sites are usable for people that use screen readers and other assistive technologies
AnimationsI can animate objects using either CSS or a JavaScript framework like Three.js
Hardware accelerationI understand certain properties & animations can use the GPU for performance
Render profilingĀ²I can use tools like Lighthouse to understand what is slowing down browser rendering & performance
Image formatsI understand when to use each image format (JPG, PNG, WebP, ā€¦), and how to optimize them
Common Browser API knowledgeI understand common browser APIs like fetch and history, and know when to leverage the browser and when to write my own JavaScript

Master

SkillExample
Resource prioritizationĀ² Ā³I understand resource prioritization and the steps from streaming initial HTML payload, to fetching the resources, to rendering them in priority order
Render debuggingĀ²I understand how the browser performs paint operations and how to optimize them
Comprehensive Browser API KnowledgeĀ²I understand more invisible APIs like WebGL, Paint, and the DOM and understand how they differ or can work in sync to render parts of a page
Browser processesI understand the Browser, Renderer, and GPU processes that lie underneath the higher-level APIs

Ā² related to II / Ā³ related to II

You may find that much of the ā€œCSS Devā€ from the Great Divide post fits in here, with the addition of JavaScript like fetch and history, and the omission of CSS frameworks like SMACSS. So already weā€™re breaking up that division! As for CSS framework knowledge, that fits more neatly inā€¦

šŸ‘©ā€šŸ”¬ II. JS Programming & Architecture

The knowledge of JavaScript & Architecture is the recent development of front-end into a more formal, proper software environment from web devā€™s laissez-faire ā€œjust throw that code anywhereā€ beginnings. This roughly correlates with the JavaScript-oriented type in Chrisā€™ post somewhat, and is closer to the comfort sphere of a traditional Computer Science education. Whereas Camp 1 trends toward static display, Camp 2 adds dynamism, automation, and interaction. You could even call this ā€œthe backend of front-end.ā€

This area of knowledge is concerned with How should this application be interacted with? and How should code for the front-end be organized for delivery and team maintainability? The pursuit of these 2 questions, together, have led to many milestones such as that React thing youā€™ve heard so much about (along with Node.js, which weā€™ll cover more in the last section).

Though JavaScript is one of the most popular programming ecosystems, itā€™s still developing. And for that reason I donā€™t feel comfortable dividing intermediate- and master-level topics. Everyoneā€™s journey through here will differ, and for that reason, I only distinguish between basics and non-basics.

In your rebuttal of this blog post, please be gentle with this section ;)

Beginner

SkillExample
Fundamentals of JavaScriptI can build basic things with vanillaĀ JS and donā€™t always need a library (only sometimes)
JavaScript quirksI understand the basics of working with objects in JS, the basics of this, and a rough understanding of scopes
Async knowledgeI understand the basics of Promise() and can write code to fetch remote data (AJAX) or deal with async operations
Fundamentals of FrameworksĀ³I understand how to spin up a React / Vue / Svelte / whatever project and get something visible
Fundamentals of CSS organizationĀ¹I have some basic strategies to organize styles, whether thatā€™s a methodology like SMACSS or a utility like Tailwind

Intermediate/Master

SkillExample
Comprehensive JS knowledgeĀ³I can solve any common problem in JS (when sensible), and I possess up-to-date knowledge of the latest ECMAScript 20xx features
Front-end philosophyI have cursory-to-advanced knowledge of how strategies like State Machines, Observables, Component-based architecture, etc. solve different problems for building web applications
Performance profilingI understand how to profile JavaScriptā€™s performance, even moving operations off the main thread where needed
Inheritance and prototypesBeyond data types, I understand JavaScriptā€™s prototypal inheritance design
Type SystemI understand JavaScriptā€™s type system and coercion, and know how best to leverage it (and potentially possess TypeScript knowledge)
TestingI ensure all JavaScript is tested, whether with unit / E2E tests, headless browser tests, or VRT
Advanced network knowledgeĀ¹I have comprehensive strategies for consuming API data and feel comfortable using client like Apollo or rolling my own.
DOM manipulationĀ¹I understand JavaScriptā€™s role in DOM manipulation, and strategies for managing this such as React (related to Camp 1)
WebAssemblyI understand how JavaScript interops with WebAssembly and know when to leverage it

Ā¹ related to I / Ā³ related to III

In JavaScriptā€™s strange, strange development, something very weird happened that few could have predicted: JavaScript turned into a backend language with Node.js. This not only changed how we prepared JavaScript for the browser (Camp 1); it also changed how we wrote it (Camp 2).

Letā€™s be clear: Node.js is a backend language. In this post weā€™re not talking about the backend, but we canā€™t deny that Node.js has changed the front-end ecosystem forever with advanced tooling to npm. And this knowledge makes up the final area.

šŸ‘·ā€ā™€ļø III: The Toolchain (Node.js, npm, Babel, bundlers)

The final area of expertise is one you wonā€™t see outlined often, if at all, as separate from JS (II). It likely got lumped in with the ā€œJS devsā€Ā in The Great Divide post. Though it seems like a part of JS, the toolchain is more ā€œmetaā€, and its concern more aligns with: Can the way we develop web applications be improved? and itā€™s given rise to module systems, package managers, transpilers, bundlers, and even new languages.

So while web dev today is largely JS, thus explaining the confusion between II and III, perhaps it wonā€™t be for long with things like WebAssembly on the rise. And you can contribute to the toolchain without being a JS dev whatsoever (for example, though Babel is central to JS dev these days, Babel plugins themselves apply generic principles of ASTs that apply to any language, and nothing about it is uniquely JS other than the syntax used to write it).

This area of knowledge is also hard to outline because by its nature it questions the ontology of front-end development. But itā€™s also the most powerful because it has the ability to transform how we work. And as it also requires at least an intermediate understanding of some programming language (even if not JS), the ā€œBeginnerā€ section was omitted entirely here.

Intermediate

SkillExample
ConfigurationI can configure a local development without a boilerplate, working directly with tools like Gulp, webpack, and Parcel
TranspilationĀ¹I can configure Babel and PostCSS to transpile code for specific targets
Bundling & optimizationĀ²I can set up build pipelines to ship production-ready code and optimize delivery of those bundles
Advanced npmIā€™ve deployed my own packages to npm

Master

SkillExample
ArchitectI can build front-end boilerplates for other people to use
AST understandingI can create my own Babel or ESLint plugins
Bundler understandingI can create my own webpack plugins
Code GenerationI can generate JS programatically
CIĀ²I create automated pipelines for deploying npm packages as well as shipping optimized bundles to production
Ecosystem understandingI understand how to deploy npm packages for Node.js, web browsers, and CLI tools, and how to target each

Ā¹ related to I / Ā² related to II

Usually when complaints arise about the state of front-end development, whether thatā€™s how much itā€™s changed, or if itā€™s too complicated, usually JavaScript gets the blame when really itā€™s the toolchain. Of course, this is confusing, since JavaScript is both the engine that runs the toolchain (Node.js) and the input/output of the toolchain itself (browser JS).

This is also the area of expertise thatā€™s undergone the biggest changes of front-end development, and it wonā€™t be settling any time soon. Still, nowā€™s the perfect time to jump in and contribute because all these things arenā€™t settled yet.

A final note on mastery

Recently, a coworker used the term ā€œPlatypusā€ to refer to an engineering problem which is difficult to classify (obviously based off an animal that lays eggs, is aquatic, has fur, and poison), and I love that. He didnā€™t remember the origin (and I Googling it only gave me the results you might expect), so I apologize for not being able to source this (if you know where this originates from please contact me).

In a similar vein, you probably you noticed the superscript Ā¹s, Ā²s, and Ā³s linking skills in one area to another. This is a natural failing of any taxonomic system to be perfect. While thereā€™s always overlap, thereā€™s still enough net value to drawing lines that itā€™s worth doing.

Mastery of any of these areas is a slippery thing, too. Iā€™m reminded of Matt Mightā€™s post, The illustrated guide to a Ph.D. To merely reach the limits of human knowledge is not enough; weā€™re all pushing to try and make that little ā€œdentā€ in the shape of whatā€™s possible. And with that act, we leave behind a bigger world to explore for the next generation.

Even theoretically if you could master something, it would only last for a short time until someone came along and changed whatā€™s possible with their dent. And I canā€™t say this enough: the internet is a fledgeling industry. Weā€™re still figuring everything out.

Above all else, be kind to yourself, and pursue mastery only to the extent itā€™s rewarding for you and others around you. And if you do write an ā€œus vs themā€ post, write it with the intent of unifying, not dividing. God knows we have too much division going on as it is.