I keep wanting to try Ember, but honestly, it drives me crazy every time. Why is there not a simple "quick start" that shows how to get it up and running. You have lots of good documentation but you skip over the most important part!
Amen. I know zilch about ember specifically. But this kind of thing is endemic in the tech world (even more so on the business side of things where people allocate budgets to line items like "docs").
Seriously, if your product is a new API, don't even think about writing reference documentation until you have a 2-page "birds eye view" document that explains your jargon and metaphors to a new user. Without that any reference documentation is going to be useless.
ember-data is a completely separate project that is still under heavy development. You can use ember without touching ember-data, and unless you are on the happy path of Rails with the active_model_serializers[0] gem, I would recommend not using ember-data.
You can roll your own light-weight layer, and Ember's object system will give you lots of rich functionality. There is also ember-resource[1] and ember-rest[2] if you want something a little less hand-crafted.
> Why is there not a simple "quick start" that shows how to get it up and running
This is what I love about Angular: just go to angularjs.org and right on the landing page you find excellent live code samples and videos guiding you gradually into Angular. Besides, Angular just feels much more intuitive.
Yeah, I've tried to get into Ember a couple times now, and each time I end up ditching because of the documentation. It seemed sparse, and what document is up there seems like it's often out of date.
Does anyone know if they've gotten the documentation (including the guides) synced with the API yet?
The guides are synced with the API now. But I feel like you essentially need to read every section before you can get a feel for how to put together an application.
There was a quick start project I found at one point which looked like what I wanted, but it was not in sync with the latest guides / api so I couldn't use it. Not sure if that has been updated now, but there is no obvious link that I know of and I don't remember where I found it.
A quick start guide definitely does not "go against" what we believe in. At EmberCamp, we had a slide dedicated to improvements we would like to make to the documentation. The first bullet was "Getting Started".
Why not YUI? I'm so confused at the proliferation of these JS frameworks where everyone literally keeps reinventing the wheel.
Excellent as a learning exercise but other than that, what's the point? YUI has been around for so long compared to these. It's mature, it's under active development, very well documented, it has the option of including so many more things if you want, it's modularized,has a devcon every year, releases architectural videos every so often, has a dedicated CDN.
Looking at todoMVC, YUI takes ~400 lines of code to do what Angular does in 135, ember does in ~160, jQuery does in ~160, and even Backbone does in ~350 (and is anyone starting a project with backbone today?). Backbone unpacked, however, is only about 900 lines without spaces and comments. How big is YUI?
To be fair, the YUI version has more comments, but it's fundamentally harder to follow too, IMHO.
Further, YUI did a poor job of getting tutorials out at the quality of those available today for backbone, ember, and angular. As such, I at least found no approachable way to really get a mental model without working on an existing YUI project with a mentor or reading through a lot of documentation.
I had done a simple YUI proof of concept with YUI 2, and went, "this is more work than jQuery" and never went back.
So people reinvented the wheel, but they made it better. I'm glad that Yahoo blazed the path, but I'm not convinced it's the better option today.
It's not true. A lot of people are perfectly happy with Backbone.
This "X is old hat, use Y" phenomenon of "hype recycling" is part of a cultural problem that seems particularly endemic to the startup world. There is a lifecycle of "bleeding edge" to "mature" to "abandoned" that never lets up. There is always a newly-hyped library or framework or methodology that's trying to shift people's attention; and rather than refining and evolving the existing stuff into stability and maturity, many devs start new, wobbly, immature projects. But the bleeding edge is fickle, and when the dust settles there are some remaining competitors, but then suddenly the dust rises again and you're urged to abandon everything because the new stuff is in a separate programming language, so everything else is now incompatible; so the cycle goes. It results in a lot of work, and I like the competition and sheer energy of a developer community fired up about something, but I believe there is also a lot of work wasted.
Sometimes I wish software developers were more like engineers, and that people slowed down a bit. As one gets older, one gets to value maturity over novelty, and to see the importance of backwards compatibility, transition paths and careful releasing.
It all depends on what kind of app you're writing. If you're happy with whatever solution you're using then it's foolish to change just for the sake of change. However, I've known multiple developers who started with Backbone and then found that it wasn't able to meet their needs and then switched to Ember. Zendesk is one such example. The goals of Ember are actually very different from Backbone. Furthermore, living on the bleeding edge with others is better than living on your own bleeding edge by yourself with a ton of code that you rolled on your own.
Oh, sure. Changing libraries/frameworks in order to satisfy one's requirements -- or for quality reasons, or for any other good reasn -- is completely justified. It's the habit of chasing whatever is today's new hot thing that I dislike, and similarly, the habit of dismissing yesterday's favourite as being old hat.
As for Ember, I'm sure Ember is wonderful. I still haven't figured out what design decisions in Backbone drove develpers to create Ember, but I'm not qualified to question it. Either way, Ember and Backbone are both trying to solve the same basic thing: Providing an MVC framework for JavaScript, mostly focused on the browser. As I understand it, Ember wants to be a more complete toolkit than Backbone, which is very simple and minimalistic and leaves things like templating to other libs.
What is interesting is that Yehuda Katz was also behind Merb, which in my mind is a good example of a gratuitous project; Merb was someone reinventing Rails with the goal of being perhaps 10% better than Rails in the areas of performance and modalarity, while at the same time completely incompatible, and a lot of people jumped on the bandwagon. As it turned out, the developers decided to reimplement Merb's conceptual improvements back into Rails and shut the project down.
Again, I'm not qualified to critique Ember, but the Ember/Backbone competition certainly looks, on the surface, a lot like the Merb/Rails situation back in the day. I would love to hear more about why the devs decided to create Ember and not evolve Backbone. If the Backbone devs did not want to go in Ember's direction, that is of course a perfectly acceptable (if unfortunate) reason to start over.
Thanks. I don't have time to watch the talk right now, but skimming through it, it sounds like a view layer like you describe could perceivably be bolted on top of Backbone, at least if one added support for attribute-level bindings?
I should restate: if someone started with backbone on a project, there's no reason to pull it out and restart with ember. It has its advantages for a certain type of project and a certain type of developer today.
If you like minimal frameworks, like to make your own design decisions and want to build your own framework on top of a library, backbone is great.
If you are just looking for a minimal subset of MVC because you're doing some high-concept app that doesn't fit into the standard web application paradigm, it's worth looking at backbone.
Most importantly, if you're retrofitting an existing application, backbone will be invaluable for years.
The ideas behind it are solid and relevant today and it's not a bad idea to use it. I just believe that if you are starting a web application today, for 95% of the use cases, you are better off sticking with jQuery or moving to Ember, Knockout or Angular.
That isn't to disparage any of the other libraries and frameworks, though.
> for 95% of the use cases, you are better off sticking with jQuery or ...
This is terrible advice. If you can't tell the difference between a procedural app full of jQuery callbacks and a an app modularized with Backbone objects, then I don't think you have had real experience writing apps with either of these libraries.
It depends. Are you doing single page apps? jQuery is awful advice. Are you doing internal 2007-style internal apps with only a small amount of interaction? I'd argue jQuery is a cost-effective way to get a project out.
I haven't figured out how to get a team who is "barely" conversant in javascript productive in an MVC framework just yet, myself.
LOCs aren't a great metric. I'm far more productive with Backbone than with JQuery alone and Angular offers a fundamentally different approach (stuff auto-magically just works) which is brilliant but isn't always easy to customize.
I get your point about angular -- I tend to think it has a particular use case in mind and does really well for that one. However, my point was that backbone doesn't give you much more than plain javascript itself -- let's not expect to abstract everything away compared to one of the full service frameworks. YUI, however, is aiming to be a full service framework. What is the additional benefit?
Now, it's possible that YUI would show itself closer in terms of LOC/complexity to the other frameworks in a larger application. But looking piece by piece, ember and angular just seem to do things more efficiently, more clearly than YUI. And that was my point when discussing LOC.
If you write single-page web apps, you owe it to yourself to check out Ember.js. The learning curve is a little steep, but once you get up and running you can't beat it for a client side MVC.
I think if we're going to start this debate that we need to substantiate the claims on both sides. This is probably not the ideal place for that debate, however.
they are very differnt , DI is great but all the directive lifecycle pisses me off sometimes. and dirtychecking on huge collections? without a native Object.observe it is slow.
For what it's worth, it's not clear how Object.observe will substantially improve the performance of large collections.
For example, if you insert an item at position 0 of a 10,000 item array, Object.observe will publish a change for every item (since they are all moved one item down). It is then up to the receiver of those changes to reverse engineer what exactly happened (which is slow).
What is needed is Array observers, which would notify the index of the change, number of items removed, and any items added (the `splice` signature). Ember emulates this, but by using a different API than the normal Array API. I hope that future extensions to Object.observe will support Array observation.
As a member of TC39, I worked closely with several members of the Chrome team on Object.observe and hope to work with them again on an Array extension to the spec to make Array observation faster. I yearn for a future where Ember can get good performance without having to ask our users to use an alternative API.
There seem to be a few general themes going around on this thread and I'd like to address them all:
1. Ember docs aren't up to date
As this thread notes yesterday Ember.js Version: v1.0.0-rc.1 was released. This is the first release candidate of Ember.js 1.0. As with any project (and as was noted by Jeff Atwood in the Ember Camp keynote) you can expect the APIs to be fluid until version 1.0 at which point they become quite stable. From what I understand any further release candidates are going to be about bug fixes and not API changes so at this point you can basically consider the APIs locked in for version 1.0.0.
Along those lines the Ember Core team has announced that Ember.js is going to follow semantic versioning[1] which means that there won't be any major API changes in minor releases.
During the 'Ember State of the Union' session yesterday there was an acknowledgment of the quick start and docs stuff. They announced that yes there will be an effort to create 'The Best Quickstart EVAR™'
They also announced that the Ember Core Team will keep an eye out for docs that are out of date and will ask the authors to put a little disclaimer at the top of the post which says that the code isn't the 1.0.0 API.
Finally in the context of talking about bringing more people onto the Ember Core team they mentioned that seeing someone passionate about the community and documentation could be a reason to be considered.
All these things left me with the impression that documentation and quickly/easily onramping people to the framework is incredibly important to the Core Team and the community.
Also it really is worth mentioning that the API docs[2] and Guides[3] are just github repos. If you see something that is incorrect or there is something that just isn't there please clone the repo and add/fix it. That's a great way to become a contributor to the project and help other people not run into the same issue that you did.
2. Ember vs Angular vs Backbone vs Knockout vs jQuery (did I miss anybody)
First to be fair let me say that I don't really have experience with angular, backbone, or knockout. I've checked them out and read some docs but I haven't really dug in.
My thoughts are that it's still the early days of such rich client side applications. The teams behind all of these projects are incredibly smart and /me thinks that there is much to be learned from each one.
As with any toolset you pick what works best for the problem your trying to solve, what leverages your existing skills while pushing you to learn something new, what has the most thriving community, and yes what is easiest to onramp.
3. Why would you use Ember?
When it came time for me to wrap my head around an MVC (or MVC-like) client side framework I decided to check out Ember.js first because I like the work that Yehuda Katz and Tom Dale had done in earlier projects (jQuery, Rails, W3C TAG, SproutCore). I immediately found that I liked Ember.js for several reasons:
* Convention over configuration—-If you come from Rails this one is a no brainer. There are some things that are done pretty much always. Why bother setting that stuff up? It should just work and for the most part it does.
* Router--Ember's notion of mapping every potential state of your app to a url[4]. Actively acknowledging that URLs are a strength of the web platform which allows us to share deep state of our app.
* This video introduction by Tom[5]--I recently had the realization that frameworks such as Cocoa are amazing because of the building blocks that they provide. I also realized that the web platform has all these amazing primitives but there was just no framework that built on top of it. In that video Tom says that Ember.js is meant to be like Cocoa for web development and that immediately struck a chord with me.
* Client side MVC FTW!--Once upon a time I was a member of the W3C HTML5 Working Group and an acknowledged contributor to the HTML5 spec[6]. Early on I (like many others) saw the potential of HTML5 and it makes me happy to see a framework built which handles so much of the app on the client side with Javascript and HTML5.
There is one tool I'd like to mention--the Ember Inspector[7]. It is a really great Chrome extension which adds an `Ember` tab to your dev tools. This let you get Ember specific javascript output and visual feedback when hovering over controllers/templates.
It's still pre-release but I've played around with it and my impression is that as it matures it's going to become an indispensable tool for the Ember.js developer.
Our application is currently jQuery and vanilla JS managed with require.js. I recently led spikes investigating both Angular and Ember. I landed on Angular.
I found Ember to try too hard to be Rails when JavaScript is not Ruby. If you've got experience with Rails, Ember would probably be familiar enough that bending JavaScript into that model would be okay. But I think Angular is more geared toward the strengths of JavaScript (and away from its weaknesses).
It's also a different kind of framework. Rails is so popular that it's understandable for frameworks to want to follow along that model. But Angular takes a completely different approach, trying to extend HTML. Because of this, Angular apps are incredibly readable. Our UI guy who isn't an engineer was able to look at the HTML and understand exactly what the app was doing.
I also found Angular to be easier to piecewise convert an existing project, since any arbitrary element can be your entire Angular app. This might be possible with Ember, also, but I wasn't able to easily figure out how since the documentation is weaker than Angular's.
The biggest problem I had with Angular and our current infrastructure was using the patterns introduced by require.js since Angular has its own opinions about dependency management.
