It has some pretty cool and unique features:
Speed - It's currently one of the fastest promise implementations. In a current set of benchmarks from another promise vendor, when.js 3.2 is 10x to over 100x faster than the native Promise implementations in Firefox, Chrome, and Node (v0.11.13).
Scalability - Most other implementations don't scale well. As the amount of parallelism and number of promises increases, their performance increases linearly or worse. When.js's speed and memory usage scale better than linear, even for tens of thousands of parallel promises.
We're planning followup posts to dig a bit deeper into each of these 3 aspects. Specifically, we'll talk about the combination of architectural and code-level optimizations that make when.js fast and scalable, and the trade-offs and decisions we've made when dealing with debuggability.
But what's next for curl and cram? Isn't it about time we bumped curl to 1.0.0?
Well, it may not be so simple. If you haven't noticed, we've been talking a lot about ES6 modules and loaders recently. ES6 is the future, of course, and one of cujoJS's core principles is to embrace the future. More than a few times we’ve asked:
What do the cujoJS projects look like in an ES6 world? Are curl and cram even needed at all?
Five releases in one week! So, what’s new?
- More compatibility, including support for dojo 1.8/1.9, lodash, and Windows command-line
- Improved and updated documentation
- New features, including a “legacy script” loader similar to RequireJS’s “shim config” ...
Sometimes the only way to move forward is to let go of the past. As library authors, we are particularly cognizant that the environments we support has a direct impact on the environments you, as developers, support. After all, turning away a visitor at the door means fewer visitors and lost revenue/mindshare.
To date, each cujoJS project independently chooses which environments it actively tests against. This makes it harder to determine the supported environments when using multiple cujoJS projects. We'd like to fix that. Before making any changes we be clear about our plans, and provide an opportunity for feedback.
This post originally appeared on HTML5 Hub
As a young coder, the first design pattern I learned was inheritance. This was, of course, my introduction to Object Oriented Programming (OOP). I was blown away by the simple idea that I could add or change an object’s behavior by overriding bits of it. I eventually went on to learn and use much more advanced Design Patterns by the Gang of Four, all of which expand upon simple inheritance. It seemed that inheritance and OOP were the answer to all design problems, whether known or yet-to-be-discovered.
These same folks knock us for our lack of a real web presence as well as our scant educational materials. We're happy to announce we're beefing up!