What are some reasons to use ember-cli over existing rails asset pipeline?

I have a relatively moderately sized ember and rails app using rail’s asset pipeline for my asset compilation. I am also one of those obnoxious people who loves CoffeeScript, and so all my JS is CoffeeScript. Yesterday, I thought I would try out ember-cli so I used “git filter-branch” to extract my ember app out of my rails application into a new ember-cli app. I put the breaks on after realizing that the switch to ember-cli was going to take me more than a few hours I put into the ember-cli.

My observed pros of moving to ember-cli:

  • Likely faster asset compilation (even though rails asset pipeline does not seem slow on my machine)
  • Likely better add-on support. I’ve noticed some add-ons don’t always work with with “old-school apps.”
  • Better testing.
    • I have been testing my ember app in rails with teaspoon, which is less than a fantastic experience.
  • Separation of code bases.
    • There is not a good reason that my ember code is in the same repository as my rails code.
  • Departure from seemingly inevitable monoculture of ember-cli.
    • There is a big push to promote ember-cli, and I understand the reasons.
    • I am worried about my app missing out on the future ecosystem of ember if I don’t conform to ember-cli.
      • I’ve already encountered some difficulty with certain add-ons that are developed for ember-cli which do not work without ember-cli.

Observed cons of moving to ember-cli:

  • Tedious migration.
    • CoffeeScript is not a first-class citizen in ember-cli when everything has to be escaped with backticks.
    • Stating all of the dependencies and exports, for each file, is also tedious.
  • Debugging is more difficult
    • ember-cli asset compilation does not give as detailed of errors as rails’s asset pipeline.
    • Unable to browse individual files when in development in a web browser. I realize I can use command+O in the source view to find the source map for an individual file, but the source maps are converted to JavaScript and do not map line-for-line with my CS. Easy enough mental conversion, but rails maps the CS accurately and in separate files.
  • Effort.
    • I’m guessing that it will at least take me a day to convert my codebase to ember-cli.

I am trying to evaluate the benefit of moving to ember-cli, and I’m very much open to the idea. I am just looking for perspective as to why a switch would or would not be beneficial. If anyone has some experiences or perspectives for or against converting from rails asset pipeline to ember-cli, I’d love to hear them.

1 Like

Do it, The community is moving towards ember-cli, it’s pretty much the standard now. Also code changes pushing a page refresh is pretty nice.

If you want to deploy in one app you can use GitHub - ember-cli-deploy/ember-cli-deploy: A deployment pipeline for Ember CLI apps

I’m using coffeescript and it’s a bit annoying to do the backticks on the export and import but not terrible.

The files should be available in chrome when debugging under “no domain” you shouldn’t need to debug in the giant js file.

I agree that live reload is nice. I am currently getting that functionality with GitHub - guard/guard-livereload: Guard::LiveReload automatically reload your browser when 'view' files are modified..

I remember seeing a presentation at the recent EmberConf about ember-cli-deploy. That looks very handy. I currently deploy my application with a custom docker deployment process: GitHub - mrinterweb/freighter: Easy deployment of docker containers over ssh. My current strategy is slow because the entire rails app container must be rebuilt and pushed to the servers every time I make a change. Deploying to Redis would be pretty awesome, especially considering that Redis is already part of my stack. Ember-cli-deploy is an excellent suggestion.

Do you know if, when debugging, the source maps retain the original CoffeeScript? In my experience, the files were mapped to the compiled versions.

I debug in js, believe I read a while back that there was a way to integrate it nicer into the browser but I didn’t dig farther since it wasn’t a major pain point for me.

Yeah, mentally converting JavaScript to CoffeeScript doesn’t require many brain cycles. So it is not a big deal. I’ll check around a bit to see if I can find that reference to better cli coffeescript mapping.

Another reason to use ember-cli is http://emberaddons.com/. There are a lot of useful addons already available, even one that should the aforementioned issue with CoffeScript and the es6 modules syntax, if you are into that: Ember Observer

The testing story is really nice with ember-cli as well. Especially when testing components.