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.
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
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.
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 yet again 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 also find Tachyons or similar Atomic CSS libraries to also simplify CSS issues in a more maintainable way -- also with no compile step. From 2017: https://css-tricks.com/growing-popularity-atomic-css/
Maybe someone enjoys fixing breaking changes in layers of dependencies, but it isn't me.
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.
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...
How can your post be read as anything other than "open source devs should be billed"?
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.
Plenty of individuals and companies release open source software that requires payment.
https://www.gnu.org/philosophy/free-sw.en.html
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.
ME: Where do I start?
LLM: upgrade library X to v123
Me: Library Y complains it need v120
LLM: downgrade to V120
Me: I thought we were upgrading?
LLM: upgrade Library X to v123
Me: You're repeating
LLM: Sorry I couldn't help you I'm only an LLM
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.
For a large project (with years of manpower baked in) I would expect about a day of maintenance work per year. Assuming you have good test coverage.
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.)
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?
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/
My advice is to use as few technologies in your stack as possible. Sure, your project might work best with a relational db and a dedicated document store but it might be less ongoing effort to emulate one with the other.
And freeze (or at least document) the versions of any dependencies for release. Your project runs fine with CoolTech.1.4 now but in 5 years when you come to rebuild you will find that the interface to CoolTech.6.44 is completely different.
And even then things might fail. 20+ years ago I made some Java applets that were well received and useful. Technically they still work (I think) but nobody runs Java in the browser so those projects have been unusable for years. We can be smug about our pure HTML5 static sites now but who knows what the browser landscape will be like in 2050.
Pure HTML probably has the best chance of surviving.
If you took that thought seriously you'd do HTML3 with nested tables and font tags, that stuff is going to last forever. But HN fashion says Javascript bad CSS good.
I mean, JS is pretty objectively bad. It's a great example of the "worse is better" phenomenon.
I've always had one primary side project of my own that's consumed 95% of all my time over the years, and so I've rewritten it from scratch at least 5 times as technologies (libraries, databases, languages, etc) have evolved. Not many people are lucky enough to love one app so much you'll do this, so your other side projects just die off, because they're not worth a rewrite.
Adjacent points: I also think that selecting mature projects for your dependencies matters significantly. My old couchdb or early node work is generally defunct. On the other hand, I have some dotnet projects that are still functional with zero updates from a decade or more ago.
Additionally, it's reasonable to keep a copy of your dependencies somewhere in case the vendor dies, the licensing changes, or something else catastrophic happens. Even if you just image dev's machines when they offboard. There have been a few times this has prevented permanent project death or rewrite emergencies for me.
I've now started to be more ruthless in cutting older projects that aren't going anywhere (or are not 100% automated) and I also try and consolidate new project ideas as a features to existing products.
Still its hard and everything is a balance. Some of my projects in case anyone's interested: https://www.hackyexperiments.com
Still haven't figured out which would be a good long term solution for frontend. For the moment I'll keep using Svelte which I really like but I have doubts about it's longevity.
Core functionality now relies on no libraries, and increasingly moving off Next.js towards more open frameworks like Remix.
At it's core it's React + JavaScript + SQL, aiming to run this thing for decades.
But when I think about Backbone.js, Vagrant, AngularJS, or Dojo.js, I remember thinking how lame and ugly they were and hated how popular they had become. I thought “this is it? you got function but no form.” But in the end, those projects fell into disuse and I was happy again.
JQuery is also that way, Vue used to be usable that way...
It's my favorite way to slowly add some order to legacy apps that have been overcome by jQuery soup.
I am building https://github.com/claceio/clace to try and fix this for internal tools. Go, go templates, HTMX, SQLite and Starlark is the stack. A goal is that apps should be easily maintainable after six months and after six years.