I am in the middle of writing a blog post that is similar to this. My post even also references The Great Divide.
However, my conclusions are different. I think the main problem with front-end today is the complexity of the tooling and the lack of specification updates to implement successful concepts that would allow the removal of frameworks and tooling. I think many of the tasks he describes in this post would cease to exist entirely if we began focusing on implementing things directly into specs and aggressively sunsetting the use of frameworks and tooling.
We have to get away from everything is Javascript and an abstraction land. If a front-end developer didn't have to learn frameworks and how to debug Webpack configurations, they might have more bandwidth to learn how to write HTML properly.
I think he sets up kind of a straw man here. There are a lot of front-end developer roles that are just straightforward JavaScript programming with some domain specific knowledge of Web APIs and frameworks. Then there are front-end developer roles that include the more nuanced stuff he talks about, but I don't think there are a lot of companies plopping all of this disparate stuff into one person's lap.
The real problem is that in 2014-2015, Front-End Developer stopped meaning "A person with an eye for design and detail who can write clean markup and CSS and add some interactivity to a webpage with JavaScript" to "Classical software engineer who writes code in JavaScript". This transition happened because of the mass move to single page applications. But organizations still need people who can do what the previous incarnation of front-end developer did, even if they don't know it. They just don't have a standardized name for the role.
And as someone who has been both versions of front-end developer (I successfully transitioned when I saw the writing on the wall but one look at my personal site should tell you I'm of the old guard.) I think there is a possible version of Front-End Developer in the future that is somewhere in the middle. Truly balanced. Right now things are just too heavily weighted in one direction. I don't think the right move is to necessarily create a bunch of other roles. If that was going to catch on, I think it would have already.
I hope you write your blogpost - I don't actually fully agree with your post entirely but my differings are only in the detail, the general thrust is right on point.
> many of the tasks he describes in this post would cease to exist entirely if we began focusing on implementing things directly into specs and aggressively sunsetting the use of frameworks and tooling
Nitpick: If you look at the tasks he describes one-by-one, this isn't really true as they're mostly spec/implementation domain/sdlc/ related, rather than framework/tooling apis. However... while he makes the list sound as complicated and insurmountable as possible, it isn't. These are mostly tasks I know how to do. And most are reasonably easy to know how to do. The problem is that FE devs don't learn these things, they expend their time gaining other much less portable / long-lasting knowledge (related to frameworks & tooling).
The other sleight of hand the author pulls is listing way more tasks than one would ever have to do on one product or team - quite a few of them are niche insofar as most devs would leverage an abstraction library to provide them with generic versions of these features; building from first-principles would be a rarer special-case for narrowly domain-focused product teams.
>while he makes the list sound as complicated and insurmountable as possible, it isn't.
This is a really great point, and ties into what I was saying. I made the transition when I had to. I am not a genius/wunderkind. I just sucked it up and did it.
I have a hypothesis about this, actually. JavaScript used to really suck. Like, people don't even know who weren't around in the 2000s. It was not at all the language it is today. And there was no StackOverflow or Github or MDN with perfect documentation or coding bootcamps or Udemy courses or any of the other numerous resources on learning how to code. Your options were W3Schools and posting questions on the #javascript channel in Freenode IRC. I think a lot of people doing front-end development simply decided they just couldn't do "real" programming because the resources weren't there to assist them and they didn't have a normal CS background. I definitely had that idea in my head for a long time.
The people who were decent at writing JavaScript in the 2000s were software engineers with computer science degrees who probably mostly wrote Java. And they were doing it holding their noses.
When you look at people that had such an immense impact on how the look and feel of websites developed, like Jeffrey Zeldman and Chris Coyier. Those were just guys. They weren't software engineers. But they are hugely important figures that I worry will eventually be lost to time.
He wants the other skills to be as highly valued as the programming skills - but they just aren't. You aren't going to get paid $250k a year to tighten up sloppy CSS. That CSS is probably CSS-in-JS shit anyways with a framework added to it like Tailwind. A lot of companies probably don't even realize what they lost in this transition. They perhaps weren't even cognizant of it happening.
>I hope you write your blogpost
Oh, it's for sure happening. I've sunk too much time into it. However, I'm going into extreme detail in several areas. It's more of a manifesto/conceptual framework I guess so it's taking a long time to put together.
FWIW I don't think the article was a strawman. That's always been my experience with smaller companies
I started out writing HTML and CSS back in the late 90s, but the job has changed and grown so much since then.
Two jobs ago, I had to do HTML + CSS plus Filemaker, AppleScript, Maria, Redis, Varnish, CDN, DNS, SMTP, SPF, and so much more.
Two years later, at a new job, I still had to do much of that, then add in Drupal, Babel, Webpack, Docker, Figma, Illustrator, Imagick, Nginx, Parcel, GraphQL, React, Next, OpenLayers, Google Tag Manager, Data Studio, Analytics, and so much more.
Two more years later, add in Typescript, Jest, Selenium, CI/CD, Miro, Bun, web workers, MapGL, WebAssembly, Ramda, REDUX, Rxjs, Redux Observables, React Router, Appcues...
That's just one person, in half a decade. The ecosystem as a whole is even more complex.
I think integrating useful things into the base Ecmascript would be a great start, but not the whole story. There is still a ton of dev ops, network admin, sys admin, email admin, graphic design, marketing, advertising, etc. crossover.
Maybe huge tech companies have specialized roles, but smaller ones have tiny web teams that are expected to get the job done no matter how the technologies change. The devs can't even keep up with the tech, much less the managers or HR or execs.
It's part of the fun, for now, but yeesh... I'm going to age out at some point, brain can't keep up much longer lol
The rate of change in computer tech is so fast: in terms of standards, paradigms, hardware capabilities and so on that I think any attempt to be really organised about it can be disrupted by other companies innovating.
And there are so many platforms and languages to learn, in addition to the front end does it all.
Probably you need more people whose role is “X that codes”. Designer that codes, SEO specialist that codes, etc. It matters less if they write any code on the job than they get what it is all about. Then they can have productive discussions with engineers.
After all any concern that isn’t just straight coding feels like requirements analysis. People can specialize in this. You can have a marketing specialist who talks to coders and SEO and marketing team and can put together what is needed.
But tech is dynamic and changing every 6 months so I think it comes with the territory. Not even a problem necessarily. If it is then the actual managers need to address it. It just comes down to skills, roles and responsibilities after all.
There are other issues with frontend and WebApps. No metalevel. We keep reinventing terminal features that can't be manipulated as objects (in the abstract sense, not java).
Very often users are stuck with rest based flows and process that would be better if they could adapt / batch them on their own.
I understand the increased complexity is nauseating and churning out an awful lot of really narrow developers, but I will be honest...
All of the bullet points listed are why I enjoy web development. I am able to amass a seemingly unbounded amount of knowledge, work on an unbounded number of interesting, varied problems, and have the blessing of being compensated appropriately for my investment in myself. Modern web development is, within all this complexity, an open door to anywhere in the world for those with patience.
I didn't even want to be a web developer when I was young. I wanted to be a game developer. Complexities and salaries were somewhat equivalent back then. Then around 2015 it became clear that web development was becoming a cutting-edge marriage of a wealth of amazing technologies and applications. I really love being a part of this industry, whether or not I despise 80% of it.
I agree the need to keep things small is a key part of front-end tooling, but it is worth noting that the choice by the ecosystem to effectively statically link everything (vs having a versioned stdlib which could be cached in a privacy-preserving way) does mean that sometimes size is traded off in detrimental-to-user ways (e.g. dropping support for older/unpopular browsers ASAP, worse implementations are chosen over better ones due to file size).
I do wonder what's going to happen with the use of WASM, I doubt it's going to produce libraries any smaller than ELF, so are people going to try and use caching tools like indexeddb to avoid repeated downloads (and is that the next key bit of tooling to arrive), or are we going to burn our mobile data just so people can avoid building native apps?
As a side note, I find the numpy comment quite interesting: I'm guessing the ~30MB is based on the wheel?
It looks to me (based on the size of numpy in Debian) that ~1/2 of that is shared libraries (e.g. BLAS) which isn't part of numpy. There's also things like: f2py (which helps wrap Fortran libs for use in python), which is just over 1MB; tests including test data, which looks to be about ~5MB; and SIMD support which is almost 2MB. I suspect there's other things you could strip out which would make the size smaller to make things more comparable to front-end work (I've noticed on shared systems that the size of people's conda installs is comparable to my container with a full dev environment, both doing similar things with python). I do think you'd struggle to get it under a few MBs though, as for comparison the FFTW shared lib on my system alone is 2.1MB (with the static one sitting at 4.3MB), and I'd be concerned if there was a different FFT codebase which was much smaller than that (as you'd start wondering what's been left out/incorrectly implemented).
> Modern javascript code is compiled and that's not going away anytime soon
Absolutely, I think most opponents of this change in the workflow have failed to understand the requirements being placed on developers to push a cutting-edge, performant and platform-neutral service ecosystem.
I am a systems programmer with very little experience writing html, but I have written some very basic frontends for a blog and a startup website. What real web developers can do with the tooling they have is amazing. There is a gigantic mountain of abstractions here, and they almost feel arbitrary, but when you read about them, you learn that each absurdly general tool was put into a standard or a framework to do a specific thing.
To me, web development feels about the same as the time I made a processor in minecraft: you have so many weird and arbitrary constraints placed on you by the framework of HTML + CSS (let alone adding a JS framework), and then on top of that you have n + 1 different tools and methodologies to do the same thing, each of which has subtle tradeoffs. It amazes me that anyone can actually develop code in that environment!
...then jquery came, helped normalise js cross browser. then sass, and simple build tools like gulp which i found useful and easy to manage.
in 2022:
> install git
> setup git credentials
> install node
> install npm, yarn, npx....probably missing other package managers
> run npm install
> it fails for obscure reasons: deprecated packages, missing packages, incompatible node versions etc etc
> try to fix all the myriad npm issues
> npm install
> npm run dev: failed docker not found...
> install docker: cannot install
> sudo install docker
> not on sudoers list will be reported
> create IT ticket for sudo access
> 2 days later, install docker
> run npm dev
> make the edit
> commit failed, you are 10 commits behind
> try to merge, cannot automatically merge
this is just a contrived example of all the added stuff we have to deal with which is NOT directly a part of what i need to do, edit some css or html or maybe tweak some js.
javascript has completely changed the meaning of front-end. front end is really full stack javascript developer who can also build responsive for almost unlimited browsers/os's....whilst also being good at js/react/vue/redux state management performance and building fancy animations and transitions with css/svg, accessibility, typography....on and on
it is a lot...the work itself might not be so hard based on your own exp, but the expecations on us are very high.
I am sure it wasn’t roses in 2010 but I het your point. One 2010 concern I remember was performance and opting for flash as a poor mans web socket and trying to figure out if sliverlight was the next thing or adobe flex!
Anyway yeah the new NPM world causes a lot of pain. Module problems throw me as a sort of occasional enough to to deep dive into the topic but often enough to be a PITA. Usually things work with 3 techs but the 4th one buckled it. Eg React? Cool! Typescript? Cool! NextJS Cool! StoryBook … oh shit this ain’t gonna work.
In a silo like .NET and especially in the 2008 heydey stuff just worked with other stuff. Even on .NET now it is complex as every old
initiative still exists and you might have to use it hut there is a lot of new stuff. There are at least 3 versions of web programming paradigm.
I just think we need fewer tech choices but that probably wont happen. The incentives are aligned to have a soup of competing options.
It is great and bad at the same time.
We are getting more done now. People are making SaaS in their spare time. That is amazing! Tell someone in 2010 that it is not only possible but cheap and commonplace to do so!
definitely wasn't roses. having to deal with a bunch of transparent gifs to for rounded buttons during the web 2.0 craze was a headache...but at least it was immediate, i was working directly in html and css
and yes you're right the overall scene now is 100x better in terms of the open source community. many problems have been sold. it's more the tooling and layering of everything that is exhausting, and the ever expanding list of nuances and edge cases...
Isn't this mostly self-inflicted, though. The 2010 way works just as well today.
* npm as a tool, sorry, it sucks. You got to replace all other languages with javascript, live with the consequences of that choice.
* libraries/packages/... are easy to add but hard to maintain. Extremely fine-grained packages with no culture of long-term stability make this a lot worse.
* I'd rather have git complain about a merge than spend time finding out which of file.html, file_old.html, file2.html file_new.html , ... are in use. Lucky you if only 1 file is the answer.
* The whole 'programmers want to install tooling but the sysadmins wont let them' story goes back to at least the '80 ies. Devs on unix installed software in their home folder instead of letting responsible sysadmins install it system-wide (when the sysadmin has time and can be convinced it is usefull).
People were moving to version control for web sites in the late 90s when their projects started turning to chaos.
Virtualization of servers started when the tooling became available around 2005. Linux containers were available, and used where it made sense, in 2010.
The name Ajax dates from around 2005, and before that it was called "remote scripting". First version of Google Maps dates from this era, and would be called a ~SPA~ today.
I think the difficulties you describe are caused by cargo-culting - being lured into using platforms/frameworks because their landing pages are just so damn glitzy, with little understanding.
The visual surface of the web makes into a medium for fashion, and people are drawn to shiny things and vulnerable to fashions.
What's needed are people who are both cold headed and have good taste.
pretty much every developer job requires this nowadays, but of course the setup git credentials is often more complicated today than it was a few years ago with generate new ssh key and write in form field.
Developers on GitHub have keys at https://github.com/<username>.keys, so I just add that to my server in the right places and new developers are off to the code mines (next to me).
The linked article lists a lot of jobs that a frontend developer may be asked to do. Many sites certainly have all of those, but it is not realistic to say that every frontend developer is expected to know how to do all of these. (honestly these days I'm happy if a frontend developer actually knows what a DOM node is).
But it is certainly true that Frontend development is complicated, and often under-appreciated. IME, the person doing a final integration is always the person who has to deal with all the miscommunication that has accumulated over the project. This is true in all fields I am aware of. Frontend development typically fills this role, because the flaws in the design of the data layer, or the miscommunications between the business stakeholder and the designer are typically invisible until someone actually tries to integrate it end to end. Actually delivering a good user experience in a reasonable amount of time while identifying and mitigating these hurdles is very challenging, and can be taken for granted especially if you end up doing a good job at it.
IME the items listed in the article do happen to some people some times, but are much less fundamental than the general integration problem.
I think one of the reasons I like working on the backend more is that every once in a while, you get to do a clean sweep and throw away layers of abstraction. You can work on some app with Ruby on Rails and then load librarys on top of that and then load libraries on top of those that monkeypatch the original libraries... but nothing stops you from grabbing one particular critical API call and reimplementing it in a raw http.Handler in Go that spews simple SQL straight to your DB, sweeping away half-a-dozen layers of abstraction in one fell swoop, or whatever similar story you like to tell. The backend's responsibility ends with delivering the correct bytes in response to some HTTP message and it doesn't matter how you get there.
The frontend... well... the equivalent is technically there, if you are willing and able to work with the grain of the browser. When I'm left to my own devices I can successfully front-end a lot of things with just some basic Javascript and some simple HTML. But it doesn't tend to scale, and it really doesn't scale if you've got some manager who loves that prototype of the calendar selector you did (that was just the browser widget), but really needs these three bullet points that are impossible to do with the native widget so now you're pulling in a library to provide a framework that provides the backbone of the actual widget that does the job and there's simply no other practical alternative because, what, are you going to spend six weeks implementing it yourself instead? No. Of course not.
It's not that the front end never drops a layer of abstraction. jQuery was pretty successfully dropped, to cite one specific example. But you don't ever get that clean sweep, because that's just... too clean a sweep to satisfy any manager or designer.
I think the basic issue is that we're neither implementing new widespread patterns in the browser (new widgets, elements, etc.) nor really making it so we provide lower-level building blocks for interaction. Where we did add elements (like the calendar for example) they're so broadly specified that the browsers disagree on them so much you'll find yourself hard-pressed to actually use them. I think type=email is the only "new" element that is uncontroversially useful.
You mostly have the "free" decades-old elements, and when you step a toe beyond them you're incurring a huge amount of work to try to emulate what the browser was giving you, or probably a library or framework to do it.
On the very simplest end, I'm still baffled that there's no combobox element. `datalist` is kind of a mess and isn't quite the same.
It's a good point. I'm not sure if I ever internalized it completely.
For example, "You believe in design, and you're paying for it, but you are not getting your money's worth because of the gap between engineering and design," could be used in a compelling PowerPoint presentation for a C-level audience. I've definitely seen it.
It's comparable to a restaurant that pays people to find and buy sushi-grade fish because they believe in doing so, but it turns out that the cook is simply deep frying it without anyone seeing it. Shame.
The knowledge of and distribution of talent are out of sync.
My first reaction is: This will never work. A C-level PowerPoint needs a problem statement AND a clear action AND estimates of timings, money, people, in simple words, everything in tiny baby steps. Without action, it's just underlings complaining. With action, they say make it so and come back a few months later and ask what the results are in simple terms of time and money.
But this is a strange reaction. I claim to think that people will solve things if they understand the problem. What makes the suits different?
Somehow, I excluded the execs from actual peoplehood. They are out there, making ignorable sounds like a radio, or doing random damage to infrastructure like a bad storm, but always without any real thinking going on. A bit like Eliza. Spending their time doing political feuds against other execs. Gathering more underlings or budget. Reorganizing people to other random corners of the buildings. Eating big dinners while talking to other execs. Creating a new C-suite job for someone they like.
Oh well, I'm probably cliche level wrong. Or maybe the AI people should target exec-level consciousness as a stepping stone to real-people consciousness ;-)
I'm not sure, in most places I've worked there are multiple people doing these things and some of the parts, like understanding accessibility rules is left to one person to handle, so there is some minor separation of tasks.
I think you might have worked in good places then. Kudos, and I'm jealous! :-) Wherever i have worked, there has been a constant corporate push to squeeze the least amount of people to work on "web stuff"...and of course such "web teams" need to have several (high-paying) Chiefs leading them, who merely direct orders at the "web team". /sigh
> the unending list of topics to learn and the vast swings of urgent demands puts you in a state of constant stress and reinvention
At least all these tasks use (mostly) the same tools, and stick to the same (couple of) languages. A full-stack workflow usually adds an entirely different set of tooling and languages, and then DevOps adds an entirely different set of tooling, languages, concerns, domain, and mindset.
Within 10 years, I've never worked on frontend-only nor backend-only. My responsibility is the same because I don't introduce unnecessary complexity. All team members can do anything, one could do better than the other. Don't open pull request for too long, that's only problem, otherwise no problems at all.
i think ultimately what drives the churn in javascript are business needs. selling more things, and reducing costs.
node is a product of reducing server cost by offloading the app onto the user. this is why your browser tab is using 5gb of ram.
spa are also part of this race to have the most attractive and fluid experience for the customer, and to cut on costs by having a single web app that can function on many different platforms.
and having all these build tools to reduce file sizes to save on hosting delivery costs.
so i dont think its so much a technical issue as it is one driven by business needs. this is the main issue. all this innovation in js has raised the level of expectation to a level that the language/platform itself was never design to accomodate. and now we are stuck with this mess for the forseeable future.
However, my conclusions are different. I think the main problem with front-end today is the complexity of the tooling and the lack of specification updates to implement successful concepts that would allow the removal of frameworks and tooling. I think many of the tasks he describes in this post would cease to exist entirely if we began focusing on implementing things directly into specs and aggressively sunsetting the use of frameworks and tooling.
We have to get away from everything is Javascript and an abstraction land. If a front-end developer didn't have to learn frameworks and how to debug Webpack configurations, they might have more bandwidth to learn how to write HTML properly.
I think he sets up kind of a straw man here. There are a lot of front-end developer roles that are just straightforward JavaScript programming with some domain specific knowledge of Web APIs and frameworks. Then there are front-end developer roles that include the more nuanced stuff he talks about, but I don't think there are a lot of companies plopping all of this disparate stuff into one person's lap.
The real problem is that in 2014-2015, Front-End Developer stopped meaning "A person with an eye for design and detail who can write clean markup and CSS and add some interactivity to a webpage with JavaScript" to "Classical software engineer who writes code in JavaScript". This transition happened because of the mass move to single page applications. But organizations still need people who can do what the previous incarnation of front-end developer did, even if they don't know it. They just don't have a standardized name for the role.
And as someone who has been both versions of front-end developer (I successfully transitioned when I saw the writing on the wall but one look at my personal site should tell you I'm of the old guard.) I think there is a possible version of Front-End Developer in the future that is somewhere in the middle. Truly balanced. Right now things are just too heavily weighted in one direction. I don't think the right move is to necessarily create a bunch of other roles. If that was going to catch on, I think it would have already.