When.js 3.2 released

We recently released when.js 3.2 (3.2.2 as of this post), cujoJS's JavaScript promises implementation.

It has some pretty cool and unique features:

  1. 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).

  2. 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.

  3. Debuggability - asynchronous code and promises are notoriously hard to debug. In other JavaScript promise implementations, asynchronous failures are silent by default. When.js 3.2 detects asynchronous failures and makes them loud by default.

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.

When.js has consistently been one of the most widely used JavaScript promise implementations (80k+ npm downloads in the last month!), and we think that trend will continue!

Continue reading...


The future looks bright for modules, but what about curl.js?

In an increasingly mobile-first, JavaScript-everywhere landscape, the importance of curl.js and cram.js as the foundation of a modular architecture has never been more clear. On the cujoJS team, we're continually researching and developing new and better ways to assemble your code, whether it's AMD, CommonJS, legacy scripts, CSS, HTML, JSON, etc. If you haven’t done so already, check out what you can do with the latest releases.

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?

Continue reading...

New cram.js and curl.js releases!

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” ...

Continue reading...

Do you still support IE 6? What about Netscape 4?

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.

Continue reading...

OOP is not my hammer

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.

Continue reading...

The new and improved!

cujoJS is taking off! We've always felt that there was a need for better architectural tools in JavaScript. Obviously, we are not alone. It seems like we make new friends every day: developers from all over the JavaScript community continually reach out to thank us for bringing sanity to their code -- and their life.

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!

Continue reading...