Browsers are pretty good at loading pages • Hacker News Board

Re: Browsers are pretty good at loading pages

#251

Post by onion2k » Mon, Jul 22, 2019, 7:22 AM UTC

dijit wrote: post #246

onion2k wrote: post #233

Earlier quoted context omitted.

... loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory. Unfortunately for us front end engineers we can't rely on the user having any internet connection let alone a good one. Most of the push behind static site generators is to get as much of the code necessary to display all the website in to your browser as fas…

Well. I can speak from a pretty solid experience here. I’ve travelled the US by train, the length of the UK by train and large swathes of Europe by train. The site that tends to be the best to use is the ones that don’t take much to load. Connection tends to be spotty, you get bouts of “some” data and then you’re dry again for a while. If you can squeeze a page load in there it’s infinitely better than a half opened…

Your first page load is -incredibly- important here. It’s the difference between a usable site and an unusable one.

This is the point I was making. If the server can send the user enough data on the first load to make the whole app/site usable then the user won't need to wait for the network if they're in a tunnel. They've already got the necessary resources (which shouldn't be everything, just what's necessary). In that scenario client side routing beats server side completely because server side rendering just doesn't work when the user doesn't have a network connection.

That said though it's wasteful and entirely unnecessary if the user has a good connection. Really websites should have a good mechanism for testing. The Network Information API doesn't have particularly good cross browser support and it isn't especially reliable yet.

Re: Browsers are pretty good at loading pages

#252

Post by TeMPOraL » Mon, Jul 22, 2019, 7:24 AM UTC

weego wrote: post #235

ComputerGuru wrote: post #208

Earlier quoted context omitted.

Yeah, but you force me to stare at blank spaces while your webfont downloads [0]. I guess I should be thankful you’re not using that font for the body text, too (most sites do!). [0]: https://imgur.com/a/FAX6BDW

That's conflating two different issues

It's the same meta-problem, though: modern webdev practices involving adding gimmicks for no good reason that introduce extra complexity and resource use, and then adding even more complexity and resource use trying to fix all the expected behavior and features of browsers that the initial gimmick broke... and doing it poorly.

Re: Browsers are pretty good at loading pages

#253

Post by baroffoos » Mon, Jul 22, 2019, 7:25 AM UTC

klez wrote: post #240

nojvek wrote: post #214

This may get downvoted to oblivion due to the HN bias against js. The correct answer is it all depends. Certain things are faster to do in JS. Certain things are faster as a page load. One has to profile and see what makes sense. There is a reason Atlassian is dog slow and trello runs circles around in terms of UI performance. The immediate Once you have a substantial amount of JS, and you’re an app site, which a lot…

> This may get downvoted to oblivion due to the HN bias against js. Now, come on. Very few people in here would say that js had no place in the web. A lot of people are against js when alternatives exist. Trello is an application, so js makes sense there. A blog article that doesn't even display when js does not load, that's where people have a problem.

It seems a large chunk of people would rather trello was built entirely out of html forms so you press a to make the card move to the left and then the page refreshes with the card moved.

Re: Browsers are pretty good at loading pages

#254

Post by buro9 » Mon, Jul 22, 2019, 7:32 AM UTC

I browse using Brave, with JavaScript disabled by default and full "shields up" on every site.

Anecdotally I would say that 10% of the web is unusable, another 20% is barely usable... but to my utter surprise the other 70% is functional to some basic level.

The one I am most impressed with is Amazon. I am not an Amazon fan at all, and try to avoid shopping there or using their services, but when I do happen to need something in a small quantity and fast Amazon are very good, and so when I visited recently it took me a while to comprehend that the site looked right, felt right, hadn't degraded the experience to any shocking degree, and was fully functional even without JavaScript and 3rd party cookies, etc.

There is still a lot to be said for the very simple approach of make it all in HTML on the server first, and only use JavaScript to add small enrichments that can only be done in the client.

Re: Browsers are pretty good at loading pages

#255

Post by TeMPOraL » Mon, Jul 22, 2019, 7:39 AM UTC

enraged_camel wrote: post #177

TeMPOraL wrote: post #101

Earlier quoted context omitted.

> Because it's faster. The whole point of the article is that it's not true. It's not the only article that disproves it, and honestly, it's not difficult to notice it. Just go to any blog running off a static site generator; loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.

I don’t think blogs are a good example. How much complex logic do they have, and how many database queries and data processing do they do before they serve their content? Furthermore, how much interactivity do they have? Not much.

I'd guess as much as 90% of pages out there - fetch a blob of data from the server, render it, and have most interactions not touch the server at all.

You can view e.g. ecommerce sites as blogs with one post per combination of (search query, filter switches, page selected). This necessitates frequent shots to server, but the site otherwise transfers roughly a page's worth of data per viewed page. I've never seen an on-line shop that was made better by being an SPA, over an old-school page reload every click.

Similarly discussion forums - there's Discourse that's arguably more gimmicky with its client-side magic; beyond that, if you want to see what would happen if you turned HN into an SPA, look no further than the dumpster fire the new Reddit design is.

Re: Browsers are pretty good at loading pages

#256

Post by csande17 » Mon, Jul 22, 2019, 7:43 AM UTC

iddan wrote: post #245

LoSboccacc wrote: post #234

this is the first time I see mentions of react being difficult to optimize and I'd like to know more, is there any in depth quality article about it anybody knows on top of the usual light blogs a search finds?

No there isn’t because it’s BS. React is super easy to optimise. https://reactjs.org/docs/optimizing-performance.html

People say React is easy to optimize, but many of the React apps I use in practice have crummy 50-100 millisecond response times on basic operations like "click button" or "press key in text field". And a significant portion of the performance difference between beta MDN and old MDN was the ~half second the React code took to run in the beta.

I'm pretty sure front-end developers aren't writing slow code on purpose. The most reasonable explanation I can come up with is that React makes it easier to write reliable UI code but harder to reason about performance -- features like "by default, all of a component's descendants are recreated and diffed with the DOM on any state change" point strongly in this direction.

Re: Browsers are pretty good at loading pages

#257

Post by iCarrot » Mon, Jul 22, 2019, 7:50 AM UTC

TeMPOraL wrote: post #108

arethuza wrote: post #42

Earlier quoted context omitted.

I occasionally suggest to people who complain on HN about the bad old days of table based layouts to do a "View Source" ;-)

The "bad old days of table based layouts" weren't really that bad, as evidenced by every generation of web developers reinventing tables in weird new ways. From "semantic" div soups through flexbox to CSS grid, it seems to me that most of layouting work is just building tables without using the tag ;).

There were real arguments against layout tables back in the day (though the situation may have changed): https://stackoverflow.com/questions/83073/why-not-use-tables...

One thing for sure: layout tables are undeniably powerful, that's why people want to recreate them but without the penalties that come with real .

Re: Browsers are pretty good at loading pages

#258

Post by TeMPOraL » Mon, Jul 22, 2019, 7:50 AM UTC

onion2k wrote: post #251

dijit wrote: post #246

Earlier quoted context omitted.

Well. I can speak from a pretty solid experience here. I’ve travelled the US by train, the length of the UK by train and large swathes of Europe by train. The site that tends to be the best to use is the ones that don’t take much to load. Connection tends to be spotty, you get bouts of “some” data and then you’re dry again for a while. If you can squeeze a page load in there it’s infinitely better than a half opened…

Your first page load is -incredibly- important here. It’s the difference between a usable site and an unusable one. This is the point I was making. If the server can send the user enough data on the first load to make the whole app/site usable then the user won't need to wait for the network if they're in a tunnel. They've already got the necessary resources (which shouldn't be everything , just what's necessary). In…

If. There are two failure points here, both of which are so frequent that I can't even recall seeing an exception.

One, if your first page load tries to load a full page, instead of just some JS that bootstraps the process of loading of the rest of the page, which lets the first load finish before execution. Better yet, it should load the absolute minimum bit of JS site kernel. Then, the first load is likely to succeed on a slow/spotty connection, and we can skip to problem #2 below. This isn't being done correctly in most of the sites I visit for some reason; the first page is either attempted to be downloaded in full, or the "skeleton" of the UI is the piece that always loads the longest.

Two, loading UX. You have a loaded UI skeleton with boxes that need to be filled via further requests. Or, I've clicked on something and a subsection of the site needs to be refreshed. What happens is either nothing, except the SPA getting unresponsive, or I get the dreaded spinners everywhere. If the requests succeed, the spinners eventually disappear. If they don't, they don't. Contrast it to the pre-JavaScript style: if something needs reloading, my page is being rendered essentially top-to-bottom, complete bit of contents popping up as they're loaded; the site is usable in partial state, and if anything breaks, I get a clear error message.

Can this two problems be solved correctly in client-side rendered code? Yes. Can SPA be faster than full page loading? Yes. Is it usually? No, because web development is a culture. When a company decides "let's do SPA" or "let's do client-side rendering", they unfortunately inherit almost all the related dysfunction by default.

Re: Browsers are pretty good at loading pages

#259

Post by Sharlin » Mon, Jul 22, 2019, 7:51 AM UTC

jakobegger wrote: post #3

I don't get client side navigation. It's a worse experience in every way. It's slow, often doesn't support things like command-click, it usually breaks the back button, and even if it doesn't it breaks the restoration of the scroll position. The only thing worse is a custom scroll UI. Why do people try to reinvent the most basic features of a webbrowser? And if they do, why do they always only do a half-assed job at…

https://en.wikipedia.org/wiki/Inner-platform_effect

Re: Browsers are pretty good at loading pages

#260

Post by TeMPOraL » Mon, Jul 22, 2019, 8:05 AM UTC

iCarrot wrote: post #257

TeMPOraL wrote: post #108

Earlier quoted context omitted.

The "bad old days of table based layouts" weren't really that bad, as evidenced by every generation of web developers reinventing tables in weird new ways. From "semantic" div soups through flexbox to CSS grid, it seems to me that most of layouting work is just building tables without using the tag ;).

There were real arguments against layout tables back in the day (though the situation may have changed): https://stackoverflow.com/questions/83073/why-not-use-tables... One thing for sure: layout tables are undeniably powerful, that's why people want to recreate them but without the penalties that come with real .

Yeah, they were. Though arguably not in the link you posted - those are mostly clichés, as correctly pointed out by the original poster. Especially the "separation of content from layout" and CSS Zen Garden were obviously[0] nonsense, and you can observe how SPAs of today go against both.

Tables had performance problems when they got large and content got potentially dynamic. That I learned only many, many years later - I never did sites big enough to run into such problems then.

The accepted answer in this post is cringeworthy. So much rationalization these days, makes you wonder what we're rationalizing today.

--

[0] - I admit I bought the CSS Zen Garden for a while; it took me some time and experience to realize that, really, no one does that in practice, and it requires ridiculous amounts of either forethought or afterhacks to do it.