5 ms·

> There are a lot of JS tools, but none of them do what we want. We’re trying to coordinate them. We want to provide a good default experience out of the box,

> There are a lot of JS tools, but none of them do what we want. We’re trying to coordinate them. We want to provide a good default experience out of the box, so we’re building a CLI to: scaffold, skeleton files, set up build, set up testing environment, possibly even deployment Was there something wrong with the yeoman & grunt/gulp combo? The yeoman tool is great for the scaffolding and skeleton story, and even for setting up your build, test, deployment environments using whatever combination of grunt & gulp you want to build into your generator. I'm starting to get weary of this constant need to reinvent the incredible tools that we have already instead of iterating and improving them.

sehr 12y ago
We’re working with the Ember CLI team who are extracting reusable bits. Working with Joe from broccoli and reusing those bits. Current changing the Angular build from gulp to broccoli. Working with the NPM team on package management and resolution. The package managers that exist today aren’t good, but NPM is the closest of all of them. Sounds like they're doing exactly that!
- dpritchett 12y ago
  I wish they'd gotten Jo's name right. Luckily her work speaks for itself.
mixonic 12y ago
Yeoman, Grunt, and Gulp are (I believe) all various implementations of a task runner. They chain tasks in different ways, but at the end of the day think of your asset build as a set of discrete steps. Broccoli (https://github.com/broccolijs/broccoli https://github.com/broccolijs/broccoli), the build tool written by Jo Liss and supported by the Ember community, is truly an asset pipeline tool. It is concerned with transformations to filesystems and file contents, not tasks. This makes Broccoli a faster and easier to use tool for implementing complex asset pipelines. The main domain object is "trees". A tree represents a directory hierarchy of files that will be regenerated on each build. Broccoli uses directories of symlinks in tmp/ to cache un-changed files from step to step, allowing it to restart a build at any depth and only process those files that change. Some links you might enjoy on Broccoli: * http://aexmachina.info/intro-to-broccoli/ http://aexmachina.info/intro-to-broccoli/ * http://moduscreate.com/better-builds-begin-with-broccoli/ http://moduscreate.com/better-builds-begin-with-broccoli/ * http://hashrocket.com/blog/posts/broccoli-the-build-tool-not-the-vegetable http://hashrocket.com/blog/posts/broccoli-the-build-tool-not... (how Broccoli is used in Ember-CLI) I can't speak to the weariness, but I can say that Broccoli is completely unlike Grunt, Gulp, or Yeoman and without it (or something like it) Ember-CLI and the next generation of build tools would be impossible. Broccoli has been in development since fall of 2013, and been used aggressively by Ember-CLI users since summer 2014. Give it a look!
- abritishguy 12y ago
  Yeoman is for scaffolding
- andrewstuart2 12y ago
  Grunt and gulp are task runners, yeoman is a scaffolding tool that does exactly that, and all the generators I've used and written will scaffold out Grunt or Gulp tasks which take care of the build/test/deploy story. Usually with live-reload and filesystem watches for autoupdate.
- pfooti 12y ago
  In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing. In a way, it makes a lot of sense that broccoli is part of the Ember-CLI system - I found broccoli to be the most opinionated of the runners. As long as your structure mapped easily onto the opinions of broccoli, things were easy and speedy. If you want to do something not supported, or customize how things work, not so much. As an example, I submitted a PR to configure where and how broccoli stores its temp directory structure a year ago (./tmp wasn't right for my project), which is still open (and admittedly wasn't the most elegant solution). Gulp and Grunt, on the other hand, make far fewer assumptions, provide very little in the way of out-of-the-box "just works", and are far more easy to tweak. In my own experience, my issue was getting certain cat/minify/sort processes to work in broccoli (to deal with angular module declaration ordering) was annoyingly complex enough that I just moved to gulp where it was easier (and someone else had already written a gulp plugin).
  - woah 12y ago
    I used to be really into gulp, until I discovered that I could replace my entire gulp file with a 1 line shell script in package.json
    - contrahax 12y ago
      If you can do it in one line of shell then do it - you don't need a build system. I don't understand why everyone sees it as a competition - just use the right tool for the problem you need to solve.
adambratt 12y ago
The problem is that a lot of these js tools that are being built are being built on top of other hobbyist js libraries that are built on top of others that creates this weird chain of dependency that appears to arise from nothing other than the author's coding style preference. Take a look at just one of gulp's dependencies (and arguably one of the most important) vinyl-fs which it uses for file watching. This is the actual chain of abstractions for the file watching functionality in gulp. vinyl-fs < glob-watcher < gaze < graceful-fs * gulp.watch uses vfs.watch provided by vinyl-fs * vfs.watch is actually just glob-watcher (lol) * glob-watcher is a simple 20 line wrapper around gaze watch * gaze uses graceful-fs to watch full paths 4 levels of library abstraction for file watching. Something that the built-in fs.watch handles natively. Here's the actual description of the gaze library "A globbing fs.watch wrapper built from the best parts of other fine watch libs." Yet apparently that wasn't enough as the gulp authors had to toss in 2 more layers on top of it. And at the end of the day gulp still sucks for watching files on linux. I understand that there are other pieces of vfs that are being used by gulp...but it still doesn't make any sense to me how there can be SOOO many accepted libraries dealing with just file watching. And instead of making a pull request for new features on existing libraries, developers are just building other libraries around them to do what they want. There's so much fragmentation in the JS world and no one can seem to ever agree to work together on anything. In comparison, in the Python world there's pretty much one agreed upon library for something like file watching "watchdog". There are alternatives but it stands out above all the rest.
- contrahax 12y ago
  fs.watch actually doesn't work just fine, not sure what gave you that impression. We went with the best file watcher that was around at the time because we didn't feel the need to write our own. The layers of abstraction are there so other people can make use of them as modules. We are (and have been) evaluating other solutions for file watching but gaze is still the best option for us to use under the hood.
  - thealphanerd 12y ago
    I've been stuck in file watching hell before... CHOKIDAR!!!!! I actually had a really interesting conversation with Bert Belder about some of the lower level problem with file watching. It came up that perhaps there could be a working group around fixing this issue.

sehr 12y ago

We’re working with the Ember CLI team who are extracting reusable bits. Working with Joe from broccoli and reusing those bits. Current changing the Angular build from gulp to broccoli. Working with the NPM team on package management and resolution. The package managers that exist today aren’t good, but NPM is the closest of all of them. Sounds like they're doing exactly that!

dpritchett 12y ago
I wish they'd gotten Jo's name right. Luckily her work speaks for itself.

mixonic 12y ago

Yeoman, Grunt, and Gulp are (I believe) all various implementations of a task runner. They chain tasks in different ways, but at the end of the day think of your asset build as a set of discrete steps. Broccoli (https://github.com/broccolijs/broccoli https://github.com/broccolijs/broccoli), the build tool written by Jo Liss and supported by the Ember community, is truly an asset pipeline tool. It is concerned with transformations to filesystems and file contents, not tasks. This makes Broccoli a faster and easier to use tool for implementing complex asset pipelines. The main domain object is "trees". A tree represents a directory hierarchy of files that will be regenerated on each build. Broccoli uses directories of symlinks in tmp/ to cache un-changed files from step to step, allowing it to restart a build at any depth and only process those files that change. Some links you might enjoy on Broccoli: * http://aexmachina.info/intro-to-broccoli/ http://aexmachina.info/intro-to-broccoli/ * http://moduscreate.com/better-builds-begin-with-broccoli/ http://moduscreate.com/better-builds-begin-with-broccoli/ * http://hashrocket.com/blog/posts/broccoli-the-build-tool-not-the-vegetable http://hashrocket.com/blog/posts/broccoli-the-build-tool-not... (how Broccoli is used in Ember-CLI) I can't speak to the weariness, but I can say that Broccoli is completely unlike Grunt, Gulp, or Yeoman and without it (or something like it) Ember-CLI and the next generation of build tools would be impossible. Broccoli has been in development since fall of 2013, and been used aggressively by Ember-CLI users since summer 2014. Give it a look!

abritishguy 12y ago
Yeoman is for scaffolding
andrewstuart2 12y ago
Grunt and gulp are task runners, yeoman is a scaffolding tool that does exactly that, and all the generators I've used and written will scaffold out Grunt or Gulp tasks which take care of the build/test/deploy story. Usually with live-reload and filesystem watches for autoupdate.
pfooti 12y ago
In my experience using grunt, gulp and broccoli as task runner / build systems for complex applications, they all end up doing about the same thing. In a way, it makes a lot of sense that broccoli is part of the Ember-CLI system - I found broccoli to be the most opinionated of the runners. As long as your structure mapped easily onto the opinions of broccoli, things were easy and speedy. If you want to do something not supported, or customize how things work, not so much. As an example, I submitted a PR to configure where and how broccoli stores its temp directory structure a year ago (./tmp wasn't right for my project), which is still open (and admittedly wasn't the most elegant solution). Gulp and Grunt, on the other hand, make far fewer assumptions, provide very little in the way of out-of-the-box "just works", and are far more easy to tweak. In my own experience, my issue was getting certain cat/minify/sort processes to work in broccoli (to deal with angular module declaration ordering) was annoyingly complex enough that I just moved to gulp where it was easier (and someone else had already written a gulp plugin).
- woah 12y ago
  I used to be really into gulp, until I discovered that I could replace my entire gulp file with a 1 line shell script in package.json
  - contrahax 12y ago
    If you can do it in one line of shell then do it - you don't need a build system. I don't understand why everyone sees it as a competition - just use the right tool for the problem you need to solve.

adambratt 12y ago

The problem is that a lot of these js tools that are being built are being built on top of other hobbyist js libraries that are built on top of others that creates this weird chain of dependency that appears to arise from nothing other than the author's coding style preference. Take a look at just one of gulp's dependencies (and arguably one of the most important) vinyl-fs which it uses for file watching. This is the actual chain of abstractions for the file watching functionality in gulp. vinyl-fs < glob-watcher < gaze < graceful-fs * gulp.watch uses vfs.watch provided by vinyl-fs * vfs.watch is actually just glob-watcher (lol) * glob-watcher is a simple 20 line wrapper around gaze watch * gaze uses graceful-fs to watch full paths 4 levels of library abstraction for file watching. Something that the built-in fs.watch handles natively. Here's the actual description of the gaze library "A globbing fs.watch wrapper built from the best parts of other fine watch libs." Yet apparently that wasn't enough as the gulp authors had to toss in 2 more layers on top of it. And at the end of the day gulp still sucks for watching files on linux. I understand that there are other pieces of vfs that are being used by gulp...but it still doesn't make any sense to me how there can be SOOO many accepted libraries dealing with just file watching. And instead of making a pull request for new features on existing libraries, developers are just building other libraries around them to do what they want. There's so much fragmentation in the JS world and no one can seem to ever agree to work together on anything. In comparison, in the Python world there's pretty much one agreed upon library for something like file watching "watchdog". There are alternatives but it stands out above all the rest.

contrahax 12y ago
fs.watch actually doesn't work just fine, not sure what gave you that impression. We went with the best file watcher that was around at the time because we didn't feel the need to write our own. The layers of abstraction are there so other people can make use of them as modules. We are (and have been) evaluating other solutions for file watching but gaze is still the best option for us to use under the hood.
- thealphanerd 12y ago
  I've been stuck in file watching hell before... CHOKIDAR!!!!! I actually had a really interesting conversation with Bert Belder about some of the lower level problem with file watching. It came up that perhaps there could be a working group around fixing this issue.