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

371–380 of 458 posts

Re: This Page is Designed to Last

#371

Post by whack »

winfred wrote: post #135
whack wrote: post #124

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. In comparison, the websites that I've built and hosted or deployed mys…

>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…

> The question is, is wordpress going to be around in 70 years? No one knows. But that static HTML page will still render fine

The question isn't whether wordpress will be around in 70 years, but whether it will outlast your self-hosted website. Anything that is self-hosted requires significantly more financial/logistical maintenance, and what is the likelihood of someone continuing to do that for 70 years?

Re: This Page is Designed to Last

#372

Post by BiteCode_dev »

asdasdasdasdwd wrote: post #370
BiteCode_dev wrote: post #320

Earlier quoted context omitted.

I like the idea, but wanted to know how realistic it would be so I made a quick and dirty Python script to download all my bookmarks. If you want to make the same experiment, you can get it from here: https://gist.github.com/ksamuel/fb3af1345626cb66c474f38d8f03... It requires Python 3.8 (just the stdlib) and wget. I have 3633 bookmarks, for a total of 1.5 Go unziped, 1.0 Go zipped (and we know we can get more from be…

> definitely something I wish mozilla would consider There used to be this neat little extension called Read It Later that let you do just that. Bookmark and save it so you could read it when you were offline or the page disappeared. Later they changed their name and much later Mozilla bought it and added it to Firefox without a way to opt out. It was renamed to Pocket.

Pocket is not integrated with your bookmarks. For offline consultation, you need a separate app. Of course this app is not available on Linux, where you have to get some community provided tools.

Bookmark integration would mean one software, with the same UI, on every platform, and only one listing for your whole archive system.

Re: This Page is Designed to Last

#373

Post by Pigo »

epicide wrote: post #362
Pigo wrote: post #347

> We can avoid jquery and bootstrap Amen to that at least. Nothing bums me out more than someone using jquery just for a simple DOM selection, or having a simple layout and using bootstrap just because you know their columns.

For those that just want to do DOM selection, querySelector(All) is widely supported at this point. If you want a simple CSS framework (because you don't want to write CSS) that includes a grid system, Milligram is a useful alternative.

I haven't seen Milligram yet, I'll check that out.

I've seen people include the full jquery just to select something by ID. But I guess it's hardly my worst horror story.

Re: This Page is Designed to Last

#374

Post by sudo_rm »

majewsky wrote: post #357
joshspankit wrote: post #340

I would actually shift this quite a bit to say if you’re designing your page to last 10 years, put it on the internet archive on day 1. Invite them to crawl it, verify the crawl was successful, and even talk about that link on your page . It removes the risk of domain hijacking, hosting platforms shuttering, and the author losing interest. P.s. The internet archive is doing excellent work. Support them.

And as you give a content donation, please also consider a monetary donation to keep the lights on at the Internet Archive: https://archive.org/donate/

I started a recurring donation through your link. Thanks for posting this.

Re: This Page is Designed to Last

#375

Post by larrywright »

majewsky wrote: post #361
larrywright wrote: post #335

Earlier quoted context omitted.

This is the advantage to Evernote. Since it’s a browser extension, it has access to anything you have access to.

The downside is, since it’s a browser extension, it has access to anything you have access to.

Agreed that there’s a tradeoff. I don’t think there’s really an alternative solution though.

Re: This Page is Designed to Last

#376

Post by madacol »

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.

What's the problem with prettifying algorithms?

Re: This Page is Designed to Last

#377

Post by rsync »

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…

""Prefer one page over several" is diametrically opposed to the hypertext model. Please don't do this."

I think I agree with you here, in that much of the power of hypertext lies in the hierarchical "tree" model.

And yet, I think it has not been used properly up to this point ...

I hesitate to post this as this is not quite finished[1], but here goes - this is something called an "Iceberg Article":

http://john.kozubik.com/pub/IcebergArticle/tip.html

... wherein the main article content is, as the article suggests, a single, self-contained page.

And yet ... that is just the "tip" - underneath is:

" ... at least one, but possibly many, supporting documents, resources and services. The minimum requirement is simply an expanded form of the tip (the "bummock"), complete with references, notes and links. Other resources and services that might lie under the surface are a wiki, a changelog, a software repository, additional supporting articles and reference pages and even a discussion forum."

[1] Neither wiki nor forum exist yet, but the bummock does...

Re: This Page is Designed to Last

#378

Post by Tepix »

chispamed wrote: post #332
Tepix wrote: post #310

I agree with all the points except for "Obsessively compress your images". The same argument as point 2 ("Don't minimize that HTML") applies: It's an extra step in the queue, and you lose some quality in the result. Besides, bandwidth and storage will only get cheaper. Unless you have a site that contains thousands or more images, chances are you won't really notice the difference the compression makes. Maybe for pre…

I disagree, image compression is still highly relevant and will stay relevant for a long time. It’s not about hosting costs and hosting bandwidth, it’s about user bandwidth. I frequently travel between countries by train and bus and when outside cities it’s almost impossible to get any non-optimized page to load. And this doesn’t even only extend to the time spent inside the train. Depending on the country (all devel…

Compare the available mobile bandwidth and cost today with what we had just 5 years ago. We're talking about regular web pages here. Sure, you don't want to put full resolution images straight into your page. That makes no sense. But if you have a regular page with a couple of images, its size up to a certain size won't matter in most places in a few more years, just as it doesn't matter today if you live in a more densely populated area. I have a mobile phone contract where I get 10GB of traffic (which seems a lot to me but which is laughable if you compare it to other markets such as Kuwait where contracts with 1TB/month are normal) for less than 20€ per month and I only manage to use 3GB per month or so most of the time.

Re: This Page is Designed to Last

#379

Post by SamBam »

rsync wrote: post #377
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…

""Prefer one page over several" is diametrically opposed to the hypertext model. Please don't do this." I think I agree with you here, in that much of the power of hypertext lies in the hierarchical "tree" model. And yet, I think it has not been used properly up to this point ... I hesitate to post this as this is not quite finished[1], but here goes - this is something called an "Iceberg Article": http://john.kozubi…

I don't see how that's fundamentally different from a Wikipedia article, which is basically

(1) a single, self-contained page, (2) that is just the "tip", and (3) linked within it is all the stuff mentioned

That site has various opinions about the "tip" being uncluttered of links, etc, but that's just an opinion (and one I disagree with).

Re: This Page is Designed to Last

#380

Post by charlesdaniels »

dragonsh wrote: post #139
charlesdaniels wrote: post #112

Earlier quoted context omitted.

Shout out to https://joplinapp.org/ I was an Evernote user when I was on macOS. When I switched to Linux, a proper web clipper was something I really missed. I'm now on Joplin and it does everything I used to use Evernote for and then some. It even has vim bindings now! As far as longevity goes, I think they got their archive / backup format right - it's just a tarball with markdown in it.

No need of proprietary code and apps why not build it into browsers. I have seen Firefox and Chrome can download web pages. So it will be nicer if they can download the bookmarked pages and store in a local html, css, image folder. I think it's pretty easy to achieve. Also people need to move away from those esoteric reactjs, angular, vuejs and plethora of CMS as API or static site generators relying on some js frame…

> No need of proprietary code and apps

Joplin is open source, which is a big part of the sell to me. It definitely isn't the best of all possible note taking systems that could ever exist, but it's the best open source one I've found so far, and I don't have time to write a better one at the moment.

> why not build it into browsers. I have seen Firefox and Chrome can download web pages. So it will be nicer if they can download the bookmarked pages and store in a local html, css, image folder. I think it's pretty easy to achieve

This is solving a different problem though. WARC/MHT and other solutions can do this. Joplin is more of a note taking system that allows ingesting content from the web into one's own local notebook, which is relevant to what the GP post was talking about - Evernote.

However, it would seem that "the modern web" is the now popular standard. 10 years ago it might have been Flash or Java web applets or whatever. Now it's JS. I'm not convinced that JS is any better than what it has replaced. However, people keep paying developers to write them, so presumably someone likes them.

> Also people need to move away from those esoteric reactjs, angular, vuejs and plethora of CMS as API or static site generators relying on some js framework which won't last even 2-3 years. Use a static site generator which can generate a plain html, like static site generators built on pandoc, python docutils or similar.

Agreed, but that's also not a problem that Joplin, Evernote, or any other such tool is going to be able to solve. Unless you are complaining that Joplin is an Electron app? That's my biggest issue with it personally. It runs well enough, but is definitely the heaviest application I use regularly, which is a little sad for a note taking program. On the other hand, I haven't found a better open source replacement for _Evernote_. There are lots of other open source note-taking programs though.

> Personally I like restructuredText as the preferred format for content as its a complete specification and plain text. So the only thing in this article I will change is that content can also be in rst format and then generate html from it. Markdown is not a specification as each site implements their own markdown directives unlike restructuredtext specification and most of the parsers and tooling are little different from each other.

reST is indeed very nice. At one point, I kept my personal notes as a Sphinx wiki with everything stored in reST. I found this to be less ergonomic than Evernote/Joplin, although in principle it could do all the same things that Joplin can do, and then some.

Post reply on HN