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:
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.
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:
|Fundamentals of HTML||I understand what different HTML tags do|
|Fundamentals of CSS||I understand how to use & apply CSS to HTML to style pages|
|Fundamentals of Browser Resources||I understand where to put CSS & JS files and reference them in the HTML for them to show up|
|Accessibility||I can ensure sites are usable for people that use screen readers and other assistive technologies|
|Hardware acceleration||I 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 formats||I understand when to use each image format (|
|Common Browser API knowledge||I understand common browser APIs like |
|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 processes||I 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
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
🔗👩🔬 II. JS Programming & Architecture
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).
In your rebuttal of this blog post, please be gentle with this section ;)
|Async knowledge||I understand the basics of |
|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|
|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 philosophy||I have cursory-to-advanced knowledge of how strategies like State Machines, Observables, Component-based architecture, etc. solve different problems for building web applications|
|Advanced network knowledge¹||I have comprehensive strategies for consuming API data and feel comfortable using client like Apollo or rolling my own.|
¹ related to I / ³ related to III
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.
|Configuration||I 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 npm||I’ve deployed my own packages to npm|
|Architect||I can build front-end boilerplates for other people to use|
|AST understanding||I can create my own Babel or ESLint plugins|
|Bundler understanding||I can create my own webpack plugins|
|Code Generation||I can generate JS programatically|
|CI²||I create automated pipelines for deploying npm packages as well as shipping optimized bundles to production|
|Ecosystem understanding||I 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
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.