Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 10 15:47
    Zadvornyi opened #13
  • Jul 07 18:28
    ianwalter synchronize #43
  • Jun 22 13:04
    jorgebucaran edited #44
  • Jun 22 13:04
    jorgebucaran opened #44
  • Jun 13 01:45
    ianwalter edited #43
  • Jun 13 01:44
    ianwalter opened #43
  • Jun 04 20:03
    ianwalter opened #42
  • May 24 00:16
    jorgebucaran closed #36
  • May 23 19:20
    barissenkal synchronize #36
  • May 22 13:13
    barissenkal opened #36
  • Apr 07 16:18
    jorgebucaran closed #35
  • Apr 07 13:30
    ManuCart opened #35
  • Feb 15 04:37
    jorgebucaran closed #33
  • Feb 15 04:37
    jorgebucaran deleted #10
  • Feb 14 09:35
    jorgebucaran edited #37
  • Jan 22 07:08
    jorgebucaran closed #34
  • Dec 29 2018 04:18
    jorgebucaran deleted #33
  • Dec 29 2018 04:18
    jorgebucaran deleted #21
  • Dec 29 2018 04:18
    jorgebucaran deleted #17
  • Dec 29 2018 04:18
    jorgebucaran deleted #6
Sylvain Pollet-Villard
@sylvainpolletvillard
compatibiity with colleagues node version is not a problem, we have the engines parameter in package.json
I'm not sure to understand why a Flyfile has to be written in the same language than Fly itself
Sylvain Pollet-Villard
@sylvainpolletvillard
Does that mean that when async functions will be natively supported on the latest Node.js, it still won't work on basic fly ?
Luke Edwards
@lukeed
no
it will
Babel / fly-esnext ONLY compiles es6/7 code that isn't supported
of course you can use Node v6 now and not worry about any of this
but a lot of people don't know or understand that
as fo now, Fly still support node 0.12
and that's why Fly & Fly-esnext are separate
ONLY have the user who still want es6 (and don't support it natively) download Babel
for everyone else, there's no need
if you're using a node version that natively supports async or whatever else you want to use, then great
i dont see what the problem is then
if you don't support async or whatever natively, then do use fly-esnext
that's why it's separated
because the Babel dependency is totally useless..... EXCEPT for people who need it
Luke Edwards
@lukeed
fly will be fully functional out of the box, regardless of what you natively support & that's all that matters
Sylvain Pollet-Villard
@sylvainpolletvillard
now I understand your move, even if I found a bit pessimistic the assumption that most people don't know what is supported by their current Node version and what features can be transpiled
Luke Edwards
@lukeed
you'd be surprised :/ most of my node-project issues are because people don't fully know the full capabilities and limitations of their environments
Luke Edwards
@lukeed
i certainly dont
nothing wrong with it. don't think anyone can really know the full extent of anything; especially given the complexity of node
Sylvain Pollet-Villard
@sylvainpolletvillard
I know, but we're dealing with this problem on browsers for years and the situation is not so bad. At least Node is the only platform to support for server-side JS.
plus you get a start up crash when using async or yield on old Node versions. Its not that hard to figure out whats going on.
anyway, I'm okay with fly-esnext, I just got confused by fly readme
Sylvain Pollet-Villard
@sylvainpolletvillard
and once again, why generators arent ES6 ?
Luke Edwards
@lukeed
@sylvainpolletvillard they were introduced n V8 are not not EcmaScript specific
only additional syntax was bundled into es2015 for generators
Sylvain Pollet-Villard
@sylvainpolletvillard
right, but ES6 is the first specification mentionning them. I think its confusing to put them under "ES5 version"
Jorge Bucaran
@bucaran
At the beginning of Fly, we could choose between generators, async/await or plain old ES5. What changed ?
This is not 100% accurate.
In the beginning, fly was written heavily relying in es6 features, compiled into vanilla es5 by babel
generators wer and are still used to implement fly internally
and flyfiles were and are still written using generators
what changed internally was that we are not using babel anymore
@sylvainpolletvillard What was the confusing part?
Was it "ES2015 and beyond" ?
Luke Edwards
@lukeed
@brj I think it's the Readme example using generators
He doesnt like that it's using generators and labeled as es5
Sylvain Pollet-Villard
@sylvainpolletvillard
right, I got confused when it was specifically asked to write flyfiles in "native ES5". I thought it was some kind of limitation in the flyfile parser, but actually there is none and we can totally write flyfiles in ES6 if we use Node 6.
I think it would be clearer to describe "fly-esnext" as "fly + babel" instead of sticking to ES versions, so that the documentation is still relevant when Node LTS will have 100% ES6 support
Jorge Bucaran
@bucaran
Ah, gotcha. Yeah, I see the problem.
The original flyfiles were written in ES5 syntax, but using generators, since that was a feature that could be enabled with the --harmony flag.
I don't think this is a big deal anyway.
Luke Edwards
@lukeed
nope
i'm working on fly stuff now... ill put a little note in there about node 6 & v8 environment capabilities
Jorge Bucaran
@bucaran
Hi @/all! I've created a Slack channel for Fly! https://flyjs.herokuapp.com
Everyone is invited :airplane:
Cheers!
Luke Edwards
@lukeed
:clap: All chat & support is migrating to Slack. If you find that your post here is silent, it's because we're there :wink: :star2: