3 ms·

Inventing their own build tools instead of using a Grunt plugin seems like a severe case of NIH for ember. I'd be curious to hear their rationale beyond "the c

by ben336 13y ago

Inventing their own build tools instead of using a Grunt plugin seems like a severe case of NIH for ember. I'd be curious to hear their rationale beyond "the currently-available options all have fatal flaws that make them unpleasant to use as your app gets larger."

iamstef 13y ago
Many of us are currently using a grunt-based system, see: https://github.com/stefanpenner/ember-app-kit https://github.com/stefanpenner/ember-app-kit The need for improvements actually came out of that project, feel free to read pending issues for further context and rational.
wycats 13y ago
In general, I've come to believe that it's very easy to look at decisions as "severe cases of NIH" by looking at available tools and assuming that something must fit the bill. Especially in the young ecosystem that is JavaScript, there are often areas where the existing out-of-the-box solutions just don't satisfy the use cases of other open source projects. As Stef said, our first attempt was to build a grunt-based build solution, and it may still be possible to do so, but it wasn't as simple and drop-in as you might expect. When the work to build on top of existing solutions becomes significant, it's not longer an obvious and "severe case of NIH" to consider more home-rolling. Sometimes those home-rolled solutions even become useful for the broader ecosystem (for example, git). I don't think that Ember should build a huge, monolithic build tool system tightly coupled to Ember. We're already looking at bringing together the best in breed of existing tools and working with people who are building other tooling components that satisfy some of our needs. We absolutely plan to use bower for package management, for instance. NIH is a really easy accusation to throw out, but real life, especially with large open source projects and young ecosystems, is hardly that simple.
- ben336 13y ago
  Fair enough. I think the "tightly coupled to ember" part is what left a bad taste with me. Obviously the ember community is free to use whatever they want. But if the build tool is only useful for ember (and the "ember" name in the example cli indicates that will be the case) it seems like it might struggle longterm to keep up with grunt or other more broadly applicable build system.
  - iamstef 13y ago
    Your concern is noted, and is also a concern of ours. Rest assured the ember-cli will only be a small veneer providing a curated experience of community tools. The reason for the proposed tight coupling within the ember-cli is to ensure we can provide a stable, performant development experience.

by ben336 13y ago

iamstef 13y ago

Many of us are currently using a grunt-based system, see: https://github.com/stefanpenner/ember-app-kit https://github.com/stefanpenner/ember-app-kit The need for improvements actually came out of that project, feel free to read pending issues for further context and rational.

wycats 13y ago

In general, I've come to believe that it's very easy to look at decisions as "severe cases of NIH" by looking at available tools and assuming that something must fit the bill. Especially in the young ecosystem that is JavaScript, there are often areas where the existing out-of-the-box solutions just don't satisfy the use cases of other open source projects. As Stef said, our first attempt was to build a grunt-based build solution, and it may still be possible to do so, but it wasn't as simple and drop-in as you might expect. When the work to build on top of existing solutions becomes significant, it's not longer an obvious and "severe case of NIH" to consider more home-rolling. Sometimes those home-rolled solutions even become useful for the broader ecosystem (for example, git). I don't think that Ember should build a huge, monolithic build tool system tightly coupled to Ember. We're already looking at bringing together the best in breed of existing tools and working with people who are building other tooling components that satisfy some of our needs. We absolutely plan to use bower for package management, for instance. NIH is a really easy accusation to throw out, but real life, especially with large open source projects and young ecosystems, is hardly that simple.

ben336 13y ago
Fair enough. I think the "tightly coupled to ember" part is what left a bad taste with me. Obviously the ember community is free to use whatever they want. But if the build tool is only useful for ember (and the "ember" name in the example cli indicates that will be the case) it seems like it might struggle longterm to keep up with grunt or other more broadly applicable build system.
- iamstef 13y ago
  Your concern is noted, and is also a concern of ours. Rest assured the ember-cli will only be a small veneer providing a curated experience of community tools. The reason for the proposed tight coupling within the ember-cli is to ensure we can provide a stable, performant development experience.