Progressive enhancement is a design and development principle where we build in layers which automatically turn themselves on based on the browser’s capabilities.
The idea of progressive enhancement is that everyone gets the perfect experience for them, rather than a pre-determined “perfect” experience from a design and development team.
The paradigm shift that web development is entering hinges on the fact that while React was a key enabler of the Single-Page-App and Component era of the web, in practice it normally tends to result in extremely poor products. Built-in browser APIs are now much more capable than they were when React was first invented.
Can we please stop adding complexity to our systems just so we can do it in JavaScript? If you can do it without JavaScript, you probably should. Tools shouldn’t add complexity.
You don’t need a framework to render static content to the end user. Stop creating complex solutions to simple problems.
One dev team made the shift from React’s “overwhelming VDOM” to modern DOM APIs. They immediately saw speed and interaction improvements.
Yay! But:
…finding developers who know vanilla JavaScript and not just the frameworks was an “unexpected difficulty.”
Boo!
Also, if you have a similar story to tell about going cold turkey on React, you should share it with Richard:
If you or your company has also transitioned away from React and into a more web-native, HTML-first approach, please tag me on Mastodon or Threads. We’d love to share further case studies of these modern, dare I say post-React, approaches.
This looks interesting. On the hand, it’s yet another proprietary creation by one browser vendor (boo!), but on the other hand it’s a declarative API with no JavaScript required (yay!).
Even if this particular feature doesn’t work out, I hope that this is the start of a trend for declarative access to browser features.
There’s a big difference between the interface to a thing being one line of code, and the cost of a thing being one line of code.
A more acute rendering of this sales pitch is probaly: “It’s just one line of code to add many more lines of code.”
And as Chris puts it:
Every dependency is a potential vulnerability
Photoshop in the browser? That needs JS.
But the reality is, most of what we build is either static HTML or mostly just forms and page reloads. We can build the web that way by default, and progressively enhance a more Ajaxy experience on top of it.
The result is an app that’s faster to load, faster to run, and less prone to breaking… without much additional work for your developers.
Call it HTMLX or call it Hijax, what matters isn’t the code so much as the idea:
Front-end JavaScript fatigue is real. I’m guilty myself of over-engineering JS UI despite preferring good old server templates. I don’t even think HTMX is that good but the philosophy behind it embarrasses the modern JavaScript developer. For that I appreciate it very much.
This is a great thought exercise in progressive enhancement …that Scott then turns into a real exercise!
When I was in Amsterdam I was really impressed with the code that Rose was writing and I encouraged her to share it. Here it is: drop this script into a web page with a form to have its values automatically saved into local storage (and automatically loaded into the form if something goes wrong before the form is submitted).
I somehow missed this when it came out in January but Amber just pointed me to it—an interview with Chris about HTML web components, available for your huffduffing pleasure.
Even the smallest of business websites now seems to have cookie popups simultaneously telling us they ‘value your privacy’ while harvesting data about who we are, where we are, what we’re looking for and what we were doing online before we landed there.
Tracking scripts have become so pervasive that they have effectively become an industry standard, and most businesses deploy them not only without question, but without consideration of what it means for customer privacy.
It’s like CSS exists in some bizarre quantum state; somehow both too complex to use, yet too simple to take seriously, all at once.
In many ways, CSS has greater impact than any other language on a user’s experience, which often directly influences success. Why, then, is its role so belittled?
Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.
This is a good description of the appeal of HTML web components:
WC lifecycles are crazy simple: you register the component with
customElements.defineand it’s off to the races. Just write a class and the browser will take care of elements appearing and disappearing for you, regardless of whether they came from a full reload, a fetch request, or—god forbid—adocument.write. The syntax looks great in markup, too: no more having to decorate withjs-somethingclasses or data attributes, you just wrap your shit in a custom element calledsomething-controllerand everyone can see what you’re up to. Since I’m firmly in camp “progressively enhance or go home” this fits me like a glove, and I also have great hopes for Web Components improving the poor state of pulling in epic dependencies like date pickers or text editors.
You can’t create a complex modern web application like Google Mail without JavaScript and a SPA architecture. Google Mail is a webmail client and webmail clients existed some time before JavaScript became the language it is today or frameworks like Angular JS or Angular BS existed. However, you cannot create a complex modern web application like Google Mail without JavaScript. Google Mail itself offers a basic HTML version that works perfectly well without JavaScript of any form—let alone a 300KB bundle. But, still, you cannot create a complex modern web application like Google Mail without JavaScript. Just keep saying that. Keep repeating that line in perpetuity. Keep adding more and more JavaScript and calling it good.
This is a really lovely little HTML web component from Jason. It does just one thing—wires up a trigger button to toggle-able content, taking care of all the ARIA for you behind the scenes.
This really is a disgusting exlusionary state of affairs.
I hate to be judgy, but I honestly wonder how the people behind some of these decisions can call themselves web developers.
With classes, we can send CSS static values but with custom properties we can send dynamic ones, which is a major shift in the way we can style state. This is something that has been true for some time—and is extremely well supported—but sometimes it takes solving a small real-world problem to make you appreciate the value of it.
I think we still haven’t come to fully appreciate the superpower of custom properties: dynamic values that are shared between CSS and JavaScript.
The idea of needing a framework for everything has been massively oversold.
Premature optimisation is the root of all evil:
Trying to imitate their mega stacks is pointless. Some might argue that it’s a sacrifice we have to make for future scalability and maintenance, but we should focus first on building great sites for the user without worrying about features users might need in the future. If what we are building is worth pursuing, it will reach the point where we need those giant architectures in good time. Cross that bridge when we get there.
The power of interoperability:
Web components won’t take web development by storm, or show us the One True Way to build websites. They don’t need to dethrone JavaScript frameworks. We probably won’t even all learn how to write them!
What web components will do — at least, I hope — is let us collectively build a rich ecosystem of dynamic components that work with any web stack. No more silos. That’s the web component success story.