Why is ember-cli so important for the future of ember?

Ember CLI
1

Hey everyone. I’m just getting into ember for the first time over the past month. I have a lot of experience with both front and back end MVC frameworks, including backbone, rails, and laravel.

Honestly, the most frustrating part for me so far has been ember-cli. As a developer, I already have a set of tools that I’m used to using (grunt, gulp, sprockets for rails, etc), and I’m really frustrated that the ember community has pretty much decided that I need to be using the tools packaged in ember-cli (broccoli, jshint, etc) instead. I understand that ember is an opinionated framework, but I feel that it is a bit overreaching for ember to also become opinionated about what build tools I should use. I particularly have gripe with broccoli, which seems to be a CPU, memory, and storage hog.

I’ll admit that the command-line package management feature of ember-cli is pretty nice (mimicking ruby’s gem service), but it’s not game changing. It definitely isn’t worth the trouble the rest of ember-cli has been causing me. Also, ember-cli seems bloated and the code strikes me as messy.

I’ve read in a few places how ember-cli is the future, and how it is the next, necessary step for ember. However, I have not really seen any justification for these claims. Could you all kindly explain to me why forcing me to build my project with certain tools is so important for the future of ember?

1 Like
2

My take is it’s similar to why shipyards use cranes and shipping containers. When you know you have a ton of stuff to haul/move, creating a uniform process that enables easier bulk distribution and reorganization / transport of the ingredients is the most efficient and often used method.

Ember-CLI = Crane Components = Containers Ember-JS Code = Stuff in containers

A skyscrapers analogy also works with crane + scaffolding sorta, but I hope you get the idea

3

Everyone is entitled to their opinion. I share the opposite feelings.

I’ve lived, and largely still do, in the world of “roll your own build system, test framework, etc.” It typically ends up being a total disaster where sharing resources across projects is a major pain. By shifting to a structure that every project can align with, engineers are now able to jump into any project and immediately be productive… and as a bonus be able to share large chunks of our applications in the form of addons (see: www.emberaddons.com).

I think once you get over whatever humps you’re facing, which are still unclear to me, then you’ll begin to see the light. Feel free to open issues around the individual problems you’re seeing with ember-cli.

3 Likes
4

Because it provides a common way to structure all Ember apps, a common format for writing extensions, a standard testing integration, and (now) a common deployment process. Before all of that, Ember was just a .js file and everyone was reinventing all of that stuff every time, for every project. It fragmented the ecosystem and made you have to know too much about Ember’s guts and the available pipelines to build anything with it. At this point, Ember CLI is probably more indispensable than the actual framework.

I’m sure there are folks on here that would be curious about your Broccoli issues though- it should be heads and tails above grunt, et al. If you’re having performance issues with it, that’s unusual and might be something that can be fixed.

1 Like
5

I pretty much agree with what you say, although I can somehow relate to OP in that if you have a specific toolset and are heavily invested in it / know your way around it, it can be somewhat frustrating to have to relearn everything.

One problem with ember-cli is that it seems sometimes hard to leverage what the general JS community has to offer. It is not always straightforward to integrate libraries, tools, etc. that other people use into Ember (yet). I just worry a little about “not invented here” and the Ember community maybe losing touch with the JS community in general. But that’s not something that necessarily has to happen as long as interoperability remains a concern.

I think it will be great if in the future ember-cli grows to be more flexible. E.g. I don’t see a compelling reason why QUnit is the default test framework. There’s ember-mocha which works great, but the documentation is somewhat sparse / fragmented.

As an aside, while Ember CLI addons can be a great solution for some problems (something like ember-simple-auth), I’d much rather have people producing high quality libraries that are independent of whatever frameworks you use. I’d hate to have the situation we have in the Ruby community where pretty much every toy gem has a dependency on Rails.

2 Likes
6

It’s probably important to make a distinction between Ember.js (the library) and Ember (the framework)

Although ember-cli will be the default stack that is documented in the guides, it is not a requirement for using the the Ember.js library. That will continue to ship as a git repo, bower package and npm package for the foreseeable future (although, honestly, I don’t suspect bower will be supported much longer).

You can install and consume that code using whatever tools you prefer. There is no coupling between Ember.js and the set of build tools we selected.

Although you have selected a set of preferred build tools, every day there is some developer making the jump from “just a little jQuery” to “full-blown apps in the browser” who shouldn’t need to also navigate the build tools landscape.

The state of the world for everyone right now is that building applications for the browser of any significant value requires a build step. There were essentially two options: make no recommendation around build tools or make some recommendation about build tools.

Because there is no consensus on build tools in the JavaScript world any set of tools we selected will leave some group dissatisfied with our selection. But, selecting some tools is a superset of selecting no tools: you can use whatever tools you want.

There are a number of features in the larger framework that will have a build tools requirement to work out of the box. Addons, engines, and fastboot are three that come to mind.

Although you’ll be able to keep using Ember.js with your preferred build tools, if you wanted framework features like addons, engines, or fastboot, you’d need to roll this behavior on your own.

1 Like
7

This is a good point.

When I think of “framework” I think of stuff like Cocoa or Cocoa Touch. As Cocoa is to Objective C, Ember.js and Ember framework is to Javascript. The library is a key part of the tooling, but just a part. And a framework is not merely a build tool. So when we consider stuff like the UI, in Ember that is just HTML and CSS and JS based components. However you need to a tool like Ember CLI to bring that together in a standardized way. The UI bits are shared across the community (various addons). And the tooling let’s us share and integrate the parts that make Ember feel like a coherent framework. This despite the fact that the core team does not directly maintain all the pieces.

8

Just wanted to say thanks for all the replies. This is giving me a lot of food for thought.

I think I’m going to keep on keeping on with ember-cli. I have a few questions that I’ll open up as separate topics, so as not to pollute this discussion.

In the meantime, please keep the thoughts flowing. I think that this topic could provide valuable information and direction for future ember developers.

1 Like
9

IMHO the best way is for frameworks and build tools to be loosely coupled, so that there can be a friendly competition of build and other tools (and may the best one win!)

I disagree with Ember’s decision to grant Ember-CLI a monopoly on being the “official build tool,” and I think it’s doubly bad that from v2.0.0 Ember and Ember-CLI will share a version number(!) Not to disparage the work Ember-CLI team has done, but I disagree with a number of the design decisions made in Ember CLI. For starters:

  • It’s dependencies take 100s of MB of disk and its a memory hog
  • It relies on “resolver” magic to avoid the chore of importing ES6 modules the proper way; this leads to ugliness when you go to write tests (see: integration mode)
  • Ember addons are an 80%+ overlap of what Browserify does already.

I think the community is better off with competing build tools to help arrive at solutions faster. (We all know how competition with React has spurred on Ember development – see: Glimmer!)

10

@johnnyshields vertical integration can sometimes be a good thing in that the pieces are more likely designed to work well together.

Other tools may be great but that doesn’t always mean that they work great together.

That being said I don’t think competition is completely precluded. You can still build a different and better build tool.

Good ideas win out assuming they actually solve problems that people care about or actually have. Want to use grunt? Well one can continue to use ember app kit, or fork it and make improvements. Want Gulp based system? Build a system on it. Is Yeoman still a thing?

Even better build a native OS X, Linux or Windows system that works well with those OSes and GUI tools.

Why not a real compiler that optimizes the hell out of things and convert all that code down to ASM.js or some lower level byte code.

I am sure there is some room for more strongly typed systems.

Ember CLI may not be perfect but I kind of like the fact that the energy is focused on a single unified solution. A lot of fractured tooling is rarely pleasant even if we may be attached to particular pieces of the system. And it seems like despite best intentions sometimes “friendly competition” can devolve into lots of reinventing the wheel, hype fatigue and churn, if the all the attempts fail to reach critical mass.

I would also say “granting a monopoly” is a bit strong. But I can appreciate that a popular solution can suck the wind out of other efforts. The reality is it takes a lot of collective effort to get any system off the ground.

As for specific criticisms

It’s dependencies take 100s of MB of disk and its a memory hog

Yeah, a lot of moving parts in that node_modules folder. I suspect that is really about fixing some of the problems with NPM and being smarter about dependencies. But in my day to day usage I don’t notice this bloat too much. It is actually a part of the system that I don’t really worry about too much.

It relies on “resolver” magic to avoid the chore of importing ES6 modules the proper way; this leads to ugliness when you go to write tests (see: integration mode)

I suspect this will get better over time as the module stuff and experience with it matures. But yes a more pure modules system would be nice. But it took us a while to get here (AMD, Require). ES6 was called “Harmony” for a reason.

Ember addons are an 80%+ overlap of what Browserify does already.

I would be curious to hear more on how this is a problem. There are addons that do lots of different things that have nothing to do with runtime dependencies.

11

@eccegordo while I agree there are short-term time-to-market advantages to building a “monolith” framework as Ember has done, ultimately Ember is following the classic “Not Invented Here” paradigm and is rejecting perfectly viable, widely-used, and battled-tested solutions (Browserify, Grunt, Node libs) for it’s own (Ember Addons, Broccoli, Ember-flavored Javascript.)

Re: Browserify specifically, the question should really be why NOT use Browserify when it has literally 10x the number of installs as Ember-CLI (1.6mm per month vs. 160k - see: browserify - npm, ember-cli - npm) My main problem with Ember Addons is that they ONLY work with Ember, we get all these silly “ember-cli-bootstrap” type addons which do nothing but wrap a third-party lib (and then the maintainer goes AWOL and never updates the version.)

12

IMHO marketshare is rarely, if ever, a valid argument for quality. As an OS X user for over 15 years, the argument “you are never going to make it, too few users” holds little water with me. Popularity alone != quality.

Not saying browersify is a bad tool. But surely there are other measures of why it should be used or not used.

I can understand the frustration with abandoned addons. But addons themselves are and can be so much more than simple wrappers around other libraries. And it is not that hard to create your own addon to wrap bootstrap or whatever other package.

Now the monolith thing is a different argument. There is something to be said for the UNIX philosophy of small single purpose tools.

13

Addons make sense where they extend / implement functions that only make sense within the Ember context. But in the Ruby world, we’ve come to a place where every gem and their mother depends on Rails, and people have only recently come to realize that this isn’t after all such a good idea (and it’s arguably even worse if this happens to Ember, because Ruby users, by and large, know and use Rails, but JS users do not necessarily use Ember). That said, @johnnyshields, there is ember-cli-browserify, which is arguably a better solution (just one thin wrapper instead of one for every library).

And while marketshare is not a valid argument for quality, in the OSS world it has a number of benefits:

  • more people can review the code
  • more people can give support
  • the tool, its intricacies, details and pitfalls are more widely known and documented
  • the Ember core team does not have to deal with tooling and can focus on Ember-the-library

This doesn’t mean that there isn’t a valid reason to still use your own tools, but you have to know the tradeoff. Personally, I don’t mind ember-cli in general so much, but some things do harm interoperability. Testing was already mentioned.

1 Like
14

@eccegordo Ember should find ways to plug into the existing standards of the JS ecosystem (including Browserify) before impulsively building it’s own “Galapagos Island” paradise where everything has evolved independently from the Javascript mainland. Market share of OS project is also a good measure of whether a project is likely to be abandoned in the future.

@Fryie my app server is in Rails, that was originally a selling point to adopt Ember. But the more I’ve worked with Ember and explore JS alternatives, the more I feel Ember should liberate itself from its Rails heritage and do things the established Javascript way (node, react, etc). “When in Rome…”

My team will explore making an alternative Ember build system, based on standard JS tools. Our CI run with Ember CLI takes 15 minutes for 200 acceptance / 500 unit tests and consumes upwards of 700MB memory (after fixing all identifiable leaks in our app code), which is simply not viable for our requirements.

15

I somewhat agree. OTOH, in my humble opinion (coming from the Ruby / Rails world), the JS ecosystem sadly is sorely lacking in some regards. I’ve spent half a day trying to find out how to properly lock package versions (npm shrinkwrap seems to only do half the job) because of tests suddenly failing on the CI server, something that in Ruby land is a simple “check in Gemfile.lock” away. That is, I believe that in some respects, the best solution is not out there yet.

I have to agree that the testing situation could be improved, although the 15 minutes strike me as particularly odd. In my case, there is some ramp up time for building the app (I think some intelligent caching might be a deal-breaker here) but after that tests run fairly quickly - much faster indeed than the Rails experience (where the full DB is always loaded).

16

@Fryie re: NPM, on the plus side, unlike Bundler, NPM never has version conflicts among sub-dependencies (due to usage of ES6 modules) and it uses a consistent manifest file for both your project and its libs (package.json) instead of the arbitrary split between Gemfile/gemspec which make it difficult to have subprojects. I’ll trade that for the overhead of having to use npm shrinkwrap any day!

17

The problem I am encountering is that, even if you are writing the bulk of an application and all of the user interaction in JS in the browser, a browser app isn’t its own world. It connects to and is delivered by a back end web application that provides it with data services, BI, the results of proprietary algorithms, etc. which hopefully includes some of the stuff that makes it “magic”. In my world, that back end is C# / ASP.NET MVC / IIS / SQL Server / Azure.

It isn’t clear to me how I can integrate Ember-CLI mechanisms with the capabilities of something like Node.js Tools for Visual Studio to get end-to-end build and debugging. Broccoli performance on Windows is also awful. I can get it down from an initial 40s to 10s, and perhaps 6s if I could figure out what form to fill out so that corporate would let me tweak the “System Endpoint Protection” settings but that still isn’t very good. The Broccoli folks don’t appear to be interested in making those numbers get much better either. Windows isn’t their bread-and-butter, and doesn’t excite them.

I really love the new physical code architecture that Ember CLI works with. I really want it. I also want the new Resolver, the transpiler, and template compilation. I want unit and system test - QUnit, Jasmine, Mocha - apples and apples really, and YUIDoc does what I want. I just want to use Visual Studio as my environment rather than a mechanism that doesn’t work well on the only platform my corporate code will ever deploy within.

The “Microsoft shop” case is just one example. I expect there will be a lot of variations on this same theme, so it would be nice if the “package” were broken out a little so people had the bigger building blocks to make other integrations without each one of us reverse engineering the whole arrangement.

1 Like
18

@Lupestro Ember-CLI shouldn’t need to connect to your backend; that’s Ember / Ember Data’s job (with some config you add to point Ember Data to connect to your server.) But true dat about Windows massively lacking support in Ember CLI

19

These reasons have nothing to do with Bundler, however, and everything with Ruby-the-language. The way Ruby’s require is built, different sub-dependencies (for better or worse - I haven’t had many problems with conflicting dependencies) just aren’t possible unless you use your own dependency resolution system. And the split w.r.t. to gems / applications is due to the fact that Rubygems predates Bundler. It’s certainly not worse than JS having npm, bower and on top of that libraries are often incompatible due to the different module systems.

IMO Bundler has made the best out of its situation, continually improving, while with npm / node there doesn’t even seem to be a standard way to enforce a particular node / npm version? Also npm-shrinkwrap is:

  • not the default, and not even actively encouraged
  • needs to be run manually after every update of your dependency (something you most likely forget)
  • behaves weirdly and unintuitively when you e.g. go into your package.json and update a dependency (it will just silently ignore that update if you have a contradicting specification in your shrinkwrapped file - Bundler here will complain and tell you that you need to run “bundle update some_gem”)
  • does not actually enforce that you’re using particular versions of packages (with Bundler, this is simply “bundle exec” - or binstubs, if you prefer) - Ember actually does this by performing its own checks
  • etc.

At least that is my understanding of it, and I could be mistaken, but to me, Bundler behaves much more consistently. I may run into dependency issue while installing, but if I install my gems, then at least I can be sure they are installed in the right version.

My point is that, while I agree that insular solutions are generally bad, the current solutions, IMHO, are lacking as of yet.

Although, in general, I agree with you. It would be much nicer to actually write a sane npm wrapper / alternative that can be used outside of the Ember context and build Ember around that - instead of going the other way around.

20

Just throwing this out there- from the outset, Ember declared itself as a convention-over-configuration solution. Part of that is having a “blessed path” for things like build tooling, plug-in architectures, etc. Having a rich ecosystem of solutions for these things with no standard that really sticks out has its advantages, but it’s not what Ember is for. It DOES describe almost every other client-side solution out there, so if those are truly desired characteristics, one doesn’t hurt for alternatives. If we take out all the opinions, then we’re just “Angular, but kinda different and less popular,” and I don’t think that stokes anyone’s fire.

1 Like