Stability is a trade-off unto itself. I often think about Steve Losh’s Hamster Wheel. React yesterday, Go+HTMX+Templ today, and maybe Common Lisp tomorrow!
A lot of the JS ecosystem was designed back in a time when web browsers sucked. DOM updates were very slow (necessitating a shadow DOM), there were all kinds of idiosyncrasies between browsers, and there weren’t tons of built-in tools like web workers, client side storage, crypto, canvas, components, etc. So you’d end up with hundreds of dependencies just to fill in holes in the browser functionality. But now browsers are much better and most of that stuff is unnecessary.
That article (from 2021) doesn’t seem to contradict the idea that browsers are way better now in a way that makes a lot of the JS ecosystem less necessary.
Browser differences really are far less common these days. I write a ton of vanilla JavaScript and I very rarely need to think about the differences between different browsers at all, beyond checking https://caniuse.com/ to make sure the feature I want to use is widely supported.
I’m not a big fan of React, but I found the “If Not React” post to be a very poor description of React’s flaws, and I think it mixes up “React is bad” and “overly heavy, poorly written applictions are bad”, but those are two very different claims. The article has one footnote which makes some more specific — and more reasonable — criticisms of React, but a lot of the rest can be boiled down to “use the best tool for the job” and “avoid doing too much on the client”, both of which can be achieved even when using React.
I’m very surprised to find out the author is a TC39 member.
It’s theoretically possible to build a lightweight application in React… but in practice it almost never happens that way. Why is that? It appears that there are things about the React ecosystem that push developers away from lightweight solutions. I’m pretty confident that’s where Alex is coming from here.
In my experience, it’s more usually the other way around: developers under deadlines and pressure, or developers who just want to solve their problem the quickest way, tend to produce more heavyweight applications by pulling in lots of dependencies, and doing all the work client-side. These developers also tend to choose React because it’s very popular and fairly intuitive once you’ve got your head around the concept of the VDOM and the render function.
That is to say, these applications would be overly complicated in any framework, it’s just React’s popularity that makes it such a lightening rod for these sorts of cases.
I agree with you that you’re making the same point as Alex, but that’s exactly the point that I find so weak in the original post. There are much better criticisms of React, including its divergence from browser standards (c.f. onChange), the way it encourages developers to lock complex application state into components, and the impedance mismatch between the stateful DOM and the immediate-mode style of rendering that React uses. The article does reference these, but these criticisms are mainly stuck in a footnote somewhere.
I agree that making good React apps is possible (and I personally quite like React), but the point of the post (and Alex’s many other previous posts about the frontend world) is more that most React apps aren’t good, and that points to React itself not being a good choice for most apps. I disagree a little, and tend to think that people who write bad React apps aren’t going to magically write great server rendered apps, but at least their bad code isn’t taking seconds to find its way onto my device and choke it.
Well, one of the posts you link was made in June. That was six months ago, so it isn’t all of a sudden, is it? I think anti-react sentiment has been building up over the past couple of years, even. Alex Russel wrote “The Market for Lemons” nearly 2 years ago: https://infrequently.org/2023/02/the-market-for-lemons/
I think it’s probably a combination of developers/content-creators being herd creatures and also people finally maybe acknowledging just how trash it is as a development experience. Sometimes, in its blind fumbling, the lumpenproletariat of webshit developers stumbles across a good idea.
From “The Frontend Treadmill”:
Companies that want to reduce the cost of their frontend tech becoming obsoleted so often should be looking to get back to fundamentals. Your teams should be working closer to the web platform with a lot less complex abstractions. We need to relearn what the web is capable of and go back to that.
From “If Not React, then What?”:
Across more than 100 consulting engagements, I’ve never seen two identical React setups, save smaller cases where folks had yet to change the defaults of Create React App (which itself changed dramatically over the years before it finally being removed from the React docs as the best way to get started).
Those are probably the two money shots I’d really point at, though honestly everything linked from the “If Not React, then What?” article is worth reading.
And while React is terrible, it seems to have proven a few times to be the least terrible of the available options that happen to meet the project requirements.
I think you’ve hit it on the head–requirements are absurd. I would wager that when most folks interact with most sites, there’s only a few things that they genuinely care about and most of the rest of it is bullshit done to pad the resumes of developers, pad the resumes of designers, pad the resumes of product managers, or make a business feel like they have a “real” product.
Like, let’s face it…99.999% of websites will never have the traffic of Craigslist, nor the amount of UGC, or nor the reliability. 99.999% of sites will never have the dopamine drip of users breathlessly awaiting notifications (and psychology tells us, though it is a dark pattern, that on-demand refreshing is a random reinforcement schedule that is superior for creating engagement that’s probably preferable to push notifications anyways), and 99.999% of websites do not have users that will notice even an hour of downtime every year (modulo, say, e-commerce and holidays).
I mean to really hammer this home. From Wikipedia:
In 2009, Craigslist operated with a staff of 28 people.[21] By 2019 this number grew to 50 people. In that year alone the company made more than $1 billion in revenue, while charging only ca.5 US$ for most ads (the exact price depends on the type of ad and service/property location).
I mean, fuck’s sake, look at their stack. Gaze upon their works and despair. Perl. They mention bugzilla. I’d bet anybody here a beer or coffee that their “requirements” are probably pretty modest and really useful to their users.
most of the rest of it is bullshit done to pad the resumes of developers, pad the resumes of designers, pad the resumes of product managers.
I know that resumé padding happens (I’ve done it!) but I think a lot of the time it’s actually current-job-justification rather than next-job-preparation. And I don’t think it’s necessarily a conscious thing. People are hired to perform a role and so they do the thing that they think they’re supposed to be doing, and rarely is someone taking a top-down view and saying “we don’t need to do this”.
Actually, yes. They are. I think a handful of influencers are pushing for fancy, ‘native-like’ UI/UX and arguing (in bad faith, of course) that if you don’t agree with that approach then you don’t care about users/security/accessibility/whatever. Apparently there is a complexity ceiling with, say, htmx, and the moment you even think about making an app, you will instantly hit that ceiling and then you should have chosen React in the first place.
I hope my sarcasm is coming across clearly. I have decided to completely ignore these merchants of complexity and use my own limited influence to push for simple UI/UX that leveraged browsers as hypermedia document viewers, instead of trying to shoehorn them into being operating systems.
I will wryly note that the author finds a way to make 7 GET requests, including HTMX, to render something that is trivial to style with bare HTML and style tags.
If you are refering to my blog, you can see in its codebase that it is simply a Hugo static site. I don’t think of this codebase as a Go+HTMX+Templ project, I am just writing content in Markdown and letting Hugo generate the static HTML files.
I did experiment a little bit with HTMX on that codebase in the past, and I erroneously left the <script> embedding the HTMX package in the header of the page. Nonetheless, as of the time of publishing this blog post, no element on the page was actively using the imported HTMX package.
Thanks for the feedback though, I removed the <script> element that was unnecessarily embedding HTMX to the blog.
As a mantainer of 3 react apps at work, I have to deal with this dependency churn all the time. Moving to a different stack is not an immediate possibility. One thing that I have started doing is removing dependencies in favour of having our own implementation, e.g. we have our own router, our own form handling lib.
We also have another app in Elm, which has been great, none of this dependency fatigue.
You’d think viewing text would be automatically done by a browser, but many websites disagree and shove megabytes of JavaScript down the pipe to “enhance” the viewing pleasure.
It is, until you decide that you need to handle forms completely differently from the browser, in which case you have to implement it from scratch or pull in a library. This is part of what makes front-end development so uniquely cursed.
Tbh, if you decide you need to handle forms completely differently from the browser, you are likely doing something wrong, and almost certainly breaking accessibility requirements.
Sure, because the browser by itself can’t know which SPA framework is being used and automatically work with that. But this is an easy problem to solve: set up an onSubmit handler for the form, and write a tiny bit of JS to prevent default, grab the FormData, submit it with a fetch() request, get the response, and update some state in the app. Boom, you have partial page update again.
Couldn’t tell if this was a subtle stab at the «dependency fatigue» fatigue or not, but if not: last Elm release was in 2019 (I think?) so chances are that this Elm dependencies aren’t very… actively… maintained. I don’t have any dependency fatigue on my Pascal project either.
I’ve come to realise that having your own router is often quite straightforward. Often they don’t need to be that complicated.
our own form handling lib
I’d seriously consider this next time, too, though it’s less clear to me where the edge-cases and splinters might be for forms, having not tried to implement my own handling for a long time.
A little bit of jumping on the bandwagon syndrome. The author went directly looking for frameworks and is talking about using the present day second most hip stack, regardless of its merits or shortcomings.
Perhaps take a step back and look at the problem at hand. What are you trying to do? What would would need. Which small problema need to be resolved and which tools would help? Is a framework/library/etc even necessary at all. What for?
What problem was react solving in the first place?
On the other hand, I used regular JavaScript to make a SaaS app which generated 90% of HTML on the client from JSON data in 2009 when most cool kids were using jQuery to modify DOM and were generating HTML on the server. And that JavaScript, with just a little care worked, against all JS framework “FUD” at the time, on all browsers then and still works 15 years later.
So maybe there are more choices than the two … to cope or indulge in an overengineered frontend ecosystem, or go back to the future, to rendering HTML on the server again. JavaScript is still just a programming language and people used to do wild things with those for decades :)
That catDict project’s code is such an interesting read. The fun thing with React projects is that given the size of the ecosystem you always learn about something new every time you open a project up and look inside. For me today that was @chakra-ui/react and winston. I got curious to learn more about that and funnily enough found more of the same over there
winston.Logger has been replaced with winston.createLogger.
winston.setLevels has been removed. Levels are frozen at the time of Logger creation.
It can be kinda frustrating sometimes but I try to remind myself it’s also kind of a good problem to have when you consider the alternative. My own personal “Go+HTMX+Templ” comfort food stack is Rails, where the opposite problem exists. Instead of things updating too often and breaking backwards compatibility, a huge proportion of the package ecosystem is abandonware by now. Every time you try to try out a new gem there’s a good chance bundle add is going to fail on you because the gemspec says it only supports up to Rails 7 or whatever. Then you go looking through the recent forks and maybe see a handful of different attempts at updating it but nothing stands out as finished. So you give up and keep looking / abandon your idea / build it yourself.
The maintenance burden is what matters, the last thing I want to be doing after I finally get back to a personal project is fight with the hips system, update dependencies with braking changes, find out there is no replacement for one lib I’m using and it’s abandoned / not longer compiles if I update common dependencies wit other libs, etc.
I want to come back months later and be able to work on a personal project, not spend my fleeting time maintaining it. Tech stack here matters
It’s insane to me that people accept the BS work of keeping up with the version treadmill. Don’t you want to be doing things other than fiddling with code that was working fine yesterday?
In my opinion, I think many developers feel that any code containing bugs (or that hasn’t seen an update in some period of time) is a potential exploit and the only thing to do is constantly update the code. Yes, I want to do other things than fiddling with code that was working fine yesterday, but I think that’s a (sadly) minority position these days.
Yes, I am considering this, since multiple people gave me the same feedback.
I didn’t go into too much detail about the Go+HTMX+Templ stack because I wanted to keep the blog post short and focus exclusively on the topic of dependency management.
I’m maintaining a React app at work in production and am looking fondly at htmx, lol. The whole React stack has a bonkers level of complexity. The constant flow of upgrades and security vulns. The evolving ‘best practices’ every couple of years. The Node and npm breakages. Having to move away from the deprecated CRA to Vite and Vitest. The list goes on.
React of so much more features than any other framework it’s insane. Choosing a dependency wisely it’s an engineering job. You don’t simply include everything you find on the Internet. You also need to check for quality of your dependence. Be reasonable and have no problems.
I’d like to see how it compares with an app using Preact and preact-router for rendering only, and custom code using vanilla DOM APIs for everything else, with a minimalist build system (no webpack, no bundler). I did this on a few personal projects and I think it works fine. Of course it’s complicated to use JSX this way, but I’m fine with handwriting calls to createElement once I have aliased it to a shorter name (I name it h).
In other words, I’m not sure that React itself is the issue. I feel like the issue comes from the ecosystem (including bundlers like Webpack).
How much of the burden of this ecosystem can be laid at bundlers like Webpack?
And how much of the original need for bundlers like Webpack was due to the browser’s lack of support for modular JavaScript vs other missing essentials?
Over HTTP/2 multiplexing, bundling becomes a performance detriment, as common individual pieces cannot be cached.
Well I haven’t done any serious frontend web development for years, and I believe you that bundling is probably no longer a good idea with HTTP/2, but as far as I know it’s still pretty common (at least with Angular), I’ve often seen people struggling with webpack and similar tools until recently, and I feel like it could be better if webpack was designed as a generic build system like make or scons or whatever (I may be wrong). So I believe some part of the burden can be laid at bundlers. But otherwise yes, I agree with you.
Frontend technologies are relatively new compared to backend counterparts and they are still developing, thus in constant flux. What you’re experiencing is, which may sound ridiculous, a revolution. That’s why the APIs change so much, we’re still figuring this out. I have to admit it’s a lot of churn, but it’s necessary for a better future.
My suggestion would be to either choose a boring and stable alternative, e.g. Ember, or stay in the current major and push against the FOMO. Switching to htmx works well too, albeit a large refactor IMO and has tradeoffs that may be too much depending on project requirements.
Frontend technologies are relatively new compared to backend counterparts and they are still developing, thus in constant flux. What you’re experiencing is, which may sound ridiculous, a revolution. That’s why the APIs change so much, we’re still figuring this out. I have to admit it’s a lot of churn, but it’s necessary for a better future.
Is it, though? Frontend is basically doing, these days, the work that a GUI toolkit used to do on desktop, since frontend developers have decided to reject the platform-native toolkit and implement their own, using it only as a low-level rendering target. You do see some churn in desktop GUI toolkits, but nothing like in web frontend.
Fair point, and since I have zero experience in native UI development I can’t say much. But lately I’ve seen React influence mobile development such as SwiftUI and Jetpack Compose, which must’ve meant some churn for mobile devs and that there was room for innovation.
I will agree Android development churns about as much as Web frontend development. I was thinking more about desktop UIs, which have been a lot more stable. You can run Win32 apps from the late 90s on modern Windows, and I believe you could mostly rebuild them without changes. You can rebuild NextStep apps for modern MacOS with very few changes.
I’ve heard that Windows is legendary in terms of backwards compatibility, probably due to enterprise customers they have.
“with very few changes” depends on how many changes do you consider to be very few. The author complains about Tanstack Query but v5 comes with a codemod that does the job for you.
While I haven’t done any desktop app development, I’ve heard that retained mode graphics (which I gather is the default for desktop toolkits) is harder to develop and I enjoy that the industry started to adopt immediate mode graphics.
Stability is a trade-off unto itself. I often think about Steve Losh’s Hamster Wheel. React yesterday, Go+HTMX+Templ today, and maybe Common Lisp tomorrow!
hope springs eternal for lisp fans
A lot of the JS ecosystem was designed back in a time when web browsers sucked. DOM updates were very slow (necessitating a shadow DOM), there were all kinds of idiosyncrasies between browsers, and there weren’t tons of built-in tools like web workers, client side storage, crypto, canvas, components, etc. So you’d end up with hundreds of dependencies just to fill in holes in the browser functionality. But now browsers are much better and most of that stuff is unnecessary.
I strongly disagree. The same problems that existed years ago exist today: https://bower.sh/my-love-letter-to-front-end-web-development
That article (from 2021) doesn’t seem to contradict the idea that browsers are way better now in a way that makes a lot of the JS ecosystem less necessary.
Browser differences really are far less common these days. I write a ton of vanilla JavaScript and I very rarely need to think about the differences between different browsers at all, beyond checking https://caniuse.com/ to make sure the feature I want to use is widely supported.
I have been seeing a lot more anti-React sentiment all of a sudden. The most interesting I’ve read in the last 24 hours:
I’m not a big fan of React, but I found the “If Not React” post to be a very poor description of React’s flaws, and I think it mixes up “React is bad” and “overly heavy, poorly written applictions are bad”, but those are two very different claims. The article has one footnote which makes some more specific — and more reasonable — criticisms of React, but a lot of the rest can be boiled down to “use the best tool for the job” and “avoid doing too much on the client”, both of which can be achieved even when using React.
I’m very surprised to find out the author is a TC39 member.
It’s theoretically possible to build a lightweight application in React… but in practice it almost never happens that way. Why is that? It appears that there are things about the React ecosystem that push developers away from lightweight solutions. I’m pretty confident that’s where Alex is coming from here.
In my experience, it’s more usually the other way around: developers under deadlines and pressure, or developers who just want to solve their problem the quickest way, tend to produce more heavyweight applications by pulling in lots of dependencies, and doing all the work client-side. These developers also tend to choose React because it’s very popular and fairly intuitive once you’ve got your head around the concept of the VDOM and the render function.
That is to say, these applications would be overly complicated in any framework, it’s just React’s popularity that makes it such a lightening rod for these sorts of cases.
I agree with you that you’re making the same point as Alex, but that’s exactly the point that I find so weak in the original post. There are much better criticisms of React, including its divergence from browser standards (c.f. onChange), the way it encourages developers to lock complex application state into components, and the impedance mismatch between the stateful DOM and the immediate-mode style of rendering that React uses. The article does reference these, but these criticisms are mainly stuck in a footnote somewhere.
I agree that making good React apps is possible (and I personally quite like React), but the point of the post (and Alex’s many other previous posts about the frontend world) is more that most React apps aren’t good, and that points to React itself not being a good choice for most apps. I disagree a little, and tend to think that people who write bad React apps aren’t going to magically write great server rendered apps, but at least their bad code isn’t taking seconds to find its way onto my device and choke it.
Well, one of the posts you link was made in June. That was six months ago, so it isn’t all of a sudden, is it? I think anti-react sentiment has been building up over the past couple of years, even. Alex Russel wrote “The Market for Lemons” nearly 2 years ago: https://infrequently.org/2023/02/the-market-for-lemons/
I think it’s probably a combination of developers/content-creators being herd creatures and also people finally maybe acknowledging just how trash it is as a development experience. Sometimes, in its blind fumbling, the lumpenproletariat of webshit developers stumbles across a good idea.
From “The Frontend Treadmill”:
From “If Not React, then What?”:
Those are probably the two money shots I’d really point at, though honestly everything linked from the “If Not React, then What?” article is worth reading.
And while React is terrible, it seems to have proven a few times to be the least terrible of the available options that happen to meet the project requirements.
Maybe out requirements are just too ridiculous?
I think you’ve hit it on the head–requirements are absurd. I would wager that when most folks interact with most sites, there’s only a few things that they genuinely care about and most of the rest of it is bullshit done to pad the resumes of developers, pad the resumes of designers, pad the resumes of product managers, or make a business feel like they have a “real” product.
Like, let’s face it…99.999% of websites will never have the traffic of Craigslist, nor the amount of UGC, or nor the reliability. 99.999% of sites will never have the dopamine drip of users breathlessly awaiting notifications (and psychology tells us, though it is a dark pattern, that on-demand refreshing is a random reinforcement schedule that is superior for creating engagement that’s probably preferable to push notifications anyways), and 99.999% of websites do not have users that will notice even an hour of downtime every year (modulo, say, e-commerce and holidays).
I mean to really hammer this home. From Wikipedia:
I mean, fuck’s sake, look at their stack. Gaze upon their works and despair. Perl. They mention bugzilla. I’d bet anybody here a beer or coffee that their “requirements” are probably pretty modest and really useful to their users.
I know that resumé padding happens (I’ve done it!) but I think a lot of the time it’s actually current-job-justification rather than next-job-preparation. And I don’t think it’s necessarily a conscious thing. People are hired to perform a role and so they do the thing that they think they’re supposed to be doing, and rarely is someone taking a top-down view and saying “we don’t need to do this”.
Actually, yes. They are. I think a handful of influencers are pushing for fancy, ‘native-like’ UI/UX and arguing (in bad faith, of course) that if you don’t agree with that approach then you don’t care about users/security/accessibility/whatever. Apparently there is a complexity ceiling with, say, htmx, and the moment you even think about making an app, you will instantly hit that ceiling and then you should have chosen React in the first place.
I hope my sarcasm is coming across clearly. I have decided to completely ignore these merchants of complexity and use my own limited influence to push for simple UI/UX that leveraged browsers as hypermedia document viewers, instead of trying to shoehorn them into being operating systems.
The hype cycle is approaching its denouement.
To me, the entire JS/Node ecosystem suffers from this. I don’t understand why so many packages release breaking changes so often.
It’s ironic too, because the web itself is famous for its backwards compatibility. It’s our tooling on top that’s always breaking.
I will wryly note that the author finds a way to make 7 GET requests, including HTMX, to render something that is trivial to style with bare HTML and style tags.
Tbf, personal projects are for experimenting with things, even if they are overkill.
Agreed, but the trick is knowing when you’re doing it.
And why not experimenting doing it simple and using bare bones tech?
¿Y por qué no los dos?
If you are refering to my blog, you can see in its codebase that it is simply a Hugo static site. I don’t think of this codebase as a Go+HTMX+Templ project, I am just writing content in Markdown and letting Hugo generate the static HTML files.
I did experiment a little bit with HTMX on that codebase in the past, and I erroneously left the
<script>embedding the HTMX package in the header of the page. Nonetheless, as of the time of publishing this blog post, no element on the page was actively using the imported HTMX package.Thanks for the feedback though, I removed the
<script>element that was unnecessarily embedding HTMX to the blog.Looks like it’s down to the page text, analytics (no big deal), and two favicons. Solid shave, well done! :)
EDIT: Not trying to bust your chops too much, just felt topical given the content of the blog post.
As a mantainer of 3 react apps at work, I have to deal with this dependency churn all the time. Moving to a different stack is not an immediate possibility. One thing that I have started doing is removing dependencies in favour of having our own implementation, e.g. we have our own router, our own form handling lib.
We also have another app in Elm, which has been great, none of this dependency fatigue.
Does form handling need a separate library? Isn’t it automatically done by browsers?
You’d think viewing text would be automatically done by a browser, but many websites disagree and shove megabytes of JavaScript down the pipe to “enhance” the viewing pleasure.
It is, until you decide that you need to handle forms completely differently from the browser, in which case you have to implement it from scratch or pull in a library. This is part of what makes front-end development so uniquely cursed.
Tbh, if you decide you need to handle forms completely differently from the browser, you are likely doing something wrong, and almost certainly breaking accessibility requirements.
browsers don’t have a way to render server-side form submission errors without a full-page refresh
There’s quite a few options, but one i wanna call out is setting
targeton the form to an iframe.Sure, because the browser by itself can’t know which SPA framework is being used and automatically work with that. But this is an easy problem to solve: set up an onSubmit handler for the form, and write a tiny bit of JS to prevent default, grab the FormData, submit it with a fetch() request, get the response, and update some state in the app. Boom, you have partial page update again.
well that’s why people use libraries, to avoid doing that by hand
Couldn’t tell if this was a subtle stab at the «dependency fatigue» fatigue or not, but if not: last Elm release was in 2019 (I think?) so chances are that this Elm dependencies aren’t very… actively… maintained. I don’t have any dependency fatigue on my Pascal project either.
I’ve come to realise that having your own router is often quite straightforward. Often they don’t need to be that complicated.
I’d seriously consider this next time, too, though it’s less clear to me where the edge-cases and splinters might be for forms, having not tried to implement my own handling for a long time.
A little bit of jumping on the bandwagon syndrome. The author went directly looking for frameworks and is talking about using the present day second most hip stack, regardless of its merits or shortcomings.
Perhaps take a step back and look at the problem at hand. What are you trying to do? What would would need. Which small problema need to be resolved and which tools would help? Is a framework/library/etc even necessary at all. What for? What problem was react solving in the first place?
On the other hand, I used regular JavaScript to make a SaaS app which generated 90% of HTML on the client from JSON data in 2009 when most cool kids were using jQuery to modify DOM and were generating HTML on the server. And that JavaScript, with just a little care worked, against all JS framework “FUD” at the time, on all browsers then and still works 15 years later.
So maybe there are more choices than the two … to cope or indulge in an overengineered frontend ecosystem, or go back to the future, to rendering HTML on the server again. JavaScript is still just a programming language and people used to do wild things with those for decades :)
That catDict project’s code is such an interesting read. The fun thing with React projects is that given the size of the ecosystem you always learn about something new every time you open a project up and look inside. For me today that was
@chakra-ui/reactandwinston. I got curious to learn more about that and funnily enough found more of the same over thereIt can be kinda frustrating sometimes but I try to remind myself it’s also kind of a good problem to have when you consider the alternative. My own personal “Go+HTMX+Templ” comfort food stack is Rails, where the opposite problem exists. Instead of things updating too often and breaking backwards compatibility, a huge proportion of the package ecosystem is abandonware by now. Every time you try to try out a new gem there’s a good chance
bundle addis going to fail on you because the gemspec says it only supports up to Rails 7 or whatever. Then you go looking through the recent forks and maybe see a handful of different attempts at updating it but nothing stands out as finished. So you give up and keep looking / abandon your idea / build it yourself.There’s your answer. The second someone needs a production web app for a business they’re going to be looking more fondly at React.
For small-to-medium sized projects with 1-2 developers, it doesn’t really matter what tech stack is chosen.
The maintenance burden is what matters, the last thing I want to be doing after I finally get back to a personal project is fight with the hips system, update dependencies with braking changes, find out there is no replacement for one lib I’m using and it’s abandoned / not longer compiles if I update common dependencies wit other libs, etc.
I want to come back months later and be able to work on a personal project, not spend my fleeting time maintaining it. Tech stack here matters
It’s insane to me that people accept the BS work of keeping up with the version treadmill. Don’t you want to be doing things other than fiddling with code that was working fine yesterday?
In my opinion, I think many developers feel that any code containing bugs (or that hasn’t seen an update in some period of time) is a potential exploit and the only thing to do is constantly update the code. Yes, I want to do other things than fiddling with code that was working fine yesterday, but I think that’s a (sadly) minority position these days.
Edit: remove sarcastic remark.
[Comment removed by moderator pushcx: Don't mock people like this.]
This is exactly what I was trying to convey with my article!
At least from my experience Go+HTMX+Templ allows me to do this.
Less dependency management pain = more fun time programming my personal project
Any chance you could write a more detailed article about your stack, how you use, and how it all fits together?
Yes, I am considering this, since multiple people gave me the same feedback.
I didn’t go into too much detail about the Go+HTMX+Templ stack because I wanted to keep the blog post short and focus exclusively on the topic of dependency management.
I’m maintaining a React app at work in production and am looking fondly at htmx, lol. The whole React stack has a bonkers level of complexity. The constant flow of upgrades and security vulns. The evolving ‘best practices’ every couple of years. The Node and npm breakages. Having to move away from the deprecated CRA to Vite and Vitest. The list goes on.
Maybe?
At my previous job we switched away from React to HTMX for our less rich Web UIs (think portals in HTMX vs. real-time positioning displays in React).
The Nine Circles of Dependency Hell is a cathartic read
It’s been a while since I touched front-end, but is not upgrading dependencies not an option? Are there that much security vulnerabilities?
React of so much more features than any other framework it’s insane. Choosing a dependency wisely it’s an engineering job. You don’t simply include everything you find on the Internet. You also need to check for quality of your dependence. Be reasonable and have no problems.
I’m writing my frontend in Rust so I don’t have to deal with the nightmare that is the modern TS/JS toolchain.
… go on?
I’d like to see how it compares with an app using Preact and preact-router for rendering only, and custom code using vanilla DOM APIs for everything else, with a minimalist build system (no webpack, no bundler). I did this on a few personal projects and I think it works fine. Of course it’s complicated to use JSX this way, but I’m fine with handwriting calls to createElement once I have aliased it to a shorter name (I name it
h).In other words, I’m not sure that React itself is the issue. I feel like the issue comes from the ecosystem (including bundlers like Webpack).
How much of the burden of this ecosystem can be laid at bundlers like Webpack? And how much of the original need for bundlers like Webpack was due to the browser’s lack of support for modular JavaScript vs other missing essentials?
Over HTTP/2 multiplexing, bundling becomes a performance detriment, as common individual pieces cannot be cached.
Well I haven’t done any serious frontend web development for years, and I believe you that bundling is probably no longer a good idea with HTTP/2, but as far as I know it’s still pretty common (at least with Angular), I’ve often seen people struggling with webpack and similar tools until recently, and I feel like it could be better if webpack was designed as a generic build system like make or scons or whatever (I may be wrong). So I believe some part of the burden can be laid at bundlers. But otherwise yes, I agree with you.
Frontend technologies are relatively new compared to backend counterparts and they are still developing, thus in constant flux. What you’re experiencing is, which may sound ridiculous, a revolution. That’s why the APIs change so much, we’re still figuring this out. I have to admit it’s a lot of churn, but it’s necessary for a better future.
My suggestion would be to either choose a boring and stable alternative, e.g. Ember, or stay in the current major and push against the FOMO. Switching to htmx works well too, albeit a large refactor IMO and has tradeoffs that may be too much depending on project requirements.
Is it, though? Frontend is basically doing, these days, the work that a GUI toolkit used to do on desktop, since frontend developers have decided to reject the platform-native toolkit and implement their own, using it only as a low-level rendering target. You do see some churn in desktop GUI toolkits, but nothing like in web frontend.
Most stewards of desktop GUI frameworks did a decent job of backwards compatibility. Not always great, but you didn’t worry about it to this extent.
It’s easy to lose that historical context when the claim that “it’s different this time!” resounds so often.
Fair point, and since I have zero experience in native UI development I can’t say much. But lately I’ve seen React influence mobile development such as SwiftUI and Jetpack Compose, which must’ve meant some churn for mobile devs and that there was room for innovation.
I will agree Android development churns about as much as Web frontend development. I was thinking more about desktop UIs, which have been a lot more stable. You can run Win32 apps from the late 90s on modern Windows, and I believe you could mostly rebuild them without changes. You can rebuild NextStep apps for modern MacOS with very few changes.
I’ve heard that Windows is legendary in terms of backwards compatibility, probably due to enterprise customers they have.
“with very few changes” depends on how many changes do you consider to be very few. The author complains about Tanstack Query but v5 comes with a codemod that does the job for you.
While I haven’t done any desktop app development, I’ve heard that retained mode graphics (which I gather is the default for desktop toolkits) is harder to develop and I enjoy that the industry started to adopt immediate mode graphics.
This explains the post.
…how?