Hacker News Reader

Comment by birksherty | Hacker News Reader

"I much prefer the current state of affairs to the way things were a decade ago"

It's what the developers say. Every developer has latest macbook, works on a shiny new office with AC with all the bandwidth and gadgets. And they think people all around the world also has the same thing.

Whereas lots of users don't care about the AJAX loading. Users want websites to be fast and less annoying. But, developers only care about latest hot frameworks even though that will make things slow for users.

Newest Youtube redesign is the same. It consumes more cpu and way much slower than the previous one. I know because I don't have a high end laptop and 100mbps internet. It does not matter because Google employees use all the latest gadgets.

View on HN

> Users want websites to be fast and less annoying.

Well, pulling some JSON via AJAX and updating a small part of the page is faster than reloading the entire thing.

You would think so. I mean, that's obvious, right?

And yet websites are slow. That's not just "get off my lawn" crankiness, either. We're now downloading multiple megabytes, and things are rendered via javascript late in the process, so we start seeing content later than we used to, and we get the final render later than we used to.

Modern websites are largely slow and annoying, a topic that has come up many, many times--with benchmarks--on HN.

Doesn't that have to do with overengineering more than anything? Most of the Javascript on a modern website is pretty much superfluous I'd say.

I'd also say that the JS and its burden on CPU, RAM, and battery, is also pretty trivial compared to rich media consuming more than a few MB's off a user's mobile data plan. Many people consider 1 MB to be around the upper guideline for bundle sizes; 2 MB of JS is considered quite big.

But HTML CSS JS cannot compete against rich media, and how badly it drains the user's most finite resource of all -- mobile data. That's what makes an information lookup even on native Yelp costly to the user.

Is JS the problem though? For really heavy apps, sure, but many people consider 1 MB to be a good upper threshold for bundle sizes.

I think the biggest culprit over the web, the thing that makes me hesitant as a mobile user to visit websites willy nilly, is media content, such as images, sound, and video. Many websites look empty without media, so people splatter at least a few things on there, as do advertisements, and I think that's easily a few MB.

I also think the biggest resource that people are consuming nowadays, including well-to-do people with iPhones, is not CPU, RAM, or even battery resource, but mobile data limits.

But why are we loading even 1MB to display 2K worth of text?

If people only wanted 2 kb text pages, it'd be a different story. But rich media is often what people want, so it makes even an information lookup on native Yelp expensive. Once you bring in rich media, 1 MB of JS is very minor, and JS can be used to optimize your rich media downloading.

Sure, but why do I need that crap on pages without rich media? And why do I need to wait for my browser (since it's on a computer other than the latest model iMac) to spend 20 seconds rendering that mess of JavaScript before I can view that content (text OR rich media), when it could display vanilla HTML faster than I can blink?

I'm with you. You'll frequently see news stories with 3-5 MB of junk to augment a < 50 kB piece.That's more information than all of published human writing before 1800. Sorry, but that's stupid, and looks bad. Yes, a good chunk of that is ads, but a lot of it is loading all of two versions of bootstrap so you can use one class and similar silliness.

It's actually often slower. Depending on how much functionality is written in JS and how many API calls you are making. Some single page apps out there can bring my MacBook Pro to a halt with their bloated spaghetti JavaScript and tons of AJAX calls everywhere. Rendering dynamic HTML on the server is often faster.

The problem is latency, which actually will get worse as bandwidth increases.

1 request pulling down 1 Mb can be quicker than 4 requests for 10Kb each.

I found a presentation a while back that covers "website obesity"[0]. It puts some quantifiers on the problem you're describing.

[0]: http://idlewords.com/talks/website_obesity.htm

I think the Youtube redesign idea is to use something like polymers or whatever they are called. They are a Google technology supported in Chrome, but since other browsers need to use some clunky and superslow javascript polyfill Chrome suddenly feels like the fast browser.

Wow, this is evil.

Not really. Other browser vendors can implement the standard too, which is called Web Components.

fyi: It's generally considered bad practice to assume bad intentions when alternative explanations suffice.

I don't think that assumption was unfair. The way that the previous comment was framed, Google implemented this so that other browsers seemed slow. Those intentions seem pretty evil.

With the framing of pushing browsers to implementing the Web Components standard it seems much less evil.

I think the true motivations are likely somewhere in the middle.

It's still a draft i think.

you're right, they used Polymer and Material Design for the frontend in combination with the spfjs framework, which was introduced in 2014.

https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtu...

https://github.com/youtube/spfjs

https://www.youtube.com/watch?v=yNe_HdayTtY

Google developers definitely know there's a problem https://www.youtube.com/watch?v=4bZvq3nodf4

Reply on news.ycombinator.com