Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This Page is Designed to Last

jeffhuang.com

Post reply on HN
Print view View original

181–190 of 458 posts

Re: This Page is Designed to Last

#181

Post by ljosa »

jerezzprime wrote: post #160

I'm confused about the widely held opinion that it is paramount that all web content persist for infinity. That seems parallel to someone expecting my personal handwritten journal to be archived and available to all of future humanity. I'm not convinced that is a positive thing, nor is it a necessary thing. How egotistical do you need to be to think that your personal blog is worth persisting forever?

TFA is written from a reader's perspective: the author had found a bunch of links important enough to bookmark, and then most of them disappeared.

Re: This Page is Designed to Last

#182

Post by iwalton3 »

rodw wrote: post #179

I think this article is excellent, but one small nit: isn't it contradictory to say don't minimize HTML but do minimize SVG? The justification in the HTML case is that "view source is good" and "it's compressed over the wire anyway". Don't those arguments apply equally (or nearly equally) well to SVG?

Programs such as Inkscape put a lot of extra information into SVG files that is not actually needed for them to render. File size reductions with SVG minifiers can be significant. For instance, the applications-internet.svg icon goes from 31K to 9K when compressing it with svgo.

Re: This Page is Designed to Last

#183

Post by setr »

rodw wrote: post #179

I think this article is excellent, but one small nit: isn't it contradictory to say don't minimize HTML but do minimize SVG? The justification in the HTML case is that "view source is good" and "it's compressed over the wire anyway". Don't those arguments apply equally (or nearly equally) well to SVG?

I've never looked into svg specifically but I would assume that even if it's xml, it's generally far from reasonably human readable/editable, in which case you're not losing the properties by minimizing. Unreadable -> more unreadable is much less significant than readable -> unreadable

Re: This Page is Designed to Last

#184

Post by nrp »

rodw wrote: post #179

I think this article is excellent, but one small nit: isn't it contradictory to say don't minimize HTML but do minimize SVG? The justification in the HTML case is that "view source is good" and "it's compressed over the wire anyway". Don't those arguments apply equally (or nearly equally) well to SVG?

I think the argument is that HTML can and should be human readable and editable, while you really need a tool to meaningfully create and edit SVGs anyway, so minifying isn’t a loss.

Re: This Page is Designed to Last

#185

Post by rodw »

est31 wrote: post #49
mark242 wrote: post #14

I fundamentally agree with the principle -- that pages should be designed to survive a long time -- however the steps the author lays out I completely disagree with. "The more libraries incorporated into the website, the more fragile it becomes" is just fundamentally untrue in a world where you're self-hosting all of your scripts. "Prefer one page over several" is diametrically opposed to the hypertext model. Please…

> "The more libraries incorporated into the website, the more fragile it becomes" is just fundamentally untrue in a world where you're self-hosting all of your scripts. There are more problems though. older library versions might be vulnerable to XSS attacks, or use features removed by browsers in the future for security reasons (eval?). Or you might want to change something involving how you use the API but the docs…

Also unless you're very diligent about semantic markup and separation of content, presentation, interaction logic, the more complicated s site is the more difficult it is to port.

I have run into this problem trying to migrate very old web pages or blog posts off of SaaS sites that are shutting down or just decaying. It's not just that complicated sites make it difficult to extract the content in the first place; it's difficult to publish that content on another site in a high-fidelity, and sometimes even readable, way.

The hard part isn't keeping the old site (page) running (although that's not always easy either). The hard part is when you want to do something _else_ with that content -- more complicated means less (easily) flexible.

Re: This Page is Designed to Last

#186

Post by tyzerdak »

I don't get about Prefer one page over several.

Anyway some points seems reasonable but I bet most people will use wordpress and when they are not interested they will abandon it and it's gone.

Imo better force web archive to make more archives and donate it or smth.

Re: This Page is Designed to Last

#187

Post by berbec »

filereaper wrote: post #167
winfred wrote: post #135

Earlier quoted context omitted.

>Let's be honest with ourselves. The best way to make your content last for a long time is to host it on a platform that is free and very successful. For example, whatever photos I posted on Facebook 12 years ago? Still alive and kicking. The articles I've published on wordpress.com 7 years ago? Still in mint condition, with 0 maintenance required. You view on timeline is too short. We're not talking about keeping so…

Clearly the only reasonable way is to store it in a Mainframe...in EBCDIC It'll live forever... /s

Never underestimate the bandwidth of a station wagon full of punch cards.

Re: This Page is Designed to Last

#188

Post by rodw »

incompatible wrote: post #166
Normal_gaussian wrote: post #159

Earlier quoted context omitted.

I've outlived and outhosted all of the third party hosts I've used.

I guess you can last 10 years, which is apparently what "This Page is Designed to Last" aspires to, but what if we have greater ambitions? Like 100 years?

Then I think you need something like archive.org.

You can design and mark-up content that will still be useful and readable in 100 years. You might be able to preserve the presentation logic (CSS-style) for 100 years.

You probably won't be able to preserve the interaction design for 100 years (without a dedicated effort -- that's why they bury computers along with the software in time capsules).

But I think it is optimistic to think that _most_ SasS hosts are going to archive content for 100 years. Preserving digital content is an _active_ process. It takes resources and requires deliberate effort.

Postscript: I'm trying to think of modern companies that would preserve content for 100 years, assuming they make it that for.

Facebook is the only significant current platform that I can even imagine preserving content for 100 years, but even that seems like s stretch. Historians might step in to archive it, but is there real value to Facebook to maintain and publish 50 year old comments on 2.5 billion unremarkable walls?

Twitter won't. Certainly Insta, SnapChat, WhatsApp etc. won't. Flickr probably could do it relatively easily but won't. YouTube maybe, but there's more to store. Something like GitHub maybe?

Re: This Page is Designed to Last

#189

Post by chrismorgan »

nrp wrote: post #184
rodw wrote: post #179

I think this article is excellent, but one small nit: isn't it contradictory to say don't minimize HTML but do minimize SVG? The justification in the HTML case is that "view source is good" and "it's compressed over the wire anyway". Don't those arguments apply equally (or nearly equally) well to SVG?

I think the argument is that HTML can and should be human readable and editable, while you really need a tool to meaningfully create and edit SVGs anyway, so minifying isn’t a loss.

Depends on the SVG. I regularly hand-write SVG diagrams. But I won’t claim to be normal!

Re: This Page is Designed to Last

#190

Post by rodw »

setr wrote: post #183
rodw wrote: post #179

I think this article is excellent, but one small nit: isn't it contradictory to say don't minimize HTML but do minimize SVG? The justification in the HTML case is that "view source is good" and "it's compressed over the wire anyway". Don't those arguments apply equally (or nearly equally) well to SVG?

I've never looked into svg specifically but I would assume that even if it's xml, it's generally far from reasonably human readable/editable, in which case you're not losing the properties by minimizing. Unreadable -> more unreadable is much less significant than readable -> unreadable

That's why I hedged a bit. SVG is certainly less readable, but it can be human readable if not aggressively minimized.

I've both created and modified SVG documents by hand with a text editor, and also view-sourced SVGs to see how they work.

The only thing that is especially unreadable are the long strings of coordinates that make up paths, and even those can be manageable with comments. No one does complex paths by hand, but the rest is colors, shapes, transforms -- all things you can read and may want to modify.

Post reply on HN