11 ms·

Announcing Amber.js

311 points by wycats 15y ago

burke 15y ago
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.
asolove 15y ago
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 http://news.ycombinator.com/item?id=3248552
- sid6376 15y ago
  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.)
  - judofyr 15y ago
    Indeed. Bindings are just triggers that makes sure the data model is in sync with the view. It's just for convenience. There is also a model binding plugin to Backbone: https://github.com/derickbailey/backbone.modelbinding https://github.com/derickbailey/backbone.modelbinding
    - sid6376 15y ago
      Thanks for the explanation!
    - jashkenas 15y ago
      Just to be clear -- the Backbone.js "party line" is that automatic 2-way binding between views and models is usually undesirable. The model contains the "truth" -- the current state of the app. Views should be bound to models and automatically update when the model changes. But when the view changes, the reverse is not the case. You don't want every checkbox click, radio button twiddle, and keystroke to be causing your model to change ... thereby emitting changes which may cause other pieces of your app to re-render, changes which may cause Ajax requests to persist the model state to the server, and so on. Instead, most apps have a "save" button for some changes, a mouse click for others, or drag and drop, or a gesture, or an "undo" link. It's much more convenient and flexible to allow your app to react to DOM events as it needs to, instead of having specific model attributes hard-bound to concrete DOM elements. ... that said, if the latter is your cup of tea, there's a plugin for that.
      - evlapix 15y ago
        I think what you've pointed out is true. Once I learned BB, I've always felt like I had to decide between fast views with KO, or scalable logic with BB. When the modelbindings plugin came into my life, I was super excited to potentially have the best of both worlds. It was immediately obvious to me, the downsides you suggested. In my simple case it was an append interface, not an edit interface, so I stubbornly worked around it by creating orphaned models that are bound to my user editable view, and then get added into the app focused collection once submitted.
- shiftb 15y ago
  What are the meaningful API differences between Spine and Backbone?
  - asolove 15y ago
    For the full story, see my comment at: http://news.ycombinator.com/item?id=3248552 http://news.ycombinator.com/item?id=3248552 tl;dr: managed attributes and fine-grained model attribute events make life a lot easier and change the boundary between model and controller.
koudelka 15y ago
I certainly hope this doesn't splinter the community. Moving the version up, then just forking, seems like it'd do just that.
andrewvc 15y ago
I thought this was going to be about http://amber-lang.net/ http://amber-lang.net/ , smalltalk on javascript. Another project worth checking out.
- mark_l_watson 15y ago
  +1 that is very cool, thanks.
carldall 15y ago
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?
- rxcfc 15y ago
  See http://blog.sproutcore.com/changes-to-sproutcore/ http://blog.sproutcore.com/changes-to-sproutcore/ for more information on the future of SC1.
- deleted 15y ago
  [deleted]
  - tomdale 15y ago
    Just to be clear: all existing SproutCore 2.0 apps are Amber apps. It's a brand change, not a code change.
    - carldall 15y ago
      Yeah, but SC1 and SC2(Amber) are rather different.
      - rmgraham 15y ago
        Hence the rename.
- ynniv 15y ago
  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.
krmmalik 15y ago
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 15y ago
  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.
  - krmmalik 15y ago
    Thanks for responding. Do you have a video of the demo?
    - joubert 15y ago
      Hi - here's a video of the meet up and a link to the demo Amber-on-NodeJS code http://joubert.posterous.com/yehuda-talking-about-amberjs-sproutcore-20 http://joubert.posterous.com/yehuda-talking-about-amberjs-sp...
- bmuon 15y ago
  You can run pretty much any JS library on Node with jsdom https://github.com/tmpvar/jsdom/ https://github.com/tmpvar/jsdom/
  - wycats 15y ago
    Amber's runtime component runs in node without any special browser shims.
swah 15y ago
Is this like Backbone?
MatthewPhillips 15y ago
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?
- maratd 15y ago
  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.
- davej 15y ago
  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.
- rxcfc 15y ago
  We're definitely aware of this issue and are working on some solutions that should be relatively painless.
- ccapndave 15y ago
  bpm (http://www.getbpm.org/ 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.
- ebryn 15y ago
  Amber's object model is very powerful. It has mixins and easy-to-use inheritance. You can reopen classes too.
- bmuon 15y ago
  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.
mahmoudimus 15y ago
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 :)
- MatthewPhillips 15y ago
  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.
- jashkenas 15y ago
  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/ http://www.sproutcore.com/ You can scroll through a long list of Backbone apps here: http://backbonejs.org/#examples http://backbonejs.org/#examples I'm not aware of app lists for the others you mentioned.
- Cushman 15y ago
  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.
  - Androsynth 15y ago
    I'm not sure why you are getting downvoted. Although I don't feel you necessarily need to share it on HN, the best way is the build some simple apps and find out for yourself what the libraries are all about.
    - 15y ago
CoffeeDregs 15y ago
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 15y ago
  "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.
seddona 15y ago
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.
- scelerat 15y ago
  HTML was made with documents in mind. Ever since the web's inception HTML has been pushed beyond its original design specs and now people are writing applications in it (actually they have been since CGI). That interfaces continue to evolve and even replicate "native" interfaces shouldn't be a surprise. As far as the "right" abstraction on the web... this too is evolving and highly dependent on your application. Are you curating a collection of hyperlinked documents? Or are you writing a drawing application? If your answer is closer to the latter than the former, then the analogy you're looking for is something more like Postscript, where HTML and Javascript serve as a display language for an output device (a browser), driven by an underlying application.
erichocean 15y ago
I wrote about the future of SproutCore 1.x here: http://dl.dropbox.com/u/323974/Future%20of%20SproutCore.pdf http://dl.dropbox.com/u/323974/Future%20of%20SproutCore.pdf
- caycep 15y ago
  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:
  - wycats 15y ago
    "Blossom will use the GPLv3 license, with commercial licensing similar to the Sencha model." I don't have a clear idea about what's going on in the SproutCore community, but I don't think this has universal support. One of the reasons we rebranded to Amber is that our codebase is inspired by SproutCore 1, but it is a complete rewrite, targeting a smaller file size and web-centric development. All of the fragments of SproutCore 1.x target native-style applications with a ton of JavaScript, while Amber targets ambitious web-style applications using HTML and CSS for the presentation layer. Amber apps don't have much in common with SproutCore 1 (or "blossom") apps, so a clean naming break felt like a clarifying thing to do.
    - erichocean 15y ago
      Blossom is a commercial product, it's not part of the proposed SproutCore.js path forward for SproutCore 1.x. It is, however, API-compatible with the MIT-licensed view layer (called "Classic") in SproutCore.js. See the paper for more details.
- Joeri 15y ago
  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.
spatten 15y ago
"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.
RShackleford 15y ago
fuck Amber.js
jebblue 15y ago
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.
- funksta 15y ago
  Some people actually like writing javascript ;^)
  - jebblue 15y ago
    I get it, it's cool, maybe it's jealousy I'm experiencing.
Androsynth 15y ago
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.
tree_of_item 15y ago
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 15y ago
  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>
ghempton 15y ago
Amber looks to be getting awesomely close to a CSS/HTML version of Flex.
kqueue 15y ago
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.
gfodor 15y ago
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.
autarch 15y ago
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?
- jashkenas 15y ago
  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.
  - autarch 15y ago
    That's actually really good to know. I'll have to look into that further.
- tomdale 15y ago
  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.
atomical 15y ago
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!
andyl 15y ago
The Amber claim is "if you’re a Backbone fan, I think you’ll love how little code you need to write with Amber". Can anyone explain the differences between Amber and Backbone, why Amber might require less coding?
- grayrest 15y ago
  Both Amber and Backbone fall into what I call the KVO frameworks category (Angular, Javascript MVC, Knockout, Batman, others). Both use jQuery for DOM manipulation and revolve around the idea of having a canonical model and having that as the center of your app. As you change the model, it fires events that you use to update the DOM. The difference is that Backbone is philosophy. Backbone provides a basic but complete set of tools for observing model changes combined with a set of utilities that are useful but not prescriptive to make wiring up DOM events, URL handling, etc straightforward. It works with what's in jQuery/the browser. All together, it provides the organization most js apps are sorely lacking but doesn't dramatically reduce LoC over what you could do with well factored jQuery and underscore. It's nice enough that the YUI team basically adopted it wholesale for the App framework in 3.5. Amber is all about binding. You can not only observe properties but bind them to other properties bidirectionally so that changing one causes the change to propagate through all bound values including things like values being arrays. This extends to the Handlebars templating (which was written for Amber) where you can bidirectionally bind, for example, a boolean on your model to a checkbox and to a class on a div so that checking the checkbox toggles the class without anything in your app directly manipulating the DOM. The implementation is an attribute plus two object path strings in the template. It's not panacea but since DOM/Event/State manipulation is ~60-70% of most JS apps I've worked with, you can achieve dramatic code size reductions. The cost is that Amber is 10x the size of Backbone, the templating language is tied to the framework, and there's more overhead in understanding the concepts, how they fit together, and how to apply them to your code. When I talk to people who are writing jQuery spaghetti, I steer them towards Backbone for the simplicity and superior docs but mention that I use Amber for my own projects.
pbreit 15y ago
So SproutCore 2.0 is being renamed Amber.js?
- rxcfc 15y ago
  Yes.
tenderlove 15y ago
AMBER ALERT!
barumrho 15y ago
I couldn't help but think about AngularJS while reading this article. (http://angularjs.org/ http://angularjs.org/) I am not sure why it isn't as popular as other JavaScript frameworks like Backbone.
- ludicast 15y ago
  AngularJS is ridiculously good so I'm not sure either. For those who are unfamiliar: Angular examples are about 1/4 the size of backbone equivalents. I'm working on an angular version of the most recent peepcode backbone cast. It's about 1/5 the code size, and available here: https://github.com/ludicast/angular-peepcode-todo https://github.com/ludicast/angular-peepcode-todo
tomkr 15y ago
It looks like it's actually called ember.js. http://www.emberjs.com/ http://www.emberjs.com/
- mvzink 15y ago
  Indeed, for those of us who missed it, they had a poll: http://news.ycombinator.com/item?id=3335916 http://news.ycombinator.com/item?id=3335916 and Yehuda announced the change yesterday: http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcore-2-0-is-now-ember-js/ http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor...

311 points by wycats 15y ago

burke 15y ago

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.

asolove 15y ago

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 http://news.ycombinator.com/item?id=3248552

sid6376 15y ago
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.)
- judofyr 15y ago
  Indeed. Bindings are just triggers that makes sure the data model is in sync with the view. It's just for convenience. There is also a model binding plugin to Backbone: https://github.com/derickbailey/backbone.modelbinding https://github.com/derickbailey/backbone.modelbinding
  - sid6376 15y ago
    Thanks for the explanation!
  - jashkenas 15y ago
    Just to be clear -- the Backbone.js "party line" is that automatic 2-way binding between views and models is usually undesirable. The model contains the "truth" -- the current state of the app. Views should be bound to models and automatically update when the model changes. But when the view changes, the reverse is not the case. You don't want every checkbox click, radio button twiddle, and keystroke to be causing your model to change ... thereby emitting changes which may cause other pieces of your app to re-render, changes which may cause Ajax requests to persist the model state to the server, and so on. Instead, most apps have a "save" button for some changes, a mouse click for others, or drag and drop, or a gesture, or an "undo" link. It's much more convenient and flexible to allow your app to react to DOM events as it needs to, instead of having specific model attributes hard-bound to concrete DOM elements. ... that said, if the latter is your cup of tea, there's a plugin for that.
    - evlapix 15y ago
      I think what you've pointed out is true. Once I learned BB, I've always felt like I had to decide between fast views with KO, or scalable logic with BB. When the modelbindings plugin came into my life, I was super excited to potentially have the best of both worlds. It was immediately obvious to me, the downsides you suggested. In my simple case it was an append interface, not an edit interface, so I stubbornly worked around it by creating orphaned models that are bound to my user editable view, and then get added into the app focused collection once submitted.
shiftb 15y ago
What are the meaningful API differences between Spine and Backbone?
- asolove 15y ago
  For the full story, see my comment at: http://news.ycombinator.com/item?id=3248552 http://news.ycombinator.com/item?id=3248552 tl;dr: managed attributes and fine-grained model attribute events make life a lot easier and change the boundary between model and controller.

koudelka 15y ago

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

andrewvc 15y ago

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

mark_l_watson 15y ago
+1 that is very cool, thanks.

carldall 15y ago

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?

rxcfc 15y ago
See http://blog.sproutcore.com/changes-to-sproutcore/ http://blog.sproutcore.com/changes-to-sproutcore/ for more information on the future of SC1.
deleted 15y ago
[deleted]
- tomdale 15y ago
  Just to be clear: all existing SproutCore 2.0 apps are Amber apps. It's a brand change, not a code change.
  - carldall 15y ago
    Yeah, but SC1 and SC2(Amber) are rather different.
    - rmgraham 15y ago
      Hence the rename.
ynniv 15y ago
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.

krmmalik 15y ago

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 15y ago
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.
- krmmalik 15y ago
  Thanks for responding. Do you have a video of the demo?
  - joubert 15y ago
    Hi - here's a video of the meet up and a link to the demo Amber-on-NodeJS code http://joubert.posterous.com/yehuda-talking-about-amberjs-sproutcore-20 http://joubert.posterous.com/yehuda-talking-about-amberjs-sp...
bmuon 15y ago
You can run pretty much any JS library on Node with jsdom https://github.com/tmpvar/jsdom/ https://github.com/tmpvar/jsdom/
- wycats 15y ago
  Amber's runtime component runs in node without any special browser shims.

swah 15y ago

Is this like Backbone?

MatthewPhillips 15y ago

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?

maratd 15y ago
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.
davej 15y ago
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.
rxcfc 15y ago
We're definitely aware of this issue and are working on some solutions that should be relatively painless.
ccapndave 15y ago
bpm (http://www.getbpm.org/ 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.
ebryn 15y ago
Amber's object model is very powerful. It has mixins and easy-to-use inheritance. You can reopen classes too.
bmuon 15y ago
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.

mahmoudimus 15y ago

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 :)

MatthewPhillips 15y ago
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.
jashkenas 15y ago
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/ http://www.sproutcore.com/ You can scroll through a long list of Backbone apps here: http://backbonejs.org/#examples http://backbonejs.org/#examples I'm not aware of app lists for the others you mentioned.
Cushman 15y ago
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.
- Androsynth 15y ago
  I'm not sure why you are getting downvoted. Although I don't feel you necessarily need to share it on HN, the best way is the build some simple apps and find out for yourself what the libraries are all about.
  - 15y ago

CoffeeDregs 15y ago

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 15y ago
"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.

seddona 15y ago

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.

scelerat 15y ago
HTML was made with documents in mind. Ever since the web's inception HTML has been pushed beyond its original design specs and now people are writing applications in it (actually they have been since CGI). That interfaces continue to evolve and even replicate "native" interfaces shouldn't be a surprise. As far as the "right" abstraction on the web... this too is evolving and highly dependent on your application. Are you curating a collection of hyperlinked documents? Or are you writing a drawing application? If your answer is closer to the latter than the former, then the analogy you're looking for is something more like Postscript, where HTML and Javascript serve as a display language for an output device (a browser), driven by an underlying application.

erichocean 15y ago

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

caycep 15y ago
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:
- wycats 15y ago
  "Blossom will use the GPLv3 license, with commercial licensing similar to the Sencha model." I don't have a clear idea about what's going on in the SproutCore community, but I don't think this has universal support. One of the reasons we rebranded to Amber is that our codebase is inspired by SproutCore 1, but it is a complete rewrite, targeting a smaller file size and web-centric development. All of the fragments of SproutCore 1.x target native-style applications with a ton of JavaScript, while Amber targets ambitious web-style applications using HTML and CSS for the presentation layer. Amber apps don't have much in common with SproutCore 1 (or "blossom") apps, so a clean naming break felt like a clarifying thing to do.
  - erichocean 15y ago
    Blossom is a commercial product, it's not part of the proposed SproutCore.js path forward for SproutCore 1.x. It is, however, API-compatible with the MIT-licensed view layer (called "Classic") in SproutCore.js. See the paper for more details.
Joeri 15y ago
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.

spatten 15y ago

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

RShackleford 15y ago

fuck Amber.js

jebblue 15y ago

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.

funksta 15y ago
Some people actually like writing javascript ;^)
- jebblue 15y ago
  I get it, it's cool, maybe it's jealousy I'm experiencing.

Androsynth 15y ago

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.

tree_of_item 15y ago

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 15y ago
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>

ghempton 15y ago

Amber looks to be getting awesomely close to a CSS/HTML version of Flex.

kqueue 15y ago

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.

gfodor 15y ago

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.

autarch 15y ago

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?

jashkenas 15y ago
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.
- autarch 15y ago
  That's actually really good to know. I'll have to look into that further.
tomdale 15y ago
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.

atomical 15y ago

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!

andyl 15y ago

The Amber claim is "if you’re a Backbone fan, I think you’ll love how little code you need to write with Amber". Can anyone explain the differences between Amber and Backbone, why Amber might require less coding?

grayrest 15y ago
Both Amber and Backbone fall into what I call the KVO frameworks category (Angular, Javascript MVC, Knockout, Batman, others). Both use jQuery for DOM manipulation and revolve around the idea of having a canonical model and having that as the center of your app. As you change the model, it fires events that you use to update the DOM. The difference is that Backbone is philosophy. Backbone provides a basic but complete set of tools for observing model changes combined with a set of utilities that are useful but not prescriptive to make wiring up DOM events, URL handling, etc straightforward. It works with what's in jQuery/the browser. All together, it provides the organization most js apps are sorely lacking but doesn't dramatically reduce LoC over what you could do with well factored jQuery and underscore. It's nice enough that the YUI team basically adopted it wholesale for the App framework in 3.5. Amber is all about binding. You can not only observe properties but bind them to other properties bidirectionally so that changing one causes the change to propagate through all bound values including things like values being arrays. This extends to the Handlebars templating (which was written for Amber) where you can bidirectionally bind, for example, a boolean on your model to a checkbox and to a class on a div so that checking the checkbox toggles the class without anything in your app directly manipulating the DOM. The implementation is an attribute plus two object path strings in the template. It's not panacea but since DOM/Event/State manipulation is ~60-70% of most JS apps I've worked with, you can achieve dramatic code size reductions. The cost is that Amber is 10x the size of Backbone, the templating language is tied to the framework, and there's more overhead in understanding the concepts, how they fit together, and how to apply them to your code. When I talk to people who are writing jQuery spaghetti, I steer them towards Backbone for the simplicity and superior docs but mention that I use Amber for my own projects.

pbreit 15y ago

So SproutCore 2.0 is being renamed Amber.js?

rxcfc 15y ago
Yes.

tenderlove 15y ago

AMBER ALERT!

barumrho 15y ago

I couldn't help but think about AngularJS while reading this article. (http://angularjs.org/ http://angularjs.org/) I am not sure why it isn't as popular as other JavaScript frameworks like Backbone.

ludicast 15y ago
AngularJS is ridiculously good so I'm not sure either. For those who are unfamiliar: Angular examples are about 1/4 the size of backbone equivalents. I'm working on an angular version of the most recent peepcode backbone cast. It's about 1/5 the code size, and available here: https://github.com/ludicast/angular-peepcode-todo https://github.com/ludicast/angular-peepcode-todo

tomkr 15y ago

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

mvzink 15y ago
Indeed, for those of us who missed it, they had a poll: http://news.ycombinator.com/item?id=3335916 http://news.ycombinator.com/item?id=3335916 and Yehuda announced the change yesterday: http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcore-2-0-is-now-ember-js/ http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor...