Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

Announcing Amber.js

A little over a year ago, I got my first serious glimpse at SproutCore, the JavaScript framework Apple used to build MobileMe (now iCloud). At the time, I had worked extensively with jQuery and Rails on client-side projects, and I had never found the arguments for the “solutions for big apps” very compelling. At the time, most of the arguments (at least within the jQuery community) focused on bringing more object orientation to JavaScript, but I never felt that they offered the layers of abstraction you really want to manage complexity.

When I first started to play with SproutCore, I realized that the bindings and computed properties were what gave it its real power. Bindings and computed properties provide a clean mechanism for building the layers of abstractions that improve the structure of large applications.

But even before I got involved in SproutCore, I had an epiphany one day when playing with Mustache.js. Because Mustache.js was a declarative way of describing a translation from a piece of JSON to HTML, it seemed to me that there was enough information in the template to also update the template when the underlying data changed. Unfortunately, Mustache.js itself lacked the power to implement this idea, and I was still lacking a robust enough observer library.

Not wanting to build an observer library in isolation (and believing that jQuery’s data support would work in a pinch), I started working on the first problem: building a template engine powerful enough to build automatically updating templates. The kernel of the idea for Handlebars (helpers and block helpers as the core primitives) came out of a discussion with Carl Lerche back when we were still at Engine Yard, and I got to work.

When I met SproutCore, I realized that it provided a more powerful observer library than anything I was considering at the time for the data-binding aspect of Handlebars, and that SproutCore’s biggest weakness was the lack of a good templating solution in its view layer. I also rapidly became convinced that bindings and computed properties were a significantly better abstraction, and allowed for hiding much more complexity, than manually binding observers.

After some months of retooling SproutCore with Tom Dale to take advantage of an auto-updating templating solution that fit cleanly into SproutCore’s binding model, we reached a crossroads. SproutCore itself was built from the ground up to provide a desktop-like experience on desktop browsers, and our ultimate plan had started to diverge from the widget-centric focus of many existing users of SproutCore. After a lot of soul-searching, we decided to start from scratch with SproutCore 2.0, taking with us the best, core ideas of SproutCore, but leaving the large, somewhat sprawling codebase behind.

Since early this year, we have worked with several large companies, including ZenDesk, BazaarVoice and LivingSocial, to iterate on the core ideas that we started from to build a powerful framework for building ambitious applications.

Throughout this time, though, we became increasingly convinced that calling what we were building “SproutCore 2.0″ was causing a lot of confusion, because SproutCore 1.x was primarily a native-style widget library, while SproutCore 2.0 was a framework for building web-based applications using HTML and CSS for the presentation layer. This lack of overlap causes serious confusion in the IRC room, mailing list, blog, when searching on Google, etc.

To clear things up, we have decided to name the SproutCore-inspired framework we have been building (so far called “SproutCore 2.0″) “Amber.js”. Amber brings a proven MVC architecture to web applications, as well as features that eliminate common boilerplate. If you played with SproutCore and liked the concepts but felt like it was too heavy, give Amber a try. And if you’re a Backbone fan, I think you’ll love how little code you need to write with Amber.

In the next few days, we’ll be launching a new website with examples, documentation, and download links. Stay tuned for further updates soon.

UPDATE: The code for Amber.js is still, as of December 8, hosted at the SproutCore organization. It will be moved and re-namespaced within a few days.

63 Responses to “Announcing Amber.js”

If you rename amber, please, do not rename it brite or bright, as I have already a project with solving the same problematic (with a different approach).

One question, given the renaming of the framework, the namespace SC will be renamed to another stuff (like AM)? Or it will still SC?

I notice a lot of focus on the templating bits of Amber.js. What about the other bits of Sproutcore? Controllers, models? What’s going on there?

I’m currently using Knockout.js in production. While it’s a great project with some fantastic qualities, it’s hardly the same as Ember.js. Here are a few differences:

- Ember.js aims to be a framework. Knockout aims to be a tool
Steve has noted this on the mailing list. As a result, KO doesn’t provide or suggest support for routing or persistence. While people can (and do) add that functionality on to KO, it’s not trying to provide a complete client side framework as Ember is aiming to do.

- Building complex, client side apps with KO isn’t a piece of cake
KO doesn’t have a robust (or much at all) system for managing models or relationships between models. As a result, it can be tricky to properly structure a KO app that scales well and is easily maintainable.

- KO’s performance isn’t always exemplary
As Tom already pointed out, scanning the DOM at init can be costly. Further, I’ve found it’s manipulating of DOM elements to be slow as it checks for changes to each element’s value before removing it.

- KO can leak memory if you’re not careful
I’ve spent countless hours making sure every dependentObservable is cleaned up.

- KO’s code aesthetics might be offensive to your eyes
Generally, I find the code hard to follow and the long, long, long camelcased method names to be confusing. The Ember.js code is clean, neatly organized, and, for the most part, easy to follow. I encourage you to read the dependentObservable code in KO and summarize how it’s working.

All that said, Knockout has many great qualities which I haven’t bothered to lay out. Steve’s done great work and I’ve definitely appreciated using the tool. However, KO does have some weaknesses that I’ve encountered as I’ve built a non-trivial app with it. I’m looking forward to Ember.js as I think it will address many of the problems I’ve run into.

FYI: Amber.js has been renamed to Ember.js

Where can I get the datastore and statechart packages?

@Wilker The Namespace is EM and Ember, but for a while it will be SC too

Github Repo

You will lose to Backbone.js

This is for sure.

thanks…always an inspiring person…cant wait to play around with ember.js :)

the bi-directional databinding is what make it more interesting than backbone to me. but really, where can I find the serious documentations?

Question does this require jquery or can you use something smaller like xui.js??

Right now Ember requires jQuery 1.6 or 1.7.

Leave a Reply