Hacker News Reader

Comment by NoGravitas | Hacker News Reader

I very strongly agree with this. There are certainly web apps that can only reasonably be done mainly-client-side. I'd give Office 365 as a baseline example.

But what drives me crazy is sites like Medium [0][1]. It's a shared blog site. To read a one sentence essay on Medium requires downloading over a megabyte of data. And their comment system is still inscrutably terrible.

Content-focused sites should absolutely not be done as SPAs. Server rendered HTML and client-side enhancement will deliver a better experience to the customer and IMO a better developer experience as well.

[0]: http://idlewords.com/talks/website_obesity.htm [1]: https://medium.com/@mceglowski/chickenshit-minimalism-846fc1...

View on HN

The page you link to on Medium renders after less than 100KB have been downloaded with an unprimed cache.

Javascript is not required to read it. Javascript is used to provide extra functionality outside of the download / render cycle, to speed the experience of the page up, and to make future navigation faster.

I understand where you are coming from, but you picked a bad example.

> Javascript is used to (...) speed the experience of the page up

That is one thing I'm totally not buying. How does JavaScript speed anything up over simple staticly rendered text, (which is what Medium should be)?

Optimistic loading / prefetching / etc -- the list goes on if you take the time to think about it for more than a second.

Used correctly, it can hugely speed up the experience by preloading things.

In an ideal case you could have a fast initial page load with static HTML. Then an async script tag quietly loads a script in the background while the user is reading (done properly, this can be imperceptible). Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load.

That's not usually the reality but it's definitely possible.

How is that faster than loading a single HTML template with the "dom" already rendered correctly by the server?

I think you missed this part

>Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load.

In the GP's example, the first page load is already rendered by the server. It's subsequent page loads that are rendered in JS.

..so you want to preload the content of every link on the page?

Because if it's just to display comments or something, I stand by my original statement.

That's a big revision of your original comment ;)

Speeds up subsequent pages accessed at least.

The related articles and comments are not rendered until after the page is readable. If they had to be rendered on the server, it would cause the article to take longer to be readable.

There's a lot of different caching and persisting strategies you could put in place to load comments or related articles quickly that don't involve entire HTTP round trips. There's a definite trade-off there (and a not insignificant one, especially on mobile)

Not to mention, HTTP2 mitigates a lot of this, without the downside of huge upfront downloads.

Yes, sources are packed pretty well, but there's still a lot going on for a blog article:

* 10 XHR requests on page load

* 3 downloaded fonts

* Continuous XHR requests as you scroll through the article

* ~400ms time spent executing javascript (according to timeline benchmark)

I'm not really sure why all those things need to happen to load some text in a blog article.

Does it stop downloading after that initial 100K? If not, then I think the original claim is a reasonable description. Reading one sentence will cause one megabyte of data to be transferred.

Reply on news.ycombinator.com