I consider it a grave undertaking when you use JavaScript to bring forth these abominations. Several of these sins have crept into our midst, and it has come time to purge ourselves of their presence. Okay, so I may not feel that strongly about it, but this list should raise a few eyebrows. In essence, the issues I address are meant to facilitate discussion among developers regarding the tools at our disposal — specifically JavaScript.
Validating user input
An intranet or an in-house Web application might survive with a bit of JavaScript validation for user input, but server-side validation is your best bet when developing Web sites available to the public. This is a no-brainer for a senior developer with a touch of security experience under the belt. The simple truth is that client-side validation opens the door to a plethora of problems.
Popping faux windows
Clients shake in their boots at the thought of the all-powerful popup blocker. We have done little to diminish their fears or to offer alternative solutions eliminating the need for popup windows. Instead, we have coded kilobyte upon kilobyte of JavaScript so that we can pop faux windows. You cannot bookmark, print, minimize, maximize, or organize them, but they sure do look real.
Striping tables like a Zebra
There is no denying that tables need a designer’s touch. Zebra striping is all the rage, and readability can actually be improved with proper styling. However, there is no need to add the slightest JavaScript weight to your page in order to make this happen. Unless there is a lock-down of server-side code, zebra striping should be accomplished with a tweak to business logic and a few class names.
Floating or flying widgets
Pricing configurators are a handy tool for online retailers, but they can be an eyesore as well. These configurators typically take the form of floating or flying widgets that slide up-and-down the browser window. Often times these widgets overlap important content with distracting movements, and they deliver little satisfaction considering the JavaScript implementation efforts required.
Dragging and dropping
The ultimate ego booster for a Web developer is owning the bragging rights to a custom built drag-and-drop JavaScript library. Performance, speed, and code weight are always taken into consideration, but usability, accessibility, and purpose, always play second fiddle. Few applications can truly benefit from dragging and dropping elements around the browser window.
Retrieving the date and time
I consider JavaScript calendars to be the only exception to the rule. In any other circumstance, business logic that requires retrieval of the current date and time via JavaScript is unacceptable. The accuracy of the date and time can easily be compromised since it relies solely on the date and time displayed on the user’s machine. There are several server-side solutions that overcome this obstacle.
Ignoring the rogue error
Inexperienced developers are more likely to let a rogue error slip through the cracks due to the introduction of frameworks and enterprise-scale JavaScript libraries. The immensity of client-side code in the Web site or application makes it difficult to troubleshoot, and if everything is working, why complain about one little error? If you have to ask that question, you have committed the deadliest sin of all — complacency.
[...] The 7 deadly sins of JavaScript [...]
I take some exception to “Striping tables like a Zebra.” Sure, you can have your server-side scripting add classes to the table’s tag, but if you have a big table, that’s a lot more to download. Plus, when the person goes to print a large table (which they’d likely do), the browser removes the background color.
The only way that javascript would hurt is if the user has javascript turned off. But that kind of user would end up printing the page, don’t you think?
Interesting read though.
Hi David,
Thanks for the feedback – good points. I think it has less to do with performance, and more to do with where and when to use JavaScript. Both methods are relatively straightforward – the question remains, which is best to use in this scenario?
I agree on Zebra striping: leave it to CSS, not JS.
another Javascript red-flag is how to properly craft DHTML. it’s easy to create memory leaks that can crash IE.
“Leave it to CSS, not JS” doesn’t really make much sense.
I don’t think anyone’s suggesting using JS to edit the style of DOM elements, but rather to intelligently apply classes to appropriate table rows. Of course CSS actually handles the visual presentation, we just need a way to intelligently apply handles.
The question is whether or not this logic belongs on the server or client side.
I would say that this logic most definitely belongs on the server side, but that doing it via JS is not a real problem, and certainly not a cardinal sin.
[...] The 7 deadly sins of JavaScript Validating user input, Popping faux windows, Striping tables like a Zebra, Floating or flying widgets, Dragging and dropping, Retrieving the date and time, Ignoring the rogue error [...]
Clientside validation makes for a nicer user experience cuz you can catch a lot of honest input errors before they “leave the page” so to speak. I think you should say RELYING ON ONLY clientside validation is a deadly sin, and with that I agree.
I agree with Colleen re. the JS validation piece.
I see client-side validation as a usability enhancement, while server-side validation is a security requirement.
Give the user immediate feedback that there’s an issue with their submission, then when they’ve gotten everything that we’d need to process the form, we’ll check it on the back end for integrity.
By all means, though, if the user has JS turned off, make sure that submit button still works and all of the input is validated on the server!
@ Colleen / Rob
I agree that there are definately some usability benefits — thanks for pointing that out.
Rob, regarding the submit button… hmm, I wonder what application you might be speaking of… maybe one we are both familiar with ;)