[b_e_n_t_o_n]

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.

[shkkmo]

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.

[lelanthran]

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

[lsaferite]

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?

[chuckadams]

> XML+XSLT is the "red-headed stepchild" that everyone seems to hate

One look at XSLT syntax and you learn why.

[lsaferite]

I mean, I've used XSLT plenty in my career and I honesty don't have any issues with it at a high level. It's essentially just another templating format with the added benefit of being a markup language itself and being rendered directly by browsers without adding any JS.

[lelanthran]

Your take is getting more and more uncharitable.

In what world is 60 lines of JS an SPA?

Come on, enquiring minds want to know. Show us all this SPA you know off that is 60 lines or less.

[lsaferite]

So, I think perhaps you are confusing me with the person further up in the thread. They said "don't use a SPA". You replied with a counter argument about JS. Then *I* pointed out someone else in the thread demonstrating using XML+XSLT to to client-side rendering and I called out people using SPAs to dynamically render what is essentially a static website. So "Your take is getting more and more uncharitable" seem to assume that the GP and myself are the same, and we are not.

Your last line seems overly aggressive and confrontational. I have zero desire to engage with that.

All that being said, have a wonderful day.

[b_e_n_t_o_n]

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.

[DangitBobby]

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.

[account42]

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

[Dalewyn]

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