If you find me out in the wild and talk to me about what I'm excited about, topic #1 is most likely going to be how much Ember-CLI rocks. Here's a rough list as to why:
- Fully decoupled front-end and back-end code. Ember deploys down to four static files that rely on external JSON apis to do rich data access. We can think of front-end services in the same way we can on the back-end.
- Pluggable test layers: you can now run mocha, jasmine, whatever you really want when testing Ember applications. I'm not a fan of jqunit, so writing unit/integration tests with it was less than ideal.
- Heavy use of ES6. Your in-app dependency management is via the new module system which is a much better way to live than previous solutions.
- Smart deployment additions: It's easy to minify/asset fingerprint the dist files, making deployment as simple as
ember build and rsync'ing the files to a web server.
It seems like the first question people ask is 'how can I do this in Rails'? Rather than educate you on why the answer is 'this stays as far away from Rails as possible', people build tools to inject ember-cli applications inside a Rails application. Let's educate now:
ginx/apache <3 static apps
The coolest thing about your ember-cli app is that nginx/apache are designed specifically to serve static files INSANELY QUICKLY. There isn't any step where they have to ask a Ruby process to handle a request, and just hang out till Ruby gets done doing its thing. It can also do fun things like caching with no intervention outside of basic configuration setup.
Rails comes with a long trail of middleware
When you are serving dynamic content on each request for a HTML file -- it makes sense to have all sorts of cool stuff, like session storage handled by Rails. When you are serving static content, it gets slowed down by the fact that Rails needs to add in all the site cookies, any request/response headers, etc on the html file served that are wholly unnecessary for your static app.
There's also a reasonable chunk of middleware your JSON API doesn't need. The approach of avoiding the middleware by using
ActionController::Metal is a topic for a different discussion. When people are talking about Rails being 'heavy', the long chain of Rack middleware is usually what they are stating is heavy. When I'm building an app that takes information from a database and injects it into a HTML file, I'm very happy for the existence of the middleware.
Managing JS dependencies in Ruby is slow and unnecessary
Purging the asset pipeline with fire is a topic for another day (it's actually a case study I need to write about) but lemme hit you with a TL;DR:
- On a reasonable sized project, the asset pipeline is roughly 2-3 orders of magnitude slower than one of many JS tools that does the same job. This is the difference in the real world of deciding to check Twitter/HN or not.
- Waiting on a gem maintainer to update a static file in a Ruby library that you can acquire via a JS dependency manager right now makes little sense. When I write JS libraries, I'm sure as shit not going to write a Ruby gem to chuck it into the asset pipeline. Assume that is the default, and get comfortable on the channels that they will distribute their library: npm or bower.
#require directive in Rails defaults you to a world of file system load order based dependency management. This is in fact a world of pain. Get away from it now. Nowwwwwwwwwwwwwww.
I'm not going to lie to you. bundler > npm > bower in terms of suffering. Both npm and bower are young; I have faith they will eventually have the stability that bundler has and/or Yehuda Katz is just going to flip out and fix dependency management in JS. It's still easier than the two alternatives: relying on a Ruby gem not maintained in step with the JS equivalent or manually vendoring all your JS/CSS.
JS build tools sucked when the asset pipeline came out. They have come a significant way since the asset pipelines inception and they have far surpassed the performance and ease of use Ruby can offer for building out static assets.
Code generators in other languages are not inherently evil
I <3 Rails. Rails has made me an ambitious developer for nearly eleven years now and kept my lights on for over six years full-time. Rails will not always be the tool used to develop web applications. Devoting ALL YOUR BRAINSPACE to its best practices is going to leave you behind. It's OK to not know how to do something in ember-cli. It's fantastic to learn new things.
It's even possible that we want to bring things from ember-cli's toolchain back into standard Rails development. Perhaps their blueprint system is the superior option. It makes a ton of sense to ask people to learn additional code generators without wrapping them up in a Ruby process.
Side note: do people actually use code generators?
Here's the deal: Ember-CLI is some next level shit on generating a static web app. No one is great at it right now. Learn about it, deploy an app with it, try to get deep in the static application mantra. Learn the pros and cons. I believe that splitting the generation of your JSON api and the browser application has considerably more pros than cons. You may disagree -- then go ahead chucking Ember apps inside Rails apps.
What really bums me out is that latter approach to web application development looks an awful lot like "I got me this Rails shaped hammer, and ember-cli looks like a rails engine shaped nail". I assure you that it deserves more attention than that :)