Live data from Hacker News

Browsers are pretty good at loading pages

carter.sande.duodecima.technology

271–280 of 328 posts

Re: Browsers are pretty good at loading pages

#271
post #194
post #183

Earlier quoted context omitted.

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.

I am able to reproduce this bug with Safari on a Macbook. I clicked on an item in "newest", then quickly pressed Cmd-Left to return to the previous "page". The front page reappears, but I'm unable to scroll with arrow keys or trackpad. An additional press of Esc returns the expected functionality. It seems to be a fast and responsive site when it works, though.

> It seems to be a fast and responsive site when it works, though.

LOL.

Y'all, I love speed as much as anyone, but your development priorities should be 1) it works and 2) it's fast.

Using HTML links where 1) is never in doubt and all focus can be placed on 2) seems like good engineering to me.

Reinventing browser navigation is like building a rocket. You should be really, really sure that you need to do it before you try.

Re: Browsers are pretty good at loading pages

#272
post #237

Earlier quoted context omitted.

HN is very fast. Stackoverflow is very fast. Lots of other well engineered sites are very fast. As the article shows, browsers are well optimized and really don't download all the content again. In most cases it's just the HTML, which is streamed and rendered as it comes in. All the assets are cached, and scripts are even stored in compiled state to skip reparsing. Some sites might be slow at generating that HTML but…

This is what I don't really get. It seems like some people are under the impression that generating and parsing HTML is slow or takes a lot of resources. In almost all cases it's going to be faster and less resource intensive than generating JSON - especially if you are just using a templating language to interpolate some values. I agree that JSON could lead to less data being transferred over the wire, but that assu…

> I agree that JSON could lead to less data being transferred over the wire

I haven't benchmarked the difference, but I bet HTTP compression removes most of the difference

> but that assumes your client already has cached the megabytes of JavaScript needed for you SPA

A cache that will need to be busted every time you deploy new code. You do deploy often, right?

Re: Browsers are pretty good at loading pages

#273

Earlier quoted context omitted.

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?

Yes, Chrome uses V8 which has Isolates (also used by some FaaS platforms like Cloudflare Workers), and adds more optimizations on top like disk-based caching to share across processes. The script is keyed from a hash of its contents. https://v8.dev/blog/code-caching-for-devs

Thanks! I guess will have to see if FF and Safari support same thing. Perhaps in another year can remove cache busting from builds.

Re: Browsers are pretty good at loading pages

#274

Earlier quoted context omitted.

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 .

Maybe it's a fault of Sturgeon's law - I sort of wonder if the "necessity" to have so much web output - so many applications, so much new development does not create a situation where there is a pressure to make 95% of everything crap, because you need to get a lot of developers to make things and some of those developers are going to be crap, and you need to make lots of decisions and some of those decisions are going to be crap, and you need to do a lot of changes in short periods of time and that results in a lot of crap.

It just seems more likely to me than any culture about a language per se.

Re: Browsers are pretty good at loading pages

#275

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…

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 operating system, now is a good time to stop.

I seriously hope this sort of condescending “elitist” bullshit would die off.

Re: Browsers are pretty good at loading pages

#276

Earlier quoted context omitted.

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 .

Maybe it's a fault of Sturgeon's law - I sort of wonder if the "necessity" to have so much web output - so many applications, so much new development does not create a situation where there is a pressure to make 95% of everything crap, because you need to get a lot of developers to make things and some of those developers are going to be crap, and you need to make lots of decisions and some of those decisions are goi…

Might be, but I wouldn't discounting culture as a mechanism reinforcing it. People aren't working in isolation; they build on each other, and enshrine "best practices" that are often enough the sources of these problems.

But thinking of it, Sturgeon's law may be at play. PHP used to suffer from similar reputation to JavaScript, and only started regaining its status as a proper server choice once the masses moved to greener pastures. Sure, the language was a "fractal of bad design" and had footguns galore, but it wasn't that bad, and most of the traps were avoidable when you had half a brain and used it. The web may be crap very well because it's where anyone fresh to programming can find a high-paying job, and you can become a "senior engineer" after one year of job experience.

But that, still, is a problem. Outside of programming, there are quality standards on the market - often enforced by governments. Even if 90% of chairs are crap, you can't go and sell that crap to the public. Quality standards filter most of the crap out.

If that's the case, I'm not sure what to do. Introducing quality regulations to programming might help solve the problem of website bloat and constant leaks of private data, but it would also destroy the best thing about the web and programming in general - if you have an idea and a computer, you can make it and show it off to everyone.

Re: Browsers are pretty good at loading pages

#277
post #32

Earlier quoted context omitted.

It takes a little longer to load, but it also lets you continue working while your train goes through a no-internet zone.

textarea manages client-side state just fine in the HTML version.

Can I open and reply to 25 different emails, and have the replies sit in my outbox until I reconnect? Because that’s a lot more useful to me than how fast it loads.

Re: Browsers are pretty good at loading pages

#278
post #275

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…

> Yeah, because most visitors to most websites can and know how to disable images in browser settings.

Maybe they would, if the UX culture of these days wasn't removing every feature that isn't used on every interaction, and then devs wouldn't try to build increasingly complex reimplementations of browser features on each page.

In an ideal world, lazy loading of images would be something handled purely by the browsers, and users would be aware how to operate it. The site's job is to declare what it wants to show; the User Agent's job is to decide what to show, when and how. But nah, the web culture prefers to turn browsers into TVs.

Re: Browsers are pretty good at loading pages

#279

Earlier quoted context omitted.

I have no idea. I do a lot of front end work in React, and the assumption that an SPA is a better experience for people because you don't have to do a page reload to see a new page is really baffling to me. It's widespread too - across industries and disciplines and age ranges, as if the people suggesting these things have never used SPAs.

Because page reloads are jarring and discontinuous experiences. They run counter to a good user experience. That's not to say that every SPA is a good user experience, but just that a page reload is not part of the recipe for a good user experience.

A page reload is part of the expected experience on a traditional site when you're navigating to a new page. I expect it to look like I'm going to a new screen, not simply replacing the content on the existing screen. Not every website is an app or should act like one.

Re: Browsers are pretty good at loading pages

#280
post #277

Earlier quoted context omitted.

textarea manages client-side state just fine in the HTML version.

Can I open and reply to 25 different emails, and have the replies sit in my outbox until I reconnect? Because that’s a lot more useful to me than how fast it loads.

It sounds like a traditional email client would fit your needs perfectly. Check out Thunderbird: https://www.thunderbird.net/
Post reply on HN