Live data from Hacker News

The Bullshit Web

pxlnv.com

341–350 of 568 posts

Re: The Bullshit Web

#341

Earlier quoted context omitted.

I agree in theory. However, I haven't noticed the slowness in their website and the ads are well done and blend in with the webpage. They may have to redesign/rearchitect their whole website to get what you are asking for. It should be noted that traditional newspapers include ads alongside news content and no one complains. In fact people used to sift through the Sunday NYT simply for the ads.

There is no such thing as "the ads are well done and blend in with the webpage". Especially on a website where you pay for a subscription.

That's no different from paying for a real newspaper subscription though.

But I guess you could say that you are paying for delivery instead.

Re: The Bullshit Web

#342
post #45

Unpopular opinion alert: Maybe the "bullshit" is only bullshit to you, the thorny tech-savvy reader. Maybe businesses have tried the plaintext approach, and their business was improved by adding fonts, stylesheets, API calls, spinners, scripts, high-res images, and god knows what else. Maybe speed improvements are not important beyond a certain point. Maybe 5MB doesn't matter to most people. Maybe micro-optimization…

Or maybe it's really easy to have all the individual decisions make sense, but still arrive at a really insensible complete decision. Like a local maxima.

It's easy to be smart, make smart decisions and end up somewhere dumb.

Re: The Bullshit Web

#344
post #103

Earlier quoted context omitted.

You can do all of those analytics server side, there's no reason to deliver it via JS and have the client do the computation. You're already sending all the required info to track that sort of thing via the request itself.

It's amazing to me that no one out there seems to do server-local handling of ads, either... If you put ads directly into your page instead of relying on burdensome external systems, suddenly blocking isn't a thing anymore. ALL of the functionality supposedly needed for analytics and an ad-driven business model can happen server side, without the page becoming sentient and loading a billion scripts and scattered reso…

I don't think it's very surprising. Advertisers won't let publishers serve ads directly because that requires trust in publishers to not misrepresent stats like impressions and real views. I don't know how you'd solve that trust problem when publishers are actually incentivized to cheat advertisers.

Re: The Bullshit Web

#345

We have a ridiculously-backwards model on the web where you essentially pay for what you use (via your data plan, and via forced ads prior to promised content) without having any way to know in advance what it will end up costing you to display content. Heck, you don’t even know if the content will display correctly after all that loading. Worse, there are many ways to trigger loads accidentally, meaning you may want…

So while you are fiercely criticizing sites which apparently understand and leverage the reality of zero-marginal cost digital data, you assume that data caps are a necessity in a digital world. Workers don't shovel extra connectivity into the towers when you go over your data cap. So why are you focusing on data flowing over the nearly-always-on connection you have through your data plan, rather than the bullshit te…

Data caps are like your city bus. You can buy a bulk number of rides per month at a discount, and everything over that is billed at a regular rate.

The bus doesn't magically add more seats when you make extra trips on it, but it still costs more to take the bus three times a day than twice a week.

Even though the marginal cost of your body on the bus is minimal, having the fee serves to reduce crowding (demand at that price point) as well as fund the infrastructure. Data caps are the same.

Now, you can argue that data caps are surrounded by deliberately misleading marketing and that overage charges are unnecessarily steep. But you seem fundamentally opposed to the concept of data caps.

Re: The Bullshit Web

#346

Earlier quoted context omitted.

What do you mean by "bloat is on the mobile side"?.

The problem with bloat. That is, web pages are just much slower to download and render on mobile than on desktop. E.g. a page that takes less than a second to load on desktop can easily take ten seconds to load on mobile. But two or three years from now, that same page will load in less than a second also.

You may wish to re-read the article, right from the beginning. Mobile phones are already faster and better than the author's computer attached to his 56K modem way back then.

Re: The Bullshit Web

#347
It strikes me that, if people want web developers to load less stuff, there have to be ways to reduce redundancy. It might also make privacy easier.

For example, some sort of self hosted standard based framework for tracking common things like scrolling or ad clicks or page visits that supports multiple consumers, both internal to the site publishers for detailed analytics and logging and ad view tracking, and less granular access for external companies that can add value can get information from. Your user's data stays on your self hosted user data server, and analytics can make server to server requests for aggregate data with GraphQL or a standardized api at least, improving user privacy.

If you really needed additional functionality, there could be standardized add-on modules, or updates to the spec.

Re: The Bullshit Web

#348
Oh yay, another article complaining about all the bullshit modern websites want to load, and then also complaining about the best solution so far.

Yes, it sucks that amp requires loading a chunk of js from Google. But you know what? It actually makes things better. It solves a real problem, better than anything else is solving any similar problem. Nobody else is successfully convincing publishers to slim down their pages.

If you have a better plan, let's hear it. But bitchy blog posts aren't going to convince your local paper to improve their page speed.

Re: The Bullshit Web

#349

I disagree that the AMP cache is the main benefit of AMP. There are plenty of CDNs that give performance similar to, or better than the AMP cache. The only benefit of AMP is that the pages are promoted higher in results. Back to the main topic of the article, the same could be said for the desktop and the mobile phone. Developers and framework builders are constantly adding bloat as cpu/memory increase. Since most pe…

>The only benefit of AMP is that the pages are promoted higher in results. Not just promoted in the results but actually pre-loaded in the background when you're using google search. It's double the monopoly fun.

True. Hopefully anti-competitive stuff like this will be challenged in court so we don’t have to play the game.

Re: The Bullshit Web

#350

Earlier quoted context omitted.

> but low efficiency has no business- or environmental- downside, then why be efficient with it? But it has. Data transfer and processing isn't free. It works on electricity. You may think that a difference between 10KB (efficient) and 10MB (current web) is meaningless because resources are abundant, and it let you save couple hours of dev time[0] - but consider that this difference is per user , and you saved a coup…

I don't think people actually waste three orders of magnitude more electricity by loading 10MB vs 10KB - sure, that much more CPU time is used specifically on loading the extra data, but that would be a fraction of what's being used for all the other processing going on, and people don't just flip the power switch as soon as a page load finishes.

I agree with your point, but the GP's has validity too: the infrastructure to get that page to where it is read, does draw power in proportion with the amount of data it's handling.
Post reply on HN