Yehuda Katz is a member of the Ruby on Rails core team, and lead developer of the Merb project. He is a member of the jQuery Core Team, and a core contributor to DataMapper. He contributes to many open source projects, like Rubinius and Johnson, and works on some he created himself, like Thor.
Announcing Amber.js
December 8th, 2011
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.
Gregory Igelmund, Posted December 8, 2011, 11:40 am
Actually I jut went trough this confusing process comparing SproutCore 1 and SproutCore 2. Looking forward to give Amber.js a try..
Mason Hale, Posted December 8, 2011, 11:42 am
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. https://github.com/NicolasPetton/amber
Naming conflict?
Mateo, Posted December 8, 2011, 11:45 am
Really looking forward to seeing what you guys have come up with! However, the new name might cause a bit of confusion with http://amber-lang.net/, no?
Jesse Cooke, Posted December 8, 2011, 11:47 am
I’m bummed on the name since there’s already a js project called Amber: http://amber-lang.net/
Jesse Cooke, Posted December 8, 2011, 11:49 am
That’s what I get for posting on my phone… ditto with Mateo.
Dan, Posted December 8, 2011, 11:54 am
Just wondering if you’ve heard of Backbone JS (http://documentcloud.github.com/backbone/)
Brian Cardarella, Posted December 8, 2011, 11:55 am
Awesome. Can’t wait to try it.
Garth Williams, Posted December 8, 2011, 12:08 pm
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.
andy l, Posted December 8, 2011, 12:11 pm
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?
Bala Paranj, Posted December 8, 2011, 12:14 pm
When can we expect Amber in Action?
Dan, Posted December 8, 2011, 12:31 pm
Who designed the current Sproutcore website? It’s pretty nice, hopefully Amber will be on par.
Rajiv Navada, Posted December 8, 2011, 12:32 pm
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.
Andrew, Posted December 8, 2011, 12:55 pm
I remember you mentioning this at a JavaScript meetup. Looks good, I’ll give it a go.
Steve T, Posted December 8, 2011, 1:23 pm
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”.
Jon Crosby, Posted December 8, 2011, 1:26 pm
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!
Jodo, Posted December 8, 2011, 1:27 pm
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.
Francois Stephany, Posted December 8, 2011, 1:28 pm
When reading the title on stackoverflow, I thought you were talking about the Amber Smalltalk in Javascript (which is quite new).
Casey Rankin, Posted December 8, 2011, 1:28 pm
Very excited to try this!
andy matthews, Posted December 8, 2011, 1:46 pm
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.
andy matthews, Posted December 8, 2011, 1:47 pm
Forgot to add, when can we expect to see some demos and sample apps?
Erich Ocean, Posted December 8, 2011, 1:53 pm
“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.
Been living on another planet?, Posted December 8, 2011, 1:57 pm
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? (amber.st).
This is really confusing.
Pavel Forkert, Posted December 8, 2011, 2:01 pm
Thanks, Yehuda. It’s VERY good that you are going to continue support of SproutCore 2.0!
Luke Melia, Posted December 8, 2011, 2:03 pm
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?
Steffen Fritzsche, Posted December 8, 2011, 2:10 pm
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.
TD, Posted December 8, 2011, 2:14 pm
Fantastic guys. This is EXACTLY what was needed: everyone in the SC1.x community will be happy to follow you.
MySchizoBuddy, Posted December 8, 2011, 2:17 pm
So will Amber have the native-style widgets of Sproutcore 1.
Andre Bernardes, Posted December 8, 2011, 2:31 pm
Looks hot! Can’t wait to get my hands on it.
Markus Gaelli, Posted December 8, 2011, 2:54 pm
Not a good name as there’ s already a Smalltalk written in JavaScript called Amber:
http://amber-lang.net/
Cheers
Markus
FP, Posted December 8, 2011, 3:14 pm
I like what I hear about SC2/Amber.js and cant wait for the new Amber.js website! (hopefully simple and yet informative!)
Tad Thorley, Posted December 8, 2011, 3:32 pm
Sounds awesome, but I was surprised by the name choice. Why not something sprout-y like, I don’t know, sprig.js?
James A Rosen, Posted December 8, 2011, 4:22 pm
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: http://www.zendesk.com/lotus/
secondplanet, Posted December 8, 2011, 5:07 pm
Couldn’t you name it something isn’t already a JS project?
Lindsey Simon, Posted December 8, 2011, 5:16 pm
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!
MySchizoBuddy, Posted December 8, 2011, 5:26 pm
@Dan offcourse he has heard of backbone. he mentioned it in the article didn’t he.
Peter Hulst, Posted December 8, 2011, 5:50 pm
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….
Tom Dale, Posted December 8, 2011, 6:27 pm
@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. ;)
Steven Roussey, Posted December 8, 2011, 7:06 pm
Let me know when you are at the point where I should start adding Amber support to Illuminations. :)
Guillem Camprodon, Posted December 8, 2011, 8:11 pm
Thank you guys for all the good work you’re doing. Great!
Dmytrii Nagirniak, Posted December 8, 2011, 8:35 pm
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.
Dmytrii Nagirniak, Posted December 8, 2011, 8:38 pm
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.
indrid cold, Posted December 8, 2011, 9:15 pm
So, are you guys saying there’s already another project called amber? Is that what you’re saying?
Gary Mc, Posted December 8, 2011, 11:03 pm
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 (http://millermedeiros.github.com/js-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 http://angularjs.org) 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.
Tom Dale, Posted December 8, 2011, 11:40 pm
@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.
charles sistovaris, Posted December 9, 2011, 4:21 am
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) ?
Thanx
Richard Durr, Posted December 9, 2011, 7:56 am
To avoid confusion, you named it after another significant JavaScript project (Amber, http://amber-lang.net/)?
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 :(
Reggie, Posted December 9, 2011, 8:00 am
Is this about smalltalk or something else?
marajit, Posted December 9, 2011, 8:09 am
“Bramble.js” Domain’s open.
geddesign, Posted December 9, 2011, 11:20 am
What does this mean for Handlebars? Any chance you’ll add binding support to that?
crudbug, Posted December 9, 2011, 4:21 pm
@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