Hacker News Reader

> Flow, introduced 3 months after TypeScript

Do you think Flow was built in 3 months as a reaction to Typescript? Not that it was a big enough problem that two different groups of people independently decided to try to solve it? EDIT: disregard this, Flow was introduced much longer than 3 months after TypeScript. The blog post introducing Flow mentions TypeScript, and is probably worth reading for background [1]

> Nuclide instead of Atom/Sublime/VSCode

Nuclide is an Atom plugin.

> Jest instead of Jasmine/Mocha

Jest provides a superset of Jasmine functionality, and uses Jasmine as its test runner.

[1] https://code.facebook.com/posts/1505962329687926/flow-a-new-...

> Do you think Flow was built in 3 months as a reaction to Typescript?

They probably knew that TS was in progress when they started, but I don't have a window into that. I did ask some Flow devs a few weeks ago if they are interested in merging with TS, and they answered with a categorical no.

I can't speak for either project, but personally I would say that I don't think static typing in JS is a solved problem, and at this stage to me it seems a monoculture would be much less fruitful than a competition of ideas.

I would agree if they were at all different, but they seem to be syntactically and functionally identical.

As a caveat, I am a daily TS user, and have only played around with Flow.

I am not a computer scientist, but I have heard people repeatedly argue that Flow sets out to create a "sound type system" which TS intentionally does not.

What this means in practice I don't fully understand but it seems to result in enough architectural differences that it apparently makes sense to have both despite the superficial similarities in syntax and behaviour.

I think the issue is that TS is non-modular and dictates javascripts reach. It behaves like no other tool and blocks others from working. Take something like React/Redux for instance, which are built around modern day javascript, but if you transpile any example on the official Redux page right now you will see TS bail out because it can't understand some of the syntax.

Flow on the other hand solves one problem and solves it well. It behaves as any other tool would.

Not sure I understand. Can you give a concrete example?

You can only do as much as TS allows you to, unless you route through babel in a second pass. TS is a tool that controls to which extend you can use language features that are drafted. They do pick drafts here and there, but others they omitt, object spread for instance which is very common for Redux.

As i said, try to transpile this in TS: http://redux.js.org/docs/basics/ExampleTodoList.html

This is why they made Flow.

Still not sure I understand. All the code in that link is valid TS - TS is just a superset of JS.

Object spread is not part of the ES7 spec. It is a proposal which has not made it to stage 3 yet, and might still be dropped. That said, there is a TS issue tracking adding support for it: https://github.com/Microsoft/TypeScript/issues/2103.

TypeScript was released October 1, 2012. Flow was released November 18, 2014

Did Flow take 2 years to get implemented? I didn't think the initial release looked like a project that had 2 years of dev time on it.

Whoops, my mistake. I don't know enough about the history of Flow to comment further.

Hey, I work on Yarn and Jest. Let me respond to why we built Jest: It solves a ton of problems no other test runner solves and it works well at Facebook's scale. We open sourced it more than two years ago but only recently started to promote the project in open source more actively because it is working so well at FB.

If you are curious to find out more about why we built it, please read our blog posts, beginning with one about testing performance and our unique constraints at FB: http://facebook.github.io/jest/blog/2016/03/11/javascript-un...

Finally, test runners tend to get stale. Any large organization will run into trouble with any kind of tooling as companies scale up engineers or codebases. Testing is no different and we aimed to solve those problems for Facebook; getting to open source our solutions is an added bonus and we are excited to work with the JS community to build the best tooling we can possibly build.

I for one am thankful for Jest and Yarn. I recently switched over to Jest and I love most everything about it and the built in watch with caching reduces friction immensely (now if we can just allow custom preprocessors to return promises that would make life easier for integration of things like rollup). And yesterday I flipped over to using yarn and it definitely solves most of my pain points with npm.

So yeah, I'm definitely on the "keep reinventing" side of this debate.

IMO it's the "javascript way" to invent new tools instead of trying to improve others (when it makes sense to do so).

Let me explain that a little bit... The javascript "ecosystem" takes the unix philosophy to the extreme in many ways. And one of the points of the unix philosophy is to try to avoid "bloating" tools with tons of options, and instead trying to create new tools where appropriate.

Many of those are perfect examples of where "improving" a current tool with the changes they wanted would end up with a more complicated and difficult to use tool.

- NPM makes tradeoffs that the majority of developers in the JS world want right now. Like it or not, deterministic installs isn't something that most people want or need (at least, they don't know that they might want or need it). Making a new tool that anyone can use when that is needed is a great solution, and it avoids bloating NPM with a hundred little flags and tons of code to cover edge cases. It's the perfect example because anyone can switch to using yarn when it's needed without any extra work.

- Nuclide is actually just a layer on top of Atom. They wanted a bunch of things to all work one way, so rather than try to get Atom to change to include what they wanted, or require developers install a ton of extensions, they packaged them up on top of Atom as one system.

- Jest had different goals at the start. Testing react components was ugly and difficult, and Jest wanted to solve that first (IIRC, i'm not very familiar with jest unfortunately). Again, it's something that can be used if needed, and can even be combined with other testing tools if you want (we almost did that at my work, used Jest to test the front-end components, and our current mocha+friends setup to test the "business logic").

> The javascript "ecosystem" takes the unix philosophy to the extreme in many ways.

Bullshit, nix systems rely on stable global dependencies, not 50 versions of the same library installed locally. I don't buy the "unix philosophy" excuse. The nodejs community just doesn't care about API stability which is why there is that inflated number of modules with 90% never maintained more than a year.

Come on now, I said that it's like the unix philosophy in many ways, not that it's unix...

- Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

Which is what this thread is about.

- Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

JS has wonderful stream support, and it's used everywhere in many tools. This is probably where JS is the weakest out of these.

- Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

I mean, if JS isn't this taken to the extreme, i don't know what is...

- Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

This also describes JS to a T. Tons and tons of tools, each often only usable by a small number of people in niche situations.

Now i'm not saying that JS is as well designed as unix, i'm not saying that it's exactly the same as unix, i'm not saying that Unix doesn't do things better, or that JS doesn't have it's warts. I'm just saying that it's the "unix philosophy" taken to the extreme. It might not be good, it might not last, but it's working out pretty well for many people right now.

> 50 versions of the same library installed locally

Are you seriously telling me you've never had a linker (static or dynamic) choose the wrong library?

+1 for contribution to npm. Especially given npm isn't completely deterministic there is no reason for not pushing for these changes into npm itself.

Given npms years of crap I'm ready to give it a shot anyway. This might be one of FB's projects that actually gets some traction, especially given its developed in collaboration with other big names.

When you're game changer, it's hard to make current projects maintainers nod their head for you!!! I think io.js was a good example.