

Fly.js: New generation build system - philbo
https://github.com/flyjs/fly

======
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.

~~~
girvo
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)!

------
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](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.

~~~
adrianpike
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?

~~~
s_kilk
It appears to be a makefile.

EDIT: or at least, for me, this yaml-formatted bash script is functionally
indistinguishable from a simple makefile.

------
_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/](http://www.commonjs.org/) [2]:
[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Statements/import)

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

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

~~~
Sanddancer
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.

~~~
madeofpalk
> 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"

~~~
webromance
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.

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

~~~
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.

~~~
striking
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.

~~~
madeofpalk
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.

~~~
mrec
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.

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

~~~
ahallock
What do you like about the JS build systems more?

~~~
mikekchar
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.

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

~~~
jsprogrammer
The version on npm is 3.9.0

~~~
latchkey
Gulp 4 is still 'beta'. That trick works with gulp 3 too though.

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

------
arxpoetica
[https://www.youtube.com/watch?v=lVXzyaovsMc](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 ;)

