Hacker News Reader

Comment by joekrill | Hacker News Reader

I'm going to go against what appears to be popular opinion and suggest that this reeks of a "back in my day..." complaint.

There's always been poorly-written software, poorly-created websites, bad UIs, bad UX, etc. And I don't see that changing anytime soon. Suggesting that the entire web is devolving into a vat of poor decisions is, I think, a bit alarmist. Technology changes, things progress, sometimes things get slightly worse before they get better. But I think, on the whole, things are moving in a good direction. And we'll always be able to pick out a few bad examples to justify why the sky is falling. But in the end, I much prefer the current state of affairs to the way things were a decade ago.

View on HN

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

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

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

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

I think the point here is that websites where you come for information should give you just that - information, and not to get in your way. Let me dissect the problem into parts: * Bloat - not only HTML, but also CSS, JS, a ton o plugins, social media buttons etc. This all slows things down and often obscures the content - that is the very reason you came to visit the site. * Poor UI decisions - with plain ol' HTML a link is a link, an image is an image - when you try to change an HTML document into an app you have to mix different roles. * User-hostile decisions - popups and similar, lack of permanent links, etc. In vanilla HTML you didn't have these.

This has nothing to do with "back in the old days". The web in the 90s was very often horrible, and Flash made it worse (although it's a pity Google and Apple killed it - Adobe could well have opened it when they had a chance and we could all enjoy an independent open platform - but that's a topic for another discussion.)

The problem is the bad stuff seems to be the norm. I wanted to use Patreon's embed code on my site. The embed loaded megabytes of JavaScript to show a button. All the button does is take you to my Patreon.

I took a screenshot, cropped it, saved it as PNG, and embedded it with a plain old image tag. 3KB vs. 3000KB, and maybe I lost some fancy auto-scaling magic the culled JavaScript did. Big deal.

This is a company that positions itself as the new way for creative people to make a living in the 21st century, and they need multiple megabytes and several seconds to load the 175x36 road into that future. We're not quite in the future yet, and 3MB is still a lot to ask of limited data plans.

> The embed loaded megabytes of JavaScript to show a button.

They're probably hooking into their analytics platform.

> There's always been poorly-written software, poorly-created websites, bad UIs, bad UX, etc...

Yes, but the bad websites in the old days didn't lug in a bunch of unnecessary js to accomplish their aim. I do think things are improving as a whole, like you do, but we're currently on the latter half of a pendulum swing from barebones to over-engineered.

Don't forget we used to have flash back then. It wasn't pretty.

Yeah, but basic news or discussion sites didn't use Flash. In fact, the vast majority of sites didn't; or only used it for games or video - i.e. use cases that called for it.

And "Flash sucked" is no excuse for the web being bloated and delivering text content in ridiculously stupid ways today.

does pragmatism really fade away in the face of progress?

Reply on news.ycombinator.com