2 ms·
Interesting. Thanks for the list. My biggest issue with Ember, other than the management of release schedule and API early on, is the concept of tying routes to
by mrcwinn 12y ago
Interesting. Thanks for the list. My biggest issue with Ember, other than the management of release schedule and API early on, is the concept of tying routes to models explicitly. It seems to assume that given a route context, you'll be dealing with a particular model - and only one particular model. If you want to have an additional data context, you need to establish route and then tie the routes together within one template.
This seems to confuse the relationship between a URL and the data displayed on the page.
I've really enjoyed React+Backbone, on the other hand. Very small footprint and gives me flexibility to design and build an application. After spending years with Rails, I've come around to "convention over configuration" is a nice thought, but breaks down at certain sizes. And it seems to break down much more quickly on the client side.
To me, personally, well-written Backbone+Underscore+React runs circles around the newer JavaScript frameworks. It's not to say the debate is over and settled - I just haven't found the complexity and size of frameworks like Ember to pay back more than they cost.
- deleted 12y ago[deleted]
- Retozi 12y agoI feel like these somewhat restricting patterns can increase your productivity massively. If your app fits the restriction. If not, it will slow you down. There is usually not enough emphasis on the nature of the app in these X vs Y framework discussions. I can really see why you would choose Ember say for Discourse and why (once you got it) it is very productive. But for other apps you might constantly fight the Framework. Optimal patterns really depend on what you want/need to do. (Thats why TodoMVC doesn't help much).
- tomdale 12y agoEmber has now got one of the best (IMO) release cycles in the business. We borrow heavily from Chrome, and have a very polished release infrastructure, with release, beta and canary channels you can subscribe to. Additionally, we have a strict commitment to SemVer and most Ember apps are on the latest release. As for the complaint about tying models to routes: Ember does want you to have a model per route, but the model can be any data structure you want: an array, a hash with multiple models, or a single model. I'm not sure exactly what issue you hit, but most apps of any complexity have multiple models on the page, and of course that's something we support out of the box. (You can see this if you open any production Ember app in the Ember Inspector browser extension, such as http://vine.co http://vine.co or http://twitch.tv. http://twitch.tv.)
- iamstef 12y agothese are happy-path guidelines and as such, quite easy to diverge from when needed.