Should you use Ember Cli ?

If you are considering using Ember and still comparing it to other frameworks this is not the article for you. Ember has some really strong and positive sides, overall I think Ember is one of the best JavaScript frameworks available today. The way it handles some of the common needs in modern web apps like routing, data binding is purely amazing. After considering many other options I’m going to use Ember for a big project I’m working on. This article series is only going to talk about Ember issues.
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 –

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.

11 thoughts on “Should you use Ember Cli ?

  1. I threw together a dead simple ES6 (multi file) ember project to show a non magic ember build setup using gulp. I’m working on a course to fill in the gap you mentioned. Really enjoyed the post!

  2. You are 100% correct. I am Rails developer. I know basically how Ruby works. So I can do almost anything in Rails. But Ember-CLI looks like some magic. The JS code generated out of the it is almost unreadable. When something goes wrong I am gone 🙁

  3. n0 says:

    I think the worst thing about ember cli. is the build process.
    Everything else is really useful, and although the build itself is also very important not understanding
    How your app is being built can be prone to errors.
    I hope I’ll have the time to explain how ember cli builds your app and how you can do it without it.
    I managed to understand enough from the mess in ember cli code to make my own build process but its not mature enough to be published yet.
    If you have no other choice I would keep using ember cli cause it’s benefit outweigh its disadvantages.

  4. Adrian says:

    perhaps ember-cli makes you dupable, green, unsuspecting or reliant.

    if you want to splinter your ember code (without using ember-cli) then simply split that one file up and then reference them in the usual fashion,

  5. n0 says:

    If this is your only option you might as well just use ember-cli.

    Ember-cli hides all the technicality of the build information from you.
    It shouldn’t be hard to make your own build process, but if it does its better to use ember-cli
    than not having it at all ( I guess thats why so many people are using ember-cli )

  6. Matias says:

    Where’s part 2?

  7. Adam says:

    As others have mentioned, this works for about two days, until your project is so big that it needs a build/serve tool. Then you spend all your time building an inferior ember-cli instead of working on the project you set out to complete in the first place. I’ve been there before–we build our own build tool based on Grunt before Gulp and Broccoli were available, and build times eventually exceeded 5-8 seconds, and CPU was pinned at > 80% since grunt-watch was checking so often for so many files. Instead of being an app developer, I wasted all my time working on the shitty build tool.

    Ember CLI has fixed every bit of this for me. I both know how all of it works, yet I also don’t care unless it’s broken, which is truly never.

    Maybe you were experiencing some beta issues, but this article is both total flamebait and entirely unfounded, in my opinion.

  8. Furblesgbord says:

    The thing I can’t stand about ember-cli is broccoli. Whilst I don’t like gulp that much either, surely there’s a better alternative than broccoli? I’d also noticed the eval thing which seems weird. Apparently it’s to get source maps working, yet source maps still don’t really work that well in broccoli in anything but the simplest of configurations.

  9. n0 says:

    It’s not broccoli its ember-cli.
    I’ve implemented my own app build process using Broccoli, Babel and some other modules.
    It works great and has real source maps (what means that I use exactly the same code for development and production)
    Broccoli works quite nice (~30 seconds for initial build and then only a few seconds for continuous builds).
    So the eval issue is not in broccoli its purely Ember-cli issue.

  10. n0 says:

    Took some time but it is now published –

Comments are closed.