Ember is an opinionated framework. While it is possible to use Ember without Ember-CLI, it is certainly a more difficult path.
Ember-CLI is indeed opinionated, like Ember itself. The “convention over configuration” methodology of Ember means that if you don’t follow conventions, you have to do a lot more coding work to configure things so that they work the way you want them to. Then you lose the benefits, like being able to go into any Ember project and find anything quickly because they are all arranged the same way.
Ember-CLI is opinionated, and defaults you into using ES6 because they see it as the future. However in theory you could uninstall the ember-cli-babel dependency and not use ES6. Install ember-cli-coffeescript and use CoffeeScript if you want to.
It is possible to migrate an existing project to Ember-CLI, but yes it is a lot of work. Whether it is worth it is up to you.
Turning off ES6 is a bad idea, ember is moving more towards ES6 and it will shortly be impossible to not use it. ES6 should take you less than an hour to figure out most of the new features that everyone uses if you already know javascript - there isn’t much to it.
I’m not even sure if it’s possible to remove it from your project at this point, if you are using external addons (or even if not). But trying to do so is pointless anyway - ES6 is the future of javascript and really not burdensome (beyond import / export, I don’t think you even have to change your coding style at all if you don’t want to)
File structure is probably easier to customise, you could even implement a custom resolver if you like - but first look into pod structure for your routes, which is a really nice structure.
Initially, ember-cli was a nice tool to use with ember, but gradually it has been transitioning to the only way possible to use ember. At this point we’re slightly past the point where it is a very bad idea to start a new project in ember without it, due to missing out on almost all the great things in the ember ecosystem that depend on it.
People may not like the decisions it makes for you, but that’s pretty much the point of an opinionated framework. My advice at this point is to decide if you can live with the decisions ember-cli makes for you. If you can’t, then frankly you are really better off choosing a different framework at this point - that’s my opinion based on the current state and future plans that I know of.
Yes, I understand your answer very well. I am planed to learn ES6 but for now I can’t.
After little cogitation, I think I know the basics, as I spend my time to translate the Ember ES6 resources to legacy JS.
Like many people, I choose Ember for its appropriation capability. I use Ember on my own with my personal workflow.
In fact, I made this question to obtain answers for my doubts. I hate change and I focused only on these drawbacks.
But Gaurav0, gave to me all the answers I excepted for.
My team chose not to use the CLI. We’re doing pretty well with both Ember 1.13 and 2.1.
I couldn’t sell anybody in our browser JavaScript world on bringing the notion of “build” into the development cycle. Any development cycle that inserts more than a second or two between save and reload fundamentally changes the immediacy of the “living in F12” experience. Linting, unit testing, etc - we’ve got all of those configured and available in the IDE when people want to run them. They aren’t part of the culture yet, though, so I have to work on that shift before it intrudes on that adrenaline-pumping cycle of edit/debug.
We work exclusively on Windows systems and Ember-CLI is very slow on Windows, even running elevated to permit links. We can turn off Windows indexing, but corporate policy doesn’t permit desktop users to make ad-hoc exclusions to antivirus settings, and the rapid creation of gazillions of tiny fragments as files is deeply felt. Best time? Maybe 8-10 seconds for a toy project. Testing at home where I have more freedom? Maybe 3-4 seconds. On the Mac? 1-2 seconds for the same app - still only borderline acceptable for “living in F12”.
We have no notion of a “client project”. A web application is a single deployed project that runs partly on the server and partly in the browser. All client code is checked directly into the ASP.NET MVC web application project and edited in Visual Studio The single page of the app is the Razor .cshtml file. Even all of the template compiling and minification that we do to the client in a release build occurs inside the MSBuild file for the web application. For debugging, we execute the entire project in place, with the development tree mapped into IIS. Mostly, we build the whole app once in the morning and spend the rest of the day editing in Visual Studio and reloading the app in the browser to debug. Very occasionally, we add a new action method or controller on the server side to support some client request and rebuild.
We are, however, using the directory structure and naming for Ember CLI. The names we give to require.js are the same names Ember CLI uses and all our modules are wrapped in the require.js defines using those names for dependencies. All of these modules are also loaded by a single require.js modules that adds them to the application’s global object with the appropriate names so that the default resolver can find them. It all worked more cleanly and easily than I expected it to.
So, as you can see, the reasons we aren’t using Ember CLI are a mix of performance limitations of the tool, conceptual differences in the development environment, and a team that sees less value in what it offers than what it takes away. However, Ember is working really well for us with what we’ve got, and I only hope that it continues to do so.
We are also using Ember 2.1 without CLI with success. For us, it came to a couple of things:
We are building a multi-page application. Each page loads a different Ember app, but all of them share data models, components, … we found doing this with CLI really hard.
Our components usually have tightly coupled logic and templates, and sometimes sub-components. I find CLI’s layout confusing. We use this instead, which has the added benefit of making dependency management easier as including the main component automatically pulls sub-components:
component-name/
sub-component-name/
component.js
template.hbs
component.js
template.hbs
Integrating JS tools with the rest of the world has always been a hassle. True to this tradition, CLI makes it really easy to create standalone applications, but integrating that into a non-JS asset pipeline is messy.
We don’t need no requirejs.
Ember-cli is evolving fast and seems to be much less careful than Ember to retain backwards compatibility. More generally speaking, it is nowhere as mature as Ember, which is one of the main reasons that brought us to Ember in the first place. Software chains are only as stable as their most unstable link, so…
So we built a small compiler that integrates into Django’s static files pipeline, invokes esperanto (for es6 transpiling) and ember-template-compiler (for hbs → js conversion) and auto-generates container registrations. We still get es6 goodness while retaining control on our building/deployment process.
I did try to convert our project to ember-cli though, but even ignoring the multi-app issue, I keep hitting other problems on the way - dependencies on yet-unpackaged nodejs versions, trouble installing modules as non-root user, mixed up bower/npm modules, none of which are packaged in common GNU/Linux distributions… and once I overcome all this, the resulting JS is about 30% larger than what I have now. I suspect requiresjs and amd resolver to be the culprits, but did not actually check.