Frontend has an engineering problem!
It is one field that has forged about the most enviable tooling ecosystem by roughly every measure - from growth rate to technical wizardry - and along with that an incredible amount of thought leadership on its every move,
and yet at its bottom line:
- the average website performance is only regressing with us!
- the average developer productivity is only grinding to a halt!
So it turns out, all of that "vibrant ecosystem" isn't really translating to more "accessible", "functional" apps on the user front, and neither to more "speed" and "productivity" on the developer front!
The closer you get to Frontend's bottlenecks and to how much of that is tooling-induced the more you are wondering if we just have created more problems with our tools than we've solved!
Table of Contents
- The Counterintuitive Equations!
- Looking Back: The Paradigm Shift!
- Towards a Faster Web: A New Quest!
- Introducing: Web-Native Development!
- Notes
- Acknowledgements
- References
The Counterintuitive Equations!
Consider how self-defeating it gets...
...on the user front
Given real world network and device-capability factors, performance starts with shipping less bytes, especially when it coms to JavaScript - your most expensive asset. (Truth is, all of the extra things like instant navigations and transitions that will delight your users need your app to first be accessible!)
Unfortunately, SPA frameworks, who have this as their primary call, have their engineering model going the opposite way: towards more JavaScript! These may follow different programming paradigms... but all have got the same JavaScript bottom-line!
-
[HTML, CSS, JS]>Build_Step>[JS, JS, JS]e.g. Svelte, Vue -
[JS, JS, JS]>Build_Step>[JS, JS, JS]e.g. React
Your final bundle here is the sum of your framework bundle, plus your essential JS, plus the induced (usually larger) JS from page structure, content, and styling - the obvious math to Frontend's terrifying payloads!
With your application's entire weight now culminating in JavaScript... and its non-JS aspects - page structure, content, and styling - now being accounted for in JS, you're now wrongly set up for the real world! It soon becomes clear how much of a knife edge you're on as your application becomes a real thing and starts to regress with every weight gained!
Not surprising... the idea of a "highly-optimized", "accessible", "functional" application quickly falls apart!
Reporting on this in the 2017 Real-world Web Performance Budgets (here), Alex Russell relates:
"I've seen teams that have just finished re-building on a modern tech stack cringe for an hour as we walk them through the experience of using their 'better', 'faster' experiences under real-world conditions."
Tim Kadlec also notes from field experience:
"What is clear: right now, if you’re using a framework to build your site, you’re making a trade-off in terms of initial performance—even in the best of scenarios. [...] If you are going to use one of these frameworks, then you have to take extra steps to make sure you don’t negatively impact performance in the meantime."
It is often excluded in the conversation, but many are winding up with more tooling-induced performance problems than they ever would otherwise! How entirely counterproductive!
...on the developer front
Performance is all about being able to tame complexity with the least amount of overhead. This calls for the abstractions/tools for managing complexity to hold to "a 'first do no harm' principle... make sure you are at least no less productive with overhead than you were without it." (Swyx)
Question is: are we really improving at managing complexity? Not when it feels like we're drowning in more complexity than ever, with an entire curriculum of deep programming concepts taking the place of what used to be the "HTML" kind of problems, and along with that a doze of compilers - that themselves have to cater to a number of new paradigms, magic syntaxes and dialects!
We must now rigor through the surprisingly high amount of code-level complexity, and pay the price of a compile-step (with Webpack and babel (or similar beast) and a barrage of configurations, plugins and extensions) to have a working web page! But that's not all, we must also bend along with mind-bending runtime behaviours (of hooks and friends), and debug through difficult-to-grok transforms of our code!
At this point... you're now entirely cracking a different grade of nut! Everything easy is hard again1!
Jelan shares her frustration:
"I'm getting more and more frustrated with all the added layers of complexity needed to work with most common frontend frameworks. I’ve hit a point where it just doesn’t seem like the end justifies the means in the vast majority of cases anymore."
And Chris Coyer puts a fitting analogy to that:
"Ironically, while heaps of tooling add complexity, the reason they are used is for battling complexity. Sometimes it feels like releasing cougars into the forest to handle your snake problem. Now you have a cougar problem."
Look what was going to land you in the pit of success2 winding you up with more complexity than you had at first! (On the essential/accidental3 scale, that's you having your "accidental" (tooling-induced) complexity trump your "essential" (real problem-space) complexity!) And again, that's utterly counterproductive!
If there's anything that's obvious, it is the one thing that ruins the experience each time: that "JavaScript"; this time, not the "JS" in the conventional "HTML, CSS, JS" approach, but the "JS" in our new "all-JS" equations:
- the "all-JS bottom-line" engineering model - which brings all of page structure, content, and styling to JS (
Build_Step => [JS, JS, JS])! - the "all-JS front-line" engineering model - which defaults to JS for authoring page structure, content, and styling (
[JS, JS, JS] => Build_Step)!
Looking Back: The Paradigm Shift!
Signaled by React's Rethinking Best Practices pitch back in March 2013, frontend's new era has for the most part sat on what seems to be a universal axiom: the traditional web is awful; abstract it! Everything "traditional" about the web application story - from authoring to runtime - has since been doomed for an abstraction or a re-engineering - with the conventional "HTML, CSS, JS" and the DOM being the first casualty of war, and JavaScript being the new default instinct!
Whole new ecosystems of breakaway technologies have spun, each staying at a false dichotomy with web fundamentals and staying defensive about that! Here's for an insight into the thought process...
from HTML to JavaScript:
- Mike Turley (on JSX): Why JavaScript is Eating HTML
- Mark Dalgleish (on CSS-in-JS): A Unified Styling Language
from the web platform to abstractions:
- Rich Harris: Why I don't use web components
- Ryan Carniato: Maybe Web Components are not the Future?
...from HTML to JavaScript
A surprising exodus ensues!
"HTML has been the running punchline in the web development community lately. [...] We are in the midst of a very large problem in the web development field, where HTML is being left in the rearview mirror in place of JavaScript", writes Mark Steadman
React's infamous movement may have had an initial context of just JSX and, later, CSS-in-JS! But unfortunately, this has swept and overturned how a broader share of the frontend tooling space thinks! There's now multiple JS-first agendas everywhere you look - even on web platform proposal boards!
Consider as honorable mentions:
- HTML Modules - a proposed "JS-first" import mechanism for "HTML".
- CSS Modules - a "JS-first" import mechanism for "CSS".
Slowly, some of what belongs in the HTML problem space are now beginning to land as JavaScript feature proposals - sometimes downright namesquatting HTML!
But lest you asked how "HTML Modules" and friends don't solve a problem: maybe they do! But those would certainly not be the "HTML" kind of problems, but the "accidental limitation" type of problem in the JS-first world! Proposals like this are only symptomatic of having gone the "unconventional" way; you must endlessly build JS-first bridges, seek a JavaScript metaphor for every other HTML/CSS thing, and wish the rest of the web were colored yellow! (You can tell clearly how these aren't a feature, but a means to an end!) And notice how this comes even at the risk of tight-coupling a supposed general-purpose, DOM-agnostic programming language with the DOM! (See how HTML Modules in principle tortures the JavaScript language to produce DOM primitives!)
It has turned out to be not just more JavaScript being smuggled in through the back door, but also more HTML and CSS being thrown out the window! (Probably the greater harm!) Think the case regarding the removal - rather than improvement - of HTML Imports from the spec in favour of ES6 Modules - or possibly now the name-squatting HTML Modules above! It just happened that "the JS-centric zeitgeist won" this over - to put it in Brad Frost's words!
And is someone pointing to the removal of Scoped CSS in favour of Shadow DOM based CSS? We'll come to that!
JS-first has this way led to setting fire on many good thinking around HTML just to have them reborn in JavaScript! An irreversible, all-in proposition!
Needles to say is how therefore many highly-missing features in HTML aren't even in the radar on proposal boards! When you look around, really, how much "developer mind-share" does HTML have anymore to push those?
This has been so deep that if you dared to contend with the status quo and build a specialised career on real UI development skills that means less engineering, you'd find yourself in the marginalised half of the Great Divide and risk not having a career! (So then, many devs have had to acquiesce against their own will considering that there are bills to pay!)
...from the web platform to abstractions
Suddenly, the platform is abandoned!
Born out of contempt and mischaracterization of the web platform, the focus of modern abstractions has come to seem somewhat like re-engineering web languages, replicating platform features and APIs, and duplicating the browser's efforts! The whole idea of using the web platform has remained an unattractive option for breakaway technologies. To put it in Alex Russell's words, "The incentives of framework authors are not aligned with compatibility". I often see "web standards" being touted only where it makes a big news or where the performance gains are the incentive!
Looking back at how React and its ecosystem has stayed detached over the years, Mikeal Rogers relates:
"I remember when React was launched, the whole thing was about DOM diffing. The value of it is this virtual DOM thing. Then we made the DOM fast, and who gives a shit now. But we’re still using React because of – I don’t know. [...] And then now we have Web Components and they can’t adopt it, because they’re on their own pattern, so we can’t take this feature upgrade from the platform. [And] I think there's a ton of other examples of this where the platform starts to catch up, and then the frameworks can’t." - JS Party – Episode #89 | Changelog
We just seem to be disposed to trading the "norm" and yet searching for the "kind" in the abstract world!
And what has been a particularly sad implication of the framework-first culture? The more we've invested in breakaway technologies and side ecosystems, the less we've learned about our real problem space and all the opportunities to actually move the web forward! It turns out, HTML and its ecosystem remains undertooled to date, whereas the framework web continues to flourish! You're now almost guaranteed to get stranded as being in a desert land building anything in vanilla HTML and the DOM:
"It’s really depressing that most useful tools these day are made for React projects and/or require React knowledge to set up and use. This locks out many of us who are not using React for everything & who still prefer the vanilla route for their projects." - Sara Soueidan
You just realise how much everyone seems to have disconnected from the real "problem-space" type of problems and gotten buried in "abstract" problems, leaving us with framework-specific solutions to very common problems!
It turns out, undertooling remains a real deterrent for everyone who has craved the simplicity of the vanilla web. (And this should also be one valid challenge to the challenge thrown here by Remy Sharp when he asked: what's stopping you from using exactly [that] method today?)
With so much having gone wrong in the tooling space, what follows is only expected: a community at large suffering a terrible blind spot for web fundamentals! Ground truths are now debated everywhere, "best practices" are literally going numb (hi Pete), and standards are increasingly losing their place among developers! (Consider a survey: What do you know about Web Standards?.)
Go see a typical framework-speaking dev - even in their seniors of roles; go check the typical learning path of the coming generation; and go see what the modern Frontend job descriptions on job boards are saying! Surprisingly, the modern developer career is now little about web technologies themselves and all "about [the] intricacies of the most popular frameworks", to put it in Frédéric Bonnet's words! See that?
There's a destructive information gap and a culture erosion4 now also overtaking us!
Suffice to say, the past decade has been a life of alienation from conventional wisdom, almost entirely spent trading HTML - and burning our ships on the go - in an irreversible bet on JavaScript; turning our backs and throwing dirt on the web platform to bank futures on abstractions! Yet, only a few are really talking about the almost irreversible proposition of this decade-long shift...
"In elevating frontend to the land of Serious Code we have not just made things incredibly over-engineered but we have also set fire to all the ladders that we used to get up here in the first place." - Laura Buns
Towards a Faster Web: A New Quest!
As the ills of the Framework era become more and more palpable, the bells and whistles of the decade are losing their charms on people! Folks are now coming around on our lived reality, and many are actively going back on their life's bets in search of sanity, at the risk of bringing people with torches and pitchforks to their door!
- Hajime Yamasaki Vukelic: What Got Me Writing Vanilla JavaScript again
- Sam Magura: Why We're Breaking Up with CSS-in-JS
But what about the philosophy at the tooling layer: is it now time for a rethink? It depends on how much of a rethink you are asking of!
On the one hand, folks have been hard at work with identifying and addressing inherent overheads in the current system. (But of course, not with a view to rethinking the overall JS-first philosophy!)
For example, realising that the idea of shipping applications as just JavaScript wasn't working anything good on the user front, React and friends have since slid back to the idea of being able to send HTML over the network. This has called for major architectural rework (think React 18's Streaming SSR architecture); this being in addition to the existing idea of static site generation with build tools like Gatsby. Server-Side Rendering (SSR) and Static Site Generation (SSG) have been such a feat for the status quo!
So, right now, HTML and progressive enhancement have again become an attractive option to what has been the "all-JS or nothing" camp. (In fact, Remix has this as a new bragging right! In its own words: who knew?) Put together, all of the new takes here just represent a new game plan: a long walk back to the basics; a bit of a compromise on its initial takes, but a bit of some greater good: towards a faster, functional Frontend!
On the other hand, a new wave of innovation is taking center stage with a more ambitious take than the ongoing long, painful walk back to the basics: this time, the idea of an outright HTML-first, "progressive enhancement" architecture from start! (SitePen Engineering gives the perfect Intro to HTML-first Frontend Frameworks featuring Qwik, Marko, Astro, 11ty, Fresh, and Enhance; and this is absolutely worth your time!)
I find this especially interesting because, finally, everyone can see that the idea of a faster web didn't have to be the hard, compute-intensive, and yet elusive thing we've had for years! It is now clearer than ever how much of an absolute illusion we've been on... in staying fixated to JS and yet subscribed to HTML, albeit cleverly! You'd also realise: HTML over the network didn't have to be any "modern" wisdom or such a big deal of an innovation, or any feat! Not when this is something the web has had from genesis! (Streaming SSR from day 1 of PHP, anyone?)
Sad that we seem to only live after the fact when it comes to tooling, but thanks to the new wave of frameworks for shedding the light that openly challenges the status quo! Finally, we've come to a point that we can be hopeful about: the prospect of having "accessible", "functional" applications at half the price! (Hopefully related is how we've now for the first time - since the JS-making epoch - recorded a less steep increase in the amount of JavaScript shipped to users!)
So are we good now? Well, not just yet!
Not when it seems that we've come only halfway with the idea: sending pages as HTML but authoring them as JS; addressing the tradeoff problem and its overheads on the user front but leaving it unchanged on the developer front! Clear yet? Much of the "HTML" in our new HTML-first equations is still the tooling-yielded HTML, not the hand-authored HTML; same as before where HTML is treated as a compile target, an implementation detail... something you'd abstract to have a good DX! "Tooling" still remains Frontend's primary means to its "HTML" end!
This sheer idea of getting "HTML" behind a compile wall in favor of an abstraction is also where it begins to tell that we might yet be suffering the decade-long blindspot for the platform in a new way - embracing HTML for just the performance incentives and not for the whole idea of using the platform! Let's just throw it out there: Frontend still isn't aligned with using the platform to give legacy tooling their well-earned rest and take a correction back to simplicity!
Chad Fowler notes how deep-seated this is:
"The older I get, the more I realize the biggest problem to solve in tech is to get people to stop making things harder than they have to be."
So, how about just taking the plunge... and embracing the whole web platform thing? Now, we would not only be unlocking performance on both the user front and the developer front, we would be doing more: unleashing the web's full potential! (And what could be a more ambitious goal?)
Actually, this is why we're here! Can we skip to the good parts?
Introducing: Web-Native Development!
Take this as not the name of a new framework or some anti-framework movement, but as a playbook to unleashing the web's full potential.
Web-native development5 is an approach to web development that sees the web platform as an enabler in the whole application story, and in fact, a fundamental key to succeeding at each phase of that story - from authoring to runtime! This comes as a hard reset to the decade-long cultural shift and its pessimistic take on the web platform!
This is really about embracing and leveraging native web technologies, APIs, languages and conventions, etc, and minimizing tooling! For a fact, there comes a time in life when this is all you really want... get things done with less of the drama! "I've been in enough teams in my 20 years of programming to value this part almost more than anything else", writes Andrea Giammarchi!
As the platform and its technologies and languages advance, we often can find multiple opportunities "to shed a lot of this tooling" and defer to native approaches. (JS Party - Episode #89 | Changelog) Good to know is that tools are only as good as being solutions to unsolved problems, not solved problems! Anything in exception soon begins to change the narrative to something counterproductive! Thus, for all we've bet on custom tooling, we must now beat that Sunk Cost fallacy6 to explore what's natively available!
At the end of the day, web-native development gets you banking more on the web platform and less on abstractions! You're now on the winning side - rather than on the contending side - of the web's "moving" story! You're now winning as the platform unfolds!
George Katsanos explains how this allows us take back more brain cycles to finally go make something:
"It should be obvious to all of us that if we would focus all our efforts in the Platform and stop reinventing the wheel [...] we would have a lot more free time to focus on the real reason we are in this job which is to deliver fast, stable, secure, user-friendly interfaces."
So, where's a good place to get well-rounded with the web platform? Chrome's web.dev developer centre is a treasure trove of resources on key web design and development subjects, maintained by the Chrome team and other industry experts! (Here's the learning centre.) And for when you need to take the web platform by its individual technologies, here is MDN! (And here's the learning centre.) For showcases, here is one: Using the platform - a delightful piece of a story on going buildless with ES6 modules and going framework-free with Web components, written by Elise Hein!
Up next is: how far does this go in real life? Build a twitter clone with zero tooling? Uhh, that has never been the idea, and we may never get there! The web platform is anything but a framework of its own! At some point, we are going to have to need higher-level abstractions over native lower-level features! Where there seems to be a bit of a bad news is that the current state of HTML and the DOM makes that happen sooner; it isn't long into the journey before gaps and dips in the platform gets you into forced labour! But we can easily turn this around by investing along two lines:
Low-level tooling: platform-focused initiative to standardise and factor into the platform common web development architectures and paradigms. (We're overdue for native-level reactivity and a more empowering component model - just to mention a few!)
Higher-level tooling: community-focused initiative to extend the platform's low-level capabilities with "web-native" libraries and frameworks. (We need a new wave of modest abstractions that draw on the web platform and let us do the same!)
This is where I put my money where my mouth is! I'd like to take you on a few ideas I've been working on along these lines!
Open to some tooling ideas?
Explore with Me...
Our journey spans a series of posts! We begin with the underlying equations and move on to a showcase of the proposals and polyfils, the userland libraries and framework!
For the curious, here's a sneak peak into this project on github.
Notes
- No frameworks were harmed in the creation of this article.
Acknowledgements
- Special thanks to Alex Russell for the time spent reviewing this article!
References
- Can You Afford It?: Real-world Web Performance Budgets (Alex Russell)
- 2022 Page Weight Report: JavaScript Bytes (HTTP Archive)
- The Cost of JavaScript Frameworks (Tim Kadlec)
- What drives Optimal Overhead? (Shawn Wang)
- Glossary of Modern JavaScript Concepts: Part 1 (Kim Maida)
- Rethinking Best Practices (Pete Hunt)
- Why JavaScript is Eating HTML (Mike Turley)
- A Unified Styling Language (Mark Dalgleish)
- Why I don't use web components (Rich Harris)
- Maybe Web Components are not the Future? (Ryan Carniato)
- JavaScript Frameworks & The Lost Art of HTML (Mark Steadman)
- why we’re breaking up with css-in-js (Brad Frost)
- The Great Divide (Chris Coyer)
- Web Components: The Long Game (Alex Russell)
- Is modern JS tooling too complicated? (JS Party – Episode #89 | Changelog)
- The web didn't change; you did (Remy Sharp)
- Web Standards: The What, The Why, And The How (Amy Dickens)
- From Classicism to Metamodernism — A Short History of Web Development Series' Articles (Frédéric Bonnet)
- Hype Driven Development (Marek Kirejczyk)
- What Got Me Writing Vanilla JavaScript again (Hajime Yamasaki Vukelic)
- Why We're Breaking Up with CSS-in-JS (Sam Magura)
- Intro to HTML-first Frontend Frameworks (SitePen Engineering)
- Modern web apps without JavaScript bundling or transpiling (David Heinemeier Hansson)
-
Borrowing Frank Chimero's title: Everything Easy is Hard Again ↩
-
Defining The Pit of Success ↩
-
See Cultural Erosion ↩
-
"Web-native" is a recurring theme across multiple initiatives and paradigms: ↩
- Web Native - Ionic Team's presentation of the idea, but scoped to its Capacitor runtime.
- Web-Native - Frédéric Bonnet's presentation of the idea in The Postmodernist Period of The Third Age of Web Development.
- Modern Web - Guides, tools and libraries for modern web development built on web standards.
- The Stackless Way - Daniel Kehoe's optimistic take on web development that proposes we “use the platform” instead of frameworks and build tools.
- Buildless - Pascal Schilp's paradigm for creating production websites without a build process.
Some related tags:
-
See Sunk Cost Fallacy ↩
Top comments (51)
This. So much this.
I've seen a huge decline in knowledge of 'the basics' over the years. I've watched candidates pale with utter panic when I ask them to implement a simple app on a live coding interview - and stop them when they start importing their favourite framework, reminding them that I asked them to build it using plain JavaScript.
The number of 'modern' websites on which basic, expected web page functionality does not work is insane. Probably largely because they've been created by devs who have no idea about how a basic webpage works, and what those pages are already capable of. The problem gets worse when these devs then become senior and evangelise junior devs... the issue just gets compounded. We end up with teams 'driving a car with zero knowledge of how the engine works, or having any care about how it performs'.
The fact that there is a dwindling pool of people who actually understand there is a problem, coupled with the fact that these are the very people with the understanding and knowledge to come up with viable ways forward... makes me quite pessimistic for the future of web development. That's why it's great to read stuff like this... it gives me hope.
I'll definitely be checking out your ideas on GitHub.
For this reason I filter Stack overflow. I don't want to read or answer questions about simple Tasks wrapped in Vue, Angular or React Boiler-Plate because the people are not able to split the problem from the framework.
Why this Vue based answer?
stackoverflow.com/a/61725139/1635906
Resonates very much with me. Thanks for sharing.
One issue that "web native" continues to fail to address is the other One App for the Price of Two problem (i.e. not the re-hydration one).
Ultimately the Gen 0 web was constrained by this as the chosen server side implementation language was never supported on the browser.
So whenever there was some beneficial client side interactivity, it needed to be implemented with JavaScript and that JavaScript code became the second application (the server side application being the first) of the whole "web app system".
Remix and SolidStart solve this problem by adopting JavaScript as the common language for both the server and the client (no need to wait for WASM-based tooling to mature). Now only one application needs to be maintained.
Furthermore even today most of the HTML on the web isn't "created without tools" but instead dynamically generated by PHP engines (which have their roots way back in 1995).
Yet somehow in the past 28 years no "web standard" platform (server and browser) and language agnostic, performant approach to HTML templating has emerged. Even design-system.service.gov.uk relies on a JS-based tool for HTML templating: Mozilla's Nunjucks.
So it shouldn't be too surprising that JSX has become the predominant HTML templating abstraction. While many associate JSX directly with React it is actually an independent DSL that frameworks can use to inform their HTML/DOM generation process. Love it or hate it, this may lead JSX to have a wider and more long term impact than web components.
I think Eleventy's introduction of the .webc format might be interesting here. It's an approach to templating that aims to lean into web component and native browser design. I could see it becoming more standardized as a native templating language in the future: 11ty.dev/docs/languages/webc/
But you know... the future is hard to predict :-)
The issue with web components is that their fundamental design is entirely rooted in the client side rendering era.
Effective server side HTML templating essentially boils down to efficient string concatenation. Client side templating on the other hand is about creating a DOM tree which is an entirely different ballgame.
Debunking Server Rendering as the Silver Bullet.
With Gen 2 SSR you have already lost the TTI game if you need to spin up something like jsdom for server side rendering.
Similarly WCs were never designed to accommodate efficient server side rendering—even though they can be designed in a certain way to be server-friendly but that tends to get into the "one component for the price of two" territory, something most people aren't prepared to get into.
I agree that web compenents can be improved upon. I don't think there's any reason to believe that the current state of the standard will be static for all future. So the question becomes whether the limitations are fundamental or can be overcome in time.
I think we have a fundamental disagreement of where the web is or should be headed in the future. I am of the belief that we collectively gave server-side rendering a good shot, but it turns out to be inefficient in all cases and close to impossible to scale efficiently. Static sites and pushing some work to the clients solves these problems - even as the pendulum swung too far. SPAs are also a terrible idea.
I bring up .webc because it is a format I believe could be supported natively in the browser to allow importing and using web components with no Javascript required.
It is true that .webc points in the direction of building a DOM tree rather than concatensting strings. I strongly disagree with you on the point that concatenating strings is a better way to go.
Browsers already parse HTML immediately to DOM trees and act on those. Going back to string concatenation after the structure reaches the browser is in fact less optimal.
So if you want native templating executed by the browser, something that leans into the tree structure is more efficient.
.webc, to me, looks like a format that could theoretically be used both in frontend and backend, lending itself to the powerful semantics and abstractions web developers are already used to today. Standardization and adoption will decide its fate.
That may be a fair assessment of the Gen 0 web but Gen 3 is shifting towards "what can be done on the server will be done on the server (or edge) while what has to be done on the client stays on the client".
Ebay has successfully applied this approach with marko at least since 2014 while the rest of the world was drooling over SPAs and React.
I was talking about templating as string concatenation on the server because the server has to produce HTML. Templating on the browser has to produce DOM as event handlers have to be bound (while event handlers are pointless on the server). A unified approach to templating would have gone a long way towards eliminating the "One App for the Price of Two" problem.
Hot take: client side runtime components are an anti-pattern on the web.
Browsers efficiently deal with page scoped HTML and CSS and don't benefit from components at runtime.
It's understandable that design-time components are at times a useful approach though in some cases the component scope is still too coarse-grained for optimal design and architecture.
The reusability argument keeps coming up with components but it's just a different flavour of the reusability kool-aid that came with (class-based) Object-Oriented Programming. Nothing has mitigated the Rule of Three: reusability takes additional effort, sometimes a lot, it never "just happens".
And typically something reusable will need to be flexible to be reusable; this tends to lead to the inclusion of capabilities that aren't always used, i.e. it leads to bloat.
A lean web abhors bloat. That's why I don't think bundlers are going anywhere; their treeshaking is essential for stripping out code that supports unused capabilities.
I'd add: "...for now".
Given the right semantics and format (and e.g. not requiring Javascript code to register web components) would enable the browser to leverage more significant caching strategies that are very similar to what is currently done for HTML and CSS.
See for example the chat in this thread: dev.to/nielsabildgaard/comment/24plb
Lol. I enjoyed this! And I'm happy to cover exactly this in a follow up post.
Overall, I think you're very right that these current (branded) platforms of web development (like React) are taking away from good adoption of more web-native approaches. And that the native web platform is actually very good, albeit under-tooled, today.
I am seeing a bigger picture than just the web here, too. The current situation, where lots of developers know only React and not web development coincides with a significant and global relative shortage of senior competences in general in the industry---largely due to the huge amounts of developers being trained globally, while there are often too few opportunities for junior developers to develop truly senior skills, or be trained by truly senior developers.
In a world where deep platform understanding (and deep software engineering knowledge) is a bit too sparse, big and powerful tools become an easy way to keep developers productive. Developers only have to learn one tool.
Not too long from now, companies will start to realize the damage that can quickly be done by software developers with an extremely limited purview. You've pointed out several of them in this post: teams build solutions that perform poorly in real-world conditions. We're not there yet, but when companies start realizing in general, developers will be pushed to change with changing demands.
I think it's interesting to observe how these changes are slowly starting. Svelte's CSS outputs to CSS files, and you can get similar results with plugins for React etc. The emergence of HTML-first frameworks (Astro, Eleventy), as you mention, are another important data point. Eleventy 2's .webc format leans heavily into (HTML-like) web component syntax, enabling complex static-site generation from HTML-like data.
React is like a powerful hammer, and a lot of developers have learned that most things can be hammered in. With experience and changing requirements we will see a shift towards a more analytical approach, where the right tool is used for the job. I hope.
On the whole, I agree with your observations and I am very aligned with your hopes for the future. I look forward to following your posts on this.
On a more granular note, I think there are a few of the data points you pull together that miss the mark a little bit---but there's a real chance that I'm just missing the exact point you are making.
For example, as I mentioned above, Svelte outputs its CSS natively as CSS files, rather than Javascript. That nuance is important because Svelte is a part of the tendency towards a more web-native world. There's still a long way to go, and your other criticisms (e.g. it requires learning a wholly new syntax - even as that syntax is closer to native Javascript) are still valid.
Also, while HTML imports are a really cool way to import web components for use in a page, there is no HTML-native way to embed an external HTML resource inside another---a case which HTML modules support very well within the context it is run in. In my opinion, HTML and CSS modules are an obvious extension of ES modules, which are now standard. I would like to also see more powerful HTML imports, but I can understand why the standards are currently coalescing around a single standard.
As a point against HTML and CSS support in ES module imports, you quote (source unclear) a paragraph saying that Javascript is supposed to be a "DOM-agnostic programming language". It is unclear to me where that idea comes from, seeing as Javascript includes all the abstractions that make up the DOM in the bundled standard library. This seems like a misrepresentation of what Javascript is, has always been, and will continue to be.
Your post makes me reflect on the bigger picture of how the web is evolving. I remember when jQuery was all the rage, and I remember when youmightnotneedjquery.com launched and blew my mind. Heck, I remember when ActiveX, Flash or Java Applets were trying to take over as the primary platforms for interactivity on the web, and I remember how the standards-based approach won.
In all these cases the branded, private alternatives to the standards disappeared after the best of their ideas were included into the standards.
In a way that's the history we're still seeing repeating here. The web enables incredible exploration and innovation, even in ways that are not well-supported by or even run parallel with the intentions of the standards. That has historically been a great advantage, leading to a lot of innovation, and most of the bad ideas being discarded.
I'm confident that the standards are (generally) moving in the right direction (even if there are some missteps), and we're getting an even more powerful web platform. And I'm very excited about that!
To me the real question is how much damage React has done through trying to make itself synonymous with web development - just like Flash or Java applets did. Some people will eventually have to retrain, but in the process I think they will learn how to become better and more versatile developers. Hopefully.
Plus one that Svelte outputs to CSS and we should care about that detail. So that leaves us with half of the charges against Svelte. Lol. (But should we really get into saving our individual frameworks?) Generally, there are some of these derails that exist at a drilled-in level but which don't really help the overarching philosophy nor move the web forward to new possibilities.
Re: HTML Imports: having put the problem statement well this way...
...what constitutes a corresponding solution? A JavaScript-native way or indeed a HTML-native way? Aren't there credible standards for loading subresources to converge on in the HTML space?
Re: JavaScript and the DOM: am I missing your point? Is the DOM part of the JavaScript programming language or rather the other way around?
Re: Frameworks: Yeah---the note on Svelte is perhaps a bit pedantic in the big picture. I agree with your overall thoughts, and I don't mean to detract from them! I'm sure something even better than Svelte will come along (but I think we're a good ways away from standards so good we don't need frameworks)!
Re: HTML Imports: Agreed - a fully native import in HTML would be really cool. I'll point again to .webc as a format that could have relevance, by leaning into the (already established) Web Component syntax. Imagine
<my-component src="/my-component.webc"></my-component>or somethink like this, off the top of my head:Re: Javascript and the DOM: I think the two are so intertwined that it is nonsensical to consider them as separate in any way :-) The DOM is designed to be manipulated by Javascript. Javascript is designed to manipulate the DOM.
Really great thoughts you've shared in all. I fully embrace them. And we might even have more to converse on in my next piece in this series. Looking forward to that. (I'd love to bring the .webc idea up in that article where we can play with it alongside other ideas.)
Regarding JavaScript and the DOM, this MDN reference might be what I really have in mind. TL;DR: these two things just happen to meet each other in the browser (and browser-like environments), whereas they're really independent standards. You can expect to see DOM implementations in other languages like Java, and you can even more so find JavaScript runtimes that have no idea of the DOM. E.g. node.js
I look forward to reading your next piece :-)
I understand your view on Javascript, and I agree that it has uses where the DOM is not present. And that the standards for the two are separate.
The context of my original comment was this sentence, which seems to imply not just different standards, but a lack of coupling between the DOM and Javascript:
To zoom out a bit, this sentence comes in the context of critique of HTML modules, e.g.
import htmlData from '/someFile.html';. I don't think supporting common formats for imports really ties Javascript any closer to "the web" or "the DOM" than e.g. support for importing JSON files does.(JSON is not the same as Javascript objects---and you could just write your files as Javascript files if you wanted a more clean/less tightly-coupled to web technologies approach to Javascript.)
I would also welcome import of e.g. XML data in a standardized way, and across environments (web, Node.js, deno).
Perhaps I am just reading too much into "DOM-agnostic", or the idea that Javascript isn't already (in design terms) quite tightly coupled to the design of the DOM. It would be incredibly hard to change one without consideration for the other, c.f. backwards compatibility to 1995 (for both the language and the DOM classes), having co-evolved with the web platform, etc.
The Chrome rendering engine and the Javascript V8 engine are both written in C++, so I suppose there is no "natural" connection between the two. But the HTML-DOM-API opens the DOM for any kind of manipulation, including creation of the whole DOM tree. So I suppose, the API is mainly an interface to the rendering core.
So, if we build websites mainly with Javascript, using Javascript to create HTML to let the rendering engine create the DOM might possibly not be the most clever thing we can do. In any case it is not the fastest...
As an example of this, when Flutter builds for web, it renders everything in a canvas - no DOM.
It has a lot of other downsides. HTML/the DOM is a really good model for supporting accessibility needs, for example.
Whenever I read such articles, I'm thinking that people tend to easily forget why libraries like React/Vue/Svelte exist in the first place. People seem to be forgetting, or maybe lucky enough to never came across some jQuery spaghetti nightmare apps or the PHP/ASP templating and concatenating of the past.
And what is proposed, vanilla JS, really? Start and use
getElementByIdorquerySelectorand then write a bunch of lines just to make a single variables' value to be reactive and apply that to the DOM using native Proxies, well thanks but no thanks for me.Don't reinvent the wheel just because the technology stack seems hard to you.
We can write simple web apps using vanilla JS with HTML/CSS but for complex application, the way is by using a mature and reliable library/framework rather than creating a custom framework/library that does things I want "the native way".
Did you read all of the proposals in GitHub? It sounds like you may not have, or possibly didn't understand what is being proposed?
There are some really good ideas in there.
The standards are moving really fast these days, and a lot is changing---and has changed since the launch of youmightnotneedjquery.com/ :-)
There are also a lot of much smaller ways to get started with building slightly dynamic websites - you may not need a full frontend framework. See e.g. dev.to/bindthis/avoid-server-side-...
There are still lots of good reasons for frontend frameworks to exist---but there are also lots of cases that do not need them (and where leaning into what the web already does well would result in a better solution), where they are still used, to the detriment of user experience.
It's... nuanced, basically :-)
Basically everything is nuanced xD
This is purely anecdotal,
I was once a junior dev that thought "this application is small enough, maybe I can get away with a much smaller framework." and for a while I did get away with it. Until product decisions made it nearly impossible to work with the small framework; worse still, no one else on the team knew the tiny framework. So, in the end we had to give up and rewrite the application in a scary big framework because in the end the little bump in size was nothing compared to the unmaintainable mess that would have resulted in continuing to use an obscure tiny framework that might be abandoned in 3 months.
If you're thinking, "hey how about relying purely on platform code and no framework".
This can go one of two ways and imo both are terrible,
One part of the problem is, that HTML is still a child of the late 80´s. While the web went through lot´s of transistions, the core did not change much. It is like flying to the moon on a VW beetle. Now we have a supercharged, fusion powered beetle, but in the core it is still a car, not a rocket.
See my post do we really need HTML for more details and a different approach. There are also some really lightweight demos on dev.to
If you start building a rocket not based on cars, you will loose a lot of ballast :-)
Hilarious analogy.
Yeah with stuff like Astro and Remix the trend is clear - back to "shipping" more HTML, less JS ... progressive enhancement. In a way we've come full circle - but with tons of complexity (and overhead?) added :)
Honestly you can't blame the "abstract the web" folks, because the web as a platform was just not cutting it - not as an application development platform, that is - it was underpowered.
But look at how much the "native" web standards have grown and evolved, and how browsers have become more capable - the 'native' web now is becoming a credible app development platform.
(case in point: native browser support for ES6, so that we can - at some point - finally get rid of Webpack/Babel and the need to eternally "build and bundle")
Now the only ;) remaining problems are:
Seems simplicity won't ever come back, but well, probably ChatGPT or its successors might be writing much of our code in the future anyway :-D
I agree with you. To be fair "abstract the web" was good thinking at the time; the web was indeed TOO underpowered! But what went wrong? Staying fixated to a mission whose premise has changed! It's a depressing insight when you realize how much of today's innovation is still living in the past, solving for "already solved problems".
And simplicity is sooner than you think. Trust this woke generation and its new quest!
(No, we aren't asking for too much; just let's collapse the current heaps and crates of legacy tooling, and we'll be fine.)
Nice one:
when you realize how much of today's innovation is still living in the past, solving for "already solved problems"
But CAN we already, realistically, build any kind of complex/sophisticated web app WITHOUT any sort of add-on tooling or framework?
Spoiler: No!
And let's stress again that we are here because we chose to move forward with the framework web and not the platform.
The fact that a whole bunch of browser vendors need to all faithfully implement these complex standards is one key reason why "web the platform" has advanced at a snail's pace (but it's picking up speed now) ... let's be honest, for a long time (the longest time) the web as an app development platform has been severely underpowered, JS frameworks were realistically the only way to do anything sophisticated with it.
(remember the "browser wars" of the 90s with Microsoft at its center, and actively and deliberately trying tp sabotage the standards with its own proprietary nastiness - the multiple "modes" of IE, ugh, shudder)
But aren't web components the way forward then? And what about web assembly?
From what I have learned the last years I came to the following rules (top-to-bottom) I try to follow, where possible:
Someone might wonder, why I added the first line, which is not related to html, css, js etc. but I honestly believe, that all this framework mania is also a result of the scope-creepiness of developers, managers, ceos etc.
The less features a web-app requires (the name app already implies a lot!) the less there is real need for big, complex frameworks, bundling, transpiling etc.
I broke that down for my personal website and came the result that I will do it by hand with html, css and super minimal vanilla js. Took me roughly one day to complete it, including 100% lighthouse score.
I would even advocate for simple use-case websites, that there is no need for a database! Unless your total amount of files goes into the hundrets or above you may be totally well using JSON files.
The argument that it may have to scale is to me again a scope-creep argument, leading to premature optimization for scale and - again - bloated code with lots of unused code shipped to clients.
I found that the older you get, the more you come to these principles. You begin to see the "more" in "less".
Thanks for sharing this article, I would like to point out also some points that I have found in different places that I think plays an important role in this situation:
Many companies tend to think frontend = easy stuff and backend = very complex, sensitive and difficult so, for frontend the choice in most cases is to dedicate their staff with less experience and less resources, while in backend there is a constant talk about architecture, best practices, how to improve security, etc. So my point here is, we have to admit that frontend now, in some cases, has a lot of logic and cannot be approached like 15 years ago.
One size for all, as engineers I think one of the most important things we should do is to use the right tools to achieve the best solutions and nowadays I think it's easier than ever to get caught in the FOMO/hype train and end up making simple websites that don't even require JS at all with high bundles.
In a way this is normal, or at least expected, as our industry continues to gain traction and tools become better abstractions it is entirely to be expected that we will see more products with less overall quality or deep understanding of the whys.
Very well put. Those two points stand out. And these things don't easily correct themselves. It's sad.
Reading your post again I´m really amazed: I totally agree to your analysis - every single line. Just with a different result.
Hope I can gain some insights from WebQuit. Just, my concludions are a bit different.
I have been working as a programmer for a long time, and here things are a bit different. Most programming languages provide a small, but universal set of keywords and you can - more or less - express anything with this instruction set. C++ has about 60 keywords, thats all. Truely, there are libraries or api´s, that contain 10.000th of routines, but all are expressed with these 60 keywords only.
On the WEB, things are very different. You have to learn at least:
Each tool provides its own syntax, keywords, semantics, wording etc. and is probably different in version 2 from version 1
Then you are prepared for - noting much! You just know the basiscs. Now you start learning a framework, a toolbox, a new philosophy to create your first website. Are 2000 pages enough to get a coarse overview over React or Angular or JQuery? And did this change with version 2?
So, overall, the only common sense on the WEB is Javascript. Regardless of what you do, there will be at least be some Javascript included. So, I decided to go with JS only, for convenience or just to keep things simple.
What I found: It´s working. You can do all the things with Javascript in an easy, well orgaized way. I need precisely no tools at all to do all the things, you might need a framework and a toolchain for. Just VScode and a browser - that´s all (possibly a tiny bit of PHP, sorry).
I found that the "one tool to rule them all" works pretty nice with Javascript and you may gain a lot of convenience here. And you can use some old fashion rules to control the chaos. Maybe this is not for everybody, but it works for me.
You have described the frustation to use tools to reduce the complexity, which finally bring more complexity to your toolchain? This is simply not true for my approach. The more tools I have, the simpler my life is. As each tool is only a JS library, they just bring more opportunities, no frustration.
I hope you can use some of this Ideas for your approach too. I would love to bring the best of both worlds together.
Yeah this for me. I've find the idea of JS everywhere initially counterintuitive (and it may suffer from build steps etc). The productivity boost we have from JS vertically through back to front end has been major and decisive. Shared libraries of our own that are always in sync, no mind shift for the developer, etc, etc...
So Javascript for everything and any output is effectively an object code artefact?
I started coding in assembly language and C. I wrote whole games in assembly language (yep, that old - one of them sold more that 500k units too!) Do I think we should go back to assembly because you can squeeze out the most performance... no. Assembly language has become 99.999% the target of compilers. HTML being the target of a compiler is no different. A DSL for a VM that renders things is ok in my book I've decided.
Of course it would help if the tools got out of the way and the result wasn't bloat... But I'm all for the 1 ring.
We should definitively not go back to assembler. But there is a tendency to reinvent the wheel with every new platform we get. It is like you need a different driver license for every new car. Does this boost our performance?
What a great article! So many references, I will have to spend a full working day reading them all!
I'm very glad that you've mentioned Hype Driven Development, because that has been my exact experience with frontend development. There was a time when I've learned React, and I've actually really liked it. I've even built a couple of sites with it. Then they've decided that classes are now considered old and discouraged, it's all about functional components. After a year I needed to revisit React for a project that I had, and to my utter shock I've realized, that I no longer know React – it's a totally different library now. I kinda gave up on frontend after that.
It started out as a great idea and a great solution, but it has morphed into something really horrible. You don't need to look too far – Facebook's performance is atrocious, and so is the performance of any slightly bigger website written with React.
Another thing that terrifies me is the emergence of JS in the backend world. I can imagine a bunch of suits in a meeting room: "You know all these frontend devs that we have? Let's make them also do backend. They don't have to learn anything new, because they can use the same language for that". And then you get billing modules written in a language that only uses double precision floats for the numbers.