Build without Broccoli

I know my question may be stupid. But I have to ask.

I’m working on a project with version 2.5.0 Ember and Ember-cli version 2.4.3. And in this project I am using some things like: Stylus, Rupture, Rucksack and PostCSS and my current build is done with the gulp, however, the ember-cli forces build with broccoli, but I do not want the build be due the broccoli but by gulp.

Does anyone know the best way I can disable the build ember-cli and use only the build gulp and if it is a good practice? I know it’s “native”, but gulp currently best meets my needs than broccoli + ember-cli, plan to use the ember-cli for the simplest tasks ember.

Thanks.

Just a tip, look a updated yoeman ember generator soruce GitHub - eguneys/generator-emberfs: Yeoman generator for Ember.js/RequireJS/gulp/Express web applications http://yeoman.io this is build over gulp

Thanks @heatbr I will check it out.

But I only want to use Gulp without any other build tool or generator for this. I don’t know how can I “turn off” build with broccoli/ember-cli for just use my gulpfile :frowning:

This is not possible. If you use ember, then you are generally using ember-cli which uses broccoli. You cannot just turn it off.

Yeoman is not a good choice. You will not be able to take advantage of the ember ecosystem without using ember-cli and broccoli.

I would strongly recommend against using ember without ember-cli. In my opinion, it would be better to use a different framework instead at this point.

You can certainly use ember without ember-cli. But if you’re opting into ember-cli, then you should expect to use the build pipeline it’s crafted around.

Also, all of what you mention have broccoli plugins already, porting from gulp to broccoli shouldn’t take much time.

@alexspeller Thanks for helping me again :smile: ! Well, I get it now. In fact, I do not use Yeoman. I use the Ember-cli own to create my files and I have to agree, it’s an amazing tool. But it is a strange argument not use the Ember because my build tool is not the Broccoli.

I confess, this is very strange because I think the framework should not force me to use a specific build tool but support at least the most used. I think this dependence Broccoli is not healthy. It would be wonderful if the tool allow me to decide what is best for my application in terms of build.

I know that Ember has its own way of “thinking” but humbly (and I may be completely wrong) is not for the Ember decide which build I use. This is something that took me by surprise and I confess that it was the first sad surprise. :cry:

@jasonmit Thank’s. Regarding the build I understand, but I still think it would be healthier if the tool would fit my build and not the reverse. I may be wrong.

Currently these are the dependencies that I have on the project in Ember and would like to use them with Gulp, but if not as I will have to use the build Ember itself. But I did not find many of these plugins for broccoli and I have no time to translate a plugin Gulp for Broccoli and keep it at the time. And many of these dependencies are really important in my project. And there is the factor that many of these plugins are versions with very outdated in relation to their “sisters” in Gulp or Grunt.

  1. require ( ‘gulp concat’) ----> find in broccoli
  2. require ( ‘gulp-group-css-media-queries’) ----> do not find anything in broccoli
  3. require ( ‘gulp cssnano’) ----> find in broccoli
  4. require ( ‘gulp sourcemaps’) ----> find in broccoli
  5. require ( ‘gulp postcss’) ----> find in broccoli
  6. require ( ‘gulp stylus’) ----> find in broccoli
  7. require ( ‘rupture’) ----> do not find anything in broccoli
  8. require ( ‘lost’) ----> do not find anything in broccoli
  9. require ( ‘rucksack-css’) ----> find in broccoli
  10. require ( ‘poststylus’) ----> do not find anything in broccoli

It may sound like a strange argument, but it is true - ember uses broccoli. It would be extremely difficult to change this. So difficult that it would not make sense to use ember any more.

I very much doubt that it will change. There would have to be a lot of effort put into making the build system pluggable. And a lot of effort put into maintaining that going forward. It would not add much benefit to the ecosystem. It makes more sense to port the gulp plugins to broccoli. Writing broccoli plugins is easy and fast once you know how.

You may not like it and it may not make sense to you, but that won’t change the way it is :wink: Ember is better because of this in my opinion. Broccoli is a better build system than grunt or gulp, and rather than spending effort to make ember work with other build pipelines that don’t offer any benefit, I would prefer effort is put into making ember better in other ways that actually make real improvements to developing ember apps.

2 Likes

@alexspeller I understand your point of view. And I agree it makes a lot more sense to use Broccoli, knowing better now those points you mentioned.

My dilemma is to have more of a learning curve beyond Ember itself. I thought of using a build that I’m used to instead of having to adapt to another.

But you’re right, because I really want to use Ember. And apparently the way is to migrate the Gulp for Broccoli what already exists and create those that do not yet exist.

Anyway, thanks for listening and explanations. It is better to ask than to be with out a doubt “idiot” in the head. :joy: and this is another awesome thing about Ember community: the attention with the beginners :blush:

ember-cli can be used programmatically. We do that in my company to integrate within a bigger deployment strategy.

So AFAICT, you can write a gulp task to build your ember app.

@alexspeller I hope Ember team will recognize that tight-coupling between a framework and a build tool is an anti-pattern and a major source of frustration when using Ember in the real world.

1 Like

@johnnyshields nope, they do not recognize or agree with this AFAIK, I certainly do not. I believe it is ember’s key advantage to have a tightly coupled build tool. Obviously not everyone will agree or like that, but it is extremely unlikely ever to change.

It’s really a shame, tight-coupling has been established as a bad practice in software engineering since at least the 70’s. Open interfaces allow friendly competition to build the best tools.

I’ve resigned that I have a different philosophy than the Ember team, and would caution anyone who believes in ideas like SOLID to keep their distance from the hamster. My team is moving to React.

That’s fine - ember is an opinionated framework and if you don’t agree with its opinions, you will be much happier not using it.

That said, I strongly disagree with your architectural assessment - I understand these principles very well and I don’t believe that ember violates them in the way that you’re saying it does. The principles you mention are software engineering principles, and the reasons ember is so tightly coupled is largely ecosystem reasons - and this is great because it means the ecosystem is uniform and interoperable in a way that would not be possible otherwise.

Bear in mind, I’ve been using ember for years now. When I started, ember was not tightly coupled to a build system. Now it is. It is unequivocally better now that it is than it was before. Again, not everyone will agree, but if you don’t you’ll have a much better time using tools you do philosophically agree with.

Bear in mind, I’ve been using ember for years now.

I am a CTO who has used Ember for 3 years in an app serving thousands of B2B clients. I know a thing or two about Ember myself :slight_smile: I was also using Ember before Ember CLI, and while certainly builds were a big problem back then, IMHO Ember CLI was the wrong solution to that problem. I was advocating to use Webpack / Browserify etc. which were available at the time–and most importantly to keep the door open to other tools.

Tight-coupling is like the dark side of the force–once down that path you stray, forever dominate your destiny it will. As you note in this thread, it is now nearly impossible for Ember to move to an open build architecture and co-opt other build tools. I understand there is a perception of expediency / lower learning curve by forcing users to use a single tool, but ultimately Ember has closed a door to the broader ecosystem of tools used by other JS frameworks.

It is what it is. But its not my cup of tea. For this and other similar “philosophical differences” I will not be building future products with Ember.

@johnnyshields You may notice that other frameworks that allow you to build with any tool don’t have zero configuration addons. :slight_smile: The way things are made so that you don’t have to configure stuff is that everyone does it the same.

We’ve gotten into a lot of trouble with Ember addons such as List View which have not provided a continuous upgrade path across Ember versions (a tell-tale symptom of “tight-coupling”) or have had performance issues. We’ve now removed nearly all addons from our Ember app and moved to jQuery plugins wherever possible. jQuery plugins are portable across Javascript frameworks, Ember addons only work in Ember.

I can appreciate that many developers–especially those learning to code for the first time–will be happy to play inside Ember’s closed ecosystem. My team and I are not.