Hacker News Reader

Comment by DamonHD | Hacker News Reader

> Of course, it all displays fine if JavaScript is not available, defaulting to visible – something I wish I could say was true of all sites.

Hurrah! I am very bored of sites which need you to run 100 bits of JS, often from multiple sites, before displaying any actual content? Why?

As I've said before, I try and make the first ~10kB delivered to the browser be able to render everything important above the fold, and have everything work reasonably in the absence of JS, eg for those of us running NoScript or similar out of caution.

http://www.exnet.com/Style_Guide.html

View on HN

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.

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.

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

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.

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

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) in JS on the client before submitting the form.

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

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.

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.

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.

> zkms 10 hours ago | parent | on: Performance notes

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.

FYI, I'm playing devil's advocate here a bit to see how far you can push this.

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.

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^> )

Progressive enhancement is the rule

Reply on news.ycombinator.com