Scheduled maintenance shouldn't have to mean that _everything_ goes down at once.
78 karma · joined September 25, 2010
It's reasonably quick on an iPhone 6 (though obviously slower than on a desktop). In actual use you'd obviously design things a bit differently. Again, this is a performance test, not a real application.
In the second case, he used HTML comments to comment out Handlebars code, not realizing that he should have used Handlebars comments.
1) Layouts vs. Views vs. Components
A good place to start on this is the guides: http://emberjs.com/guides/views/adding-layouts-to-views/ http://emberjs.com/guides/views/ http://emberjs.com/guides/components/
From reading those, it should be pretty clear how layouts differ. I admit that it may be a bit less clear how views and components differ. Components are actually a more isolated type of view. Views have been around for longer, but in the future, we're going to discourage people creating custom view classes in favor of using components primarily. If you're not sure whether to use a view or a component, go with a component first.
2) Ember Data
Ember Data isn't a part of Ember Core, and for a good reason. While Ember Data is certainly a useable product (myself and many other do use it in production), it's not yet as mature as Ember Core (hence still being in beta). If Ember Data isn't good for you yet, you don't need to use it. Discourse is an example of a large Ember app that completely forgoes Ember Data.
3) Templates and Views
The template is rendered inside of the view's element which explains this. Alternatively, specify `tagName` as a property when using `{{view}}` or a component helper.
4) Documentation
The guides have a ton of information so you should definitely look there first. Also, if your company is really investing in Ember there are some good paid trainings available, including online courses. Tilde, my employer, has an online training (http://www.tilde.io/events/introduction-to-ember-online/) as does CodeSchool (who I do not work for) (https://www.codeschool.com/courses/warming-up-with-emberjs), among others. Since Ember has reached 1.0 a number of months ago, the API has stabilized and documentation will be valid for much longer.
As far as Ember Data goes, this is something that it's clear that a lot of people do indeed want. That said, you can use Ember perfectly well without Ember Data (see Discourse for example).
It's funny that you point to Rails as an example of consensus, because when you look at the server-side development community as a whole, there is certainly not consensus that the Rails way is correct. I wouldn't expect complete consensus on the client side any more than I would expect complete consensus on the server side. Rails (and others) have shown that you can have multiple healthy ecosystems each with their own points of consensus.
Unfortunately, both cost money at the moment but I've heard they're worth it.
To have more people point out your shortcomings when you're already well aware of them is very frustrating. I think this is what we're seeing in Trek's response. Now that doesn't mean that I think his response is helpful - it's not. But I do want it to be clear that we do care about these issues and sometimes maybe too much.
When our new Getting Started Guide is finally released, I promise that we will do our best to address all of the different comments and complaints we receive from our users.
-Peter Wagenet, Ember Core Team Member