Live data from Hacker News

This Page is Designed to Last

jeffhuang.com

51–60 of 458 posts

Re: This Page is Designed to Last

#51
I was thinking about this exact subject matter the other day. We invest so much time in our digital content but what happens with death? How long can we really expect our content to last?

Ultimately we are all dependent on the functionality of the internet and making a physical copy is the best way to make something last. However if we intend to not only have it last but be accessible, some of the suggestions are helpful but the most significant is: where can I host something indefinitely?

Will Netlify, Github Pages, AWS, etc all be around in 50 years? 100 years? 500 years? Heck, the internet hasn't even been around for all that long.

As I write this, my only thought is that you need a system of fallbacks. Frankly, this seems like a business opportunity in which the cost of the infrastructure is purchased based on some formula. DNS is configured programmatically. File locations are distributed and redundant. I'm not sure what the best approach is but one thing is certain: the page accessibility is the least of this author's issues. He just needs the site to be hosted...

Re: This Page is Designed to Last

#53

I do believe that, usually, you should make it possible to be archived. (In one of a few cases where it isn't, consider if HTTP(S) is even the correct protocol for what you are doing; sometimes it isn't.) I agree that you can (almost always) write HTML without JavaScript codes (CSS is not always needed either, but nevertheless it can be helpful). This improves portability too. If you do want to use JavaScript to gene…

Regarding fonts, I think it's good practice to archive fonts together with your site's source, if the site relies on third party resources, like Google Fonts. (Switching the link target should be easy. Embedding a commented link to a stylesheet linking to these local resources along with the third party resource link may be of help.)

Re: This Page is Designed to Last

#55
HMTL was a bad idea that just kept sprouting cancerous growths on top of itself. Just like the author recommends not using non-web fonts, we honestly don't need much markup beyond "monospace", "em", "strong", "title 1-5", and "p". Everything else HTML does is a huge distraction.

In the past thirty years, there have only been a few actual kinds of content:

- Article

- Comment

- Reference manual

Nothing really deviates from this. If it does, then it's probably in the "application" domain and deserves all that javascript stuff.

I imagine a new semantic web inspired content type that bakes in permanent content URLs, author signatures, and supports sharing P2P and rich archival:

   
     
       (Computed immutable content hash and signature. Subsequent revisions
        will invalidate this and require new content hashes. Links can be made
        to the old version.)
     
     
       (metadata, homepage, public key)
     
     
        Semantic Web was actually brilliant 
        
         The Web was Embraced, Extended, and Extinguished
         

Lorem ipsum dolor sit amet...

It can be a really simple model. No divs or presentational CSS or anything. (Well, maybe some support for LaTeX and I18N.) The client decides how it looks, which is how it always should have been.

If every entity in the universe has an ID, they can link to each other in a distributed fashion. It won't matter if the original source URL goes down as long as someone somewhere has a cache.

It's also probably better to binary encode these (protobuf or something). Images and media could be inlined instead of href'd.

Instead of building on the layer cake, we should take a moment to reflect on what we're trying to do. We have a lot of history and bad evolution that we can garbage collect and streamline.

If our objective is to publish and share content, a lightweight version of the semantic web is the way to go.

Oh, and check out my follow-up to the author:

   
      (my own post's content hash) 
      (the author I'm responding to) 
      me 
     
       Hey you! I disagree!
     
   
Again, these can be distributed on a web. It can be p2p, federated, or live atop the classical WWW. It doesn't matter. The clients can richly use the semantic data model.

The anger for disappearing content, walled gardens, and AMP will eventually reach a boil. As technologies go, the pendulum is always swinging. This is the direction we'll eventually head back to.

Re: This Page is Designed to Last

#57
post #50

Earlier quoted context omitted.

I mean, it's not any worse than WARC support…

Maybe MAFF's are best as they use compression instead of base64 encoding: https://en.wikipedia.org/wiki/Mozilla_Archive_Format

Or SingleFileZ files which can be viewed without installing any extension https://github.com/gildas-lormeau/SingleFileZ.

Edit: it can also auto-save pages, like SingleFile.

Re: This Page is Designed to Last

#58
Make sure that archive.org - the Internet Archive - catches your website in "The Wayback Machine". Catering to that is a pretty good strategy for archiving for at least the next couple of decades, considering that institute's staying power.

And on that note - consider donating to them.

Re: This Page is Designed to Last

#59
post #16

Earlier quoted context omitted.

It's not entirely wrong, if the page is held static but the browser continues to be upgraded. If you're worried about fonts changing out from under a site you should surely also be worried about bitrot in, say, jQuery.

Or not bitrot, but ever-changing browser APIs.

When was the last browser change that broke things like simple news websites????

Re: This Page is Designed to Last

#60

I find it an interesting social phenomenon that the finite nature of content on the Web is lamented, when content has been temporal for all of human history.

And a concern for a long time as well. Witness the Dead Sea scrolls, the many things literally carved into stone, etc.
Post reply on HN