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" ... />...'


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.
