Live with grace. Write superb software.


  • Native vs Bluebird vs Core-Promise Benchmark

    I just took for a test the native promises implementation (that is available since node v0.12), the bluebird implementation, and core-promise, my own TypeScript implementation.

    The tests are here for the native, bluebirdor core-promise. Note that all the implementations pass the full Promises/A+ test spectrum of 872 tests.

    I ran each test file 11 times, using:

    for f in `seq 0 10`; do time mocha test-core-promise.js > /dev/null 2>&1; done

    Obviously, I changed the file name between iterations.

    I removed 11.9 seconds, because these are setTimeouts in the actual tests, remaining with actual execution of promises time, and these are the final results (in seconds):


    Native Bluebird Core-Promise

    1.616 1.760 1.564

    1.567 1.626 1.520

    1.568 1.669 1.548

    1.539 1.657 1.573

    1.574 1.595 1.557

    1.583 1.604 1.580

    1.543 1.582 1.540

    1.529 1.622 1.567

    1.600 1.605 1.567

    1.407 1.661 1.544

    1.467 1.640 1.587



    Unsurprisingly the native implementation won performance wise, but only less than 1% compared to the core-promise, but ~5% compared to bluebird. Also core-promise defaults to the native promises implementation if it's available, if you would use the exported Promise class (for tests I accessed the CorePromise implementation on purpose).

    var Promise = require("core-promise").Promise;

    Not to mention readability of code: core-promise's Promise vs bluebird's Promise.

    *Disclaimer* I am the creator of the core-promise, and yes I feel pretty good getting better performance than the "unmatched performance" of bluebird. :)

  • WebComponents

    I'm more and more interested in web components as a technology. Apparently out there there are two ways to do components:

    On one hand there are implementations like BosonicPolymer or X-Tag, where you can define new components that extend the HTML vocabulary, and they seem to search some common ground. The big thing that concerns me is actually shared behavior, since no one uses raw JS contexts anymore. Can you truly do that, without reinventing the wheel, without a new framework? Is integration with existing frameworks easily done for non-trivial components? (e.g. a calendar component might need data validation, that is offered by the framework, like YUI3 for example).

    Another approach is to create a widget system, like GWT composites, or YUI widgets, and the idea is that you can have widgets reusing widgets, and generally build really powerful abstractions on top of that, sticking for the most part to HTML (eventually with extensions - GWT works with XHTML and different namespaces). There are other variations in using different templating engines (e.g. handlebars), different UI class hierarchies, but the general idea is the same. You have widgets that are pure JS objects from the framework, tied to some visual representation, with composition part of the API either declaratively (by templates) either imperatively (e.g. a calendar widget manually creates the input widgets, spans and divs it needs for its visual representation, and keeps references to them).

    The difference that I see is that extending the HTML vocabulary in theory could provide a unifying common platform, allowing me (allegedly) to reuse the components across frameworks and also get a far more clean markup, since now the markup describes real components (instead of a bunch of divs that are bounded by some voodoo JS behind the curtains pulling all the logic strings).

    But I have a feeling the real challenge is framework integration, and that's why Angular didn't jumped into the Polymer bandwagon even if they are made both by people from the same company.


The one to rule them all. The browsers that is.


SharpKnight is an Android chess game.


MagicGroup is an eclipse plugin.