Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How web bloat impacts users with slow devices

danluu.com

Post reply on HN
Print view View original

581–590 of 613 posts

Re: How web bloat impacts users with slow devices

#581

Post by Tainnor »

That exchange with Jeff Atwood makes me somewhat angry. It's one thing to be annoyed at a hardware vendor (justified or not), quite another to take it out on the users of said hardware.

And while I appreciate that engineers can often afford to be blunter than people in other disciplines, I also think that a founder of two successful companies should have a bit more restraint when posting. Writing "fuck company X" (unless we're talking about a grossly unethical company, maybe) just seems like very immature behaviour to me.

Re: How web bloat impacts users with slow devices

#582

Post by acdha »

Karrot_Kream wrote: post #550
acdha wrote: post #542

Earlier quoted context omitted.

This felt more true a decade ago but there’s been a lot of improvement in both languages (e.g. Rust) and libraries - I routinely see most of the cores on my Macs fully loaded for things like working with media files which used to be single-threaded.

Languages are getting there but based on how much heartburn Rust's async causes, I still find it to be a very hard problem to give programmers a real multicore abstraction. And it starts from the ground up with operating systems designed around single core ideas. When I first read about the multi core vs single core debate in college, I thought it was silly and that multi core would be just fine. But over the years I…

async isn’t the only option: threading scales well and is often much easier to write and make production-ready (e.g. reasoning about peak memory usage can be hard in an async model).

Re: How web bloat impacts users with slow devices

#583

Post by niels_bom »

porcoda wrote: post #313

I like how most people blame bosses or scary big companies. No developers appear willing to admit that there is a large cohort of not that great web programmers who don’t know much (and appear to not WANT to know much) about efficiency. They’re just as to blame for the sad world of web software as the big boss or corporate overlord that forced someone to make bad software.

It might also be people not willing to admit that they don’t know how to optimize website performance. And if you have a somewhat complex web app it can be complicated, especially if your stack doesn’t help you (looking at you React).

Re: How web bloat impacts users with slow devices

#584

Post by apatheticonion »

jenadine wrote: post #404
apatheticonion wrote: post #360

This is why I'm excited for Web Assembly. Writing an efficient high performance, mutli-threaded GUI in Rust or Go would be awesome. Just waiting on it to be practically usable

I wouldn't be so sure. The browser ultimately need to render the UI from the DOM which is intrinsically linked with JavaScript. Wasm can help for some of the application logic maybe. But it also comes at a cost of some fixed overhead to bring up the wasm blob. JavaScript performance aren't that bad for UI.

The argument I'm making is one for increased choice in the technologies we have available to us as web developers, particularly when it comes to writing applications that aim to accommodate users with slower/more affordable devices.

In a lot of cases, shipping a wasm blob is not that bad. Depending on the language; compressed and optimized blobs are only a few kilobytes and can be "code-split" such that they are lazy loaded.

Wasm binaries also evaluate faster than JavaScript which could lead to better "web vital" metrics (like "time to first paint/interactive", though anyone can write a slow application in any language so that's not a given).

Syntactically, there is nothing missing from other programming languages that make them unsuited to working with DOM APIs.

The real blocker is waiting for wasm to gain access to DOM APIs thereby dropping the need for JavaScript glue code - once that constraint is lifted, I see no reason why it wouldn't be practical to use an alternative to JavaScript for web development.

JavaScript is practical and useful in _most_ web development cases because the runtime is built in, the ecosystem around it is quite mature and the use cases aren't that complex - however there are many cases that would benefit from more performant languages (think YouTube, Jira, VSCode, banking apps, etc).

When thinking about the "next billion" internet users (related to the topic of the article), we are going to see more users with affordable devices that feature many cores with lower clock speeds. In such contexts it is vital to efficiently leverage the available client device hardware resources - something that JavaScript isn't well suited to and something most of us don't experience (the privilege of having fast computing hardware).

Take multi-threading as an example. JavaScript's single threaded non-blocking nature is safe/ergonomic from a programming perspective and fantastic on devices that feature fast individual cores - however it falls over when clients have slower devices with more cores.

Ideally, we need _the choice_ to follow a more conventional multi-threaded model in cases where we care about performance (a UI thread + worker threads, like we see in native apps/desktop applications). The only initiative that has the potential to get us there is wasm.

Re: How web bloat impacts users with slow devices

#585

Post by apatheticonion »

atahanacar wrote: post #402
apatheticonion wrote: post #360

This is why I'm excited for Web Assembly. Writing an efficient high performance, mutli-threaded GUI in Rust or Go would be awesome. Just waiting on it to be practically usable

Because non-web applications are always very efficient and high performance, right? The problem isn't the technologies available to us. Majority of devs just have no desire to write efficient code.

I hear you. I think it's important to lead by example here and demonstrate the value of performant software that is accessible to a wider range of users/devices.

Native apps do demonstrate that there are performance gains to be made with languages better suited for runtime performance (think threads, AOT compilation, etc)

Just because there is currently a culture in the web development world that de-emphasises the importance of performance, doesn't mean we shouldn't strive to offer better tools to developers.

Right now, wasm is the only feature on the web that has the potential to offer that capability to developers - so I'd say that it's worth wanting and asking for the choice to use better tools for web applications.

Re: How web bloat impacts users with slow devices

#586

Post by MiddleEndian »

aembleton wrote: post #570
MiddleEndian wrote: post #197

Earlier quoted context omitted.

I have a Palm Phone. I generally consider web browsing to be almost impossible no it at this point lol

Are you able to change the DNS on it to NextDNS or LibreDNS: https://libredns.gr/ Blocking ads and trackers might help you to browse the web.

I block ads with uBlock Origin in mobile Firefox. I can use simple sites like hacker news, and I can actually use old.reddit.com if I'm willing to zoom in and out a bunch.

The Palm Phone lags with just about everything honestly, but I like the form factor of having a phone the size of a credit card. But since software only gets slower, most of the web is just beyond it at this point.

Re: How web bloat impacts users with slow devices

#587

Post by db48x »

lelanthran wrote: post #126

This article is basically unreadable for me 48 y/o on desktop). In the dev tools I added the following to the body to make it readable: font-size: 18px; line-height: 1.5em; max-width: 38rem; Now look how readable (and beautiful) it is. I read a lot of Dan Luu's posts, and each time I have to do this sort of thing to make it readable. Seriously, techies, it's an extra 64 Bytes to make your page more readable.

Why don’t you just change your browser’s default font size?

Re: How web bloat impacts users with slow devices

#588

Post by db48x »

youngtaff wrote: post #531
kjkjadksj wrote: post #512

Earlier quoted context omitted.

Its already perfectly readable on mobile either vertically or horizontally (a rare affordance these days)

Might be for you, but the tiny text and cramped line height makes it painful for me Pretty sure the text size is likely to be marginal from an accessibility PoV, and the line length doesn’t aid readability

This page doesn’t specify _any_ font size. It relies on your browser to choose an appropriate size instead. If the text is too small for you to read, then your browser settings for default font size are wrong.

Re: How web bloat impacts users with slow devices

#589

Post by db48x »

hmottestad wrote: post #132
lelanthran wrote: post #126

This article is basically unreadable for me 48 y/o on desktop). In the dev tools I added the following to the body to make it readable: font-size: 18px; line-height: 1.5em; max-width: 38rem; Now look how readable (and beautiful) it is. I read a lot of Dan Luu's posts, and each time I have to do this sort of thing to make it readable. Seriously, techies, it's an extra 64 Bytes to make your page more readable.

It’s pretty terrible on my phone too. Almost no margins and small font. Thankfully Reader Mode works in Safari, which fixes everything.

This page doesn’t specify _any_ font size. It relies on your browser to choose an appropriate size instead. If the text is too small for you to read, then your browser settings for default font size are wrong.

Re: How web bloat impacts users with slow devices

#590

Post by db48x »

wraptile wrote: post #406
nottorp wrote: post #400

Earlier quoted context omitted.

> max-width: 38rem; Now look how readable (and beautiful) it is. How is it readable when you're limiting text width and not taking advantage of the whole screen you paid for? [Turning 48 next month and wearing glasses.]

FYI the optimal line length is 50-75 characters and that has been the standard for text since the type writers. You don't want to move your neck when you read a single line that's kinda silly.

If you have to move your head when reading text in your web browser, then your web browser’s window is too wide. Narrow it until you are comfortable, but don’t try to impose your limitations on other people.
Post reply on HN