I’ve had a growing interest in Ember recently and am considering rewriting a recently started application in it. I’ve heard in passing that it was announced at a recent Ember conference that the future of Ember might be in modular components, instead of a simple drop all in one in solution.
My interest in Ember stems from the fact that it is an all in one drop in solution, and that I won’t have to add 10 different npm modules to get it working, a la React.
Breaking up Ember into separate components seems to me to be an anti-pattern to the whole philosophy of Ember. Can someone more experienced with the framework explain these recent announcements, and what they might mean for newcomers to Ember?
@Orbyt this is just my impression, and by no means a comprehensive reflection on the core team’s intent, but I think the idea is to make it more modular (so you can only use the pieces that you need) specifically without making it more difficult to use. While it’s possible that you may end up with a couple more npm packages I don’t think that’s going to be a huge deal in terms of developer ergonomics. We’ve upgraded our app from 1.10 to 2.13 and upgrading/package management has never really been that bad. One of the biggest criticism of Ember is that you have to import this entire large and powerful framework even for apps which are just a few components or which don’t need the router or don’t need Ember Data. By destructuring the library it could make it more friendly to a broader user base.
I’m sure that the idea is still that Ember-CLI will generate a default project, maybe stripped down, but maybe you’ll have options to add router/data/etc. at project gen time. Even if you did have to add a couple packages manually they should be drop-in and work like any Ember app today. Again I don’t really know what they intend and how things will all shake out, but I think the basic idea is that it will be just as dev friendly as before. One of the things I love most about Ember is that the core team is very concerned with developer experience and making intelligent design decisions, easy upgrade paths, and generally making things much easier for developers. I am pretty confident that this will continue in the future and that destructuring the framework will be a good move and will not significantly affect developer ergonomics.
Again, that’s just my opinion, but I wouldn’t worry that the framework will suffer as a result of this. If anything I think it’s a great move and could give it a lot of longevity.
Thanks for the great response. I hope the “it just works” part of Ember continues to be a major feature of the framework. I’m a big fan of Meteor which has (or had) a similar philosophy. My complaint with React is that it simply requires to much time configuring things that add nothing to the value of your business. Eg, a brand new React project’s package.json might look like this:
not to mention the .babelrc, webpack configs, and the fact that this doesn’t even include Redux. My hope is that Ember does not go down a similar path.
This is an absolute requirement for myself and most of the rest of the core team. While we may provide additional ways to use individual pieces, the overall focus will continue to be on the cohesive “pick up and build something” experience.