Question

The way I usually implement a select box is:

 <select size="1" name="example_length" onchange="callSomeMethod">
    <option value="10" selected="selected">10</option>
    <option value="25">25</option>
    <option value="50">50</option>
    <option value="100">100</option>
  </select>

I have attached an action on onclick event

There is another way check the dropdown source here

  <select size="1" name="example_length">
    <option value="10" selected="selected">10</option>
    <option value="25">25</option>
    <option value="50">50</option>
    <option value="100">100</option>
  </select>

In the second implementation it’s unclear what action is registered on the onchange event

Question: in second implementation we usually use some Javascript library to register the actions, but I feel that with the first implementation was clear, readable and easier to debug, whereas second implementation is bit puzzling to me, so, why do we use second approach and how to debug this?

Any link regarding this will be much appreciated.

Answer 1

I find it clearer to keep my code separate from my HTML mark up. This is especially true when the handlers are applied to multiple elements on the page. It makes for a cleaner implementation when I can go to a single place in the code — which may be included from a script that can be reused with several pages — and make a change, than to have to search throughout the code and make changes to, perhaps, many individual elements to reflect a small change in a function.

Further, I think it makes it easier to debug the code when it’s not interspersed with the mark up. Using Firebug or IE Developer tools, you can set break points in the javascript code, inspecting values and stepping through the code to find any errors. At the other extreme, putting an entire function into a markup-applied click handler makes it basically impossible to debug. You’ve already taken one step toward easing that by introducing a separate function that is called. Applying the handler via code improves this by allowing the application of that handler function to be debugged as well.

Another benefit, and this is subtle, is that applying the handlers separately forces you to use better semantics and naming conventions than otherwise. One drawback, as you’ve seen, is that when the code is inline, it’s easier to see what handlers are being applied by inspection. When applying them via code, you have to use better semantics, decorating the affected elements with meaningful class names, using good, descriptive element and function names, and refactoring back to reusable code components (to take full advantage). This seeming disadvantage, actually helps to force you to write better, more maintainable markup and javascript.