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.
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:
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.
I know it's a pain to have to evaluate all of these frikin' frameworks all the time just to get moving, but I'd really recommend building a non-trivial app in both ember and angular.
I've compiled a list of learning sources (tutorials, videos and Ember focused blogs) that I've found very helpful in my path to Ember: http://bit.ly/1aQXnrz
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!
Does Angular really qualify here? Technically it's documented, but they're terrible.
I said, "Let's not use this opportunity to start another Ember vs Angular argument."
So are you mentioning Angular.js then? If you are going to celebrate Angular 1.2 wait for the Angular 1.2 announcement and post there. Sounds like "I don't want to troll but I will anyway while telling everyone I don't want to".
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?
 https://vimeo.com/68215606 - Note it's a bit unfair with the project lead for Ember, tomdale, on one of the "cage match"
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.
We gradually moved our previous jQuery-implemented app onto Ember, so it's certainly possible to do it in stages (we still have a minor section which we haven't moved yet, because it's up for rewrite regardless).
There are still improvements to be made, but we're certainly happy to be using it live.
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).
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.
We've used Ember.js to build a reasonably complex app (github.com/balanced/balanced-dashboard) and while there have been some tricky bits it's generally been what we expected it to be.
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.)
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.
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.
http://github.com/stefanpenner/ember-app-kit aims to prevent and mitigate the tooling pain, by having the community bear the burden.
I don't get why people keep on saying AngularJS doc is bad.
Maybe I'm weird but I've found Ember JS to be horrible and AngularJS to be very good.
In the case at hand, spending half a day each (or even more) with angular and ember is not enough time to gain a truly informed opinion of either. These are big frameworks with many features, and each harbors both gotchas and benefits that won't emerge until you've worked with them over time in real projects.
For developers with limited time, asking advice from fellow trusted developers is not only acceptable, but also, in many cases, the clearly optimal strategy. Of course, the trick is to find experienced people to ask with tastes and values similar to your own.
I was more hoping those that have a strong opinion on one or the other would ensure that they try them both first.
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.
Ember Data isn't a requirement of Ember by any means. You can happily use these instead:
Ember Data, on the other hand, hasn't been ready. I also took the plunge with Ember Data with 0.12, and it turned out to be a mistake that's still looming over my head. (I think I would have been better off with Ember Model, or EPF which didn't exist at the time. Yes, I understand when you're new to the ecosystem, they all sound the same.) I think this has been a big part of where the confusion stems from. People who are new to Ember don't realize that Ember Data is a completely separate project with its own status.
Please correct me if I'm wrong, but as far as I understand, there's no equivalent of Ember Data in Angular. Am I right? If that's right, then of the little bit you've said, it seems like you've run out of excuses not to use Ember :)
This is why I'm saying I think a lot of people fall for the same trap/gotcha as you. Ember Data is totally not necessary to be productive with Ember.
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?
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.
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?
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.
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.
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?
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.
It has been a great tool in our toolbox, and we really feel the benefits of all the hard work and brilliance driving ember.
We just removed the last iframe page (yay!) last week so I think we can finally get around to doing this!
For more, see the documentation: http://emberjs.com/guides/routing/specifying-the-location-ap...
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.
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?
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.
direct injection is pretty awesome in angular btw.
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?
This is a very unfair comparison between a complete stable release of Angular and an alpha of Ember Data that even tells you it's extremely unstable and not production ready.
Regarding hosting an Ember app, can you use something like s3 with cloudfront or will it not refresh fast enough to be usable?
I truly love this outstanding project and I'd like more people to join the ember.js community.
Mind opening an issue?
As for the question:
Ember is actually built from many smaller pieces, such as:
ember-runtime is made of up: ember-metal and ember-runtime https://github.com/emberjs/ember.js/blob/master/ember-dev.ym...
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.
Use it however you'd like; contribute back if you want to.
Variety is always good, but with all JS frameworks I'm really getting confused about which framework to choose.