Browsers are pretty good at loading pages • Hacker News Board

Re: Browsers are pretty good at loading pages

#281

Post by vthriller » Mon, Jul 22, 2019, 12:17 PM UTC

oefrha wrote: post #275

grishka wrote: post #264

Earlier quoted context omitted.

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

> If my data is that limited, I'd disable images myself in my browser settings, thank you very much. Yeah, because most visitors to most websites can and know how to disable images in browser settings. In fact, let me know how to do this in iOS Safari. Before you tell me to throw my iPhone and iPad in the trash, get an Android, root the damn phone, install F-droid, compile Chromium with patches, or write my own opera…

> In fact, let me know how to [disable image loading] in iOS Safari

Given any browser, how do I reload a lazy-image that failed to load, without resorting to whole page refresh or diving deep into the Web Inspector?

Most browsers have a context menu option to reload regular images, but they cannot and will never handle a bunch of dynamic block elements with background-image option.

Re: Browsers are pretty good at loading pages

#282

Post by jbergens » Mon, Jul 22, 2019, 12:19 PM UTC

TeMPOraL wrote: post #101

tiborsaas wrote: post #49

Earlier quoted context omitted.

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…

> 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 article only tested one site with one browser, hardly a good test. It may be correct anyway but it IS not a proof.

It may also be much harder to implement something like a comment section that is fast and correct with only static html and a server backend.

Re: Browsers are pretty good at loading pages

#283

Post by smileysteve » Mon, Jul 22, 2019, 12:27 PM UTC

We've also spent 10 years getting to the current state.

Backbone was notoriously difficult to manage state in. AngularJs was quick to prototype (though often slower to develop in than HTML) but had massive memory leaks. Even modern Angular and React were new iterations that didn't solve the state problem well until Ngrx/Redux became mainstream.

Re: Browsers are pretty good at loading pages

#284

Post by jbverschoor » Mon, Jul 22, 2019, 12:36 PM UTC

It's funny, actually frustrating, that people create all these frameworks to mimic "native" looks and behavior. But there are soooooooooo many elements that are overlooked, and usually only tested on a few platforms. Don't you just love sites that capture your scrolling? Or buttons that have different hotspot areas or don't support canceling by dragging out of them?

Re: Browsers are pretty good at loading pages

#285

Post by dan-robertson » Mon, Jul 22, 2019, 12:38 PM UTC

jbergens wrote: post #282

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 article only tested one site with one browser, hardly a good test. It may be correct anyway but it IS not a proof. It may also be much harder to implement something like a comment section that is fast and correct with only static html and a server backend.

I don’t understand why doing things the non-JavaScript way wouldn’t be correct. Surely you still need to do all the correctness things on the server anyway even if you do some in JS because client side validation won’t stop other people (or spammers) from sending invalid requests to the server. When I think of a correctness problem it would be in keeping the js-rendered comment section synchronised with the server-side comment section which seems harder than making it work with no js.

Re: Browsers are pretty good at loading pages

#286

Post by wlesieutre » Mon, Jul 22, 2019, 1:09 PM UTC

wlesieutre wrote: post #222

greenhatman wrote: post #146

Earlier quoted context omitted.

It's not as fast as https://dev.to/ , which is an SPA. I.e. client side routing.

Ah, the good old “footer at the bottom of an infinitely long page.” Facebook and Google used to be guilty of this, but it’s been a while since I ran into that particular brand of user-hostile web design.

Addendum - I may have been too harsh here. The page most likely is not infinite. You should able to scroll through the entire backlog of dev.to content to access the footer.

Seriously though, you can't just bolt infinite scrolling into the middle of an existing page if you have content at the bottom.

They've duplicated most of that (but not the copyright) in the sidebar's "Key Links" box, so it's not as big a problem as I've seen on other sites.

If they hadn't, I wonder about the legal implications of making your privacy policy, terms of use, and copyright notice completely unreachable. And why keep them in the footer if you never leave it on screen long enough to click it? Just a "not my job" issue with whoever implemented the continuous scroll? Clearly someone thought about it long enough to put the links somewhere reachable, but not long enough to get rid of the old ones?

Re: Browsers are pretty good at loading pages

#287

Post by latexr » Mon, Jul 22, 2019, 1:15 PM UTC

dustingetz wrote: post #7

He says the reason people code client-side navigations is to load pages more quickly. That's not the reason. Client-side navigation evolved from single page apps, where we use javascript to create dynamic content on the fly, for example a chat application. Now that you're a stateful single page app, we need to rebuild page navigation if our single-page-app has more than one "page". I understand that projects like Gat…

> He says the reason people code client-side navigations is to load pages more quickly.

No, he says one of the developers of a specific website (MDN) told him that is why they did it in that particular case.

Re: Browsers are pretty good at loading pages

#288

Post by noad » Mon, Jul 22, 2019, 1:16 PM UTC

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…

It is not faster, ever. It is always snappier to render everything server side and avoid as much JS as possible. If you can consolidate the whole page down to a half dozen total HTTP requests or less that's ideal.

The narrow case where you make an XHR call to just reload a small slug of data instead of the whole page effectively does not exist in the real world. I mean I'm sure a few developers have implemented that exact pattern a few times, I think I remember even doing it myself probably? But it's not something that actually happens.

What's actually happening instead is people are just adding more and more intricate tracking and analytics to all these SPAs. The XHR call to reload a blurb of text kicks off three other XHR calls to register the event with the various analytics/advertising tracking partners. Oh and we're adding a new ad partner next week so make sure you refactor all the AJAX to register event handlers for all these new interactions. And can we add mouse position tracking too?

I'm starting to see some pages break into the tens of megabytes of JS scattered across hundreds of files, nobody is paying any attention to what's fast.

I'm not sure how you fix this, I've largely given up on the web. It's just a thoroughly terrible experience from top to bottom, and effectively unusable if you're a layperson.

Re: Browsers are pretty good at loading pages

#289

Post by jrockway » Mon, Jul 22, 2019, 1:27 PM UTC

the8472 wrote: post #179

tiborsaas wrote: post #49

Earlier quoted context omitted.

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…

In my experience for whatever reason github's turbolinks often take longer than opening the link in a new tab.

Github is simply a very slow website.

Re: Browsers are pretty good at loading pages

#290

Post by StavrosK » Mon, Jul 22, 2019, 1:48 PM UTC

greenhatman wrote: post #146

StavrosK wrote: post #109

Earlier quoted context omitted.

Case in point, navigation on my site is pretty fast (to me, at least) and doesn't use much JS at all: https://www.stavros.io (I promise I'll reply to your email soon)

It's not as fast as https://dev.to/ , which is an SPA. I.e. client side routing.

That definitely seems faster, I'll give you that:

https://i.imgur.com/bx1LUZD.png