5 ms·

> Built for growing teams tired of configuring, patching, and replacing their JavaScript tooling stack. Ah, great, another Javascript tooling stack! Let's jump

> Built for growing teams tired of configuring, patching, and replacing their JavaScript tooling stack. Ah, great, another Javascript tooling stack! Let's jump on board! I'll get straight to configuring, replacing and patching as soon as possible. Or maybe let's just don't. I'm tired, Boss.

whstl 1y ago
This cynicism is several years out of date. The current dominant toolchain has been very stable for years now, and is much better than the mess of Webpack/Rollup/Brunch/Grunt/Gulp/Bower/Browserify/Parcel/Snowpack/Turbopack/Babel/etc/etc. The only problem is that NOW there are too many separate different tools that aren't bundlers, so in addition to Vite one also has to configure Prettier, Eslint, Vitest, Typescript, Husky, Lint-Staged, Playwright, DotEnv, what else? A unified toolchain might not replace each and every tool above, but it will simplify a lot of this process. It will also simplify migrating between tools that it doesn't intend to replace, like migrating between Typescript and Typescript-Go. Etc. This is already the reality in Go, Rust and other languages.
- 0x696C6961 1y ago
  So you're saying that we finally have a semi-stable toolchain (I disagree) and the correct path forward is to change it all again? Lol I think the cynicism is very much justified.
  - debazel 1y ago
    It doesn't seem like this project is intended to replace the existing tools, but rather combine them into a more convenient bundle.
    - deleted 1y ago
      [deleted]
  - ownagefool 1y ago
    To be fair, the idea of the tools being standardized behind a single command like golang is nice, but this is largely what it all comes down to. "Vite+ will be source-available and offers a generous free tier." I'm also a developer ( sometimes ) and we need to eat. However, for me these tools are too low of a level of he stack to monetize, so I'll probably stick with my collection of free tools.
    - jansan 1y ago
      Evan You wrote on Twitter that source code will be accessible to everyone, but not under a full permissible license. He also wrote that they have no plans to sell any code licenses.
      - runako 1y ago
        > they have no plans to sell any code licenses Every for-profit is subject to being sold to someone with different plans. If the license is not fully open, it's not smart to expect the licensing terms to get worse.
        TheAlexLichter 1y ago
        Selling access isn't really helpful there. The target group (companies) have to care about licenses at some point, while it will be free for OSS, individuals and the community.
        Muromec 1y ago
        Every non-profit is subject to be neglected and overtaken by state sponsored psyops campaign from the GMT+3 timezone.
  - egorfine 1y ago
    For the web development world, the answer seems a strong yes. I remember gulp/grunt saga, I remember webpack 5 saga and the most recent pain with eslint 8 → 9 is a final nail in the coffin of anything stable for web building.
- skydhash 1y ago
  At this point, I don't want unified tools. I want stable ones. I'm fine with using a separate linter/formatter/transpiler/bundler/..., but why can't they just stay stable for a bit. The only two tools I like in the JS world is `yarn` and `prettier`. They're focused and do what they do well. But you add eslint and any of the others and their configuration is a full fledged turing machine. Even autotools feels nice in comparison to that mayhem.
  - whstl 1y ago
    What's not stable about Vite, ESLint, Typescript, Prettier? Apart from Vite itself, those have been standards for 8-10 years, and Vite itself has successfully replaced a huge mess of other tools. I agree that ESLint can become a mess, which is why I'm ok with a new competitor that doesn't require the extra configuration. Sure: they're also replacing Prettier (unnecessary) but everyone can keep using Prettier and change if Oxfmt ever becomes better. All the other tools here are either existing, or drop-in replacements.
    - boplicity 1y ago
      If I stop working on a project for 3 years, will I still be able to compile it, without losing an unpredictablt amount of time to fixing the toolchain? If not, then its not really stable, is it?
      - cowsandmilk 1y ago
        As someone who “owns” a framework at work that has been unfunded for several years, the answer is definitively yes. I haven’t touched the build toolchain in all those years and the project continues to build a dozen different JavaScript libraries with no issues across multiple Node.js upgrades. The current version of webpack was released 5 years ago. You can keep using eslint 8 which was released 4 years ago. This really isn’t the constantly changing space it was in the 2010’s
      - azangru 1y ago
        > If I stop working on a project for 3 years, will I still be able to compile it You will certainly be able to compile it. You might have hard time updating it though.
- dvt 1y ago
  > much better than the mess of Webpack/Rollup/Brunch/Grunt/Gulp/Bower/Browserify/Parcel/Snowpack/Turbopack/Babel/etc/etc. What? That mess is still ongoing. Next.js for example (probably the most popular "out of the box" solution) technically uses SWC, but not quite, because it doesn't support `styled-components` so you need to use Babel for that. But wait, you might also need to use tailwind, and for that you'll need `postcss` which might also work with Babel with `babel-plugin-import-postcss` but not necessarily, could also just use it as a Next plugin, but that doesn't always[1] seem to work. I don't think this mess will ever end unless we throw React/Vue, and all "reactive" frameworks in the dustbin and we'll get enough folks on board to re-invent the web starting from scratch. But no one really wants to do that (yet?), so even things like Bun or Deno will try to be as compatible as possible making continuous concessions that will lead to the ongoing spaghettification of toolchains. [1] https://github.com/vercel/next.js/discussions/65625 https://github.com/vercel/next.js/discussions/65625
  - whstl 1y ago
    Fine, then, I'll amend: that mess is still ongoing outside people who choose to not use this toolchain for one reason or another.
  - skydhash 1y ago
    React/Vue/Svelte/... are pretty nice ideas and the required tooling to make them work on top of CoreJS is not that extensive of an effort. The main issue is the complexity introduced by building everything and anything on top of each other as you described. In the C world, most tools are orthogonal. The compilers don't need to know about the design of the package managers and the task runners don't care about either. Yes, we have glue tooling, but that is also and external project and the dependencies are interfaces instead of monkey-patching each other.
- foresterre 1y ago
  On the other hand, with Node on the server we're now jumping into the ESM and nodenext/esnext mess with its .js imports. This less a problem when your project is on the web though, because vite (and I think under the hood esbuild) transforms the imports gracefully.
- joaohaas 1y ago
  >and is much better than the mess of Webpack/Rollup/Brunch/Grunt... You do know that Vite uses a lot of these behind the scenes right? Vite in general has much better defaults so that you don't have to configure them most of the time, but anything a bit out of the box will still require messing with the configs extensively. Not like OPs Vite+ changes anything regarding that.
  - EvanYou 1y ago
    Vite+ is built on top of the Rust stack (Rolldown / Oxc) developed by the same team and uses none of these.
  - whstl 1y ago
    Not "a lot of those". It used Rollup. And it does so transparently, while the alternative, Rolldown, was being finished. To me this sounds like a more than acceptable compromise in the interim.
    - EvanYou 1y ago
      Not even Rollup. Vite+ uses Rolldown which is also developed from the ground up by VoidZero.
- avhception 1y ago
  I'm not even a JS dev, I support the CI pipelines and Docker images and whatnot. It's something else every week. When I get it to work eventually, it's brittle as hell. I just want the madness to stop. I don't even care any more.
  - c-hendricks 1y ago
    Anecdotal, but I switched our webpack configs with vote a few years ago and haven't had to touch it since. Didn't have to touch the webpack stuff either. Perhaps the issues you're having are due to something else?
  - brightball 1y ago
    Take a look at Rails 7+. They shifted to just using import maps and abandoned the build step entirely. Simplifies everything.
    - manniL 1y ago
      They also abandoned performance!
      - brightball 1y ago
        Are there any negative performance stories that came from the move? I can't imagine any negatives outside of "1st load"?
  - Muromec 1y ago
    If you support the CI pipelines, you can put some conventions that you expect to run npm ci, npm build and then npm unit-tests-run and you don't care what they use as long as it returns without errors and puts the deployable artifact in ./dist/public/ or whereever you expect it. If you are bold enough you can ask to write makefiles too -- let them have it. Why should it even be your problem.
- YuukiRey 1y ago
  No it's not out of date. It's very much the reality. Every new tool is just one more thing added on top. When I have to do something in a JS/TS repo at work it's always a surprise which epoch of JS hype stuff I find. Today I fix ESLint warnings, tomorrow it's Biome errors, then I need to figure out how to override dependencies in pnpm, but oh no there's a some bug in Bun now. Did I forget the 10249120491412e12 config options of Jest? Ah no wait, this one is Vitest. For NextJS, do you remember the runtime used for middlewares? What was this swc thing again? It never ends. Every year new things are added and they never really replace anything, it's just one more thing to learn and maintain. If every technology causes exactly 1 issue per week then you quickly spend 50% of your time fixing bugs that have absolutely zero to do with what your company is actually doing. ---- EDIT And it doesn't even stop at issues. Every one of those technologies regularly goes through breaking changes. In the process, plugins are deprecated, new ones have completely different APIs. You want to upgrade one thing for a security fix, then you're forced to upgrade 10 other things and it spirals out of control and you've spent entire work days just sifting through change logs to change `excludeFile` to `excludedFile` to `includeGlob` to `fileFilter` to `streamBouncer` to I don't know what.
  - hombre_fatal 1y ago
    Meh, you're just describing software. Especially complex client-side software build chains. Opening up iOS or macOS app source code I haven't touched in years in the latest Xcode I just downloaded is a lot like that. There is anything from Swift errors to API changes to my build plist being invalid. And if I use any third-party tools, they probably don't work until I visit each one's latest readme. And that's without even insisting on using the latest unstable tech (bun, biome, nextjs) like you did in your comment where you would expect that experience.
  - whstl 1y ago
    If your complaint is that there are too many problems in too many different tools, then you sound like the perfect target for a UNIFIED tool that abstracts over others. Because of Vite, there was a total of ZERO work from my side involved in changing from Rollup to Rolldown, or from babel to Esbuild to SWC. The Rust/Go/uv model is the one to go. This is ONE step in this direction.
- egorfine 1y ago
  > very stable for years now Especially eslint with their decision to change configuration format in a way that breaks all and every plugin, tutorial, project in existence as a giant "fuck you" to the whole ecosystem and all web developers of the world.
  - sunaookami 1y ago
    Still on v8 and won't upgrade. I would rather switch to Biome. It's annoying investing more time into tooling than actual work.
- ifyoubuildit 1y ago
  > This cynicism is several years out of date. Jesus, it's bad enough I can't leave a js project for 6 months without it starting to rot. Now my cynicism has to be updated too?
port11 1y ago
Vite works fairly well. Most config for other tools can (should?) be left at the defaults. Jest is falling apart but Vitest works very well. We've come a long way. Now let's freeze the web for some years!

whstl 1y ago

This cynicism is several years out of date. The current dominant toolchain has been very stable for years now, and is much better than the mess of Webpack/Rollup/Brunch/Grunt/Gulp/Bower/Browserify/Parcel/Snowpack/Turbopack/Babel/etc/etc. The only problem is that NOW there are too many separate different tools that aren't bundlers, so in addition to Vite one also has to configure Prettier, Eslint, Vitest, Typescript, Husky, Lint-Staged, Playwright, DotEnv, what else? A unified toolchain might not replace each and every tool above, but it will simplify a lot of this process. It will also simplify migrating between tools that it doesn't intend to replace, like migrating between Typescript and Typescript-Go. Etc. This is already the reality in Go, Rust and other languages.

0x696C6961 1y ago
So you're saying that we finally have a semi-stable toolchain (I disagree) and the correct path forward is to change it all again? Lol I think the cynicism is very much justified.
- debazel 1y ago
  It doesn't seem like this project is intended to replace the existing tools, but rather combine them into a more convenient bundle.
  - deleted 1y ago
    [deleted]
- ownagefool 1y ago
  To be fair, the idea of the tools being standardized behind a single command like golang is nice, but this is largely what it all comes down to. "Vite+ will be source-available and offers a generous free tier." I'm also a developer ( sometimes ) and we need to eat. However, for me these tools are too low of a level of he stack to monetize, so I'll probably stick with my collection of free tools.
  - jansan 1y ago
    Evan You wrote on Twitter that source code will be accessible to everyone, but not under a full permissible license. He also wrote that they have no plans to sell any code licenses.
    - runako 1y ago
      > they have no plans to sell any code licenses Every for-profit is subject to being sold to someone with different plans. If the license is not fully open, it's not smart to expect the licensing terms to get worse.
      - TheAlexLichter 1y ago
        Selling access isn't really helpful there. The target group (companies) have to care about licenses at some point, while it will be free for OSS, individuals and the community.
      - Muromec 1y ago
        Every non-profit is subject to be neglected and overtaken by state sponsored psyops campaign from the GMT+3 timezone.
- egorfine 1y ago
  For the web development world, the answer seems a strong yes. I remember gulp/grunt saga, I remember webpack 5 saga and the most recent pain with eslint 8 → 9 is a final nail in the coffin of anything stable for web building.
skydhash 1y ago
At this point, I don't want unified tools. I want stable ones. I'm fine with using a separate linter/formatter/transpiler/bundler/..., but why can't they just stay stable for a bit. The only two tools I like in the JS world is `yarn` and `prettier`. They're focused and do what they do well. But you add eslint and any of the others and their configuration is a full fledged turing machine. Even autotools feels nice in comparison to that mayhem.
- whstl 1y ago
  What's not stable about Vite, ESLint, Typescript, Prettier? Apart from Vite itself, those have been standards for 8-10 years, and Vite itself has successfully replaced a huge mess of other tools. I agree that ESLint can become a mess, which is why I'm ok with a new competitor that doesn't require the extra configuration. Sure: they're also replacing Prettier (unnecessary) but everyone can keep using Prettier and change if Oxfmt ever becomes better. All the other tools here are either existing, or drop-in replacements.
  - boplicity 1y ago
    If I stop working on a project for 3 years, will I still be able to compile it, without losing an unpredictablt amount of time to fixing the toolchain? If not, then its not really stable, is it?
    - cowsandmilk 1y ago
      As someone who “owns” a framework at work that has been unfunded for several years, the answer is definitively yes. I haven’t touched the build toolchain in all those years and the project continues to build a dozen different JavaScript libraries with no issues across multiple Node.js upgrades. The current version of webpack was released 5 years ago. You can keep using eslint 8 which was released 4 years ago. This really isn’t the constantly changing space it was in the 2010’s
    - azangru 1y ago
      > If I stop working on a project for 3 years, will I still be able to compile it You will certainly be able to compile it. You might have hard time updating it though.
dvt 1y ago
> much better than the mess of Webpack/Rollup/Brunch/Grunt/Gulp/Bower/Browserify/Parcel/Snowpack/Turbopack/Babel/etc/etc. What? That mess is still ongoing. Next.js for example (probably the most popular "out of the box" solution) technically uses SWC, but not quite, because it doesn't support `styled-components` so you need to use Babel for that. But wait, you might also need to use tailwind, and for that you'll need `postcss` which might also work with Babel with `babel-plugin-import-postcss` but not necessarily, could also just use it as a Next plugin, but that doesn't always[1] seem to work. I don't think this mess will ever end unless we throw React/Vue, and all "reactive" frameworks in the dustbin and we'll get enough folks on board to re-invent the web starting from scratch. But no one really wants to do that (yet?), so even things like Bun or Deno will try to be as compatible as possible making continuous concessions that will lead to the ongoing spaghettification of toolchains. [1] https://github.com/vercel/next.js/discussions/65625 https://github.com/vercel/next.js/discussions/65625
- whstl 1y ago
  Fine, then, I'll amend: that mess is still ongoing outside people who choose to not use this toolchain for one reason or another.
- skydhash 1y ago
  React/Vue/Svelte/... are pretty nice ideas and the required tooling to make them work on top of CoreJS is not that extensive of an effort. The main issue is the complexity introduced by building everything and anything on top of each other as you described. In the C world, most tools are orthogonal. The compilers don't need to know about the design of the package managers and the task runners don't care about either. Yes, we have glue tooling, but that is also and external project and the dependencies are interfaces instead of monkey-patching each other.
foresterre 1y ago
On the other hand, with Node on the server we're now jumping into the ESM and nodenext/esnext mess with its .js imports. This less a problem when your project is on the web though, because vite (and I think under the hood esbuild) transforms the imports gracefully.
joaohaas 1y ago
>and is much better than the mess of Webpack/Rollup/Brunch/Grunt... You do know that Vite uses a lot of these behind the scenes right? Vite in general has much better defaults so that you don't have to configure them most of the time, but anything a bit out of the box will still require messing with the configs extensively. Not like OPs Vite+ changes anything regarding that.
- EvanYou 1y ago
  Vite+ is built on top of the Rust stack (Rolldown / Oxc) developed by the same team and uses none of these.
- whstl 1y ago
  Not "a lot of those". It used Rollup. And it does so transparently, while the alternative, Rolldown, was being finished. To me this sounds like a more than acceptable compromise in the interim.
  - EvanYou 1y ago
    Not even Rollup. Vite+ uses Rolldown which is also developed from the ground up by VoidZero.
avhception 1y ago
I'm not even a JS dev, I support the CI pipelines and Docker images and whatnot. It's something else every week. When I get it to work eventually, it's brittle as hell. I just want the madness to stop. I don't even care any more.
- c-hendricks 1y ago
  Anecdotal, but I switched our webpack configs with vote a few years ago and haven't had to touch it since. Didn't have to touch the webpack stuff either. Perhaps the issues you're having are due to something else?
- brightball 1y ago
  Take a look at Rails 7+. They shifted to just using import maps and abandoned the build step entirely. Simplifies everything.
  - manniL 1y ago
    They also abandoned performance!
    - brightball 1y ago
      Are there any negative performance stories that came from the move? I can't imagine any negatives outside of "1st load"?
- Muromec 1y ago
  If you support the CI pipelines, you can put some conventions that you expect to run npm ci, npm build and then npm unit-tests-run and you don't care what they use as long as it returns without errors and puts the deployable artifact in ./dist/public/ or whereever you expect it. If you are bold enough you can ask to write makefiles too -- let them have it. Why should it even be your problem.
YuukiRey 1y ago
No it's not out of date. It's very much the reality. Every new tool is just one more thing added on top. When I have to do something in a JS/TS repo at work it's always a surprise which epoch of JS hype stuff I find. Today I fix ESLint warnings, tomorrow it's Biome errors, then I need to figure out how to override dependencies in pnpm, but oh no there's a some bug in Bun now. Did I forget the 10249120491412e12 config options of Jest? Ah no wait, this one is Vitest. For NextJS, do you remember the runtime used for middlewares? What was this swc thing again? It never ends. Every year new things are added and they never really replace anything, it's just one more thing to learn and maintain. If every technology causes exactly 1 issue per week then you quickly spend 50% of your time fixing bugs that have absolutely zero to do with what your company is actually doing. ---- EDIT And it doesn't even stop at issues. Every one of those technologies regularly goes through breaking changes. In the process, plugins are deprecated, new ones have completely different APIs. You want to upgrade one thing for a security fix, then you're forced to upgrade 10 other things and it spirals out of control and you've spent entire work days just sifting through change logs to change `excludeFile` to `excludedFile` to `includeGlob` to `fileFilter` to `streamBouncer` to I don't know what.
- hombre_fatal 1y ago
  Meh, you're just describing software. Especially complex client-side software build chains. Opening up iOS or macOS app source code I haven't touched in years in the latest Xcode I just downloaded is a lot like that. There is anything from Swift errors to API changes to my build plist being invalid. And if I use any third-party tools, they probably don't work until I visit each one's latest readme. And that's without even insisting on using the latest unstable tech (bun, biome, nextjs) like you did in your comment where you would expect that experience.
- whstl 1y ago
  If your complaint is that there are too many problems in too many different tools, then you sound like the perfect target for a UNIFIED tool that abstracts over others. Because of Vite, there was a total of ZERO work from my side involved in changing from Rollup to Rolldown, or from babel to Esbuild to SWC. The Rust/Go/uv model is the one to go. This is ONE step in this direction.
egorfine 1y ago
> very stable for years now Especially eslint with their decision to change configuration format in a way that breaks all and every plugin, tutorial, project in existence as a giant "fuck you" to the whole ecosystem and all web developers of the world.
- sunaookami 1y ago
  Still on v8 and won't upgrade. I would rather switch to Biome. It's annoying investing more time into tooling than actual work.
ifyoubuildit 1y ago
> This cynicism is several years out of date. Jesus, it's bad enough I can't leave a js project for 6 months without it starting to rot. Now my cynicism has to be updated too?

port11 1y ago

Vite works fairly well. Most config for other tools can (should?) be left at the defaults. Jest is falling apart but Vitest works very well. We've come a long way. Now let's freeze the web for some years!