Thoughts on the Resiliency of Web Projects

The one thing I learned from running https://www.gnod.com (20 years) and https://www.productchart.com (10 years):

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.

This is a problem for any project, and yet another reason to prefer static files for as much as your stack as possible and do not follow the latest tech-stack trends too closely. It is called the bleeding edge because it is covered in the blood of dead projects that cannot be maintained.

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.

This happens to every developer once we get over like 20yrs experience doing side projects. Invariably the dependencies and technologies of any app become obsolete over time, and you either do a massive rewrite or else give it up.

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.

I generally agree with the thesis here.

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 have more than 50 projects and find myself often bogged down by fixes and updates. This can creep up on you. Going back to older code bases (even ones you wrote) can be daunting and annoying. One customer email can ruin the whole day. AI has definitely made this easier but it's still challenging.

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

One of my production web-based projects managing critical transit data hit the 12 year mark. It was based on straight HTML/CSS, plain Javascript, Knockout.js (yeah, this was before ReactJS and friends), JQuery, Bootstrap CSS, and with a Play Java backend on Centos Linux against a Oracle 11 DB. It needed minimal maintenance and updates, only when the spec versions changed. It has reached its end of rope when it failed the new security audit in that the software versions being too old, i.e. Oracle, Linux and JDK being too old. The customer comes up with the funding to do a rewrite rather than spending the money in retrofitting the old code. You bet one of the main goals of the new tech stack is reducing 3rd party dependencies and choosing dependencies carefully.

That's one of the reasons I'm starting to move away from JS on the server and instead use dotnet. It's super mature and you can build something with close to zero deps. You can be certain it will still be there 10 years from now. The performance (7-10x better than JS) is the cherry on top.

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.

I've been running a project for almost four years now, and have been vendoring/killing as many dependencies as I can.

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.

this post is great, my mental flowchart is similar to this. Content like this reminds me of this post https://sive.rs/plaintext

Something that has worked for me, and I don’t know how to describe it any other way, is that some projects have “style.” Like I thought Docker, React, jQuery were actually cool when they came out. Elegant, pretty, fun to use and I could see the future for them.

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.

This is an issue I have had with web projects, especially for internal tools. Without constant maintenance, they reach a state where new changes cannot be done easily.

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.

This comment section has been extremely valuable. Htmx for the win?