JavaScript Philosophy Pt. 1
Contributing my first blog entry here at Ignertia was a bit daunting. I wanted it to be accurate and objective. Of course I’ll still insert a few Internet Explorer attacks (Zing). More importantly, I wanted an entry that I felt would be viable over the next few months and possibly into the next few years. I don’t feel like this topic can be entirely expressed in one post, so continue with me over the next few weeks as we cover this topic in greater detail.
We will first begin with the “executive summary”, that short tidbit, just to wet your appetite. With each subsequent post I’ll try to stick to a logical format of topic and reasoning. Therefore if you simply don’t agree with my “philosophy” I won’t waste your time with “trivial” logical points.
Another quick point, that I might again bring up in later posts. I truly have a “love hate” relationship with JavaScript and related frameworks. I have both respect and a reoccurring annoyance for client side scripting. As programmer I have a great deal of respect and admiration for those who have contributed to the many JavaScript frameworks that continuously improve client side scripting for the user and developer.
JavaScript solutions need to be heavily weighed. There is a balance that must exist between server side and client side processing. We must attempt to; conserve bandwidth, the number of necessary requests, minimal functionality requirements, browser compatibility, search engine optimization, and screen readers (text to speech programs).
Minimally your audience should be split into two segments;
- A) Website Administration population
- B) General public population
The population of segment “A” can be reasonably estimated, in that we should know how many office users or site administrators will be accessing the website via an admin portal. The Assumptions are made this population can be anywhere from 1-1000+ and using controlled office equipment. I then tend to make the following additional assumptions:
Population A Equipment:
- Systems are up-to-date
- IT department influences the use of FireFox over Internet Explorer (Zing)
Population A Usage:
- Over time these users should become “Power Users”
- Their work needs to be done fast and accurately
- Their competency of the website should be potentially higher than the typical visitor of their site.
- Need for enhanced security (Note: I didn’t say fool proof, JavaScript can only be seen as a security enhancement)
Making the same assumptions on the general public is problematic and ignorant. This can potentially deter viable users from your site or block them from required functionality.
Ok, so here’s the dirt.
Administration population:
- Require JavaScript for form processing: General submission, “Logins”, CAPTCHAs, Input validation, error reporting, etc
- Require JavaScript for Power User functionality
General population:
- Sometimes use JavaScript for form processing: General submission, “Logins”, CAPTCHAs, Input validation, error reporting.
- If possible allow minimal same page form processing without JavaScript.
- JavaScript can be used to add “multimedia enhancements” to a page such as; video, audio, games, unnecessary applications, etc.
- Never use JavaScript to display, control, or inject important elements into a page that would not exist or exist in the correct document flow otherwise. This especially includes site navigation!
- Never use JavaScript to perform browser dispaly “hacks” for perceived greater browser compatibility.
- Never require JavaScript for basic searching
- Try to avoid JavaScript redirects
- JavaScript can be used for tracking and ad placement.
- If JavaScript is required make use of the <NOSCRIPT> tag to inform your users.
More to come soon!
