4 ms·

Yes! I have gone even more aggressive these days - just stop running JS on client machines at all. Every time a page is slow, breaks, tracks, etc, there is alm

by bArray 9y ago

Yes! I have gone even more aggressive these days - just stop running JS on client machines at all. Every time a page is slow, breaks, tracks, etc, there is almost always one culprit. My rule is now that if you can't load your page in lynx - it's broken. There are few exceptions to this rule in my eyes.

bartread 9y ago
I think it very much depends on a site or web app's purpose. Clearly it's fair to say that many sites overuse JavaScript. On the other hand offloading some computing tasks to the client can save you quite a bit in terms of hardware expenditure on the back end. Again, depends on the site, but many people now have (effectively) supercomputers, so why not leverage some of that? Sometimes it can even enhance the experience, and maybe improve both the perceived and actual performance. There are also cases where a site simply can't be expected to work without JavaScript. One of my side-projects is an HTML5/JavaScript games site. If somebody disables JavaScript they'll get a nice message explaining why they need to enable it to play the games, otherwise what would my fallback option be? Flash? Bleurgh! No thanks.
- DamonHD 9y ago
  There are indeed honourable exceptions, but they are exceptions. The fact that on many corporate sites I cannot even get to see the company name until I have enabled JS in three rounds with NoScript is silly. Sometimes I just don't bother. As yes I am running a supercomputer right now, I quite agree, but I don't want nefarious stuff run on it. And on my mobile I don't want to be wasting my battery power on emulating Deep Thought to get past the throbber. Most sites want you to see some text. Many don't let you see any without scads of JS. (Note: I do use JS to enhance my sites, but the JS is small and the sites work fine without it running.)
  - bartread 9y ago
    Agreed - no text at all without JavaScript is completely ridiculous, and not at all hard to avoid so it's deeply frustrating that there are so many sites that fall foul of it. Even my site, which is a games site containing pages that _simply won't work_ without JavaScript, manages to display something useful even on these pages when it's disabled. There are also sections such as the blog that obviously work fine without it.
- bArray 9y ago
  >Again, depends on the site, but many people now have (effectively) supercomputers, so why not leverage some of that? I agree, but seems ridiculous that my ("super") computer at current is using 7.4GB of RAM and 7% CPU for just FireFox alone, for what is mostly static content. >One of my side-projects is an HTML5/JavaScript games site. If somebody disables JavaScript they'll get a nice message explaining why they need to enable it to play the games, otherwise what would my fallback option be? Flash? Bleurgh! No thanks. That's an edge case, of course, that requires client side computing. The alternative is exceptionally infeasible for everybody involved.
- zkms 9y ago
  I concur. There's some times that running some JS can make the user experience strictly better without taking up any significant amount of memory/CPU time/energy/network (or in fact makes the system use less of those). It's frustrating when some site uses lots of JS to just reimplement browser features (like displaying text, showing a web form, history/links) which makes my laptop's fan spin up -- but doesn't bother using JS to implement genuinely useful things like validating the credit card checksum (https://en.wikipedia.org/wiki/Luhn_algorithm https://en.wikipedia.org/wiki/Luhn_algorithm) in JS on the client before submitting the form.
  - bArray 9y ago
    >but doesn't bother using JS to implement genuinely useful things like validating the credit card checksum (https://en.wikipedia.org/wiki/Luhn_algorithm https://en.wikipedia.org/wiki/Luhn_algorithm) in JS on the client before submitting the form. That's interesting, because that's a case where I would consider it not needed. I've seen some interesting behavior from a network provider where they test "password security" - despite a password I generated meeting all of their rules, the JS fights me because of some bad implementation. Either way, the server must validate the data regardless. From a design perspective, it makes sense to me to have validation done in one place, rather than several. It just seems that they may become out of sync, or lead the back-end developers into a false sense of validation security on a web form. The cost of memory is less in this case (no JS in RAM). The CPU time is probably about the same in total. The energy is probably slightly more. The network usage will be about the same (form submission vs JS validation code). We're talking small amounts here, though. The other thing is that basic HTML is very well nailed in all browsers, whereas JS reliability seems to change depending on the features used, etc. A wake up call for me was when using a slightly older IE browser and using the kindle experimental browser. Both had JS enabled and ran, but ultimately caused the JS rendering to fail for a website I had built in a destructive way (they did half the job of swapping out elements). My current design philosophy is to avoid JS at all possible costs. Minimalism spruced up with CSS.
    - dracos 9y ago
      I do think that credit card websites should implement card checksum, and what type of card it is (rather than asking you), if possible. I understand your points, but they do not change the fact that in this case a full server page refresh, possibly over a very slow/intermittent network, only to tell them something they could have been told instantly, is a poor user experience. Bad implementation, keeping in sync, or lacking server side validation, are bad developer practices just like having some of the page impossible to see without JavaScript. I think it is important to note that whilst my site works perfectly without any JavaScript, I am also a fan of using it where it helps the user.
DamonHD 9y ago
Ha! Yes, that's not a bad rule of thumb for sites that are meant to presenting text to the user. (And yes, I just tried my current pet site and it worked like a charm in Lynx! B^> )

by bArray 9y ago

bartread 9y ago

I think it very much depends on a site or web app's purpose. Clearly it's fair to say that many sites overuse JavaScript. On the other hand offloading some computing tasks to the client can save you quite a bit in terms of hardware expenditure on the back end. Again, depends on the site, but many people now have (effectively) supercomputers, so why not leverage some of that? Sometimes it can even enhance the experience, and maybe improve both the perceived and actual performance. There are also cases where a site simply can't be expected to work without JavaScript. One of my side-projects is an HTML5/JavaScript games site. If somebody disables JavaScript they'll get a nice message explaining why they need to enable it to play the games, otherwise what would my fallback option be? Flash? Bleurgh! No thanks.

DamonHD 9y ago
There are indeed honourable exceptions, but they are exceptions. The fact that on many corporate sites I cannot even get to see the company name until I have enabled JS in three rounds with NoScript is silly. Sometimes I just don't bother. As yes I am running a supercomputer right now, I quite agree, but I don't want nefarious stuff run on it. And on my mobile I don't want to be wasting my battery power on emulating Deep Thought to get past the throbber. Most sites want you to see some text. Many don't let you see any without scads of JS. (Note: I do use JS to enhance my sites, but the JS is small and the sites work fine without it running.)
- bartread 9y ago
  Agreed - no text at all without JavaScript is completely ridiculous, and not at all hard to avoid so it's deeply frustrating that there are so many sites that fall foul of it. Even my site, which is a games site containing pages that _simply won't work_ without JavaScript, manages to display something useful even on these pages when it's disabled. There are also sections such as the blog that obviously work fine without it.
bArray 9y ago
>Again, depends on the site, but many people now have (effectively) supercomputers, so why not leverage some of that? I agree, but seems ridiculous that my ("super") computer at current is using 7.4GB of RAM and 7% CPU for just FireFox alone, for what is mostly static content. >One of my side-projects is an HTML5/JavaScript games site. If somebody disables JavaScript they'll get a nice message explaining why they need to enable it to play the games, otherwise what would my fallback option be? Flash? Bleurgh! No thanks. That's an edge case, of course, that requires client side computing. The alternative is exceptionally infeasible for everybody involved.
zkms 9y ago
I concur. There's some times that running some JS can make the user experience strictly better without taking up any significant amount of memory/CPU time/energy/network (or in fact makes the system use less of those). It's frustrating when some site uses lots of JS to just reimplement browser features (like displaying text, showing a web form, history/links) which makes my laptop's fan spin up -- but doesn't bother using JS to implement genuinely useful things like validating the credit card checksum (https://en.wikipedia.org/wiki/Luhn_algorithm https://en.wikipedia.org/wiki/Luhn_algorithm) in JS on the client before submitting the form.
- bArray 9y ago
  >but doesn't bother using JS to implement genuinely useful things like validating the credit card checksum (https://en.wikipedia.org/wiki/Luhn_algorithm https://en.wikipedia.org/wiki/Luhn_algorithm) in JS on the client before submitting the form. That's interesting, because that's a case where I would consider it not needed. I've seen some interesting behavior from a network provider where they test "password security" - despite a password I generated meeting all of their rules, the JS fights me because of some bad implementation. Either way, the server must validate the data regardless. From a design perspective, it makes sense to me to have validation done in one place, rather than several. It just seems that they may become out of sync, or lead the back-end developers into a false sense of validation security on a web form. The cost of memory is less in this case (no JS in RAM). The CPU time is probably about the same in total. The energy is probably slightly more. The network usage will be about the same (form submission vs JS validation code). We're talking small amounts here, though. The other thing is that basic HTML is very well nailed in all browsers, whereas JS reliability seems to change depending on the features used, etc. A wake up call for me was when using a slightly older IE browser and using the kindle experimental browser. Both had JS enabled and ran, but ultimately caused the JS rendering to fail for a website I had built in a destructive way (they did half the job of swapping out elements). My current design philosophy is to avoid JS at all possible costs. Minimalism spruced up with CSS.
  - dracos 9y ago
    I do think that credit card websites should implement card checksum, and what type of card it is (rather than asking you), if possible. I understand your points, but they do not change the fact that in this case a full server page refresh, possibly over a very slow/intermittent network, only to tell them something they could have been told instantly, is a poor user experience. Bad implementation, keeping in sync, or lacking server side validation, are bad developer practices just like having some of the page impossible to see without JavaScript. I think it is important to note that whilst my site works perfectly without any JavaScript, I am also a fan of using it where it helps the user.

DamonHD 9y ago

Ha! Yes, that's not a bad rule of thumb for sites that are meant to presenting text to the user. (And yes, I just tried my current pet site and it worked like a charm in Lynx! B^> )