Live data from Hacker News

Browsers are pretty good at loading pages

carter.sande.duodecima.technology

181–190 of 328 posts

Re: Browsers are pretty good at loading pages

#181

Earlier quoted context omitted.

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

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…

> 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 suspect the oversized responses and cherry-picking are a result of back end and client being responsibilities of independent teams and client team is told "use this pre-existing kitchen-sink endpoint".

Re: Browsers are pretty good at loading pages

#182

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.

Good: it detects when you’re offline and displays a fun error page.

Bad: this only works on every other click. Half the time the links just silently fail....

Re: Browsers are pretty good at loading pages

#183
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.

It doesn't happen 100 % of the time, but right now going to the homepage, clicking one of the listings in the "newest listings" box, and then returning to the homepage through the browser back button triggered it.

Re: Browsers are pretty good at loading pages

#184

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.

Scrolling is extremely laggy on latest mid range Android using Chrome. Almost unusable.

Re: Browsers are pretty good at loading pages

#185
> It’s not worth it to try and go behind their backs—premature optimizations like client-side navigation are hard to build, don’t work very well, will probably be obsolete in a couple years, and make life worse for a decent portion of your users.

I don't know what is wrong with me -- when I read this sentence all my brain can see is "job security."

______________________________________________________

My take on client side navigation is the desire to cater to smartphone users instead of desktop users. Every few days it seems a popular website does a redesign that is centered around smartphones. They're increasingly bloated and wasteful. Why Twitter, why???

Re: Browsers are pretty good at loading pages

#186

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…

> Furthermore, you don't lose state, which makes things much more simple.

Nah, it makes it more complicated. You still have to handle reloads and back/forward, but now it's on you.

Re: Browsers are pretty good at loading pages

#187

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.

How do I access the footer on mobile? It just keeps scrolling it down as soon as it appears

Re: Browsers are pretty good at loading pages

#189

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…

> 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.

Re: Browsers are pretty good at loading pages

#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 other things. Maybe under the best conditions by the most knowledgeable devs, client side apps could be impressive, but your typical company doesn't have those resources.
Post reply on HN