this!!! I have a site I personally use daily. it's using react 17 and is built with node 16. upgrading either breaks it and I don't have the
time to fix the issues. It's got 3 components that break as well. And the CRA build script breaks if you update it as well.
I've spent several hours trying 3 different times to upgrade it but I run out of time and give up. So I limp along with tiny changes now and then. I don't know at what point it will become unmaintainable
I have a similar problem with an electron app. it's super frustrating.
I kind of wish the upstream devs got billed for all the extra work they cause. Then maybe they'll take the pain they create a little more seriously.
The latest is eslint which recently broke everything and now 15 or so projects I run will need several hours of maintenance each. work I'd like to put into new features but instead I have to waste on refactoring configuration
This is one of the reasons all of the little tools I've been building on https://tools.simonwillison.net/ are Vanilla JavaScript, no React or anything that needs a build tool and only using dependencies if they can't be skipped.
I'm a server-side developer by trade, but there's something REALLY neat about being able to build a useful interactive thing as static HTML+JavaScript and know that it will effectively never stop working and is entirely self-contained.
Hence the old African proverb: if you want to go fast, use a full-stack TypeScript framework with a highly opinionated build pipeline tied almost inextricably to a venture-backed PaaS. If you want to go far, use HTML and JavaScript.
That first part is not fast either. The venture backed paas makes for a lot changes in the software (all those people need to do something right?) which you need to learn. Vanilla JS, CSS, ancient Lisp/PHP/Perl/C etc I am almost always faster with.
A tell-tale sign is that even fast moving LLMs have issues keeping up with frameworks; they already changed so when you npx bla@latest create my-coolness, the LLM already is going to do things 'wrong' or different than intended as it simply doesn't know everything change yetagain for no reason anyone but the most hardcore devs care about. The rest of us just want to get our work done and have it compile 3 weeks from now still.
I find Mithril simple enough to be low maintenance for Single Page Applications. We still use a version one of it on a project launched about ten years ago -- although I use version two for later things. And you can use it from plain JavaScript with no compile step.
https://mithril.js.org
I’m having the same issue as you but for a React 16 Node 12 web app. Building it was great and good fun but after neglecting updating the dependencies it has become almost impossible to upgrade after 5 years.
I really wish developer put more effort into developing web tech that would last more in time.
> I kind of wish the upstream devs got billed for all the extra work they cause.
This is actually very easy to do!
Surely you’re already donating generous sums to these open source projects - you can simply let them know you’ll reduce your contribution until the problem is fixed.
This is a snarky reply and I’m sorry for that, but seriously why do you feel entitled to anything? Receiving any free software in the first place is more than sufficient.
This has nothing to do with entitlement. Nothing about my post had to do with open source. The same issues apply to proprietary API changes.
Further, I maintain 150 open source projects, 20+ of them active. I still take into account that making a change to an API effects every user downstream. You can spin this anyway you want. If you run an project (open or closed) and you make a change the costs 10s of thousands or million of hours of collective work downstream you just effectively burned down X amount of trees, put Y amount of carbon in the atmosphere, made Z number of people work late instead of being with friends and family, etc...
This argument always bothered me. For me, the ethos of open source and free software is altruism.
The whole point is that the developers make the software to help users. There's nothing gained by developers thought-endingly stating that the users aren't entitled to anything.
On the other hand though, it's not like users are saints either (for example, vanishingly few donate to the developers of the software they use) so it's a bit of a race to the bottom overall and I understand such sentiment.
Maybe I'm cynical, but after 30 years in the open-source community, I think the true ethos of open-source is self-interest, and the disregard open-source maintainers feel for their users reflects this.
The point of free software is to allow users to have control over the software they use. There's no inherent connection to altruism, though that is part of why I open source the code that I can.
Plenty of individuals and companies release open source software that requires payment.
Anyway, I feel this is all tangential. My issue was mostly that the parent comment suggested that open source devs be billed for changing the software they create.
My first decade of software development was on the Flash platform. Don't get me started. When I began building what I considered "Flash-caliber" HTML+CSS+JS things in 2015, I knew to avoid everything that wasn't TIG-welded to Firefox, Webkit and Chromium. I'm reluctant even about using three.js and regl instead of rolling my own little bit of WebGL.
Docker, React and TypeScript pay my bills. But they will rip away from the world, along with everything built on top of them, as soon as discourse around WASM gels into a sexy low-sodium panacea with a meaningless two-syllable name. Web devs guzzled kool-aid before and they will again, and like hell will I toss any personal code in with it.
I've spun up an old ubuntu laptop recently for.. reasons. I think the last time that machine was in use was in the late 2000s. Poking around on it, I was blown away how simple and resilient the infrastructure of some of my old projects was. Things just build, things just work -- after over a decade of being mothballed.
Did the projects work in just the laptops? Or did they work elsewhere also? I think its fairly easy for existing old projects to work, as long as the hardware it lived in is easily replicated. Not so if you have to port it to modern hardware
Nix is a possible solution to stack rot (at least in the realm of "things breaking against each other", not "things that had critical bugs or security holes discovered later")
Yeah, I've had this happen to me. I wrote a directory in cakephp and neglected to update it. Eventually the ROI to me of updating it wasn't worth the hassle.
The one exception is if you outsource the stack updating. For example, https://letterstoanewdeveloper.com/ runs on wordpress.com. In this case, I don't have to worry about stackrot, I just have to pay the bill. If/when the bill becomes too much, then I'll convert it to HTML and host it somewhere. (And yes, if I'd done it as HTML first, I wouldn't have to make the effort.)
WordPress might indeed be a good choice for a CMS.
How well does self-hosted WordPress (without plugins) behave when updating? I would think that even major releases can be updated with a simple click and don't break anything?
WordPress right now is very much a "Let's wait and see what happens in the Matt/WPEngine debacle before committing to any new projects" kind of choice.
There is a non zero chance that Matt/Automattic/wordpress.org will get crushed in the pending lawsuit. And even if they don't, pretty much only the lawyers are going to win there, and it's unclear just how much damage either side there are prepared toi suffer in an attempt to inflict more on the opposing side. I can't see WordPress as a brand or platform that'll have much reputation left unless Matt backs down, at least not at the corporate budget and due diligence levels of project.
Would you want to try convincing your boss or a client that it's sensible to use WordPress, when the competing proposals points out just how much control Matt has personally in the project, and that he's doing shit like this: https://www.theverge.com/2024/11/7/24290394/wordpress-coms-o... ?
One of the WordPress forks (minus the wordpress.org repo and ecosystem of plugins/themes) may end up being the WP legacy, or some alternative like Ghost could end up being a much better choice, for the 10+ year ongoing low-maintenance use case discussed in the article.
WprdPress had its time. In my opinion it's now dead, but not everybody has noticed yet/
With all the drama in the platform right now (caused by one of the creators), I would suggest that anyone that isn’t already deeply invested in it for whatever reason to not start now. Its future is a big question mark right now and I’m unable to recommend it as a stable solution to anyone anymore.
WordPress offers automatic core and plugin updates now. This is rarely an issue with a site that has few plugins and customizations. That said, it's a really good idea to have regular offsite backups.
In my limited experience self-hosted wordpress is pretty good about upgrades. But if you pay for hosting (like I do), you won't have to worry about OS upgrades either.
Keep your stack flat.
Most projects of my web developer friends died after months or a few years. None survived for decades. And the reason was always stack rot.
Multiple parts of their stack became outdated and so hard to update that they quit.