5 ms·

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

60 points by jerome_etienne 16y ago

yatsyk 16y ago
Backbone by documentcloud could be the other option to consider because 4k of gzipped code is not so big also.
- jerome_etienne 16y ago
  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.
peregrine 16y ago
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.
amadeus 16y ago
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_Objects/Function/bind 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.
- jerome_etienne 16y ago
  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 :)
  - amadeus 16y ago
    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 https://github.com/amadeus/microevent.js
    - jerome_etienne 16y ago
      cool. will look at it. lets take this on github
    - jerome_etienne 16y ago
      cool. will look at it. lets take this on github
maxogden 16y ago
Reminds me of https://github.com/jivesoftware/jiverscripts https://github.com/jivesoftware/jiverscripts. Check out the conc.observable component
aw3c2 16y ago
Wouldn't tiny code like this better included in the HTML itself? A fraction of a packet size versus a HTTP request.
- udp 16y ago
  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)
  - rbranson 16y ago
    ^^^ 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.
    - DTrejo 16y ago
      And for scripts that google is too slow to put on their cdn... http://www.cdnjs.com/ http://www.cdnjs.com/
- amadeus 16y ago
  When deploying to live, you should compress all JS and aggregate into a single file.
  - morganpyne 16y ago
oscilloscope 16y ago
Dmitry's got something similar, Eve: http://dmitry.baranovskiy.com/eve/ http://dmitry.baranovskiy.com/eve/

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

jerome_etienne 16y ago
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.

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.

amadeus 16y ago

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_Objects/Function/bind 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.

jerome_etienne 16y ago
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 :)
- amadeus 16y ago
  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 https://github.com/amadeus/microevent.js
  - jerome_etienne 16y ago
    cool. will look at it. lets take this on github
  - jerome_etienne 16y ago
    cool. will look at it. lets take this on github

maxogden 16y ago

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

aw3c2 16y ago

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

udp 16y ago
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)
- rbranson 16y ago
  ^^^ 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.
  - DTrejo 16y ago
    And for scripts that google is too slow to put on their cdn... http://www.cdnjs.com/ http://www.cdnjs.com/
amadeus 16y ago
When deploying to live, you should compress all JS and aggregate into a single file.
- morganpyne 16y ago

oscilloscope 16y ago

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