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

221–230 of 328 posts

Re: Browsers are pretty good at loading pages

#221

Post by wvenable »

greenhatman wrote: post #172
detaro wrote: post #152

Earlier quoted context omitted.

And it took me 2 minutes clicking around to break its idea of the page state. I am partially scrolled down the home page, and it just decided to deactivate scrollbars and the ability to scroll. A great example of how it's quite difficult to reimplement stuff that works perfectly well on traditional pages. (At least they seem to haven gotten rid of some of the dark patterns they had in the past, that's nice to see) ED…

I've never found a bug on there, and I've been on it many times. I'd love if you can show me how to reproduce this bug. I just don't have this experience with SPAs breaking. I actually have no idea where it's coming from.

I just reproduced it following the commenters instructions -- clicked the sidebar link, got a popup, pressed the back button and I have no scroll bar.

I can see what is happening there: the popup removes scrolling (because of the overlay) but the back button doesn't restore it.

This certainly does lend to the conclusion that managing page state in a SPA is not trivial.

Re: Browsers are pretty good at loading pages

#222

Post by wlesieutre »

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.

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.

Re: Browsers are pretty good at loading pages

#223

Post by bryanrasmussen »

manigandham wrote: post #206
daxterspeed wrote: post #75

Earlier quoted context omitted.

While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). If implemented correctly, JavaScript navigation should seamlessly appear like normal navigation. Not supporting streamed requests is a serious drawback. Of course browsers have actually gotten pretty good at AJAX-like loading instead of co…

JS is cached in its compiled state in modern browsers. There is no download or parsing step for repeated loads.

without a unique key in the js name/path, or any server action to enable it? If so I would like to read about this particular development - can you point me to an article on how they're doing it?

Re: Browsers are pretty good at loading pages

#224

Post by soheilpro »

buboard wrote: post #149

Try visiting indiehackers.com, the come back to hn for a comparison. I would love to love that site but i value my time and sanity more. Waiting 10 seconds for every click is just torture. Ajaxy navigation has its place i guess, but your website has to be fast for that too. The worst offenders i have seen here must be all the advertising managers like google adwords, facebook ads. Each request takes a horrible amount…

I stopped using Indie Hackers because of its terrible UX.

Re: Browsers are pretty good at loading pages

#225

Post by MattyRad »

cottsak wrote: post #211
MattyRad wrote: post #190

This is definitely in the same vein as http://boringtechnology.club/ After several years of drinking the client-side kool-aid, I've come to realize that it almost never has a positive ROI. On top of the false premise that it "makes pages faster", it doubles the cost of the entire pipeline/stack, it doubles the amount of documentation that needs to be read/written, and it doubles the statefulness of the app, amongst o…

There's such an "ego load" associated with this investment too. I find that even when a developer comes to realise that the SPA mess is largely unjustified, they're rarely willing to admit or change anything.

Agreed. It's very much a sunk cost/escalation of commitment fallacy. https://en.m.wikipedia.org/wiki/Escalation_of_commitment

Also bad is that junior engineers see shoddy client side code and internalize it. As an example, one junior engineer asked me how he was supposed to iterate over an array server side when I told him he didn't need to use Vue on a page. Server-side rendering fixtures had been completely forgotten.

I accept my responsibility in causing this mess though. I niavely pushed the SPA on my myself, my coworkers, and our end users years ago and have to live with that sin daily.

Re: Browsers are pretty good at loading pages

#226

Post by adrianN »

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…

In pretty much the same time it takes for the HTTP 200 to arrive I can also download a few kilobytes of HTML. Latency will still dominate.

Re: Browsers are pretty good at loading pages

#227

Post by adrianN »

ComputerGuru wrote: post #208
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)

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

I just set browser.display.use_document_fonts to 0 in about:config.

Re: Browsers are pretty good at loading pages

#228

Post by pmontra »

giaour wrote: post #210
pmontra wrote: post #97

Earlier quoted context omitted.

Media galleries (carousels) were client side things at least since the original xhr implementation in IE5. Maybe well before that if changing the src of a img let the browser load the new one from the server. I can't remember. But sites were small and even loading all the page again was not that bad. By the way, Rails Tutbolinks [1] are a way to get the same result with the server rendering only the html body and the…

IIRC, Turbolinks work by loading pages in the background in response to a mouseover event - by the time a click has registered, the remote content has already been downloaded and just needs to be injected into the page. The speed-up comes from anticipating clicks, not from JavaScript tomfoolery.

I checked the README and it never mentions mouseover

> Turbolinks intercepts all clicks on links to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using XMLHttpRequest, and then renders the HTML response.

I don't have a Turbolinks application to check but I found this https://github.com/turbolinks/turbolinks/issues/313

and this

https://www.mskog.com/posts/instant-page-loads-with-turbolin...

The behavior you describe is possible but it's not the default and requires adding other libraries.

Re: Browsers are pretty good at loading pages

#229

Post by fyfy18 »

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…

It's two years later, and I'm still waiting for those improvements in Jira. Until then Jira is a great case study of how not to do things in JavaScript, it's slow, it's inconsistent and I doubt the accessibility is very good.

(It's also a great case study of how it doesn't matter how good or bad your app is, the success of your business doesn't depend on that)

Post reply on HN