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.
@alexspeller Thanks for helping me again ! 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.
@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.
require ( ‘gulp concat’) ----> find in broccoli
require ( ‘gulp-group-css-media-queries’) ----> do not find anything in broccoli
require ( ‘gulp cssnano’) ----> find in broccoli
require ( ‘gulp sourcemaps’) ----> find in broccoli
require ( ‘gulp postcss’) ----> find in broccoli
require ( ‘gulp stylus’) ----> find in broccoli
require ( ‘rupture’) ----> do not find anything in broccoli
require ( ‘lost’) ----> do not find anything in broccoli
require ( ‘rucksack-css’) ----> find in broccoli
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 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.
@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. and this is another awesome thing about Ember community: the attention with the beginners
@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.
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 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. The way things are made so that you don’t have to configure stuff is that everyone does it the same.
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.