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.
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.
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.)
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) 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.
A handful of lines of JS that runs the Luhn checksum on the number in the "credit card number" field is not at all CPU intensive and can save people from such data entry errors.
If I typo the card number and there's no JS code to tell me that, I need to submit the form, wait for it to error out, have to re-enter all the billing address information, re-enter the card number, and try this whole process again. I've resorted to re-typing the card number in the "find" box and making sure that it matches the number in the form's field, just to avoid this crap.
That doesn't necessarily have to be the case. If done correctly, the page could come back with errors and the form already filled out. If the connection is secure enough to fill out the form - it must be secure enough to return your data you entered.
I think javascript is a nice addition to client side validation of forms, but it must not impact how they use the system. Having a piece of JS run and not allow me to submit a form is really terrible design, especially when the validation it is doing is running incorrectly.
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.