

Amber.js (formerly SproutCore 2.0) is now Ember.js (and released) - wycats
http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcore-2-0-is-now-ember-js/

======
dmvaldman
How does this compare to other JS MVC libraries like Backbone.js?

~~~
Jacob4u2
I can't speak for backbone.js, but this looks a little more verbose than my
favorite MVC framework; Knockout.js (<http://learn.knockoutjs.com/>).

~~~
andrewl-hn
Especially considerring Knockout Model plugin that basically adds Backbone-
style capabilities to KO models. Other notable plugins give easy bindings for
jQuery UI widgets, Underscore support for collections and external templates:

<https://github.com/SteveSanderson/knockout/wiki/Plugins>

I'd also like to point out that in the upcomming release Knockout ads several
nifty improvements:
[http://blog.stevensanderson.com/2011/08/31/knockout-1-3-0-be...](http://blog.stevensanderson.com/2011/08/31/knockout-1-3-0-beta-
available/)

My favorite are control flow bindings that let you write templating code right
inside your HTML and not withing script tags. When you have to write markup
inside a script tag you editor might get the whole autocompletion, formatting
and syntax coloring wrong. And in past it was relly annoying for me. So having
templates in HTML, not in script is really great.

One thing that helps a lot is that all bindings are defined inside data-
attributes which keeps markup valid. Most editors support them well, too.
Ember's double-braced template attributes are really weak choice in this
regard.

And if you're worried about javascript bits inside data-bind attributes you
now have an option to separate them via binding providers (see blog post
above). The syntax is somewhat clunky but still workable and I suppose it can
be improved.

Provided that Knockout has a vibrant community and growing support inside .NET
world I think Ember has nothing to offer to make me switch.

And that's unfortunate. Today I see like most frameworks converges to some
common ground. Knockout gets more features from Backbone. Backbone gets more
features from Knockout (there's at least one bindings plugin for BB although
it pales in comparison to Ko). And as far as I can see we as a JavaScript
community reached the next base.

\- We started with simple Ajax libraries. \- Then we moved to widgets. \- Now
we got MVP frameworks and think more about organizing our applications in
general.

What's the next step? That's the most important question for me and for other
JS professionals that I talked to at recent local conference. When I saw
Yahuda's announcement I really hoped that he'd give us a clue. Instead we got
another MVP variant and not a top one although a pretty solid.

I suspect that Ember still will get some users. Yahuda has dedicated fans (me
included) and Knockout as something coming from .NET world has a somewhat hard
time getting adoption among the general JS crowd. Maybe that's a good thing:
two frameworks are very similar and can learn from one another. But I
personally hoped for more.

Still, congrats on releasing the thing! Keep it up!

~~~
grayrest
> What's the next step? That's the most important question for me and for
> other JS professionals that I talked to at recent local conference.

Components with bindings IS the next step. Douglas Adams quote:

"The History of every major Galactic Civilization tends to pass through three
distinct and recognizable phases, those of Survival, Inquiry and
Sophistication, otherwise known as the How, Why and Where phases. For
instance, the first phase is characterized by the question, 'How can we eat?'
The second by the question, 'Why do we eat?' And the third by the question,
'Where shall we do lunch?'"

Whenever the topic of web app development has come up in the past 5 years or
so, I always think of this quote. In the case of front end development, the
questions are "Can we do this?" (CGI, asp/jsp/php), "Can we make this feel
better?" (ajax, rails & co), and "How shall we structure our app?"
(components, binding, widgets). This last phase only kicked of in earnest
about a year ago and I'm still evangelizing the approach to even relatively up
to date developers. They've heard of Backbone, for example, but haven't
investigated and don't know how it applies to day to day work.

Going forward, expect to see interoperability concerns addressed. I've seen
proposals for this in the form of html5 component model [1][2] and style tag's
scoped attribute [3]. This provides a common ground for people to mix
different libraries/components on the same page with a reasonable confidence
that things won't break.

[1] [http://lists.w3.org/Archives/Public/public-
webapps/2011AprJu...](http://lists.w3.org/Archives/Public/public-
webapps/2011AprJun/1345.html) [2] [http://lists.w3.org/Archives/Public/public-
webapps/2011AprJu...](http://lists.w3.org/Archives/Public/public-
webapps/2011AprJun/1364.html) [3]
<http://dev.w3.org/html5/spec/Overview.html#attr-style-scoped>

I also expect one of the KVO frameworks and it's associated widget system to
"win" like jQuery has won DOM manipulation. What makes widget frameworks in
the browser fun is that people have an expectation of being able to completely
restyle everything and the only way I know of to do that cleanly without
forcing a lot of fragile markup is with sass/less/stylus, so I expect to see
those increase in popularity.

As a whole, web apps have been less sophisticated than equivalent complexity
desktop and mobile apps. I've long believed that much of this is due to us re-
writing a half-assed widget system from scratch for every project. This
consumes a significant fraction of the time/money/effort allocated to a
project which apps on other platforms can put into additional capabilities or
polish. As such, I think the wide adoption of a KVO framework and widget
library will be an inflection point for the quality and sophistication of apps
in the browser. I'm looking forward to it.

------
acak
One of Sproutcore's most attractive features was the Mac like UI it was
capable of - <http://demo.sproutcore.com>

Ember.js does not show such examples at - <http://www.emberjs.com/examples>

Will such examples be showcased in the future or is it not a part of Ember.js?

~~~
cheald
Ember seems to be far stripped down from Sproutcore - specifically, it doesn't
come with any kind of existing view resources or existing widgets, which is
what enables those sorts of standard UIs. I suspect this is because Ember is
targeted at web apps (where visual diversity is often an application
requirement), while Sproutcore is going to be more focused on mobile apps
(where a standard UI toolkit is not just nice, but expected).

~~~
ebryn
That's true. Ember isn't trying to provide a set of UI widgets out of the box.
I'm confident that Ember-compatible UI libraries will be released in the near
future.

SproutCore 1.x isn't very mobile-friendly at the moment. The original reason
the SproutCore 2.0 rewrite began was to make the framework lightweight so that
it'd be more suitable for use on mobile platforms.

I've started a project, Ember-Titanium, that enables native mobile app
development using Ember's runtime on the Titanium Mobile platform. The project
is still in it's infancy, but I've already been successful at building apps
with it.

<https://github.com/ebryn/ember-titanium>

------
ericflo
I foresee lots of confusion between Ember.js and Ender.js. I hope I'm wrong,
because both projects look great!

~~~
rxcfc
The projects have very different goals so I don't think there will be too much
confusion.

~~~
snikch
As does Amber Smalltalk, yet they changed the name due to that conflict!

------
jpadilla_
This is how I actually imagined Backbone.js before I actually used it.

------
exogen
If the Ember.js authors keep the library focused, I'm convinced this could be
a very important project. Having tried the popular MVC frameworks out there,
and having lots of experience with KnockoutJS, nothing out there is a clear
winner yet for just binding Views. We need a library that focuses only on this
problem, and excels at it, with no knowledge of URLs, AJAX, routing, storage,
or default widgets/styles.

------
prodigal_erik
Unfortunately still lacking any progressive enhancement story to run their
logic at the server and contribute to the world-wide web of linkable
resources. Content imprisoned behind a 1990-vintage client/server architecture
seriously sucked (there's only one client that works, it's terrible, and you
can't even fix it) and I'm losing hope that we can escape a repeat of it.

~~~
exogen
What about the current state of the browser market (assuming that's what you
mean by client) leads you to believe we're moving toward a single terrible
client that we can't fix? We have several good browsers and engines on the
market, half of them open source.

You know what's 1990-vintage? The set of HTML controls you have at your
disposal, right now, even with HTML5, to send to the client to progressively
enhance. At some point you have to draw the line. Require JavaScript and offer
an API for the content. It'll be better specified than a bunch of markup
anyway, which has a tendency to change at the whim of designers and marketing.

This library is supposed to be small and tightly focused. Providing
progressive enhancement should be up to the developers using the library, not
the library authors. Including it in the library would dictate too much about
how things must work on the server, thus limiting the audience.

~~~
prodigal_erik
By "client" I mean the unhackable blob of minified js which is the one and
only piece of code in existence that knows how to get any useful content out
of today's revision of one server's undocumented protocol. APIs are the
problem, they are displacing portions of the web which were far more reusable.
They require custom clients (usually in js) per site, and the authors who
aren't responsible enough to do progressive enhancement are the same ones who
aren't capable of (or even interested in) maintaining a documented, stable,
backward-compatible API for years. Markup changed but was at least mostly
self-describing before it became acceptable to serve obfuscated data and
repair it using code that end users shouldn't need and oughtn't blindly trust.

------
wwweston
Well, I'm off to write a library called Umber.js.

~~~
freejoe76
Imma gonna do one called UmberHulk.js

------
calvin
It's "released" but it doesn't have a license file yet. In reply to this issue
on their github repo, they state it will use the MIT license, but I don't feel
comfortable using a library until I know what the terms are.

~~~
ebryn
License has been added. It's MIT.

------
MatthewPhillips
Any non-trivial application will contain more than one code file. What is the
Ember.js solution for this? Makefiles? And what about HTML? I'd like to
organize those by sections of the app. How is that achieved?

~~~
ebryn
I'd recommend rake-pipeline: <http://github.com/livingsocial/rake-pipeline>

Most of the Ember apps I'm aware of are using it.

Also, you might want to check out rake-pipeline-web-filters for additional
functionality: <https://github.com/wycats/rake-pipeline-web-filters>

~~~
MatthewPhillips
That looks pretty awesome, thanks. However I feel like this is something the
framework should handle for the basic use cases. Learning rake-pipeline is
probably worth the effort but should never be required. Developers should
spend their time thinking about their app, not deployment details.

------
swah
Takes me 15 seconds to display "Hello world" when I run the index.html on the
starter-kit... Either that runs a lot of tests or something is wrong...

~~~
chezandre
The link to the jquery file is missing a http:. So it's taking so long because
of a 15 seconds timeout.

~~~
khingebjerg
That is just a protocol relative url.

See: <http://paulirish.com/2010/the-protocol-relative-url/>

~~~
chezandre
Ok. But it still explains why it took so long to load for swah. Because when
you run index.html from your hard drive locally it wil use the file://
protocol instead of <http://>

------
ale55andro
Congrats on the release. The name is quite nice too and already growing on me.
I'm excited to try it out.

------
cheriot
Is there a mailing list?

Do you recommend any libraries for managing url state?

~~~
ebryn
There isn't an official library at this time, but we've been successful with
the SC 1.x routing library which has been ported for use with Ember.

<https://github.com/emberjs-addons/sproutcore-routing>

------
lux
The link to emberjs.com seems to be broken. Just FYI :)

~~~
rxcfc
Thanks. It was a temporary glitch and is working fine now.

~~~
dangrossman
Not working for me either, with OpenDNS:

<http://i.imgur.com/6mS9a.png>

~~~
davej
It's a DNS propagation issue. Didn't work with my ISP's DNS but worked fine
with Google Public DNS.

------
viandante
How is this different from knockout?

------
socialist_coder
Does anyone actually care about this type of news?

~~~
raganwald
Does anyone have to ask this question when they can simply observe the upvote
count at their leisure?

;-)

~~~
wavephorm
It's not democracy if there's only an upvote.

~~~
raganwald
Odd, that’s exactly how we do things up here in Canada: You vote _for_ the
candidate you like. There is no way to vote _against_ anybody.

Just like the HN front page, there is only room for the candidate who gets the
most votes to win a seat in Parliament, so our democracy functions without
downvotes.

How does it work where you live?

~~~
wavephorm
Getting only one vote is certainly not the same as being able to upvote many
articles.

If each visitor to HN could only upvote one article a day then it would be
similar.

~~~
raganwald
And politicians aren't news articles. So how is it that you get to draw a
parallel between Politicsand a web site when it suits the point you wish to
make, but when someone retorts in kind, you claim they are more different than
similar?

If what you are trying to say is that it's not democracy regrdless of how the
arrows work, I agree. It's not democracy because it isn't a system of social
governance.

