I agree with the author, and I think it mostly comes down to the original article author being young and not really having much perspective on the reliability,

I agree with the author, and I think it mostly comes down to the original article author being young and not really having much perspective on the reliability, stability and backwards-compatibility of HTML/CSS/HTTP and traditional file servers over time. The fact that you can pick up an HTML file from 1993, trivially drop it on any type of web host, and have it be accessible on any browser on any platform more or less exactly as it looked then is not to be underestimated. Compiling and running any source code from 1993 that hasn't seen maintenance since then is going to range from slightly annoying to a monumental effort requiring essentially a full rewrite. This is exemplified by this comment: > There have now been a significant number of attempts to "platformitize" dynamic computation — "serverless" programming like AWS Lambda, WASM runtimes like those provided by CloudFlare and Fastly, full container deployment via Fly.io and cloud providers. None of these have an API nearly as stable as the filesystem API used to host static files, but it's a matter of time before APIs end up well-established. Containers and WASM are certainly interesting vectors of standardization, but even if everything goes fully to plan by the most bullish proponents, you still have a much more complex environment where incentives to break backwards compatibility make it exceedingly unlikely that you'll be able to just grab a container and WASM binary and drop them into any commodity host 30 years from now. Of course HTML/CSS rendering could break too, but incentives are skewed more in favor backwards compatibility. Also, because it's just a simple, human-readable file format, slight breakage doesn't render the archive useless. Heck, even the destruction of the internet and all servers doesn't render the file useless—you just need to be able to decode ASCII/UTF-8 to extract value. I think a better thesis for the original author would have been that static site generators are not necessarily simpler than dynamic sites generated at request time. I agree with that wholeheartedly, but the beauty of the SSG is that if at any time I want to stop maintaining the code, I have a ready-made servable version of the site that is trivially archivable in perpetuity. Standardized data formats expressed in simple files will always be more durable than code.