> 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.
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
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.
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.
This site is great and I used it daily while I lived in London. Perfect for mobile. It's a real kindness of the creator to have kept it so simple and consistent over the years. I can't think of another site with as good a bytes:utility ratio.
Minor quibble but in case anyone wonders like I did, the cases for units are mostly backwards. When he writes "Kb", he means "kB" (I looked at the size of the homepage, which is 10kB).
For anyone wondering what I'm talking about, the kilo prefix is lower case K, the symbol for a byte is upper case B and lower case B is a bit. Kb = kilobit with badly capitalised kilo. kB = kilobyte. kb = kilobit.
Also, interestingly, the JEDEC unit for 1024 bytes is KB while the metric one is kB. This is the only somewhat unambiguous JEDEC unit, the other two are corruptions of metric units.
Sorry to confuse, now fixed. Think I just predate all this standardization. I did mean KB (at least, that is what DevTools uses and from where I copied the figures :) ).
Especially since the official site (http://www.nationalrail.co.uk/) has been broken for a few months if you have NoScript, even if you enable all of the 30 or so Javascript sources.
The technical problem is that if you visit the site at all without Javascript, it puts a cookie in an incorrect path, which causes all subsequent searches on the site to fail (even with full JS). Despite my attempts to get past the front line support I've still not found anyone there who is able to understand why this would be a problem. This level of incompetence makes me wonder about the whole operation.
Trainline is a fairly typical commercial website. It won't work without javascript and cookies enabled, it wants to track you, it doesn't follow accessibility guidelines and is over a megabyte and a half in size. If you access it on a mobile device it has the usual annoying ad for the pointless mobile app (complete with onerous Ts & Cs, overly grasping permissions and invasive privacy policy) covering a quarter of the screen with the tiny dismiss button. In short, everything that's wrong with web development these days and defensible only because it's one of many.
By contrast traintimes.org.uk is simple, highly usable, small, accessible, respectful of privacy and works as plain html.
For me it's an easy choice but your mileage may vary!
Just to note, though, that you can book tickets with Trainline, which you can't with traintimes.org.uk, it does have limits :) However, Trainline charge a booking fee – https://ehelp.thetrainline.com/app/answers/popup_detail/a_id... – and so I would suggest using any train operating company site (they all sell nearly all tickets), whichever one you find most agreeable.
Something that has tripped me up a bit with service workers is this:
I can use the service worker to cache all the things, and I can embed their hashes in the service worker so it knows when to refetch code that has changed, but how do I tell browsers to refetch the service worker script itself (to get the latest hashes)? I've read some people suggesting a no-cache header on just that file, although I see that isn't used here, and it seems to defeat the purpose somewhat. How do other people handle that?
traintimes.org.uk is a masterwork. The URL schema is simple enough to remember - always cool to tell people "just go to traintimes.org.uk/leeds/london"!
I'm working on a similar minimalizing project and really appreciate you sharing this.
These types of write-ups are some of the best resources as I've grown as a developer. It's a great feeling to come across one that exactly answers something you're stuck on, or explains some concept that you're pretty sure exists but you have no idea where to start.
> If you don't have a CSS cookie set, I inline the CSS in the HTML, load the CSS file asynchronously with a slightly adapted loadCSS JavaScript, and set the cookie.
What is the purpose of the cookie here? Is CSS being stored in the cookie? Does the value of setting the cookie exceed using an Etag to only load the CSS if it's modified?
I’ve reworded that bit, sorry, it wasn’t very clear!
It is as krallja says; inlined on the very first request (so any caching headers such as ETag wouldn't help, though I do set them for anything subsequent) so there is no display blocking fetching the CSS needed for display (as I have little CSS, I inline all of it, but you might want critical CSS only).
A good read, though funnily enough the live departures board doesn't seem to work for the closest station to me. Nor does it seem to work for lines that have trains going in both directions.
Though to be honest most things don't, I blame being rural.
40 comments
[ 3.5 ms ] story [ 87.8 ms ] threadHurrah! 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
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.
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.
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.)
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.
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.
(And yes, I just tried my current pet site and it worked like a charm in Lynx! B^> )
For anyone wondering what I'm talking about, the kilo prefix is lower case K, the symbol for a byte is upper case B and lower case B is a bit. Kb = kilobit with badly capitalised kilo. kB = kilobyte. kb = kilobit.
Also, interestingly, the JEDEC unit for 1024 bytes is KB while the metric one is kB. This is the only somewhat unambiguous JEDEC unit, the other two are corruptions of metric units.
However the SI k prefix means 1000 (10^3) rather than 1024, which would be Ki.
Also, Ki is an IEC prefix and distinct from the metric system. Metric doesn't have anything other than decimal prefixes as far as I know.
The technical problem is that if you visit the site at all without Javascript, it puts a cookie in an incorrect path, which causes all subsequent searches on the site to fail (even with full JS). Despite my attempts to get past the front line support I've still not found anyone there who is able to understand why this would be a problem. This level of incompetence makes me wonder about the whole operation.
It was actually the thing that made me switch to using http://traintimes.org.uk/ permanently.
By contrast traintimes.org.uk is simple, highly usable, small, accessible, respectful of privacy and works as plain html.
For me it's an easy choice but your mileage may vary!
My daily commute to Walsall has been made extra-efficient through this work
Many thanks, and, for the record, works fine on Seamonkey with NoScript on OpenBSD which is pretty minority.
Well done.
I can use the service worker to cache all the things, and I can embed their hashes in the service worker so it knows when to refetch code that has changed, but how do I tell browsers to refetch the service worker script itself (to get the latest hashes)? I've read some people suggesting a no-cache header on just that file, although I see that isn't used here, and it seems to defeat the purpose somewhat. How do other people handle that?
EDIT: At least I'm not the only one: https://github.com/w3c/ServiceWorker/issues/893
These types of write-ups are some of the best resources as I've grown as a developer. It's a great feeling to come across one that exactly answers something you're stuck on, or explains some concept that you're pretty sure exists but you have no idea where to start.
> If you don't have a CSS cookie set, I inline the CSS in the HTML, load the CSS file asynchronously with a slightly adapted loadCSS JavaScript, and set the cookie.
What is the purpose of the cookie here? Is CSS being stored in the cookie? Does the value of setting the cookie exceed using an Etag to only load the CSS if it's modified?
It is as krallja says; inlined on the very first request (so any caching headers such as ETag wouldn't help, though I do set them for anything subsequent) so there is no display blocking fetching the CSS needed for display (as I have little CSS, I inline all of it, but you might want critical CSS only).
Though to be honest most things don't, I blame being rural.