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.
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.
An insightful and incisive appraisal of technology adoption. This truth hits hard:
React and the component model standardises the software developer and reduces their individual bargaining power excluding them from a proportional share in the gains. Its popularity among executives and management is entirely down to the fact that it helps them erase the various specialities – CSS, accessibility, standard JavaScript in the browser, to name a few – from the job market. Those specialities might still exist in practice – as ad hoc and informal requirements during teamwork – but, as far as employment is concerned, they’re such a small part of the overall developer job market that they might as well be extinct.
I know how to do full-stack development, not because I wanted to but because I had to.
Grim, but true. I know quite a few extremely talented front-end developers who have been forced out of the field because of what’s described here.
There is no choice anymore, I can’t escape it. React is so pervasive that almost every job is using it. On the rare occasion that they’re not using it, they’re using something like it.
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.
The web is backward and forward compatible. Anything you learn about HTML, CSS and browser API’s will serve you well for the next 25 years, which is not something you can say about the current fashion in JavaScript libraries. By ejecting from the thrash of React and other heavy-handed frameworks and doubling down on web fundamentals, you’ll be future-proofing both your career and your codebases.
Why the heck is everyone reaching for React as soon as something on the screen needs to update? And why do we insist on squishing our frontend concerns together with our backend concerns?
I’m glad I’m not the only one constantly asking myself those questions.
Look: is the idea of physically separating “code that runs business logic and builds markup” from “code that handles realtime interactions” really that awful? You can write both in JS if you like, I promise I won’t judge, but we can’t keep pretending that they’re basically the same.
React was never able to stand on its own merits as a framework (as its merits are few). Now the cracks are really starting to show.
Here’s the inside scoop on why Github is making a bizarre move from working web components to a legacy React stack.
Most of what I heard in favor of React was a) it’s got a good DX, b) it’s easy to hire for, and c) we only want to use it for a couple of features, not the entire website.
It’s all depressingly familiar, but it’s very weird to come across this kind of outdated thinking in 2023.
My personal prediction is that, eventually, the company (and many other companies) will realize how bad React is for most things, and abandon it. I guess we’ll see.
Here’s an excellent case study of an HTML web component. Jim starts by showing how you’d create the component in React; then he shows how you’d do it as a JavaScript web component; finally he shows the way to do it as an HTML web component:
The point is we’re starting with a baseline, core experience that will provide basic functionality and content to a wide array of user agents before any JavaScript is required.
Once you’ve done everything you can in vanilla HTML to provide core elements of your baseline experience, you can begin enhancing the existing markup with additional functionality.
This is where HTML web components shine.
I’d like to suggest that everybody in web dev point their dysfunctional novelty seeking (of which I suffer as well) in the direction of HTML and CSS. See how much can be done without JavaScript. It’s a lot! Then look at writing more lightweight JavaScript that’s layered on top of the HTML as enhancements. Because it’s an enhancement and not required for functionality, you can cut the line higher and use newer tech without worry.
See how refreshing that feels.
I don’t think most people using React on a regular basis realize quite how much it’s fallen behind.
Following on from Josh’s earlier post where he said “React isn’t great at anything except being popular”, here are the details.
Every decision React’s made since its inception circa 2013 is another layer of tech debt—one that its newer contemporaries aren’t constrained by.
This is particularly damning:
No other modern frontend framework is as stubbornly incompatible with the platform as React is.
The good news:
React is a bit like a git branch that’s fallen well behind
main. You might not realize it, if React is the star your galaxy orbits around, but…well, frontend has moved on. The ecosystem has taken those ideas and run with them to make things that are even better.
The thinking behind the minimal JavaScript framework, Strawberry:
Even without specialized syntax, you can do a lot of what the usual frontend framework does—with similar conciseness—just by using
ProxyandWebComponents.
Coincidentally, I was just talking about hammers and nails in another context.
Progressive enhancement used to be a standard approach. Then React came along and didn’t support that approach. So, folks stopped talking about that and focused entirely on JS-centric client solutions. A few years later and now folks are talking about progressive enhancement again, under the new name of “islands”.
What is going on here?
It turns out, it’s the same old thing. Vendors peddling their wares. When Facebook introduced React, that act transformed the font-end space into a hype-driven, cult-of-personality disaster zone where folks could profit from creating the right image and narrative. I observed that it particularly preyed on the massive influx of young web developers. Facebook had finally found the silver bullet of Web Development, or so they claimed! Just adopt our tech, no questions asked, and you too can be a rock star making six figures! We’ve been living through this mess for ten years now.
The cosmic ballet goes on.
- Don’t wrap too much of your identity in a tool.
- Every tool will eventually fade.
- Flexibility is a valuable skill
- Changing tools does not mean starting over.
I agree with pretty much every word of this article.
Perhaps most problematic of all is the effect that contemporary developer experience has on educational programs (be they traditional classes, bootcamps, workshops, or anything in between). Such a rapidly expanding and ever changing technological ecosystem necessarily means that curricula struggle to keep up, and that the fundamentals of web development (e.g. HTML, CSS, HTTP, browser APIs…) are often glossed over in favor of getting students into the technologies more likely to land them jobs (like React and its many pals). This leads to an outpouring of early career developers who may speak confidently about things like React hooks or Redux state reducers, but who also lack any concept about the nature of HTML semantics or the most basic accessibility considerations. To be clear, I’m not throwing shade at those developers — they have been failed by an industry obsessed with the new and shiny at the expense of foundational practices and end user experiences.
And so, I ask: what exactly are we buying when we are sold ‘developer experience’ today? Who is benefiting from it? And if it is indeed something many of us aren’t too excited about (to put it kindly), how can we change it for the better?
I agree with pretty much every word of this article.
We were told writing apps with an HTML-first, SSR-first, progressively enhanced mindset, using our preferred language/tech stack of choice, was outdated and bad for users.
That was a lie.
We were told writing apps completely using frontend-y JavaScript would make our lives easier.
That also was a lie.
I agree with pretty much every word of this article.
If you’re top priority is paid employment, right now, React is a great choice for that.
True. But…
If your priority is long-term resilience and maintainability, vanilla JS (probably with a light build process on top of it) is the ideal choice.
It will never become obsolete, or suffer from a breaking version change. It’s fast and performant, results in less code sent over the wire, and generally has a smaller footprint of things to break.
I’ll compare WordPress with React and Vue, because if you didn’t look at the data, you’d think everyone was building with them, right? Absolutely wrong.
Andy reminds of the skewed world of dev perception:
It’s understandable to think that JavaScript frameworks and their communities are eating the web because places like Twitter are awash with very loud voices from said communities.
Always remember that although a subset of the JavaScript community can be very loud, they represent a paltry portion of the web as a whole.
Laurie reiterates the fact that:
And Laurie thinks that’s okay.
I don’t.