Ten Benefits of Unobtrusive Javascript

This is an addition to the excellent previous (more practical) article about unobtrusive javascript. In short, I want to say that the ability to work with JS off is only a visible tip of the iceberg and, perhaps, not the main goal. There are many other benefits of using this approach. Under the cut you will find a list with explanations (plus some examples of good js components at the end).

1. Unobtrusive Javascrit clears HTML from JS
   At the same time making HTML reusable. Relevant classes appear, duplicate onclick leaves. A coder who does not use unobtrusive javascript will someday make a tangled tangle out of the project. Not using this approach in client code today is tantamount to ignoring MVC in server scripts.
   
   Makes HTML as semantic as possible.
   It is implied that the components written by this method are based on semantically correct HTML code (actually used as a means of specifying the source data), which is already replaced with another, more decorative and / or dynamic, when loading. For example, you may have a component that turns the “ul” list into a kind of directory tree in the system, with its behavior, appearance, folding and unfolding of branches. The implementation of only the lines connecting folders of the same level would result in a giant non-semantic table.
   Creating your JS-component (for example, editbox with a drop-down list of hints), you first come up with a semantic way to write it in HTML, and only then on how to breathe in another life using JS. This is convenient, from the point of view of your js-component reuse, because the easier it is to connect it, the more convenient it is.
   ')
   The magic of the connection or "a flick of the wrist pants turn into elegant shorts"
   Having understood the principles of unobtrusive javascript, you start building the interface like this: first, the most semantic HTML, then the layout with CSS, then (after loading the page) the transformation of HTML code from semantic to “advanced”. As a result, HTML initially does not contain anything dependent on javascipt, and everything that depends on it is added to it in the right places. You just need to include the extra library with the “script” tag and point out the elements that need to be “revitalized”.
   
   The “a try without JS” method allows you to do a lot of things more correctly and easily
   At present, the javascript is so developed that it no longer needs either a “form” (for post) or a (for get) to communicate with the server. This calls into question the need to use traditional methods of application interaction with the server (given that AJAX does it faster and more economically). But winning in speed you sacrifice simplicity, because AJAX is not easy to otdebezhit, compared with the standard post / get requests. You need experts in JS to make a really good optimization. It would just be optimized (note that even traffic giants like google.com and baidu.com do not save on this).
   
   “Try without JS” allows you to do a lot of things more usable
   And it is more usable even for those who have js enabled. For example, pseudo-references (“a href =" # "onclick = ...", well, or worse, "div onclick = ...") have more inconvenience than it seems at first glance. Even from the point of view of a user with JS enabled, such links cannot be opened in a new tab, “for later”. And this is just one of the examples where javascript interferes where it would be possible to do without it.
   
   Use future standards today.
   You can easily implement support for the standard you need, which most browsers have not yet managed to implement (be it CSS3, HTML5, XHTML2, Web Forms 2.0). When the time comes and they will become popular, you will not have to change anything in the code, just remove the javascript connection (you can even leave a well-written one just in case, since it will not conflict with the browser already supporting this standard). Also, you (or rather the most “insecure” of you) can invent / implement your standard / addition to HTML (new tags, attributes, behavior, design) - the future of HTML is in your hands.
   
   Facilitates testing with Selenium and other utilities.
   Because in HTML for almost everything needed (clickable) already magically is the identifier by which you can simply and clearly identify the element. Even if the test fails once (it cannot find any button needed to continue the test), you can easily repair the test: it is easier to find where now “button.home” than to search for what was identified before refactoring as // div [1 ] / table / tr [5] / td [1] / button "
   
   Spiders and other robots easier if the site can move without using the JS-module.
   It will be easy to write your own robot, which every morning will check that all pages on the path to the landing page do not contain any PHP / MySQL fatal error. Imagine how complicated the task will be if, for example, some main cookies would be saved via js.
   
   The application will end the operation (at least somehow) even if an error suddenly jumped out in JS.
   For example, if the link was supposed to open in a pop-up, but a JS error occurred, it will open in the current window, and the user will be able to read it. Otherwise, the user will not see anything, and you will not be able to find out about it until someone strongly interested (or just kind) informs about it.
   By the way, it was always like this: when you clicked on the button, the form was submitted if js errors occurred (and, of course, if the button was inside the form). It’s just that some masters could afford to make a button outside the form (with a code like onclick = "myform.submit ()"). You can continue to be sure that most JS users are enabled, but is it worth it to ignore the simplest principles of HTML?
   
   Your application will be able to work when JS is disabled.
   Well, smoothly, from the preceding paragraph, we move on to the principle of graceful degradation, which in this approach allows us to derive at least something to someone who wants to see at least somehow.
   If you are tired of hearing this, and you do not consider this important, then do not take this point seriously. It's just that this is the only "external" benefit that is understandable to top management and other non-technical people. As you can see, the approach gives a lot more, and the ability to work with JS off can be perceived as just a nice bonus.
   Summing up, I emphasize that unobtrusive javascript is needed primarily for the developer, secondly - for the development team, third - for semantics, and only then for the small number of users who have disabled / disabled / missing javascript. Do not refuse this approach only because you have convinced yourself that it was invented to satisfy these, in your opinion, mythical 3% of users. No, it was invented to minimize (up to complete elimination) dependence on JavaScript, let it sound almost the same. And according to an unwritten rule: the smaller the dependency system (read: technical limitations), the simpler, more flexible and more stable it is. Which in turn translates into convenient testing and refactoring, rapid developer training, easy maintenance and changeability, extensibility.
   
   Anyone who wants to learn this approach would like to recommend starting with jQuery. As a result of the ideology embedded in it, almost every plugin under this mini-framework can serve as a good example of implementing unobtrusive javascript. See for yourself: Input Hint , UI tabs , Dialog , Multiple File Upload , Custom Checkbox , Gallery , Tree from , Table sort , Faviconize , Modal Previee , Reflect , HTML truncator , Tag Suggest , etc.