undefined | Better HN

0 pointsb_e_n_t_o_n1y ago0 comments

Hmm - what is the actual cost incurred by the users here? Mostly battery right? Is that not virtually inconsequential to each individual?

I mean you could sum it all up and compare it to human-hours or something but that's not a useful metric because it's distributed.

Personally I think it's better to distribute the workload across clients. We'll probably see purely client driven UI's dominate the future. Imagine users being able to display data (because fundamentally that is all a blog [or any site] is) in a way chosen by each user. That would probably be worth the extra cycles on device.

0 comments

shkkmo1y ago

Please, no. Don't use a SPA to render a blog, that's awful.

Browers already give users near complete ability to customize how web pages are displayed and SPAs usually make this worse not better.

The actual cost is forcing users to run javascript, with all its privacy leaks and security issues, to view what should be a static HTML document.

Not to mention the issues you create for battery life, network traffic, caching, etc just because you are too lazy to develop properly.

lelanthran1y ago

> Not to mention the issues you create for battery life, network traffic, caching, etc just because you are too lazy to develop properly.

This is a very uncharitable take.

It's because I know how to develop properly that I want to send the repeated content of the site to you just once; the header, topnav, lhs-nav and footer will be cached if JS is enabled. The cost of that JS is less than the common elements anyway!

lsaferite1y ago

It's funny. Further up in this discussion is someone sharing their demo of using XSLT to dynamically assemble a page from parts. This process properly caches the fragments as well. No JS required, just the default rendering process for the browser. But XML+XSLT is the "red-headed stepchild" that everyone seems to hate.

Writing a SPA just to recreate the built-in functionality of rendering a static page on the client side is overkill IMHO. If it's an actual application (the A in SPA), then fine. But for what is essentially a static website... why?

2 more replies

b_e_n_t_o_nOP1y ago

You need to quantify before you say it's an issue. Eg. if the battery cost is 0.001% vs 0.0011% it's not actually an issue, despite technically being more expensive.

DangitBobby1y ago

In this case, users with JS disabled would miss out on loading, what, a navbar and footers?

And fuck off with "too lazy to develop properly." I am so tired of HN users constantly talking shit about JS. There are times to fight for efficiency but this is just part of a tired crusade.

account421y ago

You're not distributing the workload to clients, you're duplicating it.

Dalewyn1y ago

>what is the actual cost incurred by the users here?

Time.

Every bit of JavaScript is more time to download, execute, and then render the page. Time is a valuable resource, users appreciate not being told to waste it.

>I think it's better to distribute the workload across clients.

The bulk of such loads should and ideally must be on servers, not clients. Use PHP, not JavaScript.

Also worth noting, the biggest motivator for JavaShit by far is the website owner(s) cutting costs. More load on the clients is more idling of the servers, the consequences of this will be homework left for the readers.

j / k navigate · click thread line to collapse