5 ms·

I use JS+Node+NPM for my day job and many side projects. Initial thoughts: - Why didn't Facebook contribute the updates to NPM directly? - They are coupling

by bcherny 10y ago

I use JS+Node+NPM for my day job and many side projects. Initial thoughts: - Why didn't Facebook contribute the updates to NPM directly? - They are coupling a package manager and registry proxy; the latter has many existing implementations already - The differenced between Yarn and NPM+Shrinkwrap do not seem substantive; NPM made the design decision to use a sometimes non-deterministic install algo in NPM3 to speed up install times - when network is involved, there is a serious trade off between idempotency and speed In general, FB seems to love building their own versions of existing tools: - Flow, introduced 3 months after TypeScript - Nuclide instead of Atom/Sublime/VSCode - Jest instead of Jasmine/Mocha - DraftJS instead of (insert of of the existing 100 text editors here) - ... I get that these are useful internally at FB, but I don't think they help the community much. It would be better to work with existing tools and contribute back to them than to reinvent the wheel every time something doesn't work perfectly for their use case. I get that FB uses these as recruiting tools, it's useful for them to have rights for these projects, and it gives their engineers something to do and be excited about, but I do not want a whole dev tool ecosystem controlled by big FB. Also, I find IED's approach to speeding up builds far more novel and interesting - https://github.com/alexanderGugel/ied https://github.com/alexanderGugel/ied

Klathmon 10y ago
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").
- deleted 10y ago
  [deleted]
- aikah 10y ago
  > 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.
  - Klathmon 10y ago
    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.
  - GFK_of_xmaspast 10y ago
    > 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?
mambodog 10y ago
> 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-static-type-checker-for-javascript/ https://code.facebook.com/posts/1505962329687926/flow-a-new-...
- bcherny 10y ago
  > 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.
  - mambodog 10y ago
    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.
    - bcherny 10y ago
      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.
      - pluma 10y ago
        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.
smrtinsert 10y ago
+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.
KayL 10y ago
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.
cpojer 10y ago
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-unit-testing-performance.html 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.
- jbondeson 10y ago
  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.

by bcherny 10y ago

Klathmon 10y ago

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

deleted 10y ago
[deleted]
aikah 10y ago
> 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.
- Klathmon 10y ago
  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.
- GFK_of_xmaspast 10y ago
  > 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?

mambodog 10y ago

> 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-static-type-checker-for-javascript/ https://code.facebook.com/posts/1505962329687926/flow-a-new-...

bcherny 10y ago
> 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.
- mambodog 10y ago
  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.
  - bcherny 10y ago
    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.
    - pluma 10y ago
      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.

smrtinsert 10y ago

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

KayL 10y ago

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.

cpojer 10y ago

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-unit-testing-performance.html 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.

jbondeson 10y ago
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.