Will there be continued support for people that do not want to use Ember-CLI?

It’s virtually impossible to build a modern JavaScript application without some set of build tools. This is true for Ember.js (because of templates), Ember.js 2 (templates and ES6 features) React (JSX and ES6 features), and will be true for Angular 2 (for its Typescript features).

In fact it’s never really been possible to use Ember.js this way in a production application. At the very least you need some tool to precompile your templates. The in-browser template compiler is useful for quick demos, but not the foundation of a production application.

As we approach 2.0 It’s not possible for us to document Ember in a way that hides the need for a build system. Unfortunately the build tools ecosystem is as large and varied as the the web framework ecosystem.

You will be able to build Ember applications with any build system of your choice[1] (Ember is not tightly coupled to ember-cli[2]), but the official documentation will cover the one that a plurality of Ember.js developers use today (ember-cli). Of all the available options (rake-pipeline, the hundreds of custom grunt or gulp systems, Ember AppKit, etc) only ember-cli really captured a sizable mindshare of Ember developers.

That’s why we’ve adopted it as the defacto build system for Ember applications.

It’s worth noting that a generalized version of this tool is also the build system the Angular team has selected for Angular 2.0.

I know everyone on Ember core sympathizes with web developers whose careers started during the “download a zip, add some script tags, FTP into production” era for the “front end” and now feel a bit startled that all their favorite tools are becoming increasingly complex.

But, the fact remains, that era is ending. For some of us, it’s been over for years.

There was a similarly painful, watershed moment in the early 2000s when the standardistas lobbied their colleagues to move web development away from GUI editors, table-based layouts, spacer gifs, and font tags to today’s world of HTML5, CSS3, and ECMAScript 6-based solutions.

Much of the same feedback was levied at them: “This is more complex. All the existing tooling doesn’t work. We don’t need to change. The old way works just fine.”

Users have expanding expectations about the experiences possible in the browser. In 2005 only giant corporations like Google could manage a large in-browser applications like Gmail or Google Maps. In 2015 users expect an app-like experience for most web interfaces. The increased functionality and performance of an application over a static web page is a key competitive advantage for most new companies.

As tempting as it might be to think there’s a pendulum and one day it will swing back towards a simpler style of development in the browser, recall that it’s been a decade since the industry moved away from tables and font tags and I’ve seen no signs that the tide is turning back towards those patterns.

[1] Assuming your build system has the necessary features like: ES6 compiling, ES6 modules, a template compiler, etc [2] Fastboot/Rehydration will be tied to Node. Ember needs a JavaScript environment on the server for these features and node provides the most commonly used server JavaScript runtime