Live data from Hacker News

Google open-sources JsAction, a JavaScript event delegation library

github.com

41–48 of 48 posts

Re: Google open-sources JsAction, a JavaScript event delegation library

#41
post #38
post #6

I like they are putting this on Github instead of (or on top of) Google Code

Google code could have been great.But the UX sucks so much and has never been updated. 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.

it's a shame TBH, Google Code could have a lot of potential, if only because Google as a company is chock full of developers. Maybe not as much UX designers though.

Re: Google open-sources JsAction, a JavaScript event delegation library

#42
post #31

Earlier quoted context omitted.

The API could certainly use some work, and it's worse than you mention. If it were just a matter of applying widely-known Gang of Four patterns it would be fine. All over the place it looks like the designer didn't realize there's a built-in Function.prototype.bind.

In IE8 and FF3.6, there isn't. If you believe netmarketshare.com, that's 20% of users right there.

If you are not relying on edge case behaviour of Function.prototype.bind, including the polyfill here should be enough: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Google open-sources JsAction, a JavaScript event delegation library

#43
post #40

Earlier quoted context omitted.

I like the syntax, but it bugs me that the behaviour goes into the HTML. I really like keeping my event mapping in the javascript so I keep a clean separation between structure in the HTML and behaviour in the JS.

I don't know. I think the one of the best things about Angular for example is that you often see straight away what's happening because of it's declarative nature. With normal event handlers you don't know what's going on until you specifically search for the id/class/tag in all the JS files.

In that case, it's good to have some conventions but I agree that it takes a very small amount of carelessness for maintenance to become a PITA. I think using reactive templates which associate with a model is better than declaring every reaction on the DOM level though.

Re: Google open-sources JsAction, a JavaScript event delegation library

#44

Earlier quoted context omitted.

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…

For me worst part of onclick is putting what's essentially configuration of binding in baroque syntax interspersed with elements that are there for unrelated reasons, in files that have forced structure and are not easy to partition by concern.

Thats the declarative approach that google is promoting with Angular, Polymer and now jsaction.

Re: Google open-sources JsAction, a JavaScript event delegation library

#45

Earlier quoted context omitted.

For me worst part of onclick is putting what's essentially configuration of binding in baroque syntax interspersed with elements that are there for unrelated reasons, in files that have forced structure and are not easy to partition by concern.

Thats the declarative approach that google is promoting with Angular, Polymer and now jsaction.

Yes. Apparently 15-20 years is enough for people to forget and and make a full circle in search of less sucky thing.

Re: Google open-sources JsAction, a JavaScript event delegation library

#46
post #35

Earlier quoted context omitted.

> I'd rather everything be declared up front. I'm all for declaring up front, just not in html. > Reading someone else's Backbone code (as compared to Angular or Ember) is really, really not fun for me. Backbone is far from what I consider good readability. If encourages bad habits by not providing templating and sort of encouraging use of jQuery for dom modification. Binding events to backbone view is what I conside…

Finally, we can both agree that jquery dom manipulation is a great way to find yourself in a mess of unmaintainable code. If you're a fan of backbone views though - why not React? IMO it's very similar to backbone but with sane structure and an incredibly powerful render loop.

I haven't paid much attention to React before reading this http://jlongster.com/Removing-User-Interface-Complexity,-or-...

Now I think the idea is awesome and architecture that arises from it might be very good. But this idea assumes that DOM manipulation is fast enough to do every render frame and I do not trust yet the caching magic that React.js conjures to ameliorate the fact that it actually isn't.

Re: Google open-sources JsAction, a JavaScript event delegation library

#47
post #37

This seems pretty complicated and not so simple. Someone else asked, "How is this better than Backbone?" Backbone is (a lot) more than just an event lib. A better question would be, "How is this better than OnOff?" (which is basically the equivalent of the events part of Backbone): https://github.com/LiftoffSoftware/OnOff

How is OnOff better than just the standard EventEmitter?

You mean Node.js's EventEmitter? That's not built into JavaScript (i.e. not a "standard").

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.

Re: Google open-sources JsAction, a JavaScript event delegation library

#48

So this (with specialized lib, and fairly large unintuitive js code to set whole thing up): is pretty much the same as this: 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"…

[deleted]
Post reply on HN