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
This is a trade-off, keeping in HTML and CSS will make some things easier but bring old problems we dont think about them no more… If not building a basic portfolio, for example a webshop, how will you do it? Stacks, frameworks etc. are born in necessity to do more, if HTML/CSS were enough nobody would use it
I kinda of agree with Steren, but i still want to use some facilitations: hugo and SASS basically solve most of the templating and CSS issued for me, but still outputs an immortal combination of html+css+sprinkles of js where needed.
I love simplicity, but i don’t want to pretend to live in 1999 :)
At the very least I need some form of templating. Even PHP can do it with an
includestatement — knowing I can edit the header in one place and have it take effect everywhere gives me peace of mind!
I look at it from the perspective of refactoring. For the first instance (or even second) of functionality, I don’t worry about adding any more complexity to the existing codebase or stack. Keep it simple and flowing.
The moment the number of instances starts to grow, refactoring properly becomes the better way to keep it simple and flowing and manageable. That may mean anything from adding a small templated snippet to adding best fit dependencies.
A good case study for website longevity would be the Space Jam website. That website will survive the heat death of the universe
I find it funny that the ad at the top of the article is on AWS Amplify, a framework of frameworks:) All in all, most frameworks are addressing specific sets of issues which have to be solved one way or another. They try to speed deployment and prevent reinventing specific wheels, and hope that many wheels will fit their mold. More of the same tradeoffs. Right now vs later. Quick vs maintainable. Each with their own balance and learning curve. And added croft to the project bulk, breaking points to troubleshoot.
Thank you for your opinion, as little as our current marketplace holds it. It’s nice to see more devs think that way.
For a lot of websites, the question of longevity doesn’t actually matters.
A lot of websites are temporary by nature, not expected to last more than a few years, or even less.
I have worked with a number of websites with a lifespan of a few months -by design-.
Even amongst longer-living platforms, it is not rare for a website to receive updates that are so impactful that the end result is, on a technical level, so different that it might as well be a new site.
For all of those, how lasting a stack can be is not something to be worried about. The tooling (or lack thereof) you use should always be adapted to the project you work on.
I like discover new technologies and use them. It’s because of that that I am a developper.