Unobtrusive JavaScript – How to Convince Boss and Developers to Use It

design-patternsjavascriptjquery

I'm pretty new in our develepors team.

I need some strong arguments and/or "pitfall" examples, so my boss will finally understand the advantages of Unobtrusive JavaScript, so that he, and the rest of the team, stops doing things like this:

<input type="button" class="bow-chicka-wow-wow" 
       onclick="send_some_ajax(); return false;" value="click me..." />

and

<script type="text/javascript">

function send_some_ajax()
{
  // bunch of code ... BUT using jQuery !!!
}
</script>

I suggested using a pretty common pattern:

<button id="ajaxer" type="button">click me...</button>

and

<script type="text/javascript">

// since #ajaxer is also delivered via ajax, I bind events to document 
//  -> not the best practice but it's not the point....

$(document).on('click', '#ajaxer', function(ev) {
var $elem = $(this);
ev.preventDefault();

});

The reason why my boss (and others) do not want to use this approach is that the Event-Inspection in FireBug (or Chrome Dev Tools) isn't simple anymore, e.g. with

<input type="text" name="somename" id="someid" onchange="performChange()">

he can immediately see what function executes on change-event and jump right to it in a huge JS file full of spaghetti-code.

In the case of Unobtrusive JavaScript the only thing he would see is:

<input type="text" name="somename" id="someid" />

and he has no idea whether some events, if any, were bound to this element and which function will be triggered.

I was looking for a solution and found it:

$(document).data('events') // or .. $(document).data('events').click

but, this "approach" caused it to take "too long …" to find out which function fires on which event, so I was told to stop bind events like that.

I'm asking you for some examples or strong advantages or any other kind of suggestions for "Why we should use UJS"

UPDATE: suggestion to "change the job" is not an ideal solution.

UPDATE 2: Ok, I've not only suggested to use jQuery event-binding, I did so. After I wrote all Event-Delegation, the Boss came to me and asked me, why am I doing event delegation with different approach and approach he dind't know

I mentioned some obvious benefits, like – There are 15 input-fields and all of then have an onchange event (not only, some of them have also onkeyup) So it's more pragmatic to write this kind of event-delegation ones for ALL input-fields, instead of doing it 15 times, especially if all of the HTML will be rendered with PHP's echo -> echo '... <input type="text" id="someid" ... />...'

Best Answer

Stop using buzzwords and try making strong arguments instead. Even the Wikipedia page for Unobtrusive JavaScript says that the term isn't formally defined. It may be a blanket term for a number of good ideas, but if it sounds like a mere fad or fashion your boss and coworkers won't pay a lot of attention. Worse, if you keep going on about something they view as useless, they may start to discount completely unrelated ideas that you advocate.
Figure out why you think the Unobtrusive JavaScript ideas are important. Is it because you read that they're considered best practices? Have you run into problems that you can attribute to not following these ideas? How much will adopting these ideas impact the company's bottom line?
Get inside your boss's head. Why does he do things the way he does, and why has he rejected your changes? He's probably not stupid, and he's probably more experienced than you are, so he probably has some good reasons for doing things his way. You've already alluded to some of them -- follow that thread to its end. Then figure out if and how your suggestions will improve the things that he's most concerned about.
Hint 1: Managers like money. The more directly you can tie your suggestions to increased income or reduced spending, the more impact your argument will have. Hint 2: Time is money. Hint 3: By itself, the aesthetic appeal of code doesn't make money. The opposite, in fact -- it takes time to make code look nice. Ugly code that works well is just fine with most managers.
Don't just talk about it, do it. If you're lucky enough to have a small, self-contained project come your way, ask your manager if you can do it using the "UJS" style as a sort of demonstration. When you're ready, hold a code review where you can explain how it all works and why you think it's better than the current style.
Idealism is great, but don't let it get in the way. It's more important to be seen as someone who gets things done than as a dilettante who complains about uncouth coding style. This is especially true if you're the new guy. If you can't get traction with UJS now, get some good work done instead and slowly build a case for the changes you'd like to make as you gain credibility.
Read Switch: How to Change Things When Change is Hard. It'll give you a lot more good ideas about how to build your case effectively.

Related Solutions

Javascript – Using CSS classes as decorators – a good pattern

I think what you're doing is dead on. The benefits of using classes, as opposed to making up attribute names, is that you can still validate the page. No modern browser will get upset about undefined CSS classes, and they are trivial to use with jQuery, et al.

JavaScript Event Programming – Global vs Individual Object Event Handlers

The problem with your approach is that you are replacing the browser's dispatching mechanism with your own dispatching mechanism. The browser's dispatching is not bad enough to be replaced, and is certainly better than yours:

The browser's mechanism is native to the browser, and therefore faster than your implementation in interpreted language(JavaScript).
Your mechanism uses a big switch statement, which also makes it slower.
To add more handlers to your mechanism you need to edit the giant dispatching function. To add handlers to the browser's mechanism you simply need to set the elements' attributes, which you can do from wherever appropriate - much better than a single gigantic function.

The example you've given, while seems to be very popular nowadays, is not good either since it creates massive amounts of boilerplate code duplication. I simply fail to see the benefit of searching for elements by their unique id to attach handlers to them over writing the handler directly in the element's HTML(the function call! not the implementation!).

Another popular approach is to use the class attribute instead of id - which I believe to be even worse. Why go through all the trouble of separating the logic(JS) from the document structure(HTML), just to couple it with the style(CSS)?

What I usually do is use JQuery's convenient syntax of searching-by-css-selector and attaching-anonymous-function-as-event-handler to "extend HTML" - similar to what you do but without a gloabl handler, but with separate handlers for each type of action:

//  HTML

<div class='menulink logout' data-mc='logout'> Logout </div>
<a class='menulink' data-mc='ajax' data-target='main-content-div' href='page/'>Start page 1</a>
<a class='menulink' data-mc='ajax' data-target='main-content-div' href='page/'>Start page 2</a>


// JS

$(function(){
        $('[data-mc=logout]').click(function(){
                if (!confirm(myconfig.msg['asklogout'])) {
                    return false;
                }
        });

        $('[data-mc=ajax]').click(function(){
                var target=$(this).data('target'); //retrieve data-target of the clicked tag
                return false;
        });
});

That way, I can create separate handlers instead of you giant switch statement, but just like you I can use the elements' attribute to assign handlers to elements dynamically.

Best Answer

Related Solutions

Javascript – Using CSS classes as decorators – a good pattern

JavaScript Event Programming – Global vs Individual Object Event Handlers

Related Topic