3 ms·

Stopped at "Imagine you live in a world where no part of the build has to repeat unless the changes actually impacted it." because I'm already in that world by

Stopped at "Imagine you live in a world where no part of the build has to repeat unless the changes actually impacted it." because I'm already in that world by using Nx and Nx Cloud.

falcor84 3y ago
I've never heard of Nx before, but what you describe sounds like nix, and I'm confused by the name similarity, as based on their site there appears to be no relation.
- habitue 3y ago
  Nx came from the angular ecosystem, where "ng" is short for "angular". So there's no relation to nix, it's just coincidence (I use Nx at work and nix at home, and both are great in their respective domains.)
marcosdumay 3y ago
I am still convinced the author was trying to describe Make.
- shepherdjerred 3y ago
  It's similar to Make, in that you're explicitly defining dependencies and that allows caching/parallelization, but much simpler to use, and each target can define its own dependencies (e.g. some target might need Go or NodeJS)
no_wizard 3y ago
I must admit I'm a bigger fan of the wireit[0] approach, the only pause I have is its a Google project, my temptation is to fork it. The code isn't terribly complex My biggest complaint with NX is: lack of a sane API for plugins, and it has more overhead than I'd care for. For the amount of complexity that NX has, I'd rather use Rush[1] which gives you everything NX does. My only complaint with Rush is that its development is really slow going, they really need to focus up on Rush plugins (they're good, but still experimental, and I'd love to see them clean up how `autoinstalls` work to be more intutive) I'm on the fence about turbo from Vercel [0]: https://github.com/google/wireit https://github.com/google/wireit [1]: https://rushjs.io/ https://rushjs.io/
- jangoforhire 3y ago
  Curious about your thoughts on turbo?
  - no_wizard 3y ago
    From my usages with it: It worked relatively well for somethings, namely builds and focused watch mode (like running watch only on apps via the build tool, e.g. vite or webpack). I don't like that they punted their remote cache to basically be "Sign up for this vercel service or read our API contract, which BTW can change without notice". It also lacks a smart workspace watch mode, which is frustrating. This is something that wireit in particular does really well. If you look at the GitHub discussions / issues for turbo, they stated that they're effectively only going to implement a watch mode when `turbopack` is ready, because they want to integrate it into turbo in some way. I don't think I had issues with the cache otherwise. You can, for instance, just keep an artifact in your CI of the turbo cache (its a `.turbo` directory in the root of your repo) and while not shared with your local, it works fine enough. It didn't have any smart masking of logged output either, so you have to be consciously aware of what gets logged to the console. Not usually an issue, but works well enough. To be honest though, developing against apps was okay, but if you needed distributed watch mode across apps and libraries (say, a design system or something) it was awful, because turbo doesn't have its own smart dependency graph based watch mode startup, you just end up starting watch mode across all your dependencies with mixed results. For instances, it would trigger builds that could easily go stale or have issues if not built in the correct order, which you completely forgo because you have to use `--parallel`[0] to use watch mode. I also had dependency chain issues with HMR due to out of band builds happening etc. You can hack around this with things like nodemon, but its really a terrible experience. It also lacked proper support for phased commands, you had to hack it via pipelines which meant you didn't get 100% unique distributed tasks, which could become an issue with caching if you aren't aware of this. (using && in a script entry is not a substitute here, and declaring dependent pipelines felt like you were doing it wrong, not to mention, added overhead in some scenarios) All in all, it was fine, but I like the wireit model a bit better. Turbo also does nothing around module boundary enforcements. This is one thing NX and Rush do well if you use tags. wireit doesn't have this concept on a allow / deny level, but it does have it on a explicit dependency declaration level. Turbo has neither. I'm a bit wary of Vercel. They way they treat their open source projects and community feedback sometimes give me pause. I'm sure they're great people doing their best, I have concerns the same as I do with Google here. [0]: https://turbo.build/repo/docs/reference/command-line-reference/run#--parallel https://turbo.build/repo/docs/reference/command-line-referen...

Stopped at "Imagine you live in a world where no part of the build has to repeat unless the changes actually impacted it." because I'm already in that world by using Nx and Nx Cloud.

falcor84 3y ago

I've never heard of Nx before, but what you describe sounds like nix, and I'm confused by the name similarity, as based on their site there appears to be no relation.

habitue 3y ago
Nx came from the angular ecosystem, where "ng" is short for "angular". So there's no relation to nix, it's just coincidence (I use Nx at work and nix at home, and both are great in their respective domains.)

marcosdumay 3y ago

I am still convinced the author was trying to describe Make.

shepherdjerred 3y ago
It's similar to Make, in that you're explicitly defining dependencies and that allows caching/parallelization, but much simpler to use, and each target can define its own dependencies (e.g. some target might need Go or NodeJS)

no_wizard 3y ago

I must admit I'm a bigger fan of the wireit[0] approach, the only pause I have is its a Google project, my temptation is to fork it. The code isn't terribly complex My biggest complaint with NX is: lack of a sane API for plugins, and it has more overhead than I'd care for. For the amount of complexity that NX has, I'd rather use Rush[1] which gives you everything NX does. My only complaint with Rush is that its development is really slow going, they really need to focus up on Rush plugins (they're good, but still experimental, and I'd love to see them clean up how `autoinstalls` work to be more intutive) I'm on the fence about turbo from Vercel [0]: https://github.com/google/wireit https://github.com/google/wireit [1]: https://rushjs.io/ https://rushjs.io/

jangoforhire 3y ago
Curious about your thoughts on turbo?
- no_wizard 3y ago
  From my usages with it: It worked relatively well for somethings, namely builds and focused watch mode (like running watch only on apps via the build tool, e.g. vite or webpack). I don't like that they punted their remote cache to basically be "Sign up for this vercel service or read our API contract, which BTW can change without notice". It also lacks a smart workspace watch mode, which is frustrating. This is something that wireit in particular does really well. If you look at the GitHub discussions / issues for turbo, they stated that they're effectively only going to implement a watch mode when `turbopack` is ready, because they want to integrate it into turbo in some way. I don't think I had issues with the cache otherwise. You can, for instance, just keep an artifact in your CI of the turbo cache (its a `.turbo` directory in the root of your repo) and while not shared with your local, it works fine enough. It didn't have any smart masking of logged output either, so you have to be consciously aware of what gets logged to the console. Not usually an issue, but works well enough. To be honest though, developing against apps was okay, but if you needed distributed watch mode across apps and libraries (say, a design system or something) it was awful, because turbo doesn't have its own smart dependency graph based watch mode startup, you just end up starting watch mode across all your dependencies with mixed results. For instances, it would trigger builds that could easily go stale or have issues if not built in the correct order, which you completely forgo because you have to use `--parallel`[0] to use watch mode. I also had dependency chain issues with HMR due to out of band builds happening etc. You can hack around this with things like nodemon, but its really a terrible experience. It also lacked proper support for phased commands, you had to hack it via pipelines which meant you didn't get 100% unique distributed tasks, which could become an issue with caching if you aren't aware of this. (using && in a script entry is not a substitute here, and declaring dependent pipelines felt like you were doing it wrong, not to mention, added overhead in some scenarios) All in all, it was fine, but I like the wireit model a bit better. Turbo also does nothing around module boundary enforcements. This is one thing NX and Rush do well if you use tags. wireit doesn't have this concept on a allow / deny level, but it does have it on a explicit dependency declaration level. Turbo has neither. I'm a bit wary of Vercel. They way they treat their open source projects and community feedback sometimes give me pause. I'm sure they're great people doing their best, I have concerns the same as I do with Google here. [0]: https://turbo.build/repo/docs/reference/command-line-reference/run#--parallel https://turbo.build/repo/docs/reference/command-line-referen...