11–20 of 48 posts
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?
Yes. Let's reinvent onclick attribute. What's with the recent trend of putting logic and visual configuration back into xmllish html clutter where you can't see it among the =" and meaningless words like div, span, class? Did people forget how much of a good idea was binding stuff to html from far away, from js and css files? Did new programmers evolved some new protein that prevents their eyes from bleeding when the…
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.
Why is this better than something like backbone, for instance?
Why is this better than something like backbone, for instance?
Yes. Let's reinvent onclick attribute. What's with the recent trend of putting logic and visual configuration back into xmllish html clutter where you can't see it among the =" and meaningless words like div, span, class? Did people forget how much of a good idea was binding stuff to html from far away, from js and css files? Did new programmers evolved some new protein that prevents their eyes from bleeding when the…
This isn't reinventing onClick. onClick has several problems. 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…
Why is this better than something like backbone, for instance?
JsAction provides a subset of the functionality provided by Backbone. In terms of how the two handle event delegation, in JsAction, the events are defined in the DOM. With Backbone, you typically define the events in the view which should process them. It's open for debate which is better.
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.
Earlier quoted context omitted.
JsAction provides a subset of the functionality provided by Backbone. In terms of how the two handle event delegation, in JsAction, the events are defined in the DOM. With Backbone, you typically define the events in the view which should process them. It's open for debate which is better.
> It's open for debate which is better. 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.
onclick-like functionality is coming back to frameworks. Angular and Polymer both have variations of what jsaction provides as a single-purpose library. It is sometimes just much nicer to bind stuff together directly.
> 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.
Yes. Let's reinvent onclick attribute. What's with the recent trend of putting logic and visual configuration back into xmllish html clutter where you can't see it among the =" and meaningless words like div, span, class? Did people forget how much of a good idea was binding stuff to html from far away, from js and css files? Did new programmers evolved some new protein that prevents their eyes from bleeding when the…
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 :-)