When you should not pick EmberJS as your next front-end tool
Disclaimer: In this article, the point is not to deprecate other front-end solutions. The main goal is to point out that there is no one single technology that fits every context, i.e. every use case, every project or every development team.
Following every single rule is not an option. EmberJS is not the best place for being a rebel. Of course, even if you use EmberJS you can mess things up inside your application, but because it has plenty of conventions, it is much more difficult to spoil things than with other solutions. Do you like to do whatever you want? In EmberJS you can’t. With EmberJS you have some rules that you will just need to follow.
It may sound strange but thanks to EmberJS your coding is limited to the minimum. As I mentioned before, EmberJS is like a Swiss Knife. It has tonnes of built-in solutions and thanks to that, in many cases, you do not have to code too much to achieve your goals. For instance, if you want to start using JSON API, GraphQL or FireBase, all you have to do is to replace the adapter of the application. The adapter connects your data source (API) to the local data storage. When you follow the conventions, all of this happens auto-magically — just like that. If you like to write a lot of code, reinvent the wheel, EmberJS is not the best choice for you.
To conclude, we should always look for a right tool to do the job at hand. From my experience, EmberJS is one of the best choices for building a SPA at the moment. But before you pick the tool, ask yourself the key question: Am I really building a SPA right now?