How web development got so complicated, and why
After writing several articles on the subject and looking at one brief article about the pain involved in some web dev routines, I started to wonder about how hard thigs are, comparatively, for people who develop web apps/sites right now versus what we had in the past.
Important to say, this is not only about JavaScript, which is not that hard. Actually, JS is pretty straightforward as a language. Take a look at the rest though, all the rest: CSS, bundlers, frameworks, node and npm, test runners, polyfills… a lot lies on our heads right now. How did this situation come to this point? Let’s investigate it in a timeline of the web development.
The timeline
The early 1990s: The Web was born
Standard development stack: initial HTML (which was extremely simple), hosting (should have been weird back then)
Optional technologies for the extra mile: image compression (crucial at this point and even much later, few people mastered it though)
Why we moved on: the early HTML was built for exchanging academic papers, not for commercial websites, which were mostly yet to appear. Personal websites pushed for some interactivity, pointing the direction that the Web was going to take for its first commercial boom.
The late 1990s: First server-driven websites
Standard development stack: the same HTML (CSS took a long time to catch and the compatibility was rough), how to embed CGI/Perl scripts (mostly counters or early form handlers), hosting
Optional technologies for the extra mile: PHP, hosting, JS (at the time, a very feeble and secondary scripting language), Flash, image compression, how to write CGI/Perl scripts, Java Applets (omg)
Why we moved on: commercial “service” websites started to come up with lots of money and lots of demands that CGI/Perl scripts could not meet (such as dynamic content). Also, HTML had many limitations for building layouts and managing interactivity well.
The early 2000s: Full throttle on server-rendered webpages
Standard development stack: HTML, PHP, Flash, a little CSS (the little part that was supported everywhere) and a little JS for some “magic”, hosting
Optional technologies for the extra mile: advanced early JS, advanced early CSS, SEO concepts (mostly HTML meta tags), Flash scripting (ActionScript), data sanitisation, Java Applets, image compression
Why we moved on: despite having dynamic content, the client-side interactivity on the Web left a lot to be desired. Still, JS was too hard for complex apps because of major differences between browsers (what JQuery tackled very well later) and Flash was just too slow and clumsy for this.
Up to this time, no clear distinction between backend and frontend existed consistently and most people working on it professionally could do both. From that point on, this distinction started to be seen more clearly.
The late 2000s: JQuery becomes king
Standard development stack: semantic HTML (important for Google at this point), CSS, JS with AJAX and JQuery (and knowledge of some Internet Explorer quirks), Flash, versioning (SVN or GIT)
Optional technologies for the extra mile: JQuery UI, server languages, SEO (now a way more complex science), Flash scripting, CDNs, hosting, image compression, knowledge of most Internet Explorer quirks
Why we moved on: the Web was moving towards single-page apps and, although JQuery allows for it, it makes building one a very laborious process, hard to maintain especially for bigger projects.
The early 2010s: SPAs and Angular
Standard development stack: semantic HTML, CSS, JS, Angular.js v1, CDNs, GIT, CI/CD, Jasmine/Mocha
Optional technologies for the extra mile: Ember, Knockout.js, Babel.js and JS new features at the time, Node.js, NPM, bash, Bootstrap, Underscore.js, minification tools, Bower.js
Why we moved on: Angular.js v1 was found to be too slow. Also, with bundlers still not that popular, maintaining a larger web project was a daunting task, full of small steps (bureaucratic and prone to errors).
The late 2010s (until now): React takes the crown
Standard development stack: semantic HTML, CSS with some preprocessor like SASS, JS with newer syntax (ECMAScript201X), React (or Vue.js/Angular.js), Redux (or VueX), NPM, Webpack (basic), GIT, CI/CD, Jest, Enzyme (earlier) and React Testing Library (now).
Optional technologies for the extra mile: TypeScript (almost becoming standard), CSS-in-JS solutions or Tailwind or Bootstrap and co. (or all of them), Node.js, advanced Webpack or other bundlers (Parcel, Rollup, Snowpack), Babel.js and JS new features, Cypress/Puppeteer or other E2E test tools, Next.js (or Gatsby or whatever server-side rendering tools fit the JS framework of choice).
Moving on
We see some movements now towards TypeScript being a standard tool and also a greater adoption of server-side rendering using JS frameworks. TypeScript is not universally loved but it brings an invaluable contribution to the organisation of a project, especially larger ones. Server-side rendering tends to optimise the experience for the first very important milliseconds of how a user experience a page. Those both make sense, and it is not a surprise anymore to see them growing.
One trend less obvious may come from one curious fact. Did you notice how many tools do we use now, even in the standard stack? It seems that, in general, we have an increasing number of tools we use by default, as well as an increasing number of optional tools in our stacks. The difference in the amount of knowledge a web developer must have in most cases compared to what the same person would be demanded twenty years ago is staggering. I care especially about the newcomers: to be complete developers not only they have to learn about the languages as they are now, they also have to learn so many historical things to understand the quirks that are ubiquitous in this whole stack. Why?
Why such a weird stack
We have a stack that keeps most deprecations usable forever. Imagine an architect having to build a larger house on top of a smaller house on the same land, keeping the smaller house there intact. Imagine this architect doing this many times, and you have an analog situation to current web development.
I talked about the culprits already, in depth. It is important to do it again though: HTML is there, untouched since 2008, when people still believed semantic tags were a great idea. 13 years later, nobody ever got semantic tags right, Google moved on and we still use article, or maybe main, or section? Oh, what the heck, we just want to put a div there, but people tell us (for no good reason, now) we should play this game of “find the perfect tag”, not to mention the bureaucratic obligation we have to generate a dummy index.html for our single-page apps, just because.
CSS is also there and, although we found many ways around its tendency to bring mayhem to any project, it lurks around like a sorry ghost from a distant past, when disgracefully “cascading” sounded better than “using programming logic”. CSS was born wrong 25 years ago, and stayed wrong.
Many of the stack elements we have are workarounds for those two. No matter how cool is our code made for the scoped CSS-in-JS lib or the state-of-the-art JSX-powered framework we have, we still have to generate and minify an ugly and apologetic layer with some DOM-related JS to replace what HTML cannot do and lots of CSS on a straitjacket, probably reeking of repetition because reasonable efficient code not always translates good to the mess that browsers were made to understand.
Are we fated to carry the heavy weight of CSS and HTML forever? Maybe not, and this brings us to a tendency that has potential to change things radically on the web dev world: WebAssembly. Whether being pushed by Backend devs that want their language on Frontend or people who hate JS it does not matter. Although for now WebAssembly development is still considered to be on its early phase and tools are not so good in general, there is a real possibility that it becomes the future in the Frontend Web development scene. One thing though: it still depends on a dummy index.html with some JS boilerplate to run…
Conclusion
Develop for the web has been easier, much easier in fact. Not that we should ideally go back to 1989, but web developers are drowning in procedures, libs and utilities that are sometimes just made as workarounds, and for what? For us to keep a safe distance from features that should have been deprecated and gone extinct, but lie there like slow and apparently harmless zombies. Can we kill those somehow, maybe with the help of the new hero in town, WebAssembly? Tune in for the next chapters.
