Fly.js: New generation build system

[girvo]

While I love the idea, seeing `fly-*` packages makes me sad, although I understand the reasoning. Grunt had the same problem, and Gulp does to some extent, however Browserify and Gulp had the right idea where they allow you to use the direct Browserify package without requiring a wrapper. Those wrappers lag behind the actual library typically, and have their own quirks and debugging which is too much congnitive overhead at times.

That said, this is really interesting way of tackling a build system. I love the use of `exports` and generators make a lot of sense for this sort of control flow; I wrote a "block" system for Wordpress that used generators to allow you to render the blocks in a loop inside a template, pause execution of said loop and render more of the template, then continue on. Basically insertion points for completely dynamic layout and contents.

[bucaran]

@girvo

I am sorry I missed this post.

You are not required to create packages to use Fly! You can simply pass your transformer function to `Fly.prototype.filter` and be done with it. I think plugins should be true thin wrappers to whatever utilities you are trying to incorporate into your build task.

Compare this to gulp where you sometimes need to use vinyl and other abstractions, plus stream wrappers and other deps.

[jack_jennings]

Say what you will about the usefulness or redundancy of yet another build system, I really enjoy the way the succession of JavaScript solutions have explored different means of control flow.

I'll upvote this mostly for the clever use of exports and (ab)use of generators.

[kevin_kroe]

can you upvote me? i do clever usage of basic OS and node.js environment.

my build system does the same as that Flyfile and add source maps to my coffee files, looks like this: http://pastebin.com/BtegzqVX

You could argue my polvo.yml file has more lines in it and it's less customisable compared to a script, but still i believe my .yml config is very organised and i can hook up any script to happen afterwards by appending a line to my beautiful makefile.

Not to say, with the "setup" target you could even install node.js or fly or whatever you need before even being able to execute fly.

[bucaran]

@jack_jennings

Thanks! I agree with you. I understand the opinion of the person below, but I think there is room for improvement in this area so I am trying to make the build system the JavaScript community really deserves.

[_greim_]

I'm glad people are pushing the envelope on JS build tooling, and not giving in to the "we need to freeze the toolspace now" contingent. I feel like the mainstream build tools have been interesting, but nobody has got it all figured out yet.

One question, if this is ES6, then why:

    exports.foo = function* () {}

...instead of:

    export function* foo() {}

?

[robinricard]

The first snippet uses the CommonJS [1] standard (a way to import packages into a JS file that is used by Node, webpack or browserify for example).

The second snippet uses ES6 modules [2]. Babel actually transpiles those ES6 modules into CommonJS modules when used in a Node.js environment (which is the case with a build tool).

Since even IO.js doesn't support ES6 modules for now and you're likely to use a build tool in order to use babel, you shouldn't use ES6 modules in a build file.

[1]: http://www.commonjs.org/ [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[kevrom]

Doing the latter would require you to use something like babel-node, whereas the former is all available without any such wrapper/compiling.

[bucaran]

The folks below already gave you the answer, but we are considering adding support for Flyfiles written in ES6 now. It's intrusive and opinionated, and although one of the reasons I like auto loading plugins is so that Flyfiles end up looking as agnostic as possible despite using ES5, I think it would be awesome to have ES6 Flyfiles.

[tomcam]

Not trying to sound like a stick in the mud, since my need for Javascript build systems is modest and currently satisfied by make (think Bootstrap, jquery, uglify). After all, dependency management is a deep problem.

What is the primary advantage over make? I imagine it looks much easier to read for a novice than make, but there are probably much better reasons than this one.

[kevin_kroe]

i also use make, it fits really well with coffee/stylus/jade + zsh/iterm2|tmux stack...

anything different than this seems to become very messy super fast, specially compared to make files

not to say, using identantion kills a lot of stuff people use this days, like js linters and whatnot.

not saying this tools are not useful in specific circumstances, which i can happily say i never faced.

*with a "setup" target you could even install node.js or fly or whatever you need before even being able to execute fly.

[bucaran]

Innovation fosters more innovation. We are trying to improve status quo. Even if this initiative fails, it may spark the right idea on the next person.

Fly tasks are co-routine-wrapped generators, so you get modern async flow inside your tasks out of the box and right off the bat.

TBH I don't know exactly how Fly is better than make since I don't use make since college years.

[AdrianRossouw]

since i switched to using webpack for bundling, i've pretty much stopped using gulp/grunt completely.

I just found there's very little I needed them for that couldn't be resolved using a makefile or package.json scripts.

I legitimately love gulp though, because it finally let me grok streams.

[woah]

Having used gulp and grunt, I just use shell scripts now. Why bother?

[keedot]

Ideally, as a means of abstracting and controlling changes between your build and deploy steps and the third party tooling. Bash scripts are either too fragile for sufficiently complex applications, and therefore unlikely to be reusable. Additionally, if the script is sufficiently complex, then you have an additional complex component that you have to maintain yourself. For many projects, this is a non-issue, but for others, it can be quite the ordeal.

[bucaran]

Because shell scripts are more complex to write. I, myself, having used grunt and then switched to gulp, ended up favoring shell scripts / npm scripts, only to realize gets much more complex for larger projects. I think a build system abstraction is legit, and Fly is pushing the status quo to an even simpler, thinner, yet flexible alternative.

[espadrine]

Sometimes, the hassle of allowing developers to work on it from Windows is worth the grunts.

Also, plugins. Arguably, shell scripts are also a plugin ecosystem. Perhaps a less convenient one, it's hard to say from my perspective. It's definitely hard to find versionned coffeescript bash files.

That said, wouldn't it be wonderful if Windows had bash built-in?

[striking]

Cool, but how does this meaningfully expand on the JavaScript ecosystem? Or more succinctly, "Why not Grunt?" What features does this provide to differentiate itself from other, similar tools?

People have already gotten tired of the JavaScript framework/build system/distribution tool bang. Improvements need to be more than incremental before people will choose to learn new APIs and be able to find new package ecosystems.

[keedot]

Grunt is as elegant as a penguin on land, and about as fast. My gulpfile is a fraction of the size of my gruntfile, and executes much quicker. Gulp has some control flow edges, and requires some workarounds that can make it tedious to maintain when you get into edge cases. Broccoli is ideal, but too difficult for all my team member to understand (and was still a tad flakey when I last used it).

I like to play with new ideas, and some of them don't end up hitting critical mass, but I appreciate their creation all the same. Often, they cause me to reconsider approaches I've taken on other projects.

I'm starting a new project tonight and will give this a go. It may not work, and all I've lost is a few hours. Creation for creation sake is what we should be about. Not everything should be about differentiators, and productivity gains. Sometimes, it's far more rewarding to just create, or to use someone else's creation. Almost every painting I have ever seen did nothing to differentiate itself in style, but I'm glad every single last one of them was painted.

[prezjordan]

You should be comparing this to gulp, which, like fly, prefers code over configuration.

Gulp uses streams, this uses generators. Some folks may like the look and feel of generators more than streams.

[twerkmonsta]

Yeah, cool logo, but this is almost exactly like Gulp.

The first thing I want to see on the project page is something like "Why you should use this new tool over existing proven build systems with already flourishing ecosystems".

[_greim_]

> how does this meaningfully expand on the JavaScript ecosystem

Moving from callback-based programming to generators + promises is like going from burning logs in dirt pits to gas stovetops. A build tool that incorporates it successfully deserves a hard look, at least.

[tobico]

"Fly is a build system for Node based in ES6 generators and promises that aims to be simple and elegant to write and extend"

If an objective is for it to be simple to write and extend, why use two shiny new features that most programmers will be unfamiliar or inexperienced with?

[sanderjd]

The theory is that those shiny new features are simple to write and extend, regardless of most programmers' familiarity or experience with them. I don't necessarily agree with that theory in this case, but familiarity is too often conflated with simplicity, when in reality there is a more nuanced interaction between the two.

[ahallock]

I wonder sometimes what it would be like if we didn't keep re-inventing things. Other than portability, why are any of these better than a Makefile? Most of these tools have a corresponding bin command you can run in a Make task.

[pbiggar]

I guess we'd be stuck with Make. I can't say how happy I am that that isn't the case.

[wildpeaks]

It might be worth mentioning that Gulp 4 can use ES6 if the config file is named "gulpfile.babel.js".

[bcrn]

You can use Fly with ES6 too if you would like. Another difference is, Fly itself is written in ES6, in a very functional style, with a small dependency footprint and a tiny code base. Its implementation is based in promise sequences and co-routines (the same library that powers Koa.js) giving you co-routine async flow (async/await style) support out of the box.

[jsprogrammer]

The version on npm is 3.9.0

[alessioalex]

So this is next generation only because it uses generators instead of callbacks?

[arxpoetica]

https://www.youtube.com/watch?v=lVXzyaovsMc It is over.

[aikah]

Working with Javascript as become heavier,slower and more complicated than Java. Sure you can automate code compilation(because that's what it is), but you still end up with grunt/gulp/fly builds that takes a minute or more... not really a write/refresh workflow and it doesn't make it more enjoyable than working with compiled language X or Z.

[emsy]

Usually the tools I use have finished execution (triggered by a save) before I even left the editor. It's much better in practice than it sounds in theory.

[sudeepj]

Wondering what would be the status message when the build fails: "Your fly is open" :o)

[circlingthesun]

Here we go again..

[zensavona]

This looks super slick. Very edgy javascript build tool ;)