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”

Actually I jut went trough this confusing process comparing SproutCore 1 and SproutCore 2. Looking forward to give Amber.js a try..

Amber sounds great. I look forward to learning more about it.

I did a search on Github to see if I could find anything, and I found another Amber JS project that looks unrelated.

Naming conflict?

Really looking forward to seeing what you guys have come up with! However, the new name might cause a bit of confusion with, no?

I’m bummed on the name since there’s already a js project called Amber:

That’s what I get for posting on my phone… ditto with Mateo.

Just wondering if you’ve heard of Backbone JS (

Awesome. Can’t wait to try it.

Could see this coming for quite a while now. Always had to explain to people that SC2 had very little in common with SC1. Will definitely make it simpler to differentiate now.

I’ve had good success with Backbone.js for mobile apps. Look forward to learning how Amber compares. Especially: will Amber support disconnected/offline clients?

When can we expect Amber in Action?

Who designed the current Sproutcore website? It’s pretty nice, hopefully Amber will be on par.

When I read the title, I was worried this meant SC2 was no more. Glad to find that this is just a re-branding. SC2/Amber is awesome btw. You and Tom Dale have done a great job. Can’t wait for more.

I remember you mentioning this at a JavaScript meetup. Looks good, I’ll give it a go.

Thank you! I cant wait to see some examples! I’ve been a web developer for 7 years and know JavaScript well enough to be dangerous, I usually use jquery to abstract common functionality from browser specific problems – works great for upgrading “web pages”, but I LOVE the idea of a framework that puts me on the correct path to abstract what I would want/need to (or should) do with a “web app”.

Yehuda, I found the solid direction of SproutCore 2.0 to be promising for exactly the type of app you describe. Happy to see a focused project based on those principles!

Too long, didn’t read.

Can you re-post and summarize what Amber.JS brings? All the additional information, while interesting to you, has no place here.

When reading the title on stackoverflow, I thought you were talking about the Amber Smalltalk in Javascript (which is quite new).

Very excited to try this!

Always looking for the newest and best. I’m still not decided on a JS MVC framework, although I’m leaning towards Backbone. If Amber is less code than Backbone, then more power to you.

Forgot to add, when can we expect to see some demos and sample apps?

“SproutCore 1.x was primarily a native-style widget library”

That’s selling it pretty short, don’t you think? It’s not exactly analogous to jQuery UI. The closest comparison would be Cappuccino, or on the desktop, Cocoa — i.e. a full-featured desktop application framework for apps on the web.

First things first: I love SproutCore 2.0!
But, how could you choose to call it Amber when there is already a JavaScript library called Amber? (
This is really confusing.

Thanks, Yehuda. It’s VERY good that you are going to continue support of SproutCore 2.0!

Happy to see the rename, Yehuda. I think this will help clear things up for a lots of newcomers to the communities.

Where does BPM fit in moving forward? Is it part of the Amber ecosystem, or is there an alternative approach you’re using / planning on?

I think this is zur right move. SC2, sorry, I meant Amber.js is already a great framework. Keep in the good work and don’t forget to update bpm. Tool support is what’s most important. Let is nie where we can step in and contribute some work.

Fantastic guys. This is EXACTLY what was needed: everyone in the SC1.x community will be happy to follow you.

So will Amber have the native-style widgets of Sproutcore 1.

Looks hot! Can’t wait to get my hands on it.

Not a good name as there’ s already a Smalltalk written in JavaScript called Amber:



I like what I hear about SC2/Amber.js and cant wait for the new Amber.js website! (hopefully simple and yet informative!)

Sounds awesome, but I was surprised by the name choice. Why not something sprout-y like, I don’t know, sprig.js?

Zendesk just announced the beta of our Amber-based agent interface. If you’re a customer, you can sign up for the beta here to see Amber in action:

Couldn’t you name it something isn’t already a JS project?

This sounds fantastic. I really love the Backbone API but yeah, having a change event trigger a single function like render and then having to look at what changed and piecemeal through your templates to prevent over-reflow (i.e. re-render the entire template) sounds like a worthy goal (if I’m reading that correctly).
As always Yehuda, sounds like fantastic strides!

@Dan offcourse he has heard of backbone. he mentioned it in the article didn’t he.

I would be interested to see how it’s going to be different from Knockout.js, because that already appears to meet the requirements of everything you’re describing here….

@Peter Hulst

Amber.js offers a lot of additional performance optimizations. For example, a value can change hundreds of time, but because we batch view rendering, the DOM will only be manipulated once.

Personally, I’m not a fan of Knockout’s templating solution. Embedding JavaScript into data attributes on DOM elements seems like a layering violation and doesn’t seem like it would scale well. It also requires scanning the DOM at initialization time, which can be expensive.

In general, other libraries that do bindings tend to special case them so that they work only between the view layer and the model layer. In Amber, they’re built into all objects, which means you can use them anywhere. I also think that Amber’s APIs for expressing bindings and computed properties are more elegant, but of course I am a biased source. ;)

Let me know when you are at the point where I should start adding Amber support to Illuminations. :)

Thank you guys for all the good work you’re doing. Great!

It sounds like you reinvented the wheel. You’ve effectively rebuilt KnockoutJS.

Have you at least talked to Steve Sanderson or other guys?

Also the name Amber.js is going to cause way more confusion than SproutCore 2.0 as such a JS library already exists.

Looks like trying to solve 2 issues it brought some more.

And for those who don’t like KnockoutJS “embedding” of JavaScript (cc Tom Dale).

You don’t have to. You can do it from JS. So this critique it doesn’t really apply.

Also KnockoutJS provides a way of using ANY templating language.

So it looks like the issues describe here has already beens solved.

So, are you guys saying there’s already another project called amber? Is that what you’re saying?

I’ve come from a Flex background, which has had binding for many years (recently including bidirectional) in its declarative views to an arbitrary expression. I’ve become convinced too, that views with trivial binding expressions to model properties, and controllers modifying the model, is the future (as opposed to the less desirable MVVM where the controller manipulates the view).

I’ve also come to the conclusion that the next step is using signals ( (not events) that live in the model layer – because they are independent from the DOM or any presentation layer (among other advantages). You then can write view-less tests with the model and controller, including signals, and the view is a very thin layer over the rest (therefore less testing required).

I’ve also been trying to convert a non-trivial app from Flex to JS. I found AngularJS framework (check it out and like its approach which is similar, but unfortunately its DOM magic is clashing with jQuery Mobile’s magic, and so I’m looking at alternatives. I’ll be watching Amber closely.

@Dmytrii Nagirniak

You’re saying KnockoutJS allows you to make any templating language auto-updating? I find that very hard to believe.

SproutCore existed before Knockout, and we’ve been working on what became Amber since around the same time they started. To assume that this is a NIH issue is absurd. Knockout is great but it solves the problem in a different way despite the superficial similarities. I think if you look at the different implementations of, e.g., Addy Osmani’s TodoMVC project, that much should become clear.

Nice move. The .2 naming was causing confusion indeed.
Coming from the backbone background (but using handlebars as my templates) I would really appreciate a post spotting the conceptual differences to help me out to make the switch or at least try it out. @LindseySimon re the event mechanism makes it sound juicy could you maybe elaborate on that (or Lindsey) ?

To avoid confusion, you named it after another significant JavaScript project (Amber,

Does not sound like a good idea, since the confusion already started. “Build with Amber” does now mean what? Is it written in Amber Smalltalk or the SproutCore descendant?

Sigh :(

Is this about smalltalk or something else?

“Bramble.js” Domain’s open.

What does this mean for Handlebars? Any chance you’ll add binding support to that?

@Jesse Cooke I agree with you .. amber.js project is already present. Again it will create more confusions. You might consider changing it ? some suggestions

BlackBird.js – SproutBeans.js – auracore.js

Leave a Reply