Announcing Amber.js

[asolove]

I know what you're thinking: great, another MVC library for Javascript. But wait: Yehuda knows what he's doing, it will be interesting to see what Amber includes.

As I've discussed before [1], the current discussion about MVC frameworks in JavaScript is very superficial, and meaningful API differences between, e.g. Spine and Backbone, are not sufficiently understood by people who are picking between them.

Yehuda has a lot of experience thinking about framework APIs from the standpoint of modularity, performance, and developer convenience.

He is absolutely right to emphasize that calculated properties and managed attributes on the model layer are the key to easily building JavaScript interfaces. The difference between nice MVC code and poor MVC code or jQuery soup is the idea that in each method data is only flowing one direction: nowhere are you manually updating both a UI and a data object. Two-way data flows make up the majority of the code in non-MVC jQuery-oriented code. In contrast, a robust model layer with lots of events is the best way to get code reuse and composition.

[1] http://news.ycombinator.com/item?id=3248552

[sid6376]

I am new to web development and have just started using/learning javascript and so my knowledge is limited, to say the least. But isnt what you are saying easily achievable through backbone.js.(by calling a set on a model and triggering an event which the view catches and updates itself.)

[shiftb]

What are the meaningful API differences between Spine and Backbone?

[CoffeeDregs]

I guess I'm excited that a community figure is forking/creating/updating a new-ish Javascript framework and I should focus on AmberJS in my comment, but...

I can't help but feeling that the oh-so-confusing situation with SproutCore just got more confusing. I, like many others, tried to start using SproutCore and found it to be a poorly documented jumble of code. Fortunately, SproutCore 2.0 was going to fix a lot of that. Only now it isn't. Do we have two half-baked, related frameworks? Are they kinda ports of each other? Is SproutCore 1.x now deprecated? And how confusing will it be when SproutCore 1.x upgrades to a not-AmberJS SproutCore 2.x?

This smells of politics/investor-meddling/internal-disagreements/something to me: fresh, innovative, though-derivative take on an existing codebase is forked out of the original company and is moved under another company (Tilde). Something seems amiss.

[wycats]

"Fortunately, SproutCore 2.0 was going to fix a lot of that. Only now it isn't. Do we have two half-baked, related frameworks? Are they kinda ports of each other? Is SproutCore 1.x now deprecated? And how confusing will it be when SproutCore 1.x upgrades to a not-AmberJS SproutCore 2.x?"

SproutCore 2.0 becomes Amber. We'll be moving the code into the amberjs organization today. The SproutCore folks, who are now focusing on native-style applications, will be carrying the torch on the (not deprecated) SproutCore 1.x.

[mahmoudimus]

A little off-topic, but, how are developers staying up to date in the JavaScript community?

I've been an observer of the JavaScript eco-system and it is changing so rapidly, particularly in the MVC space (i.e. SproutCore 1.xx, SproutCore 2.xx, BackBone.js, Spine.js, Knockout.js, etc etc).

It's so easy to get stuck in analysis paralysis. Is there a discussion list or a website that can help make some decisions for my next hack project?

I'm coming from a heavy backend background and I think the JavaScript MVC space warrants a hack-day project :)

[jashkenas]

Apart from evaluating the APIs yourself, and reading the source, the best way to decide is by looking the apps have been built with each framework.

SproutCore (1) has a list of apps halfway down this page: http://www.sproutcore.com/

You can scroll through a long list of Backbone apps here: http://backbonejs.org/#examples

I'm not aware of app lists for the others you mentioned.

[mundizzle]

TodoMVC: A common learning application for popular JavaScript MVC frameworks - http://addyosmani.github.com/todomvc/

[Cushman]

Pick one that seems cool. Build something with it. Share it on HN; you will get comments like "Cool-- but why are you using X instead of Y?"

Repeat using Y.

[MatthewPhillips]

Most don't. Just keeping up with new DOM additions is difficult enough. Instead you pick a project and follow it until you run into problem area it can't solve and then move on to another.

[andrewvc]

I thought this was going to be about http://amber-lang.net/ , smalltalk on javascript. Another project worth checking out.

[mark_l_watson]

+1 that is very cool, thanks.

[Androsynth]

Is it still in beta? Are the core objects going to be built up further (to their sc1 levels) or left sparse as they are now? Is it going to get a full set of guides and object documentation?

I recently tried out SC2 (now Amber, I suppose) and I had a "Wow this is cool!" moment immediately followed by a "Wow I can't do shit" moment due to lack of documentation combined with the steep learning curve. I had to put the project on hold; I hope the framework gets some serious love in the next couple months.

[autarch]

Maybe it's just me, but I find this idiom incredibly gross:

  var prop = model.get('prop')

It seems much more elegant to write:

  var prop = model.prop()

You can do the computed properties and binding thing the same way, it's really just a small difference in the model API.

But really, what I'd love to see is more model-agnostic tools. Why do I have to buy into SproutCore or Backbone's model implementation just to use the other features?

[tomdale]

The advantage of using accessors is that your implementation can switch between static properties and computed properties and the consumers of your API don't have to know which is which. This is called the uniform access principle and ends up being extremely useful.

For example, imagine you have an Store object that saves the tax rate:

  Store = SC.Object.create({
    taxRate: 0.0895
  });

Since this is a static value, I don't technically have to use an accessor. But imagine my state implements a tax holiday, and so for one day per year, the tax rate is different. In Amber, this is a simple change:

    taxRate: function() {
      if (this.get('isTaxHoliday')) {
        return 0;
      }
      return 0.0895;
    }.property()

Instead of trawling my codebase to references for this property and changing them to method invocations, because everything goes through get(), I know the change will be transparent. It's this transparency that leads to very maintainable web apps.

Some people object to the extra method invocation, but I think the expressiveness it gets you is worth it. As soon as proxies land in JavaScript, we'll add support for them so you can use the dot notation and still get the same functionality.

[jashkenas]

You don't. Plenty of folks use Backbone's views and routers in isolation, without using models or collections -- especially for apps/visualizations where the data is static, and doesn't change.

[burke]

Exciting! It really does make sense to rebrand SproutCore 2.0. As a (light) user of both 1.x and 2.0, I completely understand the change. So much has been simplified -- the barrier to entry has dropped considerably, and the boilerplate factor is basically gone. Yehuda and Tom have done a great job with SproutCore, and I'm excited to use (continue using) Amber in the future.

[spatten]

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

Sold! You read my mind there, Yehuda.

I don't exactly know why, but I'm excited by this. Heart beating noticeably faster excited. I'll be playing around with this on the weekend.

[erichocean]

I wrote about the future of SproutCore 1.x here: http://dl.dropbox.com/u/323974/Future%20of%20SproutCore.pdf

[caycep]

hm, so does this mean a fork into 2 different development environments?

i.e.: sproutcore.js/blossom - "desktoppy" MVC framework with HTML5/js as a display layer

amber.js - "web-appy" MVC framework with HTML5/js as a display layer?

*edit:

[Joeri]

It's ironic that both sproutcore and extjs fell prey to version fragmentation in the community because they tried to do too much too fast. I'm stuck on ExtJS 3.4 waiting for the 4.x line to mature to the point where it isn't half as slow and twice as buggy as 3.x.

[MatthewPhillips]

The biggest problem for me with any JS framework I've tried in the past is that it doesn't give an easy way to divide code into multiple code files. For me personally, I find any single file/module/class that is more than a few hundred LOC to be difficult to read. For this reason I've usually rolled my own frameworks. Does Amber.js address this?

[tolmasky]

Cappuccino's @import does this really well: it is both asynchronous and blocking. In other words, having three @imports one after the other will all load in parallel (without having to explicitly request it, even if they are separated by other lines of code), but the code itself will not execute until the imports are done:

    @import "one.js" // loaded in parallel to the other two
    @import "two.js" // loaded in parallel to the other two

    code code code // this is run only after one.js and two.js (but not three.js) have been loaded and run

    @import "three.js" // loaded in parallel to the other two

[davej]

Spine uses HEM which allows you to develop your apps using separate files (in JS or CS), it basically uses the CommonJS spec AFAIK.

Then when you want to move from development to production it concatenates and minifies all the files for improved network performance.

[ef4]

Actually I'd rather not see the JS framework itself trying to solve this problem. The Rails asset pipeline (based on Sprockets) is an example of a good solution to this problem that is completely agnostic to your JS framework.

I'm serving a substantial Amber app this way and it works great. I'm taking it a step further by writing most of my code in Coffeescript, and I keep all my Handlebars templates in separate files as well. Sprockets just magically combines it all.

[bmuon]

You could also look at YUI. YUI3 is built from the bottom up with that mentality: keep a file for each class, merge them in the build stage into one module file and serve all modules combined automatically.

[maratd]

Take a look at MooTools. It's built around a module/class based philosophy that makes it easy to not only configure the framework itself into what you need (the framework is built around several dozen small files), but to do the same thing to your code as well.

[ccapndave]

bpm (http://www.getbpm.org/) works with Amber and compiles multiple Javascript, SCSS and Coffeescript into a single JS and CSS file. It also has a mode where it does it in realtime for development use.

[randall]

Browserify lets you require stuff if you're used to node paradigms.

https://github.com/substack/node-browserify

[ebryn]

Amber's object model is very powerful. It has mixins and easy-to-use inheritance. You can reopen classes too.

[rxcfc]

We're definitely aware of this issue and are working on some solutions that should be relatively painless.

[korny]

brunch (http://brunch.io) provides this for backbone.js / eco / stylus - it merges multiple source files into a single deployable js (and css) file. Or you could use spine, which has this out of the box.

[erichocean]

SproutCore has supported this since 2007.

[carldall]

Good news. I wonder though, what will happen to Sproutcore? My former company build a huge application based on 1.4 (at that time), and now they're kinda left in the rain. Does anybody know when or if all the Sproutcore 1.x changes that Apple made for iCloud/MobileMe make it back into SC 1.x?

[ynniv]

There are three contingents right now. Facebook (SC2/Amber) wants to make rich web pages. Tilde (SC 1.7+) wants to continue the Strobe direction of deploying client side web applications in different contexts. Erich Ocean (1.4 fork) wants to go back to his original philosophy of creating applications that can be deployed on the natively or on the web. The primary break Erich Ocean wants to make is to drop templates and construct interfaces in the desktop / Cocoa style, not a mixed HTML templating one.

So there are still core folks working on 1.x, but in different contexts.

[rxcfc]

See http://blog.sproutcore.com/changes-to-sproutcore/ for more information on the future of SC1.

[atomical]

If the people developing Amber are reading this and I'm sure they are I hope they take away the message that the community wants better documentation, examples, tutorials, and use cases. It's not features, abstraction X, Y, or Z, it's support!

[kqueue]

I tried using SC2 (aka Amber), while it has a lot of potential and I love the powerful binding mechanism it has, it simply lacked documentation and support. I hope Amber has tackled this issue.

[seddona]

Why anybody thought it was a good idea to replicate desktop applications verbatim on the web i dont know, the era of composing GUI's from complex fully featured widgets is dying.

Declarative presentation in HTML/CSS coupled to JS (or better CS) is the right layer of abstraction for building GUI's for most applications in the foreseeable future.

Amber.js looks very interesting, i hope it paves a new wave of client frameworks that concentrate on state sync between client/server (and multiple clients) with some simple binding to presentation.

[koudelka]

I certainly hope this doesn't splinter the community. Moving the version up, then just forking, seems like it'd do just that.

[gfodor]

Can someone explain how far along this is on the spectrum of creating a constraint-based UI toolkit like OpenLaszlo or (I think) Flex? Constraint based programming is amazing for the view tier, and I've been waiting to see if someone comes along and builds one comparable to the Flash based ones that have been around for years.

[krmmalik]

Will it be possible to incorporate something like this into Node.js? I know it can be done with something like Backbone, and does it provide any distinct advantages over Backbone that would be worth investing the time in this library?

[wycats]

A few months ago I showed a demo at a meetup of using Amber in node. The main benefit of Amber in a node environment is the way it abstracts asynchronous behavior through bindings and observers.

I could easily imagine an Amber object representing a File in node, for instance, allowing other objects to bind to properties like mtime, etc.

In my demo, I used socket.io to update an HTML page whenever one of those properties changed.

[bmuon]

You can run pretty much any JS library on Node with jsdom https://github.com/tmpvar/jsdom/

[tree_of_item]

Is there a way to use SproutCore without the command line programs like sc-init or sc-server, and without it forcing a directory structure on you?

I like the idea of SproutCore, but I really just want to do <script src="sproutcore.js"> and have it get out of my way from there. YUI seems to be able to do this and it seems even larger than SproutCore, recently including MVC in its "App Framework". Of course, you need to bring your own templating, but even then that's just another JavaScript include.

Or am I missing the point of SproutCore? What is it adding that, say, YUI or Dojo isn't, that it requires so many programs?

[grayrest]

The sc-init and sc-server are Sproutcore 1.X. Sproutcore 2.X (now Amber, what we're discussing here) works exactly like you'd want:

    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"></script>
    <script src="js/libs/sproutcore-2.0.beta.3.min.js"></script>
    <script src="js/app.js"></script>

[jebblue]

It seems like new JavaScript frameworks are popping up every week.

I think Google with GWT and Eclipse less so with RAP had the right idea. Come up with technologies that abstract away the need to touch JavaScript directly. Just Java (or I suppose C# could work) on the client and the server means the developers are more in sync.

I'm more on the back-end so my perspective is more from the side lines, please don't read too much into it.

[tomkr]

It looks like it's actually called ember.js. http://www.emberjs.com/

[mvzink]

Indeed, for those of us who missed it, they had a poll: http://news.ycombinator.com/item?id=3335916 and Yehuda announced the change yesterday: http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor...