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

Browsers are pretty good at loading pages

carter.sande.duodecima.technology

Post reply on HN
Print view View original

261–270 of 328 posts

Re: Browsers are pretty good at loading pages

#261

Post by marcus_holmes »

TeMPOraL wrote: post #249
bryanrasmussen wrote: post #220

Earlier quoted context omitted.

So your argument is that many teams don't care and do a bad job and it is the fault, somehow, of the language they use?

It's a powerful argument. Defending client-side rendering here (or SPAs) is almost no-true-Scotsmanish. It is technically possible to do a good job, but it's almost never done . Yours and sangnoir's teams may care about performance and do actual software engineering - but it doesn't help me much when my bank doesn't do it, the places I shop don't do this, big sites like Reddit don't do this, and seemingly none of the…

Yeah, but how is this the fault of the language?

There's nothing inherent in JS to say "you must do a shitty job of optimising your page speed"

I'm working on replacing a PHP app that is currently taking 20 minutes to refresh the index page because their SQL doesn't scale. Is that the fault of PHP, SQL, or the developers who wrote it?

You can write crap code in any language (even Rust!).

Re: Browsers are pretty good at loading pages

#262

Post by dijit »

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…

I think you're not making the same point as me at all.

I'm going to take the common case of a news article;

Imagine for a second, you're on a train and you have low bandwidth internet, when it works, which is rare. Now you're on hackernews and you've loaded a whole comment thread, you're reading through and someone posts a link to your article.

Now, the article can load with client side routing, but will take longer. And depending on implementation might not actually have the whole article.

The page which is pure html with minor javascript is going to load, in full, and I don't need subsequent requests. And, it's guaranteed to be smaller than the one that you're over-engineering.

Re: Browsers are pretty good at loading pages

#263

Post by ZoomZoomZoom »

tiborsaas wrote: post #49
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…

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…

>>Imagine a simple image gallery. You just update the tag, update the URL with the history API and everybody is happy. If you were to navigate via links, you get the same behavior.

Please, don't! Just give me a page with thumbnails that are direct links to the original pictures! That's million times easier, works blazingly fast and I wouldn't need to spend so much time clicking multiple times to save each pic, which is the best case! The worst is serving me blobs of PNG instead of original pics. That's pure hostility.

Re: Browsers are pretty good at loading pages

#264

Post by grishka »

sangnoir wrote: post #161
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.

> The whole point of the article is that it's not true. Only for the narrow condition of loading a whole page. A lot of Web apps make async request much smaller than loading the whole page: imagine deleting one record in a list of 50 items; the async response could be the HTTP 200 header alone. I think it would be useful for developers to separate web applications from web sites and consciously make trade-offs (such…

When I want to read an article, I don't need a "web application". I want a static page with the text and the pictures. That's it. Not a single line of JavaScript. And certainly absolutely no image lazy-loading nonsense. If my data is that limited, I'd disable images myself in my browser settings, thank you very much.

What I'm trying to say is that most of the web isn't really that interactive. It's mostly comprised of content that is static in its nature.

Re: Browsers are pretty good at loading pages

#265

Post by marcodave »

testis321 wrote: post #74
hombre_fatal wrote: post #55

Earlier quoted context omitted.

A media gallery website is a good example of a use-case for client-side routing. I worked on a porn site that was basically an endless-scroll video gallery. Clicking a thumbnail opened the video in a modal overlay. All pages on the site were modal on top of the gallery in the background. You could deep link to a page and the gallery would load in behind it. It worked really well and had great UX. This generalizes to…

> I worked on a porn site that was basically an endless-scroll video gallery. So, if you're a horny teenager, you scrool down for a huge amount of time to find "the video" that will get you off... and you hear your mom coming up the stairs, Control+w (close tab), and when she goes downstairs again, you press Control+shift+t (reopen last closed tab), you're back at the beginning, and have to search for that video agai…

> you're back at the beginning, and have to search for that video again? That sucks.

and yet, that's the same behavior of the social media sites; you will spend more time (=more ads shown to you) there because you are searching for that damn video again

Re: Browsers are pretty good at loading pages

#266

Post by strken »

namibj wrote: post #175
delinka wrote: post #174

Earlier quoted context omitted.

Web apps making async requests should be making much smaller requests than loading the whole page - but they're not. They're loading a page and parsing out the "less than the page" bit to stick into the current page; or they're loading a JSON blob bigger than the current page to update the three visible elements on the page. Imagine Software Engineers that actually engineered solutions - the use of small async reques…

GraphQL was made to fix that issue.

GraphQL's nice if you want a third option to the choice between many bespoke endpoints or few generic endpoints, but if your problem is sending a list of 400 widgets with every single page load, then you have an easier and better way to increase performance sitting right in front of you.

Re: Browsers are pretty good at loading pages

#267

Post by TeMPOraL »

marcus_holmes wrote: post #261
TeMPOraL wrote: post #249

Earlier quoted context omitted.

It's a powerful argument. Defending client-side rendering here (or SPAs) is almost no-true-Scotsmanish. It is technically possible to do a good job, but it's almost never done . Yours and sangnoir's teams may care about performance and do actual software engineering - but it doesn't help me much when my bank doesn't do it, the places I shop don't do this, big sites like Reddit don't do this, and seemingly none of the…

Yeah, but how is this the fault of the language? There's nothing inherent in JS to say "you must do a shitty job of optimising your page speed" I'm working on replacing a PHP app that is currently taking 20 minutes to refresh the index page because their SQL doesn't scale. Is that the fault of PHP, SQL, or the developers who wrote it? You can write crap code in any language (even Rust!).

It's probably not the fault of the language per se, just the culture surrounding the use of that language.

It could be argued that the same language, given another chance, would produce a similar culture, though I'm not 100% convinced of that. Anyways, what we need is a reboot of web development culture.

Re: Browsers are pretty good at loading pages

#268

Post by grishka »

compumike wrote: post #68

(Disclosure: I'm Carter's desk-neighbor at Triplebyte.) I think there's actually a middle ground where you can utilize some of the more modern techniques to actually do better than the pure static pages approach, while still using normal browser-based page navigation. As a personal challenge, I wanted to see what could be done about performance for a recently-launched side project: the Ultimate Electronics Book [1],…

For the love of god, please, never, ever do lazy image loading. As a user, I expect the page to be 100% complete when the progress bar in my browser disappears.

Re: Browsers are pretty good at loading pages

#269

Post by boblebricoleur »

IanCal wrote: post #43
arethuza wrote: post #33

Earlier quoted context omitted.

HN uses the "old fashioned" approach of rendering everything server side and every link forces a page reload and I wouldn't describe the experience as "jarring and discontinuous". I'd rather have a fast full page reload than looking at a spinner while complex client side stuff does its stuff. [NB I really like React and when good SPAs are very very good - but a lot aren't].

There's definitely parts that are awkward though. I can't see the context of your comment in my reply as it's on a completely different page for example. HN has never really been a great UI though, it used to be a massive set of nested tables that didn't render properly on a mobile, it has some tiny fonts and hard to click buttons, and has unliked comments just less accessible by lowering contrast. It's good enough t…

I feel hn experience is awesome. Everything is accessible with one or two clicks. I never wait for something to load, never pest against it because of some obscure behavior. It's simple and efficient. The content is perfectly served. No frills. Even on mobile I don't really feel the buttons so hard to click, even if they are tiny. Maybe we don't use it the same way.
Post reply on HN