
Ember.js 1.0 Released - ozkatz
http://emberjs.com/blog/2013/08/31/ember-1-0-released.html
======
tomdale
I said this already on Twitter, but:

 _It’s been 2½ years since I started working on Ember.js. While I’m proud of
the code we wrote, I’m even more proud of the community we built._

We have been lucky enough to attract the companies and individuals that are
tackling the hardest problems in developing 100% JavaScript web applications;
people for whom the only acceptable answer is solid engineering, not piles of
hacks.

As we mention in the blog post, Ember.js went through a reboot midway through
its life when we realized the thing we were building was not the thing that
needed to be built. If you tried Ember.js previously and had a bad experience,
I'd really encourage you to give it a whirl again. We've smoothed over the
rough surfaces, and now have the documentation and community to help you get
started.

If you'd just like to take a peek at what building an Ember.js app is like, I
recorded a ~25 minute screencast that takes you soup to nuts:

[https://www.youtube.com/watch?v=1QHrlFlaXdI](https://www.youtube.com/watch?v=1QHrlFlaXdI)

Lastly, I'd like to express my personal gratitude to everyone that pitched in
at the 11th hour to get this release out the door. I couldn't be more proud to
call this awesome group of developers my friends.

~~~
Kudos
Have you got that screencast available as a download somewhere?

~~~
tomdale
No, but that's a great idea. Do you have any recommendations for a host that
can serve up files of this size?

~~~
wildster
S3

~~~
cpursley
Nginx + S3 & CDN for blazing fast client side apps.

------
sambeau
Let's _not_ use this opportunity to start another Ember vs Angular argument.
Can we instead take a moment to celebrate the fact that we now have two major,
stable, fast, capable, testable, tested, supported, documented, git-hubbed
single-app javascript frameworks with large, passionate communities.

Let's also recognise and celebrate the hard work put into these projects by
the Ember & Angular teams. Ember and Angular are two shining examples of
modern open-source software.

We can debate the finer points and minute advantages of each framework later,
preferably once we've all tried them both.

Congratulations, Ember 1.0! Roll on, Angular 1.2!

~~~
danso
Since when did Backbone not count as a major framework?

~~~
mayhew
Backbone is a library, not a framework.

~~~
Helianthus
Backbone is still a major player in the ecosystem, whatever you call it.

~~~
Demiurge
It's more like the ORM. And I use it quite nicely when that's what I need.
However, I can't compare it to Ember.js, because it can't replace it and other
features in Ember.

------
ehsanu1
I've been interested in using Ember.js in the frontend for a Rails app,
especially after watching a mock competition between it and Angular [1]. But
it's beta status kept me from using it, and even now I wonder if it really is
production ready, or just API-stable (which they say they will be as per
[http://semver.org/](http://semver.org/)). I also don't know if it's really
worth the up-front cost of learning and slowing down initial development of a
new product, especially while at a startup trying to set an aggressive release
date for the product.

I'm also a bit worried about the need for everyone on the team to learn how
Ember works and its conventions, when they already know how to figure out
whatever mess of ad-hoc jQuery and random objects someone would write instead
(as bad as that is for maintainability). And finally, I won't have the
advantage of green field development, as there is an existing app which will
be added to. So there will end up being a chunk of the app with Ember, and a
(functionally separate) part of the app not using Ember at all.. Which does
not seem ideal.

Anyone want to chime in with their experiences?

[1] [https://vimeo.com/68215606](https://vimeo.com/68215606) \- Note it's a
bit unfair with the project lead for Ember, tomdale, on one of the "cage
match"

~~~
gavinjoyce
> I don't know if it's really worth the up-front cost of learning and slowing
> down initial development of a new product

This is true when considering the introduction of any new technology or when
to pay down technical debt. The answer for you will likely depend on the
complexity of the product that you are building, how important a great UX is,
how close you are to shipping something, and whether the promise of building a
clean and scalable browser application outweighs the short term benefits of
delivering a "mess of ad-hoc jQuery and random objects".

I've worked within a medium sized team building a large Ember application and
have seen first hand how beneficial it can be when dealing with application
complexity and a need for precise UX attention to detail, even when using a
much earlier version. I've also experienced frustration with the documentation
and quickly moving goalposts as the framework evolved towards v1.0.

Happily, everything has become so much easier in the last few months. The
documentation and guides are now a fantastic resource after a huge push from
the team and community. The framework itself requires much less boilerplate
code, Ember automatically generates controllers, routes and views at runtime
should you not need to customise their behaviour. The addition of support for
promises across the framework has resulted in more terse and consistent
application code. I've found the community to be very helpful and I'm excited
to see how it will grow over the coming months.

> So there will end up being a chunk of the app with Ember, and a
> (functionally separate) part of the app not using Ember at all.

I'm helping a client do exactly this at the moment. Their current application
consists of a many pages with ball of JavaScript and jQuery sitting on top of
their clean REST API. They want to raise the bar for what their application
can do and the medium term goal is to deliver a single page Ember application.
In the short term, we're building some of the most complex new features in
Ember. These features will be accessed through modal iframes for a time
allowing us to build out the Ember application without having to rebuild
everything.

------
outside1234
Congrats! I'm been using Ember for over a year and I love it.

My protip for the newbie is to go install Yeoman, then install the generator
(npm install generator-ember), and then you can scaffold out a project as
easily as (yo ember), and build a minified version as easy as (grunt build),
and have a live updating version of the site as easy as (grunt server).

------
programminggeek
After building some single page JS web apps small and large, I am not sure
that building large JS web apps is actually a good idea.

In fact, a lot of the time they probably aren't a good idea. It is often
better to just build out separate pages and on a page that requires more
interactivity, use knockout or something similar.

~~~
ulisesrmzroche
I think the exact opposite actually. JS Web Apps are great. What problems did
you run into that made you think otherwise?

~~~
steveklabnik
I personally run into a host of issues, mostly relating to browser behavior
that no longer works.

For example, 'text areas' that no longer trigger the browser's built-in spell
checking. Or scrolling that works differently. Or keyboard shortcuts that are
overridden. Or, a simple 'submit' button that no longer works because of a
browser JS bug, whereas if it were just HTML it'd work.

I do like a lot of browser based apps too, but many of them have tons of
annoying issues.

(Note: I mean JS SPAs in general, not Ember ones. Most Ember apps I know are
pretty well behaved.)

------
noelwelsh
So, isn't it time we had another Angular vs Ember discussion?

I tried Ember some time ago and it just didn't click for me. It's hard to
explain exactly why, but I found myself switching between too many files to
get simple things done. I've done some simple Angular work recently, and found
it a relatively simple system.

In defence of Ember everything about the project -- docs, community -- seems
to be better organised than Angular. The Angular docs are hilariously bad.

~~~
erikpukinskis
I've been working in Ember full time now for a few months, and I really
advocate using just two files, at least to start: one for Javascript and one
for HTML.

I know, it's a terrible, horrible practice, but hear me out.

Learning Ember, especially at the beginning, required me to sort of rewire my
brain about what goes where. It's "MVC", but the M, V, and C mean _totally_
different things than they mean in Rails. Really it's more like MVCRT (model
view controller route template).

I found all the different files extremely confusing at first, especially since
each tutorial told you to lay things out slightly differently.

If you put it all in one file though, you can _really_ easily move stuff
around. You'll find yourself frequently pulling stuff out of a controller and
sticking it in a view, or a route. Having to constantly switch files, remember
where things are, create new files, and remove stuff from version control
really puts a damper on things.

My advice to anyone starting with Ember: download the starter kit from
emberjs.com and try to stick inside that as long as you can. You can just drop
it into your Rails /public folder and get up and running.

Once you have a solid understanding of the architecture, and your app is
getting bigger, it's literally an hour's work to pull everything out into
separate files and drop it into something like the Rails asset system.

~~~
iamstef
Although lots of work still needs to be done.

[http://github.com/stefanpenner/ember-app-
kit](http://github.com/stefanpenner/ember-app-kit) aims to prevent and
mitigate the tooling pain, by having the community bear the burden.

------
eknkc
I've been developing on AngularJS for a while now, and have been constantly
checking Ember's development. I happen to like a lot of stuff in Ember and
meant to use it in production. I mean, I really want to use it!

However, it took forever to reach this state. It was always beta, rc or some
other non-production version, in rapid development with API changes and stuff.
While this is great news that it's finally a stable release, It seems that
Ember Data is in a new round of development with alpha status. It feels like
some of it will never be production ready.

Angular is far from perfect, I hate it's guts most of the time, but it has
been stable enough to build stuff on top of. That's the number 1 advantage of
Angular over Ember.

~~~
gavinjoyce
> It seems that Ember Data is in a new round of development with alpha status

Ember Data isn't a requirement of Ember by any means. You can happily use
these instead:

* jQuery.ajax

* [https://github.com/ebryn/ember-model](https://github.com/ebryn/ember-model)

* [http://epf.io/](http://epf.io/)

* [https://github.com/zendesk/ember-resource](https://github.com/zendesk/ember-resource)

~~~
shawndumas
and RESTLess

[https://github.com/endlessinc/ember-
restless](https://github.com/endlessinc/ember-restless)

------
johncagula
For the uninitiated, could someone please explain what we use Ember (and
related frameworks like Angular.js) for?

For example, I build a Rails app to handle models, views, and controllers on
the backend. Then I can use HTML/CSS/JS to write a frontend to interface with
the Rails app. Why do we need another MVC framework on top of Rails?

~~~
ricardobeat
When writing a single-page app you only need a RESTful API on the backend,
much like developing for mobile, to sync your models from the client.

Ideally, the models would be shared between client and server without the need
for duplicating code. There has been a few steps in that direction in node.js,
but it's an ongoing problem that hopefully we'll figure out in the next couple
years.

~~~
johncagula
Thanks for your response.

To clarify, when you say RESTful API, do you mean the client-side MVC
framework issues API calls to a server which then updates the backend
(database?).

I guess this model is client-centric while the typical Rails app is server-
centric (MVC logic executes on the server and then serves the relevant
HTML/CSS to the client).

Any particular advantages to the client-side framework over the server-side
framework?

~~~
ricardobeat
The main advantage would be performance, plus maintainability for complex UIs.
Navigation can be nearly instant, since you're only making specific requests
for data from the server, instead of shuffling html and reloading dozens of
assets all the time.

There are trade-offs, of course: it is a tad more complex than the old way,
but that is offset by simpler implementation in the server. Network round-
trips are minimized, but you use a lot more memory and CPU on the client, and
need more extensive testing. It's a great fit for webapps, not so much for
more content-oriented websites.

------
impressive
At work we have been using Angular for about a year and we had evaluated Ember
and decided not to use it because it wasn't really as good at the time. It may
be better now, but I'm not as excited. Here's why:

1\. For most applications, the JS MVC framework needs server-side backing, so
don't fool yourself: You are no longer using MVC- you are using MVC X 2. There
is no magic server-side out there that runs on self-generated jellybeans and
weed that will power these frameworks. They are beautiful but unnecessary
cruft in such pretty packaging that you think they are doing you a favor and
washing your clothes for you. But they are only washing part of your clothes.
The rest are still dirty and on the floor.

2\. Despite the old saying, "Everything at some point will be written in
JavaScript," it is not JavaScript, but rather mobile application development
that is leading the charge in the development world currently. It is the
platform and the accessibility (intuitive, easily held and portable), and not
the "how" (whether it is webkit running Ember or Angular).

So, even though it is awesome that Ember and Angular are great, and I'm happy
for you Yahuda, just like I'm happy for Misko/Igor/Vojta, I think this is a
lot about only part of a solution, and it might not even be the right one. The
whole package and the platform must be considered, not just the web client UI.

So, I ask, now that v1.0 is out, what is being done about considering the ease
of developing the entire shebang?

~~~
jonnytran
Ember Data and server-side components like active_model_serializers for Rails
_are_ working towards the entire shebang.

I agree that mobile development is driving a lot of this. If you've built
mobile-first, then you already have an API that services multiple clients. And
the web app is just another client, no?

So it makes me wonder, maybe what we need is the equivalent of Ember Data that
runs on iOS and Android to bridge the gap between the API and the native
framework.

~~~
steveklabnik
This is the whole reason for formalizing the media type that ember-data
expects into JSON API. That way, you can implement whichever side in whichever
language and know it all works well together.

------
matthewlehner
Congratulations - This is really a huge step forward for both Ember, and front
end development. I know that it has been possible to build rich front-end
applications using JavaScript before now, but the API and tools around Ember
are excellent and really make for a productive, convention over configuration
development environment.

------
Cieplak
If you want to see ember in action, you can see how we use it in production:
[https://github.com/balanced/balanced-
dashboard](https://github.com/balanced/balanced-dashboard)

It has been a great tool in our toolbox, and we really feel the benefits of
all the hard work and brilliance driving ember.

~~~
Kudos
How come you guys aren't using push state? Does Ember not provide it in its
routing?

~~~
mjallday
We have an open issue, [https://github.com/balanced/balanced-
dashboard/issues/370](https://github.com/balanced/balanced-
dashboard/issues/370) , that documents what's blocking. We were using iframes
for backwards compatibility while we migrated from a regular HTML dashboard to
our new Ember.js one.

We just removed the last iframe page (yay!) last week so I think we can
finally get around to doing this!

------
leokun
Awesome, have been meaning to try ember. Just finished with a 6 month
meteor.js binge. Which leads me to the question: what is a good real time push
solution for ember? Does it have anything for that, or is that something I'd
have to build in separately with socket.io or sock.js or something?

~~~
gavinjoyce
There is nothing built-in but it would be straightforward to update your model
data over web sockets. The magic of Ember bindings and observers will take
care of the rest.

~~~
sambeau
Saying it would be straight-forward is a little bit of an exaggeration.

While, true, Ember will happily update any model pushed to it the difficult
bit i.e. pushing the right data to the right model (on the right client) and
_only_ the right model to _only_ the right client is an exercise left to the
reader.

The cleverness of Meteor is not in the push, it's in the logic just before the
push.

~~~
gavinjoyce
That's true, Ember doesn't have any data synchronisation mechanism over
websockets like Meteor does. It is easy to update your data model from
incoming messages but, as sambeau points out, pushing these data updates may
not be a trivial matter.

------
pearjuice
Disclaimer: I am a backend developer sporadically doing front end to speed
things up (as in: back end is done, time to help the other guys with the front
end).

Why is this better than jQuery? I haven't looked at the full code base and
documentation but did watch the 25 min demo video posted in this thread and
thought: "Well, I can do all of this with jQuery too probably just-as fast.".
What makes this different? Am I missing something?

~~~
graue
It depends on the scale of the project. If what you want to do can be done
with 200 or 300 lines of JavaScript using jQuery, then fine. Go for it!

But I've seen codebases with over 10,000 lines of JavaScript, using only
jQuery, and it isn't a pleasant sight. You either end up writing your own ad-
hoc framework to add structure, or, more likely, you end up with a bug-ridden,
unmaintainable mess where you're writing basically the same code over and
over. A framework like Ember or Angular provides structure and takes out a lot
of the grunt work of making a large, single-page app.

------
digitalzombie
I sorta learn Angularjs, well went through a few tutorials on Angular for a
company. Turned out that company is now doing emberjs and I have to learn
emberjs.

I have to say EmberData is not production ready. It's modularity is more
monolithic compare to Angularjs. There's a lot of moving parts that can break
(in term of using emblem, brunch, handlebar, etc...). And the community is
much smaller, less books, less people that talks about ember/tutorial etc...

Angularjs, it seems much better but the scoping can be a hassle.

I feel like angularjs is winning right now in term of hype, community,
resources (books, blogs, etc..), and overall I feel like angular got it right
and more ready (cause emberdata ain't ready).

On the plus side, ember got a cute mascot and angular got nothing...

Although this is just my initial reaction and it can change over time.
Hopefully Ember will get better but if I have a side project I would chose
angularjs over emberjs right now. Unless ember changed for the better.

edit: direct injection is pretty awesome in angular btw.

~~~
iamstef
comparing angular to ember-data seems strange, no?

~~~
digitalzombie
Well my reasoning is because angular have a so called model. It's scope.

Angular doesn't need a model, it's a MV whatever. Where as ember is MVC. The
framework is MVC and it's M is not complete at all. So judging from an overall
framework ember is not complete in that respect where as Angular is.

Like come on, 1.0 and hey our M in our MVC framework is incomplete. Um...
that's shouldn't even be 1.0. 1.0 to them is the api is going to be stable but
not the emberdata, the model. Really?

~~~
Kerrick
Ember.Object is the M in the Ember.js MVC framework. Ember Data is a library
to synchronize a RESTful API with your models, without ever writing a line of
networking or AJAX code.

------
zbush
Congratulations! I remember looking at Ember way back and bring really unsure
since it was all over the place. You all have done incredible work; I'm
looking forward to building with it!

Regarding hosting an Ember app, can you use something like s3 with cloudfront
or will it not refresh fast enough to be usable?

~~~
bwship
What I do for my production apps is. For dev, i simply use all the individual
files. For staging, I minify and concatenate and push it to an S3 bucket, and
read it directly from there. For production, on CDN, because of caching, I add
a version number to my js and css file name. This way I alway s guarantee that
the user is using the correct version of my client code. I have grunt tasks to
do all of these automatically, and it has worked really well for me.

------
mehulkar
I haven't contributed much to the community or the code, but I've been around
the chatrooms and keeping up with the story for around a year now. (also been
actively using ember on personal and work projects). The community around
Ember is amazing and it blows my mind how so many people have been working so
passionately on this project. Congratulations to the team. Really well done.

------
makepanic
They also have a new builds page:
[http://emberjs.com/builds/](http://emberjs.com/builds/)

------
sintaxi
Congrats on the significant milestone. All the best moving forward.

------
forlorn
I wish there were more docs/tutorials/examples in the wild.

I truly love this outstanding project and I'd like more people to join the
ember.js community.

~~~
raphaelsaunier
I don't know if you have already come across it, but
[http://emberwatch.com](http://emberwatch.com) is a great aggregator of all
the resources on Ember in the wild.

------
ppong87
just wondering what's the difference between the different builds
[http://emberjs.com/builds/#/release](http://emberjs.com/builds/#/release). In
particular what's the difference between stable/ember-runtime.js and just
stable/ember.js

~~~
iamstef
ya, we should add descriptions.

Mind opening an issue?
[https://github.com/emberjs/website/issues/new](https://github.com/emberjs/website/issues/new)

As for the question:

Ember is actually built from many smaller pieces, such as:

    
    
      - container 
      - ember-metal
      - ember-runtime
      - ember-views
      - ember-handlebars
      - ember-routing
      - ember-application
      - ember
      - ember-extension-support
      - ember-testing
      - rsvp
    

As it turns out, you do not always need everything, so building the subset
that you need totally works.

ember-runtime is made of up: ember-metal and ember-runtime
[https://github.com/emberjs/ember.js/blob/master/ember-
dev.ym...](https://github.com/emberjs/ember.js/blob/master/ember-dev.yml#L7)

It provides underlying foundation, including the object model and the KVO
system to the rest of ember. Leaving out views, application, routing, and many
more high level ideas.

------
msoad
I'm not very familiar with software licensing. What Ember.js licence means for
production use?

~~~
tomdale
Ember.js is released under an MIT license:
[https://github.com/emberjs/ember.js/blob/master/LICENSE](https://github.com/emberjs/ember.js/blob/master/LICENSE)

Use it however you'd like; contribute back if you want to.

------
level09
it would be really nice to build a migration/mapping sheet for people already
using other front-end frameworks (Backbone/Angular/Knockout etc ..)

Variety is always good, but with all JS frameworks I'm really getting confused
about which framework to choose.

------
ulisesrmzroche
Web Components. Yes! They even knocked off views off the guides.

------
sadadar
congrats tom, yehuda, and the team at ember, even if we aren't using it always
happy to have technology making great strides.

