Steren Giannini in “My stack will outlive yours”:
My stack requires no maintenance, has perfect Lighthouse scores, will never have any security vulnerability, is based on open standards, is portable, has an instant dev loop, has no build step and… will outlive any other stack.
Jeremy Keith in “npm ruin dev”:
Instead of reaching for all-singing all-dancing toolchain by default, I’m going to start with a boring baseline. If and when that becomes too painful or unwieldy, then I’ll throw in a task manager. But every time I add a dependency, I’ll be limiting the lifespan of the project.
I like both of those sentiments.
Steren’s “stack” is HTML and CSS only. Will HTML and CSS “last” in the sense of that website being online and working for a long time. I’d say certainly yes. HTML and CSS were around before I got here, are actively developed, and no other technologies are even trying to unseat them. The closest threats are native platforms, but those are so fractured, closed, and lack the worldwide utility of the URL, that it doesn’t seem likely any native platform will unseat the web. It’s more likely (and we see this happening, even if it’s slow and fraught) that native platforms embrace the web instead.
Will an HTML and CSS website be perfectly functional in, say, 2041? I’d say certainly. I’ll bet ya a dollar.
Steren doesn’t mean that HTML and CSS is just the output, but there is also no tooling at all. No build process. No templating. Here’s what he says about updating something common like navigation across pages:
So… if I don’t use any templating system, how do I update my header, footer or nav? Well, simply by using the “Replace in files” feature of any good text editor. They don’t need frequent updates anyway. The benefits of using a templating system is not worth the cost of introducing the tooling it requires.
I admit this is drawing the line further back than I would. This feels just like trading one kind of technical debt for another. Now you’ll need to write scripts or an elaborate find-and-replace RegEx to do what you want to do, rather than reach for some form of HTML include, which there are a ton of ways to handle lightly.
But I get it. Especially since once you do add that one templating language (or whatever), the temptation is strong to keep adding to the system, introducing more and more liabilities with less consideration on how they may be “limiting the lifespan” of the project.
I don’t actually think the stack matters that much.
In thinking about sites I work on (and have worked on), the longevity of the site doesn’t feel particularly related to the stack. Like, at all. The sites with the longest lifespans (like this one) have long lifespans because I care about them, and they have all sorts of moving parts in the stack.
I pick technology to help with what I want to do. If my needs change, I change the technology. I don’t just say, ooops, my stack is off, I guess I’ll shut down the website forever.
If we’re talking about website longevity, I think the breakdown of how much things matter is more like this:
- 80% How much I care about the website
- 10% The website isn’t a financial burden
- 5% The website isn’t a mental burden (“the stack” being some small part of this)
- 5% I have access to the registrant and didn’t forget to renew the domain name before a squatter nabbed it
The post Tech Stacks and Website Longevity appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
