I’m going to be very blunt and might make some people angry. For what its worth I’m only writing it in the hope that it will get enough attention in the Ember community and that this issues will be addressed properly.
I encourage you to read all my arguments but feel free to jump to the TL;DR; in the end
I started writing my first Ember app about two weeks ago as mockup for a new project I’m working on. I came to this mockup after having a lot of experience with Backbone and Angular. While backbone is really cool as a basic MVC for your app in the end it’s a very small library and even with Marionette it doesn’t give you almost anything else, not even a basic structure. Angular is much better at doing the heavy lifting for you. But for me something doesn’t feel quite right with Angular. It’s data binding with dirty checking feels like is going to be too heavy on a large app and managing my app logic from the HTML templates makes me feel a bit uncomfortable (this is just the felling I get from using Angular in reality its not as bad as it sounds).
Therefore after working with other frameworks I was excited to finally work with Ember. One common assumption is that Ember is very opinionated “Ember is Omakase” as Yehuda Katz likes to say in his presentations. Another assumption is that Ember has a steep learning curve. The learning curve is what seems to deter most of the new developers from starting to use Ember and being opinionated doesn’t help. As a heroic and experienced developer I attempted to tackle these issues head on. Who am I to be afraid of a little learning curve ? And opinions are good no ? Aren’t we all tired of reinventing the wheel and getting things wrong when there are highly talented people willing to make the hard decisions for us ?
Unfortunately I was wrong in my pompous attitude. Not only was I wrong, but after a week of fighting with Ember I came to disagree that it’s opinionated and I definitely don’t think it has much steeper learning curve than Angular or other framework out there. I actually think the main problem with Ember is that in some places it doesn’t have any learning curve but it has more of a learning gap.
What the difference from a learning curve to a learning gap ? well a learning curve is when you actually need to learn something you didn’t know before. At 1.6 MB of unminified code, Ember is probably the biggest JS framework out there. so of course you have a lot to learn, you need to learn how to use it’s routes, and understand how to do dependency injections to manage services. You might also need to change your way of thinking about controllers to understand their function in Ember. This are all classic learning issues which are not much different from other frameworks and the Ember team did great work to flatten the curve so you can get started with a basic app very quickly.
However the gap reveals when you want to use the framework in more advance ways, like splinting your code into separate files and adding some procedures to the build process. After hours of online searching I found no explanation on how to separate your files. This is not to say that this cannot be done. You can actually do the splinting part easily by simply using ember-cli ! But how does ember-cli do that ? It doesn’t seem like any one bothered to explain that.
A client tool that automatically do all the repetitive tasks like scaffolding, building, linting and testing your code is a double edge sword. Its great that complex tasks are now easy to run, but by having this tool our tasks can become too complex to handle and understand where a change in the framework/app design and structure might have made this tasks more simple and clear.
As a developer you shouldn’t use ember-cli unless you actually know how to run most of the build steps manually. When you build a web app you’ll need to rely on many tools libraries and technologies without knowing their inner workings but every now and then you’ll decide to go deeper down the rabbit hole. the more experience you’ll have the more you’ll want to understand how things works. The problem is that currently ember-cli is blocking the entrance and you can’t even take one step.
As example lets look at es6-module-transpiler which is used to take ECMAScript 6 code and interpret it to ES5 so it can run on web browsers today. The Ember way says you should use ES6 modules so this process is required for all Ember apps. the problem is that if you try to use es6-module-transpiler with your Ember app without ember-cli you’ll get some variable declaration and export errors form ember core, so it wont work. also if you look at Ember source code you’ll see that although Ember itself is written with ES6 import and export statements the actual source file names and directory structure is not compatible with ES6 modules. Ember-cli needs to do some magic to transform the source to be ES6 compatible only than actually compile it. What this Ember specific magic is ? let me know cause I couldn’t find any explanation for it (I’m guessing part of it is actually using an older and ES6 incompatible version of es6-module-transpiler).
As developers we shouldn’t wait to be spoon feed. Open source software like Ember and ember-cli gives us the opportunity to learn what it does from its code. but ember-cli loads about 100MB of resources so understanding what it does from code is going to be very hard. In the long run it would be better to learn ember-cli code but for one or two simple tasks its easier to write your own process. which is what I decided to do just to try and see if its even possible and you can find what I did on GitHub. using a newer ES6 compiler I actually found some linting and minor bugs in ember core #5586, #5585
Not knowing what ember-cli does might be more accepted if it actually did it in a good way. But lets look at some of the code ember-cli compiles from your app. This code is intended to be used in production –
;eval("define(... //# sourceURL=new-app/app.js");
;eval("define(... //# sourceURL=new-app/config/environment.js");
Lets ignore the extra semicolons which is surely an unintended bug. Why would a static compiled code should ever be running in an eval statement ? if any other tool would build your code like this you’ll throw it away immediately and never consider using it again, but since this is part of Ember core people seem to trust it blindly.
Ember-cli is a young project and its surely will go some major improvements, but the fact that we don’t have any clear explanation on how to do necessary tasks without it, means that many people are relaying on it when they shouldn’t. The current trend in Ember seems like relaying on ember-cli more and this issues will only going to get worse unless they’ll be addressed properly.
By automating complex tasks in Ember ember-cli is actually making the development process more complex and hard to understand, a lot of functionality that is being solved inherently in other frameworks is only solvable in Ember by using ember-cli.
Ember community should reverse this process and aspire running development code with almost no build process at all. If we require to build our code either for development or production ember-cli should make this tasks more transparent and clear, so app developers be able to check how they work and apply them manually.
Ember-cli still needs a lot of improvements so making it’s inner functionality clear will allow more people to actually improve and add functionality to it. if you are just starting with Ember try to understand how ember-cli works write blog posts about what you discover and ask on Ember forum when you find things that aren’t clear.