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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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 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.
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".
> 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.
"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?
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.
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 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.
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.
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.
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.
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.