Ember-cli or not?


#1

Hello,

What improvements or good things apport the usage of ember-cli to develop a project, versus don’t use ember-cli?

Thanks Dracks


#2

Most likely it saves you a lot of time to avoid writing lots of boilerplate stuff. ‘ember generate resource -modelname-’ - boom, you will have generated all you need. And you have your code structured in modules, can reuse code, use ES6 (2015) and so on… I don’t want to miss it anymore :wink: (but I was sceptical as well when I started with ember…)


#3

I think the only reason not to use it would be if you wanted to use Ember to only light up certain portions of a server-rendered application. EmberCLI is designed to facilitate a workflow where Ember IS the FE application, not just a dynamic content layer that sits on top of it.


#4

I like ember cli for ES6, http mocks and generating routes/models/etc. But is it just me or the build times are terribly slow?


#5

Are you on windows? Try to run the console you’re using (powershell, git bash, etc) as administrator. Also, there is this addon which is supposted to boost performance on windows: https://github.com/felixrieseberg/ember-cli-windows-addon


#6

I’m on mac. The problem is that it’s doing full rebuild regardless the of file I changed. For instance, I modify app.css and it will wipe out the /dist folder and rebuild everything from scratch. Things get worse when you add 3rd party addons like ember-ckeditor. Now every change means that along with all the ember files it will also process and copy the whole ckeditor library. My build times are now 13s.


#7

This may be a dated issue. But when I first tried ember-cli my mac didn’t install the correct watchman (to monitor file changes) and it reverted to whatever is the default with this error:

Could not find watchman, falling back to NodeWatcher for file system events

I finally figured out my problem (or, to be honest, I think I completely reinstalled npm) and the difference in build speed is night and day. YMMV of course, but for me ember-cli was almost unusable before. Now I love it!


#8

I uninstalled watchman because of ever incerasing recrawl errors. But watchman or NodeWatcher is just a tool to detect file changes and shouldn’t affect the build time imo.


#9

True. I misspoke. The response time in seeing the browser reflect changes (where the build time must have been just a fraction of that total time) after moving from NodeWatcher to watchman was, for me, an order of magnitude faster.

Anyway, it doesn’t sound like this is your specific issue. Just throwing it out there for others in case they see a similar problem.


#10

Other reason is when you are using windows… I was trying for days to switch to ember-cli, but always the grunt build times were faster… even on linux, .less compiler 8 sec. on ember-cli vs. 2 sec. on grunt. But not using ember-cli is becoming harder if you want for example to update the ember version, using some special addons like ember-cli-deprecation-workflow or ember-legacy-views…


#11

Don’t use it if you want to plug and play Ember into your existing build system. E.g. if you’re serving assets through Rails sprockets. Use it if you plan to develop a frontend app as a separate project and will be serving compiled static assets independently.


#12

@mehulkar I don’t think that is really a hard rule. I have had great success using Ember CLI to build a stand-alone-ish single-page app within a Rails project. Just work on it in its own directory and create a simlink from the rails public directory to the dist directory of your ember project. Sure, there is some tinkering involved for the routes to go back and forth between Rails and the Ember CLI area, but it’s not ugly or wrong. Once sorted, you can just commit it to git and deploy it like that.

Generally though, if you wanted your Ember rendered truly along side your rails content, then I agree with you.


#13

Agreed, not a hard rule. Just more pain than it’s worth.