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

1

I’ve been working with Ember for some time now, and I think it’s really practical that I can just download the library and add it to an existing project, without making it the center of my development experience. I’m just wondering if we’ll always have the option of choosing how we build and test our Ember app.

This might sound like a silly question, since you can always do anything you want with an open-source project, but I’m just wondering if it will always be as easy as it is now to just reference ember.js and start from there.

For instance, I see that all the 1.11 docs have been updated to work with modules, which is something specific to Ember-CLI (without doing any extra work). What this tells me is that someone new to Ember now should go the Ember-CLI way.

Any thoughts?

2

The current plan is to allow both, but encourage the module + cli path, as we believe it enables our users the most.

3

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

11 Likes
4

Very well said. Many at my place of employment are going through a similar realization.

5

Everything you are saying is very interesting.

I’m a .NET MVC/Web API guy, and somewhere in the past 2 years I started digging into front-end frameworks like Ember and Angular. I used to download the framework with a Nuget package and it would install dependencies in Visual Studio, and I thought it was really cool.

After that I learned about precompiling templates, and then I realized Nuget was more suited for back-end dependencies, and that there was this whole world of front-end tools that I didn’t know about.

I downloaded Node, installed Bower and Grunt. I then reworked my front-end dependencies, and created Grunt tasks to build Ember, and Bootstrap, etc. And I can still do all this in my favorite editor, Visual Studio.

I asked some questions on the IRC channel, and I was told the proper way to do things in Ember going forward was to use Ember-CLI, so I downloaded Ember-CLI and made everything work fine. The thing is that I felt like I didn’t know enough yet to make it do all these things asutomatically behind the scenes.

When I was doing everything myself, I understood the process and I could follow along at my own pace, with Ember-CLI it feels like I have to think in reverse. Ember is now the center of my world, and the .NET stuff, and possibly my Visual Studio tools, are perhaps not good enough.

Anyway, I just felt like trying to make you guys understand where I come from.

Thanks!

Edit: It also made me think that I’m probably not the only one. All these .NET developers who are now trying out front-end frameworks and are probably trying to push these technologies into their companies, how can we help them, help us, make the transition as smooth as possible? I can’t help but feel that it’s going to take years before they accept to drop ASP.NET MVC in order to run Ember in Node on their server while compiling it with Ember-CLI, even if you guys convince me.

5 Likes
6

No matter what, it is in the interest of Ember (plus whatever build dependencies it needs) to play nice with the existing build tools used by the main application (which may not be javascript-centric). If not, people would just go with something that either has a smaller footprint or does not impact the existing build process as much.

7

You might be approaching Ember.js with an incorrect mental model. Ember.js (and tools like it) are for writing full applications, not augmenting a server-generated page with additional behavior post-rendering via JavaScript.

Think of Ember.js as the browser equivalent to Cocoa Touch for building iOS applications. If you’re writing for iOS, the services that store and expose data over HTTP are no more (or less) the “main” application than the iOS application is.

There are still many tools available to developers who prefer (or are stuck using) the “islands of richness” approach. Ember.js is not designed for their particular needs. Those developers will be much happier using something like jQuery or Knockout.

1 Like
8

You might be right, so the situation is kinda confusing for people who are not doing or coming from javascript-only stacks. There are a lot of solutions/workarounds out there now for ember integration with some main web stack (say rails), and obviously there is overlap and duplicity of functionality/dependencies which prevents these solutions from becoming more refined and widely adopted.

9

we see a lot of people having great success with .net for the backend and ember for the front-end, HTTP is a lovely interface :smile:

2 Likes
10

I wonder if ember-cli would support jspm? For example, we have developed a bunch of ember components and it would be great to publish them as ember-cli add-ons but I think it’s not possible because ember-cli will not be able to resolve imports like this import tmp from './my-tmpl.hbs!'.

11

We’ve traditionally been a Microsoft only shop…but we’ve started building a bunch of our front-ends with Ember (using Ember-cli). Back-ends are still mostly WebAPI (C#) with a few Web APIs in Nodejs.

1 Like
12

will there be longterm support for ember-rails. @tricknotes is working on intergrating es6 in to ember-rails. once that is done will we be able to use the new features that are coming in ember v2 ?

13

I would hate to use ember without the greatness of Ember-cli.

14

I use Ember as the entire front-end of my application and WebApi is the backend. Unfortunately, we work an environment that moves very slow. The good news is that there is some inertia now toward node, build tools etc. And I can see myself getting my hands on the greatness that is the node ecosystem in the coming months. I have been experimenting at home with node and getting up to speed so that when I do have those tools, I will be able to move forward with ember-cli. I think I can speak for other developers in my situation when I say, ‘we hear you loud and clear, just don’t abandon us just yet’ - we are working to modernize, but we’re not always the one’s in control of our environment.

15

From the sound of it, shouldn’t Ember-CLI eventually just become EmberJS proper? It seems like there are two forked approaches to building an app with Ember…

1 Like
16

The ember-cli approach is great if you’re starting from scratch but If like me you’re porting an existing application that not only needs to coexist with another framework (jsf) but is huge and written well before ember-cli existed. It would take months to port it over and even then it wont work (because ember-cli only allows one page).

17

Yeah, when our app started ember-cli wasn’t exactly production ready, plus we didn’t want to add it and ES6 to “learn ember” in our task list. We had an already understood build system (rails asset pipeline) and tooling that integrated with it easily (ember-rails gem).

Fast forward to today and virtually everything has shifted over to ember-cli. Porting a project from a globals based app is not simple, especially if this is your first ES6 rodeo. We picked ember-animate over liquid-fire and are now stuck at 1.10 due to compatibility issues there. The solution for getting a globals-based version of liquid-fire is not simple (note: it is still appreciated!) and is currently breaking for me for reasons that are not exactly clear.

It’s very clear to me that ember-cli is the community’s choice for a way forward. I can’t say I’m incredibly excited about this, but it is what it is. Figuring out another build/dependency/tooling system is annoying, especially for a team that’s looking to expand and probably won’t have the luxury of hiring someone with Ember experience.

My big complaint, though, is that there’s so few resources on the transition. Is everyone just rewriting things from scratch in ember-cli? The docs on ember-cli.com point you to an automatic migration tool that really throws you in the ES6 deep end. I haven’t seen anything about how to do an incremental port from globals to ember-cli, which is really where I’d be most comfortable.

18

Take a look at GitHub - fivetanley/ember-cli-migrator: migrate your files to the standard ember-cli structure, preserving git history. I have used it on a few ember-rails projects to massively reduce the conversion burden. Note: it is not perfect, but does a ton of the grunt work.

19

Yeah, I’ve found that and used it. It did get a lot of the grunt work out of the way, but trying to debug the cases where it got confused as my first ES6/ember-cli experience wasn’t terribly pleasant. I’ll have to keep plugging away at it, but we’re kind of at a point right now where I can’t just stop everything to make the transition happen.

Do you have any suggestions for asset handling when we eventually get things transitioned over? I’d prefer to not disrupt the current (Rails asset pipeline-based) system too much. I tried ember-cli-rails a while ago, but after managing to wedge it to the point where Rails needed to be restarted I gave up on it for development purposes. (note to anyone reading: this very well could be due to my system’s node/rails/etc config)

20

While I love the idea of Ember-CLI - it’s turning out to be too restrictive.

Ember-CLI prevents me from pulling in 3rd-party ES6 modules as well as unnamed AMD modules. I have to roll my own build process in order to do this. But as soon as I want to do that, I lose the benefit of being able to write components in the Ember-CLI style (e.g. I have to import the App into each component).

Wish there was a better alternative for using Ember without the restrictions of the CLI’s build process.