Live data from Hacker News

Browsers are pretty good at loading pages

carter.sande.duodecima.technology

211–220 of 328 posts

Re: Browsers are pretty good at loading pages

#211

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.

Re: Browsers are pretty good at loading pages

#212

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.

> webpages on good connection are so fast Not everyone has this, espicially when your someone like myself who writes informational websites for people who won't be connected to any internet for hours at a time. Super fast response times don't cut it when your response time is non existent at the moment.

If your internet connectivity breaks constantly, there is a good chance that a JS heavy client side app is going to irrecoverably break, require a hard refresh and take much longer to load because of your crap internet.

I should know, my internet connectivity sucks, and single page applications are almost without exception, a completely awful experience.

Re: Browsers are pretty good at loading pages

#213

Earlier quoted context omitted.

It's probably not the network round trip or the actionable content making reloading the site so slow. It's almost certainly tracking scripts, unoptimized database queries, and unoptimized assets.

Sure, web performance is an afterthought at many places and the more people work on a certain project the worse it gets because each team has its own motivation, but they all have the same target to shoot at. I think there's a connection between the organizational structure and the bad frontend experiences and this is almost always overlooked in these discussions. This is no surprise of course, we only see the crappy…

SPAs are the worst, because companies deploy them to avoid separation of responsibilities and turn every employee into easily replaceable "full-stack developer".

Unfortunately, a lot of people write terrible applications regardless of chosen technology. When this happens to purely server-side applications, the company is forced to optimize them to keep the hosting bill low — a positive feedback loop in action. SPA applications cause the opposite — companies move everything to client-side in order to reduce Amazon bills, and don't care if those client-side scripts are poorly optimized and contribute to global warming by causing hundred thousands machines to spin up their CPU fans.

Clearly, there should be a heavy tax on single page apps. They are

1) addictive — by making more Javascript devs, who in turn write more Javascript websites

2) act as luxurious goods ("Look guys — we have created a new version of our website. It looks so cooool (but loads a bit slow)!")

3) have ugly externalities, completely ignored by most of their creators

Re: Browsers are pretty good at loading pages

#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 of sites do, it’s usually faster to not make the browser parse and compile again. Just stay in js land as a single page application and communicate with server purely in REST.

Re: Browsers are pretty good at loading pages

#215

Earlier quoted context omitted.

I, uh, was kidding about Canada being a socialist state... For what it's worth, I had a 128 kilobit connection in Canada because American T-Mobile plans give you one for free when you're outside the country.

Unfortunately it's not always clear who's joking and who's not; many (most?) people who feel the need to comment on socialism and capitalism have done very little reading in political philosophy.

... are you being serious? I ask this question pragmatically. Perhaps my nuance for sarcasm after spending my entire life in the UK & Australia is more finely tuned than most.

The author went as far as to describe Canada as "a socialist state in North America" and later followed on with:

"(T-Mobile told me I could buy an “all-access high-speed day pass” for $5 on the black market, but I didn’t want to get arrested by the Royal Canadian Mounted Secret Police.)"

I don't think it's possible to be more overtly tongue in cheek without having to retort to using Reddit's HTML sarcasm tags.

All in all, it seemed quite clear to me that is was in playful jest.

Also, dear author, thank you for the laugh.

Re: Browsers are pretty good at loading pages

#216
post #135

He lost me when he described Canada using a dictionary-like wording but also adding some pretty personal perspective. Describing an entire country as Socialist seems super opinionated to me. Client-side navigation is quite tricky to get right - since there is no definition of right. Browser back buttons and scroll positions between back and fourth page loads are not standards-based things and the only way to study th…

>P.S. I wonder if client-side ajax calls are GZIP compressed🧐 I thought HN filtered out emojis and other graphical characters?

This is news to me too!

Re: Browsers are pretty good at loading pages

#217
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…

> Just stay in js land as a single page application and communicate with server purely in REST.

This is a sensible conclusion. Unfortunately, "js land" tends to grow as application grows. And nobody actually unloads their Javascript when it is no longer necessary (can you even do that?)

Server-side rendering means, that you shouldn't leak memory — otherwise your app will literally stop working.

Re: Browsers are pretty good at loading pages

#218

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.

Scroll, click a story, click a link off the site and then hit back button twice. You will jump to top of homepage incorrectly.

Re: Browsers are pretty good at loading pages

#220
post #189

Earlier quoted context omitted.

> 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. This is...disgusting. I was speaking of applications I have personally worked on; the teams/organizations I have worked with were concerned about performance (and measured it with regression testing). I suspe…

It’s certainly possible to write good client side code, I’ve worked on teams that really care and are given room to do it (because they were able to demonstrate its worth after so much effort.) and on teams that don’t. JavaScript, as she is spoke, is just an awful language. It has brilliant ideas and if applied correctly could make everyone’s lives better but that’s just not how it’s used.

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?
Post reply on HN