3 ms·

I did think about that! However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website. Forcing users to run cod

I did think about that! However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website. Forcing users to run code just to render some boring text seems like a waste.

b_e_n_t_o_n 2y ago
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 2y 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.
  - DangitBobby 2y 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.
  - lelanthran 2y 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!
    - lsaferite 2y 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?
      - lelanthran 2y ago
        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 2y ago
        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.
      - chuckadams 2y ago
  - b_e_n_t_o_n 2y 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.
- Dalewyn 2y 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.
- account42 2y ago
  You're not distributing the workload to clients, you're duplicating it.
lelanthran 2y ago
> However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website. If you set the bar to "0% JS at all costs" then you can't very well complain about how hard it was to maintain HTML. Part of the standards, whether we like it or not, is JS. A sprinkling of JS (say, 60 lines?) to do client-side includes does not in any noticeable way increase the workload of the client, nor deteriorate the experience of the user. After all, you provide a CSS file, right? The JS to do client-side includes using a custom element (so that `<client-side-include remote-src="...">` works) is unlikely to surpass a modest CSS file in terms of size.
- shkkmo 2y ago
  The argument is not to never use JS. The argument is that you shouldn't unnecessarily use JS in a way that breaks core functionality if it is disabled. There is no actual need solved by using client side include to load a nav bar. Doing so will break navigation on your blog for people without Javascript enabled. Even though it isn't talked about as much these days, progressive enhancement is still a really good idea.
  - lelanthran 2y ago
    > There is no actual need solved by using client side include to load a nav bar. I disagree: this[1] was such a dealbreaker that it caused the developer to literally switch stacks to get back the same feature. When you find yourself switching stacks to get some feature, trust me, it's really needed. > Even though it isn't talked about as much these days, progressive enhancement is still a really good idea. Sure, and in this specific case all the dev had to do was include a link in each blog post to the root of the site `<a href='/'>home</a>`. So when the JS is turned off the user can still navigate. Once again, I am going to point out that plain HTML+CSS+JS is conformant to the relevant specifications; when a user wants to to, for whatever reason, deviate from the specification, they already know that most things won't work for them anyway! IOW, you're not dealing with a clueless user who will wonder why the page has no navigation, you're dealing with someone who spent extra work and effort to get into the state they are, so they're already aware that most things don't work for them anyway! But you responses throughout this thread is working on the assumption that megabytes of JS is required if you want client-side includes, and you coupled that with an implication that only incompetent developers would go down that route. I can assure you, as a competent developer, that adding client-side includes with graceful degradation is maybe 60 lines of JS, cached, with no noticeable delays for the user. If you think that the only options are a) Doing a full SPA with megabytes of JS, or b) No Javascript whatsoever, then I think that you're in no position to be calling other developers incompetent or lazy.
netsharc 2y ago
> Forcing users to run code just to render some boring text seems like a waste. Do you serve your content with "Content-Type: text/plain"? Client-side parsing of HTML and CSS, layouting, etc, is a looot of code.

b_e_n_t_o_n 2y ago

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 2y 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.
- DangitBobby 2y 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.
- lelanthran 2y 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!
  - lsaferite 2y 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?
    - lelanthran 2y ago
      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 2y ago
        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.
    - chuckadams 2y ago
- b_e_n_t_o_n 2y 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.
Dalewyn 2y 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.
account42 2y ago
You're not distributing the workload to clients, you're duplicating it.

lelanthran 2y ago

> However, I didn't like the idea of making the client side do work to make up for my own poorly-managed website. If you set the bar to "0% JS at all costs" then you can't very well complain about how hard it was to maintain HTML. Part of the standards, whether we like it or not, is JS. A sprinkling of JS (say, 60 lines?) to do client-side includes does not in any noticeable way increase the workload of the client, nor deteriorate the experience of the user. After all, you provide a CSS file, right? The JS to do client-side includes using a custom element (so that `<client-side-include remote-src="...">` works) is unlikely to surpass a modest CSS file in terms of size.

shkkmo 2y ago
The argument is not to never use JS. The argument is that you shouldn't unnecessarily use JS in a way that breaks core functionality if it is disabled. There is no actual need solved by using client side include to load a nav bar. Doing so will break navigation on your blog for people without Javascript enabled. Even though it isn't talked about as much these days, progressive enhancement is still a really good idea.
- lelanthran 2y ago
  > There is no actual need solved by using client side include to load a nav bar. I disagree: this[1] was such a dealbreaker that it caused the developer to literally switch stacks to get back the same feature. When you find yourself switching stacks to get some feature, trust me, it's really needed. > Even though it isn't talked about as much these days, progressive enhancement is still a really good idea. Sure, and in this specific case all the dev had to do was include a link in each blog post to the root of the site `<a href='/'>home</a>`. So when the JS is turned off the user can still navigate. Once again, I am going to point out that plain HTML+CSS+JS is conformant to the relevant specifications; when a user wants to to, for whatever reason, deviate from the specification, they already know that most things won't work for them anyway! IOW, you're not dealing with a clueless user who will wonder why the page has no navigation, you're dealing with someone who spent extra work and effort to get into the state they are, so they're already aware that most things don't work for them anyway! But you responses throughout this thread is working on the assumption that megabytes of JS is required if you want client-side includes, and you coupled that with an implication that only incompetent developers would go down that route. I can assure you, as a competent developer, that adding client-side includes with graceful degradation is maybe 60 lines of JS, cached, with no noticeable delays for the user. If you think that the only options are a) Doing a full SPA with megabytes of JS, or b) No Javascript whatsoever, then I think that you're in no position to be calling other developers incompetent or lazy.

netsharc 2y ago

> Forcing users to run code just to render some boring text seems like a waste. Do you serve your content with "Content-Type: text/plain"? Client-side parsing of HTML and CSS, layouting, etc, is a looot of code.