Did new programmers evolved some new protein that prevents their eyes from bleeding when they try to find bits of actual meaning in xml files?
When managing a complex, JS-heavy application, it is infinitely more developer friendly to be able to look at an element and figure out what the lifecycle of that object might look like. Instead of digging through javascript (especially jquery heavy code with the possibility of obscured references) where there's no real logic behind when or where an object might be modified, you restrict it to the most basic element possible - the HTML declaration.
So yes, let's please reinvent HTML :-)
Except that what you see in your html is not your element. It's just a forced structure required by w3c (described with xml syntax) for some aspects of visual representation of your element.
Your element should be described in js where it can be fairly easily separated out to a single file, and where binding configuration (as well as other concerns such as communication with backend or other app components for example) might be in one place instead of being interspersed with html tags unrelated to that behavior. See how backbone does event binding in views to understand what I'm talking about.
> So yes, let's please reinvent HTML
HTML is not so much an invention as result of glacial (or w3c-ish in other words) process of semi-(mis)directed evolution.
I'm guessing you never had to implement a layout using tables and 1px transparent gifs. I encourage you to try. It might make you understand how rigid and misaligned with the goal HTML in its spirit is. It got some improvements over the years but there was nothing revolutionary in its development even for fairly mild definitions of "revolutionary". Flexbox might become one such mini-revolution when few generations of IE do world a favor and die already.
JavaScript is far from being perfect and you can make a horrible mess of it as well, but at least it's general purpose language that supports various mechanisms for abstracting and organizing things and fairly minimalist syntax (as compared to xml, html) for declaring/organizing things that got wide appreciation as JSON.
First, it can in theory contain arbitrary JS code and serve as a potential XSS injection vector. Also, as more make the move to blacklist inline JS via Content Security Policy, onClick becomes impossible. Second, onClick requires an explicit receiver.
Part of the benefit of something like JSAction is that it decouples the generation of the event from it's processing. I'm not arguing that JsAction is the best solution for this, but I think the general concept is sound.
Which is same debate as between onclick and addEventListener only with slightly less verbose syntax on both sides of the debate and some implicit scoping that makes it possible.
<div id="foo" jsaction="leftNav.clickAction;
dblclick:leftNav.doubleClickAction">
is pretty much the same as this: <div id="foo"
onclick="Actions.leftNav.clickAction()"
ondblclick="Actions.leftNav.doubleClickAction()">
without any abusing or manipulating of html and dom and with setup as simple and understandable as this: window.Actions = {
leftNav: {
clickAction: function() {
myApp.LeftNav.doSomeSeriousStuff();
},
doubleClickAction: function() {
// very late loading of implementation
require("LeftNavActions", function(LeftNavActions) {
LeftNavActions.doSomeOtherSeriousStuff();
})
},
// if you want add handlers from other places
// with Actions.leftNav._anotherAction.push()
_anotherAction: [],
anotherAction: function() {
this._anotherAction.forEach(function(a) { a(); });
}
}
}
Actions is a good idea that I remember from Delphi 4. It is just one additional layer of indirection that enables you to attach same behavior for example to menu option and toolbar button.> eventContract.dispatchTo(goog.bind(dispatcher.dispatch, dispatcher));
imho, there's a problem if you need to dust off your gang of four book to understand the API. Might as well include an AbstractSingletonProxyFactoryBean.
Github is successfull because of git AND its good clean UX.
Google code feels like developpers were in charge of the UX. It's a UX disaster and will be retired sooner or later.
Anyway, OnOff is better because:
1. It's smaller. 2. It's simpler/less complicated.
Also, it doesn't need a noConflict option due to the way it gets instantiated.
Nitpicking aside, it looks like an interesting approach to decoupling the DOM from your event handlers. Personally I'm happy sticking with the standard on{event} attributes for really simple stuff.
[1] https://developers.google.com/closure/compiler/docs/compilat...
The separation of thing that emits named event and listener is a good idea.
I Actually moved away from the HTML attribute DSL and started putting named events in my virtual dom instead (using [mercury][2])
The important part of this approach that is not shown in js action is to ensure you emit data structures instead of dom event objects to the listeners.
[1]: https://github.com/Raynos/html-delegator/blob/master/README.md
[2]: https://github.com/Raynos/mercury