Fly.js: New generation build system(github.com)
github.com
Fly.js: New generation build system
https://github.com/flyjs/fly
16 comments
@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.
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.
Thanks for the update bucaran! If that's the case, I'm definitely going to dive deep in it; that's exactly what I've been hoping for in a next-gen build-tool (WebPack just doesn't do it for me)!
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.
I'll upvote this mostly for the clever use of exports and (ab)use of generators.
@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.
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.
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.
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.
Maybe share a little more? From what I see, it's basically a YAML-formatted bash script, but I suspect there's more to it, right?
It appears to be a makefile.
EDIT: or at least, for me, this yaml-formatted bash script is functionally indistinguishable from a simple makefile.
EDIT: or at least, for me, this yaml-formatted bash script is functionally indistinguishable from a simple makefile.
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:
One question, if this is ES6, then why:
exports.foo = function* () {}
export function* foo() {}
?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.
Doing the latter would require you to use something like babel-node, whereas the former is all available without any such wrapper/compiling.
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...
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...
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.
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.
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.
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.
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.
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.
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.
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.
Having used gulp and grunt, I just use shell scripts now. Why bother?
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.
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.
Who said anything about bash scripts? There are other shell scripts in the sea. Also, shell scripting is much more universal, so you can use the same infrastructure to manage your web servers, your database servers, etc. A language-specific build system means that when you need to start adding components made in other languages, you need to reinvent a lot more tooling that should have been universal to begin with.
> Who said anything about bash scripts? There are other shell scripts in the sea. Also, shell scripting is much more universal[...]
I guess it depends a lot on your infra, but wouldn't (ba)sh be the most universal shell? so if shell = bash, then "shell script" = "bash script"
I guess it depends a lot on your infra, but wouldn't (ba)sh be the most universal shell? so if shell = bash, then "shell script" = "bash script"
It would. I use fish shell here, yet I prefer writing my build tasks with plain JavaScript. Fly seems to be a thin abstraction to accomplish the same. Now, the most striking advantage is support for generators/co-routine style for async stuff and also promises right from the get go.
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?
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?
Every Windows developer who has git also has bash installed. Because of that, most simple .sh build scripts tend to work fine on Windows these days.
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.
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.
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.
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.
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.
Gulp uses streams, this uses generators. Some folks may like the look and feel of generators more than streams.
The point I'm trying to make is: Gulp and Grunt exist, and have strong ecosystems. It's cool that this uses a swanky new ES6 feature. But is that really a big enough step up, that people should stop using what they're using and use this instead?
If it came with a set of modules for other packages so people could at the very least try the demo version before they buy into it, and it really is that much cleaner and more powerful, then I think people could really get behind it.
The trick to making a successful JS package nowadays is marketing, honestly.
If it came with a set of modules for other packages so people could at the very least try the demo version before they buy into it, and it really is that much cleaner and more powerful, then I think people could really get behind it.
The trick to making a successful JS package nowadays is marketing, honestly.
Grunt existed when gulp was new, and it had a pretty strong ecosystem. Gulp was an alternate that solved the same problem in a different way, and it got pretty popular. Because of it, the next version of Grunt is totally different and uses ideas from Gulp.
I find it disappointing how some people have such an allergic reaction to others trying something new. If you don't like it, don't use it.
I find it disappointing how some people have such an allergic reaction to others trying something new. If you don't like it, don't use it.
I don't think he's allergic to others trying something new, I think he's just saying that the most important information for them to provide when doing so is "how is my approach different to/better than the existing tools?"
Which is a valid point, IMO. When there already multiple widely-used tools that do X, marketing your new tool as "Does X!!!" isn't very compelling in itself.
Which is a valid point, IMO. When there already multiple widely-used tools that do X, marketing your new tool as "Does X!!!" isn't very compelling in itself.
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".
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".
> 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.
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.
"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?
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?
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.
[deleted]
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.
I guess we'd be stuck with Make. I can't say how happy I am that that isn't the case.
What do you like about the JS build systems more?
I think it's pretty similar to why people use autoconf, Cmake or the like. If you are building something of any real size or complexity, with a lot of 3rd party dependencies, then maintaining makefiles is a serious PITA (and I say that as someone who has used make extensively in their career).
So why not use autoconf or Cmake, then? Well, why would I want to write and maintain scripts in M4 when I can do it in javascript (the language I'm actually programming in)? And again you get into the configuration vs code question. Why should I rely on configurations files and learning how a complex tool works when I can write what I want to do in a scripting language (not-so-coincidentally the language I'm actually programming in)?
In fact, in our shop for various projects we use makefiles, shell scripts, rake and gulp/webpack. It's nice to use a tool that is set up for the idiosynchracies of the language you're programming in. We could make do with just one (probably rake since we do mostly ruby coding), but I can tell you with certainty that it would be more work than the varied ecosystem that we have.
So why not use autoconf or Cmake, then? Well, why would I want to write and maintain scripts in M4 when I can do it in javascript (the language I'm actually programming in)? And again you get into the configuration vs code question. Why should I rely on configurations files and learning how a complex tool works when I can write what I want to do in a scripting language (not-so-coincidentally the language I'm actually programming in)?
In fact, in our shop for various projects we use makefiles, shell scripts, rake and gulp/webpack. It's nice to use a tool that is set up for the idiosynchracies of the language you're programming in. We could make do with just one (probably rake since we do mostly ruby coding), but I can tell you with certainty that it would be more work than the varied ecosystem that we have.
1) They run on Windows without going to a malware site.
2) They do not contain shell-specific code like Makefiles with a bunch of bashisms in them.
2) They do not contain shell-specific code like Makefiles with a bunch of bashisms in them.
I haven't used any JS build system. I'm just glad I don't have to work with Make.
I'm also reacting to the idea that staying with existing tools is a good idea. People make new tools to solve new problems. And Make has a ton of problems.
I'm also reacting to the idea that staying with existing tools is a good idea. People make new tools to solve new problems. And Make has a ton of problems.
It might be worth mentioning that Gulp 4 can use ES6 if the config file is named "gulpfile.babel.js".
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.
The version on npm is 3.9.0
Gulp 4 is still 'beta'. That trick works with gulp 3 too though.
So this is next generation only because it uses generators instead of callbacks?
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.
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.
Wondering what would be the status message when the build fails: "Your fly is open" :o)
Here we go again..
This looks super slick. Very edgy javascript build tool ;)
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.