11 ms·

> If you want something to last, don't base it on something that won't last. and > I guess what I'm saying is that if you want to build a site to last 25 year

> If you want something to last, don't base it on something that won't last. and > I guess what I'm saying is that if you want to build a site to last 25 years without numerous redesigns, build a static HTML page. While simplicity is a great way to future proof things, I'm not convinced that this argument in general would work nearly as well without the benefit of hindsight. One could be forgiven for confusing it with "guess the future correctly". Plenty of relatively safe bets from 10, 20, 30 years ago haven't panned out that well. It's an interesting line of thinking though: exactly what properties of HTML make it so long lived?

untog 7y ago
I think you can generalise the advice: remove as many processing steps as you can. It's not so much that you needed to guess that HTML was going to be as long-lived as it is, it's that HTML is the final product that actually loads on the users computer, and those tend to stick around for a long time (or at least be emulated). The code that lives on a backend server somewhere, not so much. For what it's worth, I don't think this example is necessarily bulletproof: it requires a working copy of Frontpage. If Microsoft behaved more like Apple it might have been deprecated away long ago!
- btrettel 7y ago
  This is one reason why the static site generator I use for my personal website uses HTML rather than something like Markdown. I don't think Markdown is going anyway, incidentally, or that it would be hard to process on my own if I needed to. But the HTML I use is simple enough and Markdown only decreases the probability the site will last a long time.
  - dredmorbius 7y ago
    Markdown and/or markdown processors are known to change. Since there's no single Markdown spec, determining just how a page will render, or what will break, is a bit of a crapshoot. And since Markdown treats nonparsable markup as ... plain text, you don't even get errors or other indicators of failure. You've got to view and validate the output manually or by some other means. With formal tag-based markup languages (HTML, SGML, LaTeX, DocBook, etc.) you've at least got 1) an actual markup spec and 2) something that will or won't validate (though whether or not the processor actually gives a damn about that is another question, hello, HTML, I'm looking at your "The Web is an error condition": https://deirdre.net/programming-sucks-why-i-quit/ https://deirdre.net/programming-sucks-why-i-quit/) I can't find the post at the moment, but someone recently wrote a cogent rant on the fact that a change in their hosting provider (GitHub via a static site generator IIRC) had swapped out markdown processors, with changed behaviours, rendering (literally) all their previously-authored content broken. Which is indead a pain. I personally like Markdown, and find it hugely convenient. For major projects though, I suspect what I'll end up doing is starting in Markdown, and eventually switching to a more stable markup format, which probably means LaTeX (HTML has ... proved less robustly stable over the 25+ years I've worked with it). Though for simple-to-modestly-complex documents, Markdown is generally satisfactory, stable, and close enough to unadorned ASCII that fixing what breaks is not a horribly complicated task. Up to modest levels of scale, at least.
    - btrettel 7y ago
      I appreciate your reply. Seems Markdown is more complex than I recognized and this just makes me want to avoid it more. If you do find the rant you mentioned, let me know. > HTML has ... proved less robustly stable over the 25+ years I've worked with it The first website I made in 2002 still views fine in a modern browser. I didn't do anything fancy, though. I would be interested in what has been unstable as it might give me ideas on what to avoid in HTML. I don't find HTML to be that much harder than plain text or Markdown so I think I'll keep using it for smaller projects. LaTeX is worth considering as well, particularly given that I will have math on some of my webpages. One issue is that the stability of LaTeX depends strongly on which packages you use. I need to take a closer look at the health of every package I use. I think avoiding external dependencies is easier with HTML.
      - dredmorbius 7y ago
        My sense is that Markdown is probably pretty safe for most uses, particularly if you control the processing. If not, then yes, it can bite. For me that means pandoc to generate endpoints such as HTML, PDF, etc. I'm fairly confident that most of that toolchain should continue to work (provided computers and electricity exist) for another 2-4 decades. For certain more complex formatting, Markdown has limitations and features are more likely to change. But I've used Markdown to format novel-length works (from ASCII sources, for my own use) with very modest formatting needs (chapters, some italic or bold text, possibly blockquotes or lists), and it excels at that. For HTML, it's a combination of factors: - Previous features which have been dropped, most to thunderous applause. (<blink>, <marquee>, etc.) - Previous conventions which have largely been supersceded: table layouts most especially. CSS really has been ... in some respects ... a blessing. - Nagging omissions. The fact that there's no HTML-native footnoting / endnoting convention ... bothers me. You can tool that into a page. But you can't simply do something like: <p>Lorem ipsum dolor sit amet. <note>Consectetur adipiscing elit</note> Nulla malesuada, mauris ac tincidunt faucibus</p> ... and have the contents of <note> then appear by some mechanism in the rendered text. A numbered note, a typographical mark ( * † ‡ ...), a sidenote, a callout, a hovercard, say. In Markdown you accomplish this by: Lorem ipsum dolor sit amet.[^consectetur] Nulla malesuada, mauris ac tincidunt faucibus [^consectetur]: Consectetur adipiscing elit. Which then generates the HTML to create a superscript reference, and a numbered note (when generating HTML). Or footnotes according to other conventions (e.g., LaTeX / PDF) for other document formats. - Similarly, no native equation support. Maybe I'm just overly fond of footnotes and equations.... But HTML and WWW originated, literally, from the world's leading particle physics laboratory. You'd think it might include such capabilities. - Scripting and preprocessors. I remember server-side includes, there's PHP, and JS. Some browsers supported other languages -- I believe Tcl and Lua are among those that have been used. Interactivity and dependency on other moving parts reduces reliability. The expression "complexity is the enemy of reliabilty" dates to an Economist article in 1958. It remains very, very true. HTML is for me more fiddly than Markdown (though I've coded massive amounts of both by hand), so on balance, I prefer writing Markdown (it's become very nearly completely natural to me). OTOH, LaTeX isn't much more complex than HTML, and in many cases (simple paragraphs) far simpler, so if I had to make a switch, that's the direction I'd more likely go.
- bluGill 7y ago
  Google controls the major web engine. I don't trust google to not deprecate parts of html over time because the new shiny is "better". I would rather maintain markdown generators which I can update to change the markup to whatever the latest google insists needs to work instead of rewriting all my documents. I'm currently tasked with writing a UI for a machine that has a 25 year expected lifespan before wear means it is replaced. This is a real concern - think about where computers were 25 years ago and try to find something you are sure will work and look nice.
  - rubidium 7y ago
    I sure hope the UI is buttons and not screens :)
  - untog 7y ago
    Even if Google did do that (which they’ve shown no signs of, and they are still far from a browser monopoly when you look at iPhone etc) it wouldn’t stop HTML from being read. Translating from HTML -> GoogleHTML wouldn’t be meaningfully different to translating it from Markdown.
    - trilliumbaker 7y ago
      It could be argued that AMP was that attempt, and the only reason AMP gained tractions was Google started using it in the carousel of their SERPs. While Safari, when mobile is included, has ~17% of the market, that's not enough when you combine Google's browser share along with their search engine share.
  - trilliumbaker 7y ago
    Google wields too much power. To an extent, they can dictate to website owners what HTML is allowed and not allowed thanks to their dominance in search. This is compounded by the fact that their browser marketshare via Chrome and now Microsoft Edge basically allows them to do what they want with HTML. Matters are even worse. Last year, the W3C became the "yes-man" of Google. They decided to stop developing the HTML standards and just start rubber stamping whatever WHATWG produces. WHATWG is run by Apple, Google, Microsoft, and Mozilla. And who has the most power in that relationship? Yep, Google.
8lall0 7y ago
I think that the right way to rephrase that is "use the right tool for the right job". How many blogs are powered by wordpress? How many of them can be replaced with a static gen? HTML has a lot of garbage, but at least it's very hard to break it.
- stevenicr 7y ago
  Your comment merges well with one slightly above from TheFlyingFish, It's that browsers pretty good at displaying stuff even when html is not to spec. and really it's that everyone uses browsers that still display text and such on the screen even if it's broken in several places. This could change if google decided to stop showing pages with broken html - like them killing flash big cuts at a time. I have turned several worpress based sites into static html with one of the static html making plugins - and that turned those tools into the right ones for those jobs. I think most WP sites can be converted and be just fine, most people don't add new posts to them regularly from what I've seen.
theandrewbailey 7y ago
> It's an interesting line of thinking though: exactly what properties of HTML make it so long lived? I've thought about this on and off for a few years. Here's what I've come up with: 1. Popularity. You can't really display anything in a web browser without it, blank pages with one AJAX script notwithstanding. 2. Ease of use. Open a text editor, type some markup, save the file with .html, and open in a browser. When you're done, transfer to a server to show the world. That's a pretty straightforward process. 3. Well-defined, open standard. Every important piece of the web is defined, from the markup to the protocol to transfer it. I think that reasonably bug-free implementations of those standards help.
- dredmorbius 7y ago
  I'd argue your #3 is wide of the mark. It's not that there's a well-defined open standard. It's that browsers will eat any old crap that's thrown at them and turn it into something plausible, if not precisely what the author intended or reader really wants. Yes, there's a standard, and yes it's open. It's observed far more in the breach, as a few minutes with a validator on well-known sites will demonstrate. Your comment alone (prior to my response to it) returns: Tidy found 21 warnings and 0 errors!
  - TheFlyingFish 7y ago
    >It's that browsers will eat any old crap that's thrown at them and turn it into something plausible, if not precisely what the author intended or reader really wants. Reminds me of the fairly prescient "In Praise of Evolvable Systems" essay from 1996: https://web.archive.org/web/20190409041249/http://www.shirky.com/writings/evolve.html https://web.archive.org/web/20190409041249/http://www.shirky...
  - benibela 7y ago
    Even worse, the browsers could not handle standard html. HTML was based on SGML and it has all the nice SGML features. Something like <title/Hello World/ was valid HTML afair. But then the browser never implemented it properly, so html5 just describes the behaviour of the browsers.
bitexploder 7y ago
My text files still work. I have MUD design documents from when I was in high school (mid to late 90s). Org mode and Markdown are kind of eternal formats. Even if all the tooling dies, they still look decent. Basic HTML still works well enough as well. You can write a parser for XML pretty easily. HTML can also be processed and rendered trivially. I think we could collectively find some other technologies that are likely to be around in another 20 years. The simpler the file format the more likely it is to be around :) edit: A few more popped into my head. CSV. SQL schema + Data dumps (text format). The common theme to everything here is plain text. SQLite, although binary, is probably close to eternal. Git is eternal enough (recent HN post showed even POSIX shell is good enough to write a basic git client). JSON is easy to write a parser for as well. YAML.
_jal 7y ago
It is exactly the "guess the future" problem that static sites avoid. The vast bulk of software goes unsupported in less than 25 years. If you want to depend on something that long, you can guess which package will survive that long, or you can store your data in formats that the widest array of tooling supports. If you drop into a coma after uploading your static HTML and wake up in 25 years, you might have to use whatever fills the text-manipulation-scripting niche then to beat it into the right shape to import into whatever kids these days are using. If you used Wordpress, well, maybe it takes over the world, maybe it ends up a Wikipedia entry. (Putting aside, of course, that your site began hosting cryptominers a week after you slipped into that coma because you missed an update.)
bentcorner 7y ago
> exactly what properties of HTML make it so long lived? I think we're thinking about this backwards. It's not anything inherent to HTML that make it long lived, it's that the code to parse static HTML is simple, it's more or less standardized and has stuck around for a long time.

untog 7y ago

I think you can generalise the advice: remove as many processing steps as you can. It's not so much that you needed to guess that HTML was going to be as long-lived as it is, it's that HTML is the final product that actually loads on the users computer, and those tend to stick around for a long time (or at least be emulated). The code that lives on a backend server somewhere, not so much. For what it's worth, I don't think this example is necessarily bulletproof: it requires a working copy of Frontpage. If Microsoft behaved more like Apple it might have been deprecated away long ago!

btrettel 7y ago
This is one reason why the static site generator I use for my personal website uses HTML rather than something like Markdown. I don't think Markdown is going anyway, incidentally, or that it would be hard to process on my own if I needed to. But the HTML I use is simple enough and Markdown only decreases the probability the site will last a long time.
- dredmorbius 7y ago
  Markdown and/or markdown processors are known to change. Since there's no single Markdown spec, determining just how a page will render, or what will break, is a bit of a crapshoot. And since Markdown treats nonparsable markup as ... plain text, you don't even get errors or other indicators of failure. You've got to view and validate the output manually or by some other means. With formal tag-based markup languages (HTML, SGML, LaTeX, DocBook, etc.) you've at least got 1) an actual markup spec and 2) something that will or won't validate (though whether or not the processor actually gives a damn about that is another question, hello, HTML, I'm looking at your "The Web is an error condition": https://deirdre.net/programming-sucks-why-i-quit/ https://deirdre.net/programming-sucks-why-i-quit/) I can't find the post at the moment, but someone recently wrote a cogent rant on the fact that a change in their hosting provider (GitHub via a static site generator IIRC) had swapped out markdown processors, with changed behaviours, rendering (literally) all their previously-authored content broken. Which is indead a pain. I personally like Markdown, and find it hugely convenient. For major projects though, I suspect what I'll end up doing is starting in Markdown, and eventually switching to a more stable markup format, which probably means LaTeX (HTML has ... proved less robustly stable over the 25+ years I've worked with it). Though for simple-to-modestly-complex documents, Markdown is generally satisfactory, stable, and close enough to unadorned ASCII that fixing what breaks is not a horribly complicated task. Up to modest levels of scale, at least.
  - btrettel 7y ago
    I appreciate your reply. Seems Markdown is more complex than I recognized and this just makes me want to avoid it more. If you do find the rant you mentioned, let me know. > HTML has ... proved less robustly stable over the 25+ years I've worked with it The first website I made in 2002 still views fine in a modern browser. I didn't do anything fancy, though. I would be interested in what has been unstable as it might give me ideas on what to avoid in HTML. I don't find HTML to be that much harder than plain text or Markdown so I think I'll keep using it for smaller projects. LaTeX is worth considering as well, particularly given that I will have math on some of my webpages. One issue is that the stability of LaTeX depends strongly on which packages you use. I need to take a closer look at the health of every package I use. I think avoiding external dependencies is easier with HTML.
    - dredmorbius 7y ago
      My sense is that Markdown is probably pretty safe for most uses, particularly if you control the processing. If not, then yes, it can bite. For me that means pandoc to generate endpoints such as HTML, PDF, etc. I'm fairly confident that most of that toolchain should continue to work (provided computers and electricity exist) for another 2-4 decades. For certain more complex formatting, Markdown has limitations and features are more likely to change. But I've used Markdown to format novel-length works (from ASCII sources, for my own use) with very modest formatting needs (chapters, some italic or bold text, possibly blockquotes or lists), and it excels at that. For HTML, it's a combination of factors: - Previous features which have been dropped, most to thunderous applause. (<blink>, <marquee>, etc.) - Previous conventions which have largely been supersceded: table layouts most especially. CSS really has been ... in some respects ... a blessing. - Nagging omissions. The fact that there's no HTML-native footnoting / endnoting convention ... bothers me. You can tool that into a page. But you can't simply do something like: <p>Lorem ipsum dolor sit amet. <note>Consectetur adipiscing elit</note> Nulla malesuada, mauris ac tincidunt faucibus</p> ... and have the contents of <note> then appear by some mechanism in the rendered text. A numbered note, a typographical mark ( * † ‡ ...), a sidenote, a callout, a hovercard, say. In Markdown you accomplish this by: Lorem ipsum dolor sit amet.[^consectetur] Nulla malesuada, mauris ac tincidunt faucibus [^consectetur]: Consectetur adipiscing elit. Which then generates the HTML to create a superscript reference, and a numbered note (when generating HTML). Or footnotes according to other conventions (e.g., LaTeX / PDF) for other document formats. - Similarly, no native equation support. Maybe I'm just overly fond of footnotes and equations.... But HTML and WWW originated, literally, from the world's leading particle physics laboratory. You'd think it might include such capabilities. - Scripting and preprocessors. I remember server-side includes, there's PHP, and JS. Some browsers supported other languages -- I believe Tcl and Lua are among those that have been used. Interactivity and dependency on other moving parts reduces reliability. The expression "complexity is the enemy of reliabilty" dates to an Economist article in 1958. It remains very, very true. HTML is for me more fiddly than Markdown (though I've coded massive amounts of both by hand), so on balance, I prefer writing Markdown (it's become very nearly completely natural to me). OTOH, LaTeX isn't much more complex than HTML, and in many cases (simple paragraphs) far simpler, so if I had to make a switch, that's the direction I'd more likely go.
bluGill 7y ago
Google controls the major web engine. I don't trust google to not deprecate parts of html over time because the new shiny is "better". I would rather maintain markdown generators which I can update to change the markup to whatever the latest google insists needs to work instead of rewriting all my documents. I'm currently tasked with writing a UI for a machine that has a 25 year expected lifespan before wear means it is replaced. This is a real concern - think about where computers were 25 years ago and try to find something you are sure will work and look nice.
- rubidium 7y ago
  I sure hope the UI is buttons and not screens :)
- untog 7y ago
  Even if Google did do that (which they’ve shown no signs of, and they are still far from a browser monopoly when you look at iPhone etc) it wouldn’t stop HTML from being read. Translating from HTML -> GoogleHTML wouldn’t be meaningfully different to translating it from Markdown.
  - trilliumbaker 7y ago
    It could be argued that AMP was that attempt, and the only reason AMP gained tractions was Google started using it in the carousel of their SERPs. While Safari, when mobile is included, has ~17% of the market, that's not enough when you combine Google's browser share along with their search engine share.
- trilliumbaker 7y ago
  Google wields too much power. To an extent, they can dictate to website owners what HTML is allowed and not allowed thanks to their dominance in search. This is compounded by the fact that their browser marketshare via Chrome and now Microsoft Edge basically allows them to do what they want with HTML. Matters are even worse. Last year, the W3C became the "yes-man" of Google. They decided to stop developing the HTML standards and just start rubber stamping whatever WHATWG produces. WHATWG is run by Apple, Google, Microsoft, and Mozilla. And who has the most power in that relationship? Yep, Google.

8lall0 7y ago

I think that the right way to rephrase that is "use the right tool for the right job". How many blogs are powered by wordpress? How many of them can be replaced with a static gen? HTML has a lot of garbage, but at least it's very hard to break it.

stevenicr 7y ago
Your comment merges well with one slightly above from TheFlyingFish, It's that browsers pretty good at displaying stuff even when html is not to spec. and really it's that everyone uses browsers that still display text and such on the screen even if it's broken in several places. This could change if google decided to stop showing pages with broken html - like them killing flash big cuts at a time. I have turned several worpress based sites into static html with one of the static html making plugins - and that turned those tools into the right ones for those jobs. I think most WP sites can be converted and be just fine, most people don't add new posts to them regularly from what I've seen.

theandrewbailey 7y ago

> It's an interesting line of thinking though: exactly what properties of HTML make it so long lived? I've thought about this on and off for a few years. Here's what I've come up with: 1. Popularity. You can't really display anything in a web browser without it, blank pages with one AJAX script notwithstanding. 2. Ease of use. Open a text editor, type some markup, save the file with .html, and open in a browser. When you're done, transfer to a server to show the world. That's a pretty straightforward process. 3. Well-defined, open standard. Every important piece of the web is defined, from the markup to the protocol to transfer it. I think that reasonably bug-free implementations of those standards help.

dredmorbius 7y ago
I'd argue your #3 is wide of the mark. It's not that there's a well-defined open standard. It's that browsers will eat any old crap that's thrown at them and turn it into something plausible, if not precisely what the author intended or reader really wants. Yes, there's a standard, and yes it's open. It's observed far more in the breach, as a few minutes with a validator on well-known sites will demonstrate. Your comment alone (prior to my response to it) returns: Tidy found 21 warnings and 0 errors!
- TheFlyingFish 7y ago
  >It's that browsers will eat any old crap that's thrown at them and turn it into something plausible, if not precisely what the author intended or reader really wants. Reminds me of the fairly prescient "In Praise of Evolvable Systems" essay from 1996: https://web.archive.org/web/20190409041249/http://www.shirky.com/writings/evolve.html https://web.archive.org/web/20190409041249/http://www.shirky...
- benibela 7y ago
  Even worse, the browsers could not handle standard html. HTML was based on SGML and it has all the nice SGML features. Something like <title/Hello World/ was valid HTML afair. But then the browser never implemented it properly, so html5 just describes the behaviour of the browsers.

bitexploder 7y ago

My text files still work. I have MUD design documents from when I was in high school (mid to late 90s). Org mode and Markdown are kind of eternal formats. Even if all the tooling dies, they still look decent. Basic HTML still works well enough as well. You can write a parser for XML pretty easily. HTML can also be processed and rendered trivially. I think we could collectively find some other technologies that are likely to be around in another 20 years. The simpler the file format the more likely it is to be around :) edit: A few more popped into my head. CSV. SQL schema + Data dumps (text format). The common theme to everything here is plain text. SQLite, although binary, is probably close to eternal. Git is eternal enough (recent HN post showed even POSIX shell is good enough to write a basic git client). JSON is easy to write a parser for as well. YAML.

_jal 7y ago

It is exactly the "guess the future" problem that static sites avoid. The vast bulk of software goes unsupported in less than 25 years. If you want to depend on something that long, you can guess which package will survive that long, or you can store your data in formats that the widest array of tooling supports. If you drop into a coma after uploading your static HTML and wake up in 25 years, you might have to use whatever fills the text-manipulation-scripting niche then to beat it into the right shape to import into whatever kids these days are using. If you used Wordpress, well, maybe it takes over the world, maybe it ends up a Wikipedia entry. (Putting aside, of course, that your site began hosting cryptominers a week after you slipped into that coma because you missed an update.)

bentcorner 7y ago

> exactly what properties of HTML make it so long lived? I think we're thinking about this backwards. It's not anything inherent to HTML that make it long lived, it's that the code to parse static HTML is simple, it's more or less standardized and has stuck around for a long time.