Hacker News Reader

You're thinking about it wrong. The overall effect is not that users will take control over their data, or whatever. The effect is that users will complain that the site is broken. And then the pointy-haired boss will demand that the pop-up is fixed. Now instead of "page weight" being "blah blah nerd bullshit," it is something the pointy-haired boss will demand from ad network partners, and the effects will spread across the web ecosystem.

Given the choice between a person with a particular hairstyle and a person who minimizes the value of others by mocking their appearance, I would choose to work with the former.

https://en.m.wikipedia.org/wiki/Pointy-haired_Boss

"Pointy-hair" is not a hairstyle that even exists in reality. It's a Dilbert reference.

https://i2-prod.mirror.co.uk/incoming/article7110907.ece/ALT...

I doubt the singer from Prodigy has ascended to any position of corporate authority.

Nevertheless, he does have the hair for it.

>And then the pointy-haired boss will demand that the pop-up is fixed.

Which they can do by finding a way to load a lot of JS that doesn't trigger the popup (someone below mentions running eval on a png). This will likely make the site even slower to users but there won't be a popup.

I've found it best to never assume that intelligent creative people will choose the specific approach I want to solve a problem.

It's always wise to be careful how you pick your targets because people optimise for them in ways you don't expect so if you pick the wrong ones then you get unwanted outcomes.

I've seen it happen in sales, you focus on add on warranties at head office, store level they convince customer to buy cheaper product and sell the warranty (now if the margin on the warranty is high enough to offset that might be a smart move) or in one memorable instance give everyone a discount equal to the cost of the warranty..

We did wonder how that branch was selling more warranties than the next three best performing.

Yup. I work in healthcare and one story I hear is about readmission rates to hospitals. Basically, you don't want people to have to go back to the hospital after a procedure due to complications. So it makes sense for Medicare to reward hospitals and surgeons with low readmission rates. All good. Except for one little problem, there's one kind of patient that never ever gets readmitted. A dead one. And studies have shown that decreases in readmission rates are correlated with increases in morality rates (at least for certain procedures).

I don’t see why the runtime/interpreter couldn’t keep accurate count of the amount of code it has loaded at any time. We trust the implementers to handle much harder things already.

Is that really meaningful when a single photo will have far more data than most JS payloads?

Judging it by KB of data just doesn't make sense, unless you apply it to everything. And then it would show on pretty much every site.

Javascript also has the overhead of parsing the source code in addition to network transfer, which can easily take multiple seconds with a multi-megabyte bundle and that's a penalty even when the js is served from the browser cache

True, but JS with a really inefficient loop can do the same. That's the problem in judging by KB, it isn't really very conclusive. Browsers already alert on long-running scripts, maybe the threshold on that should be brought down instead.

> We know that users presented with these kinds of dialogs don't read them. They just blindly click "OK" to get the dialog to go away. So now you're just annoying people to no good purpose.

I would say you're annoying some people so others have the ability to make that choice, and the site developers will definitely see the friction of that dialog as something to be avoided. It incentivizes good behavior.

> It's measuring the wrong thing. 1 kilobyte of badly written code can do as much or more harm to the user experience than 1 megabyte of well written code will.

That depends entirely on your connection, keeping in mind your connection might be from your phone, when you have very poor reception.

The fact that people are immediately assuming it only matters for execution time after loading illustrates part of the problem, which is that developers often forget about entire classes of access and thus don't consider the problems they create for them.

> I would say you're annoying some people so others have the ability to make that choice

That is justification for opt-in instead of opt-out for this feature. But you lose that incentive you want. Want to make your users happy and have on-by-default protection to incentivize better resource management? Gotta get out of the users' way.

> That depends entirely on your connection, keeping in mind your connection might be from your phone, when you have very poor reception.

Even large payloads on slow connections can be worked around if you know what you are doing. If your site is well engineered to progressively enhance without disruption, it does not matter if JavaScript is being loaded in the background.

> If your site is well engineered to progressively enhance without disruption, it does not matter if JavaScript is being loaded in the background.

Yes but how many places actually make this effort? Seems to me that most places are very content to make some monstrous multi-MB React/Angular/etc app, ship it and wash their hands. The number of websites that have actually gone to the effort of optimising their sites is extremely small, so I'm doubtful when someone says "oh but web apps can do this too, if you only just progressively load/build it properly/etc" because that implies effort that so far, seemingly no one has gone to the trouble of actually doing.

It's not common enough, but I think the situation is getting a bit better. Node and React made it greatly easier to render your pages on the server side, and I've seen a lot more sites do it.

"Your connection is using RSA signatures instead of ECSDA. Do you want to continue?"

"The bits for this website traveled through a router in Europe. Do you want to continue?"

"This website uses some special behavior that isn't part of the w3c spec and works slightly differently in your browser than in other browsers. Do you want to continue?"

"This website was developed by a company that offers its employees below market rate health insurance. Do you want to continue?"

There exist people who'd like to know about each of these things. It would be insane to make them dialog boxes.

You’re right that saying 5MB lacks context. Instead they could use BW and latency to offer a “congestion” index the user could gauge and load js or not load js.

Just load the site. If it's too slow for your connection that's a subjective call. Close the window if you're unhappy. Deal with it.

Having to support people who refuse to load more than arbitrary amount X of JavaScript would be ridiculous.

It's not so ridiculous to expect progressive enhancement to work. It takes designers willing to use <a> and <img> tags for that to happen.

It is ridiculous when there's so many gradients and things to accommodate.

Perfect is the enemy of good.