- Accessibility concerns
- And progressive enhancement
LIES! (well, now they would be)
But Stop and Think... About YOU!
Really, the big benefit, the major and most undersold win of maintaining separation has always been the direct benefit the developer gets out of it. You can have as many event handlers as you want on the same html element for the same event as is convenient. That means if a tag with
class="some_class" always gets a certain behavior but also gets some bonus behavior when it's inside an
id="bonus_behavior" div, we don't have to start messing with logic inside our one-allowed event handler to branch for that. We can just add or not add handlers depending on context.
Easy to Read Too
Another benefit is legibility. This was a more critical concern when browser tools consisted of IE's exclusive error message telling you that there was something wrong with
[object] but IMO, it's still a big deal. CSS here, JS there and HTML is the place where both they and the server meet. With all of those things coming together in one place it makes sense to rely on the hooks (the IDs, classes, and hierarchy) to create a layer of abstraction that everything uses to connect to the HTML.
IMO, the more you CAN keep your HTML, CSS, and JS separated the easier it is to not just read but also to modify and understand what's going on. I see an empty div with "dynamic_combo_box" as a class and I have a good idea something is doing a fancy select that loads data in dynamically. I have a lead on how to find that in the JS and the CSS and if I run into the class in those concerns, I'll have a good idea what it's about and how to find it in the HTML.
Too Easy to Make Even Sloppier
And of course legibility tends to go hand in hand with maintainability. When you just do things directly by dumping it all in script tags where the relevant HTML happens to be, as often as not, it becomes easier for people to just cut and paste that script in the HTML of another page they're working on when they want similar functionality which means you now have one thing that will most likely eventually become two annoyingly similar but not 100% alike things whose behavior may become problematic over time by defying expectations and require the addition of more pointless branching to handle exceptions one needs that another didn't.
So rigging behavior to those HTML hooks encourages code re-use in a smart way. If you need to branch behavior for an alternate implementation, you just go to the same function and handle it there with HTML hierarchy or maybe a data-att triggering some alt-behavior. It's one stop-shopping for anybody wanting to understand how UI elements of a certain type work and those despicably lazy-in-a-bad-way cut & paste types will do the right/more-maintainable thing just because it's the easiest thing to do now and that's the best way to make maintainability happen. Make it the easiest "duh" thing to do even for somebody who couldn't care less whether due to panic or apathy.
But What About 2014?
It may be a legit point that in modern single-page applications, some of these stickler things maybe shouldn't be stuckled to as dogmatically as they have been but believe me when I say I don't think I'm the only one who was sold on it because it ultimately makes the work easier. I'm lazy in a (I hope) mostly-good-way. I like it when I only have to change things in one place to get changes all over an app, when I only have to look in one place to figure out what the bug is, and when I have an easy time understanding what the heck is going on and how to best re-use that code to do something very similar.
It's good like splitting out a DB or data-layer is good. It's ultimately a why-didn't-I-just-do-that time-saver like taking all of five minutes to do the laundry the night before rather than spending 10 minutes on febreezing your boxers and conducting paranoid smell checks the next morning.
For me, it is those selfish motivations that have always been the main point of why I hold on to not just unobtrusive JS but the separation of style/behavior/content concerns as much as possible even as WHAT-freaking-WG does their damnedest to muddle those concerns in understandably awesome and cool/handy ways.
Now that everybody's doing SPAs and it's almost silly trying to convince business that we should care about people who run without JS (accessibility can now be, supposedly, handled with JS-generated content), it seems like the next generation of JS devs care less about this but IMO, there is still a win there and it's mostly for you, the developer writing and maintaining this stuff. And really, that win should have always been the most underscored point but never has been for some reason because it ultimately benefits you and also the product by happy accident through virtue of being easier tweak/modify/debug.
Is it Ever Okay?
Well yeah, I guess. In a disposable throw-away app for a contest or something maybe. But I would still do it just because I'm in the habit of it and it's not actually harder to do.