Show HN: MicroEvent.js - js micro event emitter in less than 20lines | Hacker News Reader

Show HN: MicroEvent.js - js micro event emitter in less than 20lines

notes.jetienne.com

60 pointsjerome_etienne15 comments

Open articleView on HN

I really like the code, I think it's very well written!

A couple small suggestions and thoughts:

Add a couple lines so that all methods return this; to allow for chaining, especially helpful when using it as a mixin.

Rename bind/unbind method names since they have completely different meanings/uses in ES5:

https://developer.mozilla.org/en/JavaScript/Reference/Global...

P.S. If you're down with those changes I'll gladly fork, update and send a pull req, although not sure what you'd want to rename the api too.

i had chained api before, and removed it for shortness.

your point on api name is good. which name would you suggest ? something standard and readable and im sold :)

Since I'll probably be using this for a couple smaller things of mine, I forked it and went ahead and changed it to:

subscribe/unsubscribe/publish

and also added return this.

https://github.com/amadeus/microevent.js

cool. will look at it. lets take this on github

Wouldn't tiny code like this better included in the HTML itself? A fraction of a packet size versus a HTTP request.

That would become an awful mess pretty quickly. One extra HTTP request per script dependency is a pretty acceptable trade-off for keeping things tidy, especially nowadays with things like keep alive and pipelining.

If you have a custom backend, you could always give it a list of frontend scripts to send and send them all to the browser as one big virtual "scripts.js" file. Then you get the best of both worlds - all the scripts in one HTTP request, but in a separated, maintainable file structure on the server.

(The modified date to compare to/set scripts.js for caching purposes would be the highest out of all the script files, obviously)

^^^ this. Sprockets is a good way to do this if you're using Rails. If you don't need something quite as sophisticated, Rails has built-in asset caching that will combine your JS and CSS files into a single file automatically by just putting :cache => "identifier" on the asset tag helpers.

You should probably still try to use the major CDNs for very popular libraries like Prototype, jQuery, etc. These are more likely to pull from cache and not incur any additional transfer time.

And for scripts that google is too slow to put on their cdn...

http://www.cdnjs.com/

When deploying to live, you should compress all JS and aggregate into a single file.

This has been shown to not necessarily always be the best option for performance. See http://blog.getify.com/2009/11/labjs-why-not-just-concat/, and http://yepnopejs.com/

The best and brightest in the JS performance area now mostly advocate using some form of loader to load the JavaScripts, bearing in mind that the overall page speed and perceived performance can be affected by more factors than simply the number of script files that need to be requested. Hence the recent proliferation of things like yepnope.js, require.js, lab.js etc.

The fastest and best approach for your particular site will be specific to your site and there is no generic solution guaranteed to be optimal.

Backbone by documentcloud could be the other option to consider because 4k of gzipped code is not so big also.

backbone is super nice, i wont be the one saying otherwise. It isn't the same scope tho. It does event emitter and much much more!

I like micro frameworks (aka tiny libraries) because it is standalone and so small you can easily maintain it yourself if needed. So it is less an actual dependancy.

Reminds me of https://github.com/jivesoftware/jiverscripts. Check out the conc.observable component

To be honest I was surprised you couldn't bind, trigger, or unbind on a function this way already. I guess I never came across a specific need for it.

Dmitry's got something similar, Eve: http://dmitry.baranovskiy.com/eve/

Reply on news.ycombinator.com