Ember currently ships with ember data, and it is assumed that you will be using ember data within your application. The getting started guides also make the same assumption, and introduce ember data, before even mentioning that one can return a POJO or a promise that returns a POJO, for example an ajax request.
This contributes to the cognitive load of "learning ember" and I believe contributes substantially to the "steep learning curve" associated with learning ember. Ember data is indeed, a relatively complex product, with at least 4 core concepts to learn (models, store, adapters, serializers). To make matters worse, if your API isn't a nicely structure JSON-API, you're in for a hard time whilst you naviagte the ember data documentation to work out what to do. All of this is unnecessary to a new adopter to ember, and is likely to scare them off the framework entirely.
Whilst some colleagues of mine worked with getting started with ember, they quickly came across stumbling blocks, not with ember itself, but with ember data, due to the fact that our API is not a JSON-API, and understand how to get it to work with ember data is no small task. There are a bunch of concepts to learn before you can get the data down to your components. The fact that the guides don’t explain up front that you can just return a POJO highlights this very problem.
Ember data certainly provides a great standardisation of your data layer, it also provides out of the box functionality for things like fastboot and other adding like ember mirage that “just work”. However not everyones data layer is going to be resource based, some apps don’t need it, some are more transactional rather than “resource” orientated, and forcing people to “opt out” rather than “opt in” feels like the framework is making too many assumptions about how people will build their apps. Those assumptions are great from a UI and convention basis, but I’m not sure the same can be said for the data layer.
- Remove ember data from ember's package.json
- Remove almost all reference to ember data from the getting started guides, perhaps linking at the bottom of the relevant sections
- Create a separate "How does ember deal with data" section in the guides, and introduce ember data, along with other options like straight up ajax, ember redux, etc.
- I think ember is great.
- I think ember data is great.
- Forcing new ember users to use ember data makes assumptions that I don’t think the framework should make.
- Introducing ember data when users start to need data persistence feels like the right time, rather than in the getting started guides.
Also, if a store were separated out of ember data so that one could get request caching benefits while still using traditional ajax requests that might be nice.