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 really even trying to unseat them. The closest threats are native platforms, but those are so fractured, closed, while lacking the worldwide utility of the URL and open standards, that it doesn’t look like that 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.
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 still other tooling to get there. No build process either. No templating. Need to update the navigation?
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 nabs it
The post Tech Stacks and Website Longevity appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
source https://css-tricks.com/tech-stacks-and-website-longevity/
No comments:
Post a Comment