3 ms·

I should have made myself clear: I'm not against moving JS code to a separate file and I understand the benefits of caching. My point is, some hint of change f

by mojuba 18y ago

I should have made myself clear: I'm not against moving JS code to a separate file and I understand the benefits of caching. My point is, some hint of change for a given element must be given where it's declared, for example as a function call in onChange. This function itself can be defined anywhere, preferably in a separate file. Why - because when building a web app you usually look at the page and decide to modify the behavior of an element. In a good WYSWYG editor it's just one click, and you see that there's custom code attached to one of the events of that element. With "unobtrusive" style it's not obvious at design time whether an element has standard behavior or not, unless you know the code well, I mean, every bit of code in all modules.

ajross 18y ago
I'm not sure that's 100% true. Some development idioms have you staring at HTML all the time, others don't: take a look at the arc code behind YC for a good example. Likewise view-based architectures like rails spend more time worrying about how to invoke/include the view than they do tinkering with the presentation internals. And that "hint" that you want can be gotten many ways, it doesn't have to be a hard-coded event handler. Make it a class, for example. Or better, a class on the containing element (a collection of category selectors, whatever). That's even clearer than the event handler, because it's a statement of pure semantics.