Manifesto
The JavaScript Manifesto
At the moment JavaScript suffers from outdated, uninformed, and inaccessible development methods which preclude it, and therefore web development in general, from attaining its full potential.
The WaSP DOM Scripting Task Force proposes to solve this problem by the adoption of unobtrusive DOM scripting, a way of thinking based on modern, standards-compliant, accessible web development best practices.
While both front end and back end developers will profit from this change of perspective, the most important benefits will accrue to our end users, whether they use the latest and greatest desktop browser, assitive programs like screen readers, or other devices.
Let’s start by defining the problem.
Interpreted scripting language
JavaScript is a scripting language interpreted by the browser.
This simple statement contains a few serious problems.
- “Language“: Web developers who come from CSS development tend to shy away from programming languages because they are “difficult” to learn.
- “Interpreted scripting language“: Programmers of complex, compiled languages like Java or C++ tend to feel that JavaScript is “simple”. Keeping up with changing best practices is therefore not worth their time and effort.
- “Interpreted by the browser“: In the past, browsers made a distinct point of being as incompatible as possible, and they gleefully ignored standards such as W3C recommendations. Although this situation has meanwhile improved dramatically, it still influences the way JavaScript is regarded, especially by people who don’t work with it on a day-to-day basis.
Solving these psychological problems requires a new way of thinking that is more in line with modern, standards-compliant web development practices.
Unfortunately practical JavaScript development and the standards movement have not always been on the best of terms. In fact, their problematic relationship has become a part of the problem.
Bad practices
The purpose of JavaScript is enhancing the usability of web pages by adding interaction to them.
Unfortunately this purpose more often than not was an excuse for programmers to display their technical knowledge by inflicting pop-ups, scrolling status bar messages, animated layers, and other GUI elements of questionable value on unsuspecting end users. Worse, these sites’ accessibility efforts were too often limited to saying “Sorry” to users of the wrong browser.
Such old-skool scripting was quite rightly deprecated by standards-aware web developers. In doing so, though, some of them moved too far in the opposite direction: they deprecated JavaScript altogether, despite an increasing number of simple, useful example scripts that add value to a standards compliant web site.
Caught between bad practices and a bad name, abused by old-skool programmers and rejected by the standards movement, JavaScript development suffers from an identity crisis. It needs new ideas.
Enter unobtrusive DOM Scripting.
DOM scripting
DOM scripting — unobtrusive or otherwise — is not new. Any useful client side script needs to access or change the XHTML structure by way of the Document Object Model. A script that doesn’t do anything with or to the document doesn’t interact with the site’s visitors and has no purpose.
In the past web developers had to take a bewildering variety of DOMs into account. Fortunately this situation has changed. Modern browsers all support the W3C DOM, so W3C DOM is the only one that’s needed for JavaScript development. This has shortened development times, simplified scripts and reduced, though not eliminated, browser incompatibilities.
The W3C DOM is a real standard, in practice as well as in theory. It is JavaScript, and not CSS, which has profited most from the standards drive the WaSP started back in 1998.
JavaScript is harder to learn than CSS; it takes more time to produce one’s first DOM script than one’s first style sheet. Once mastered, however, DOM scripting just works, and the time spent learning JavaScript will be earned back by not having to cater to browser incompatibilities. CSS authors will be amazed at the ease with which DOM scripts may be deployed without workarounds or hacks.
As a practical matter, DOM scripting works well so long as we use the W3C DOM. As we saw, though, serious psychological problems remain unsolved. It’s here that the “unobtrusive” bit comes in.
Unobtrusive DOM scripting
An unobtrusive DOM script draws as little attention to itself as possible. In doing so, it provides a number of benefits:
- The usability benefit: An effect created by an unobtrusive DOM script does not draw the attention of the user. It is so obviously a good addition to the site that visitors just use it without thinking about it.
- The graceful degradation benefit: An unobtrusive DOM script does not draw the attention of its users when it fails. It never generates error messages, not even in old browsers. An unobtrusive script first asks “Does the browser support the objects I want to use?”. If the answer is “No”, the script silently quits.
- the accessibility benefit: The basic functionality of the page does not depend on the unobtrusive DOM script. If the script doesn’t work, the page still delivers its core functionality and information via markup, stylesheets and/or server-side scripting. The user never notices that something is not there.
- The separation benefit: An unobtrusive DOM script does not draw the attention of web developers working on other aspects of the site. All JavaScript code is maintained separately, without littering files dedicated to XHTML, PHP, JSP, or other languages.
Implementing unobtrusive DOM scripts
Unobtrusive scripting is not a coding style, it’s a way of thinking. So the question becomes: how do you think unobtrusively? You should take three steps:
- The first step is asking the right questions before creating a new script. Is the effect the script causes worthwhile? If the effect doesn’t work, what happens to the page? If the answers are “Yes”, and “Nothing, except that it loses a bit of usability”, respectively, you are creating an unobtrusive script.
- When you start programming, make a list of the methods or properties your script cannot do without. Check for the existence of these methods or properties, and if the browser indicates it doesn’t support them all, end the script.
- Make sure that your XHTML files don’t contain any JavaScript, no event handlers in XHTML tags, no little bits of extra code floating around. The document should contain a
<script>tag to link to the JavaScript file, but that is the only way your scripts obtrude into the XHTML structural realm.
It’s not a magic spell. You won’t suddenly write brilliant scripts just because you invoke the power of Unobtrusive DOM Scripting. It’s a first, modest, necessary step on a long way that will lead to a new way of thinking about JavaScript.
Let’s take a look at three areas that can benefit from unobtrusive thinking: fear of JavaScript, accessibility, and the relation between front end and back end.
Fear of JavaScript
Many talented front end developers, especially those who are standards-aware and work with CSS a lot, are afraid of JavaScript, both because it’s a programming language and because of the many mistakes made in JavaScript’s history.
Unobtrusive thinking will remove these ancient fears by making JavaScript fall in line with the rest of the standards compliant techniques. JavaScript belongs in the bag of tricks every web developer should carry.
Some web developers do not want to learn a programming language. That’s quite all right; learning to use JavaScript on a technical level is a personal choice. Not everyone will have the time or inclination for it.
However, all web designers and developers are required to learn to use JavaScript on a functional level, to understand what JavaScript can do for their sites. If, from ignorance, they don’t even consider including a little script that takes care of a little usability problem, they’re being unprofessional and cheating the majority of their end users.
Even if they don’t want to write scripts themselves, they should be able to weigh the pros and cons of including a bit of unobtrusive DOM scripting, to decide whether it will be an asset or a liability. If it turns out to be an asset, they can always ask someone else to implement it.
Nonetheless, we hope that some standards-aware web designers and developers will make the effort of learning JavaScript. We badly need a new generation of scripters who have a deep understanding of accessibility problems, can distinguish good scripts from bad because they know how wrong JavaScript can go, and are steeped in standards compliant thinking.
This new generation will be able to solve fundamental questions like the separation of behavior and presentation. If an effect can be created in both CSS and JavaScript, which technique should you use? Right now the answer depends on personal preference, tradition, and accessibility concerns. Of these three criteria, only the last one is objectively testable. The first two will have to be reviewed critically and discarded, if necessary.
Accessibility
By far the most tricky problem JavaScript is facing is that of accessibility. Unobtrusive thinking can help to solve this problem.
JavaScript has acquired an unfortunate reputation of being inaccessible. Of course this is nonsense. Scripts don’t make themselves inaccessible, their creators’ decisions do.
Some JavaScript programmers, especially those who create large scripts or complete applications, decide at the outset that their script is “never going to be accessible anyway”. This abdication of responsibility, and not the technical parameters of the script in question, is the major cause of accessibility problems.
We need to fundamentally rethink our approach to writing large scripts. The first step is to admit that any script-heavy site, no matter how large or complex, can be made accessible.
Adding accessibility to script-heavy sites is a tough job. The fundamental architecture of such sites is usually based on the preconception that JavaScript is always available. Therefore accessibility will have to be shoehorned in, which is a time-consuming and messy process. In theory a total redesign of these sites would be the best solution, but practical considerations such as time and money usually prevent that.
Despite these serious technical problems, and despite the fact that large applications won’t become accessible overnight, we should make a start. Once we acknowledge that accessibility is possibile for all scripts, strategies for incorporating it into large applications will present themselves. Actually creating best practices for accessible applications, and writing scripts that incorporate them, will take several years, but that’s all the more reason to commence our project right now.
Front end and back end
Unobtrusive thinking is a good starting point for knowledge sharing between front end and back end programmers. For instance, its insistence on separation of behavior and structure mirrors the separation of concerns used in the development of large applications.
Front end programmers can learn a lot from back end programmers. Front end programmers largely lack knowledge of application architecture and design patterns, while back end programmers practice them as automatically as breathing. Knowledge sharing in these areas will markedly benefit the front end, especially when writing large web applications.
Knowledge sharing works two ways, though. It should be an exchange between equal partners.
Back end programmers can learn a lot from front end programmers. Back end programmers largely lack knowledge of browser incompatibilities and performance, as well as accessibility, while front end programmers practice them as automatically as breathing. Knowledge sharing in these areas will markedly benefit the back end, especially when writing large web applications.
Unfortunately, the will to cooperate seems to be lacking on the back end sometimes. The main reason is that front end programming is such a lowly occupation. This essentially social factor causes two delusions:
- That JavaScript is easy, and not worth a serious programmer’s attention.
- That JavaScript can serve as a replacement for back end technology.
These misguided ideas serve to “explain” why JavaScript is used for implementing bits of business logic or data retrieval that properly belong on the back end. The development of such scripts can be shoved off on junior programmers, which allows the seniors to continue with their serious work, which of course does not include immature and simplistic technologies like, for instance, JavaScript. Besides, this process serves to consolidate the natural order of society in serious programming, where front enders know their place at the bottom of the social pyramid.
Obviously, using JavaScript as the single way of implementing business logic or data retrieval is a grave sin against unobtrusive scripting. Users will notice something is wrong when the business logic layer or the content goes missing. The script intrudes.
Front end technology can never replace for back end technology, or vice versa, because the two have different purposes. Back end technologies search for, collate, and serve data and business logic. Front end technologies present this information to the user. The two need to be properly separated, and that separation can use ideas taken from unobtrusive scripting.
Knowledge sharing on the basis of unobtrusive scripting will allow front end and back end programmers to do away with outdated ideas, and to learn some tricks they wouldn’t have discovered on their own. Because of the increased understanding for each other’s purposes and methods, they will start to cooperate better than is the case nowadays.
JavaScript’s manifest destiny
For all these reasons, the WaSP DOM Scripting Task Force proposes to make unobtrusive DOM scripting the cornerstone of all JavaScript programming. We realise that there is a lot of work to be done, that some problems, notably the accessibility of large applications, will not be solved in a few months, and that there is still resistance to the new way of thinking, both among standards-aware web developers and among “serious” programmers.
That’s no reason not to start, though.
Only the adoption of unobtrusive DOM scripting will do away with outdated, uninformed, and inaccessible development methods. Only the adoption of unobtrusive DOM scripting will allow JavaScript, and thus web development in general, to attain its full potential.
The Web Standards Project is a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all.