7 ms·

Vite+ – Unified toolchain for the web

109 points by sangeeth96 1y ago

rk06 1y ago
The Unified toolchain is an extremely ambitious project. when Rome announced their plan for unified toolchain, I expected it to fail as the next HN reader. and turned out to be right. Bun is also attempting it. Thye have made tremendous progress but they are also competing against node, and thus I don't expect to for bun to go mainstream. However, despite the difficulties, I strongly believe that Vite+ can achieve it. I strongly recommend all readers here to watch Vite documentary[0] that got released less than a day ago for vite's history and bacground of Vite+ [0] https://www.youtube.com/watch?v=bmWQqAKLgT4 https://www.youtube.com/watch?v=bmWQqAKLgT4
- norman784 1y ago
  Well, Rome failed because they run out of money while the project weren't finished yet. While Vite+ seems to have most of the things done already, so I'd consider it a success for now, what is left to see if that the companies using Vite already are willing to pay for Vite+.
  - pavlov 1y ago
    > "Rome failed because they run out of money" The sestertius isn't what it used to be.
  - debazel 1y ago
    Rome also failed because it was attempting to build everything (transpiler/bundler/linter/etc) from scratch. It was also unfortunately timed. When they started they were competing against webpack, but right around the start of the project compilers written in more performant languages like ESBuld and SWC start to take off and out compete Rome before it even got off the ground.
    - rk06 1y ago
      TIming was hardly an issue since they didn't produce anything important. moreover, their first focus was on formatter, which can be as low priority for any dev as it gets. Even Vite+ is focused on vite and rolldown first, and formatter last.
      - TheAlexLichter 1y ago
        And that is on purpose!
      - debazel 1y ago
        Sure, but a large part of why they never managed to produce anything useful is because SWC/ESBuild basically made the whole Rome architecture obsolete and killed all momentum around the project before they got anywhere.
        rk06 1y ago
        what has SWC has to do with thier success or failure for Rome? Rome was VC funded, afaik, turbopack still persists despite it being effectively obsolete with vite
        debazel 1y ago
        Rome was going to be a whole toolchain built completely in Javascript. That was why they started with linting and formatting because they first had to implement the Javascript language parser and AST that was going to be the core of Rome. Linting and formatting was two easy things to start with while the ironed out the parser and AST implementation. But when SWC/Esbuild came around to prove how much faster and efficient the compilation can be when written in a more performant language like Rust or Go, all hype around Rome died because no one wanted another Javascript toolchain. Turbopack is backed by Vercel who obviously have a lot more capital behind them, but it's also built on Rust and at least has the potential to compete.
yakkomajuri 1y ago
I guess this is similar to what Astral is doing on the Python side? As far as Astral goes, so far they've distributed all the tooling separately but it seems they might be going towards consolidation as well.
- yurishimo 1y ago
  The Vite tooling is also available separately and is fully MIT open source. This "package" does the dirty work of tying the separate OSS packages together into a singular CLI/GUI tool.
  - TheAlexLichter 1y ago
    + Adding a task runner with fine-grained caching (which isn't open source). All in a single dependency.
avhception 1y ago
> 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.
johnnypangs 1y ago
Ehhhhh... what does this mean for the open source versions of all these libs? You could interpret some of the graphs as vite oss isn't getting rolldown. That would be disappointing but still okay.
- whstl 1y ago
  > You could interpret some of the graphs as vite oss isn't getting rolldown Vite already has rolldown support in the current version, it's just in alpha/test stage.
  - johnnypangs 1y ago
    It seems to just be a plan at the moment although like you say you can test it out: https://vite.dev/guide/rolldown.html#how-to-try-rolldown https://vite.dev/guide/rolldown.html#how-to-try-rolldown Nothing is keeping them to this plan other though, I hope they do follow through. That would make the graph on the page misleading in the other direction though as the speed feature would be included in the non plus version. I want to also say I'm a happy vite user (and the other projects that team makes).
    - manniL 1y ago
      Nothing changes on VoidZero's commitment to open source. Vite 8 is still set to get Rolldown. I mentioned that also in my talks (e.g. https://youtu.be/fnyK-xXxVKU?t=3027 https://youtu.be/fnyK-xXxVKU?t=3027)
- yurishimo 1y ago
  Vite OSS is getting Rolldown; it will be part of Vite from version 8 onward. Rolldown itself is also 100% OSS.
bananapub 1y ago
just one more layer of tooling bro, just one more layer
- manniL 1y ago
  Nah, that's the last layer!
- Muromec 1y ago
  Its the opposite actually. Its about vertical integration of all tools and using the same foundational libraries in all of them. So its just vite calling oxlint built on oxc.
Galanwe 1y ago
I don't get it. If I'm looking for a new webdev stack, I would obviously want something free, open source. A big "Request early access" followed by a contact form at the top of the landing page is an instant redflag of vendor locking, who would ever want that?
- CaptainOfCoit 1y ago
  It's also explicitly not FOSS, "Vite+ will be source-available" it says on the page so effectively proprietary for all intents and purposes. A free pricing plan will be in place that will initially be very generous, but as time goes on and the business will need more money, it'll slowly get worse and worse. Eventually you'll need to migrate away or cough up serious money. So yeah, not sure who'd go for this.
  - Cthulhu_ 1y ago
    Enterprise support. If an enterprise can spend less time on tooling setup and maintenance they can spend more on product development. Mind you we use NX at the moment and that was quick and easy enough to set up with no major issues for years now, so I wonder what the USP of this tool is. We also use Vite in some projects in combination with NX so maybe this is mainly aimed at that.
  - Muromec 1y ago
    Oh I'm pretty sure my org will be happy to cough up the money the same way it pays for all kinds of other things supporting development. If anything, it could even save money on compute and net while doing it too. I'm concerned that it erodes trust into vite and makes all the other open source maintainers contributing to /the commons/ asking some questions. There is nothing really special about vite too. It's important, sure, but there is a lot of important open source projects that also need funding. Can all of them pull the same trick?
- manniL 1y ago
  Keep in mind that this is a super early preview. It will be source-available when stable. And it will be free for the community, while companies will have to pay.
__jonas 1y ago
I'm very happy with Vite, this toolchain on top of it looks useful too, I would have preferred all that to just be part of vite (similar to bun) but I guess there are good reasons to keep the scope of core vite smaller?
- CaptainOfCoit 1y ago
  Immediate business benefit that comes to mind is that you can make it proprietary/"source available" instead of FOSS and subsequently charge for it. You could charge for it while remaining FOSS and one big bundle in Vite, but businesses tend to prefer the first route for better or worse.
  - __jonas 1y ago
    Oh I see, I missed the pricing section at the end, that does make sense. I had assumed it would be another FOSS tool.
andai 1y ago
It works with bun and deno too. That's really cool, I've never heard of a thing that works across runtimes like that.
petesergeant 1y ago
Vite has been a joy to use. Very interested in an all-in-one solution from that team.
nunobrito 1y ago
Don't get me wrong but at this point you might as well just use Java instead of javascript to build web pages. Vite is basically replicating what one would expect as normal behaviour from the JDK + IDE has been doing since years. Javascript was meant to be readable for an open web, nowadays it is compiled into a puddle of text. It is OK to reinvent the wheel, it just doesn't look much better than the old one.
- romanovcode 1y ago
  Using Java/.NET with server side rendered HTML + webpack/react for dynamic components (which nearly are non-existent with modern CSS). Works great.
  - yurishimo 1y ago
    It entirely depends on the type of application you are building. Boring CRUD app that is rarely updated? Yea, server rendering is probably enough. But the requirements of "modern" software are always changing. Sure, the static table might be enough, but then some business person says, "It sure would be nice if I could check a little box in the table row or assign this user here..." and now you're adding little JS hacks. Again, not impossible, but at a certain scale, the ability to have infinite access to client driven reactivity becomes a real business empowerment. Given the interest in the JS working group to add reactive Signals to the core language, I suspect this will only become _more_ prevalent in the future. Maybe it will need less input from frameworks to do the same work and we can move back towards using built-in browser APIs, but the programming model itself works really well (so much so that SwiftUI uses a very similar reactive UI programming model). Again, I don't disagree with your point, just at a certain scale, it becomes a huge hassle to maintain. If people are going to use these tools and frameworks anyway, it helps the entire web to make them more efficient.
    - romanovcode 1y ago
      Hmm but that table would be actually what I would write in React most likely. Considering most tables want pagination, filtering and so on it would be dumb to use query-string params and reload the page. So this would actually fit perfectly. I have this set-up where .NET ViewHelper would do `RenderReactComponent('complexTableComponent', '.complex-table-component')` and it would load bundled react as 1st script and then this component as second script. If page does not need no react components it does not load any. If you have more than one it will still load the react itself only once. It is really amazingly working very, very well. And yes, if I would to build some kind of dashboard/email client or something I would say use React or Angular and API. But for regular website rendered HTML is king.
staticelf 1y ago
Interesting, I am a heavy user of vite today and the featureset is interesting but I don't really understand how it will differ from "normal" vite and why I would pay for it.
- rk06 1y ago
  On twitter, they said that there will be an announcement on monday. so we will find out then. previously (i.e. before current viteconf), Evan had said that existing OSS (vite and below) will remain OSS. only newer tooling will be monetised
  - staticelf 1y ago
    Well sure, but will there be incentives to keep developing and improving vite? Since they will probably want to have subscribers they will have to do a rug pull and make vite less great than they could've since that is how every saas works.
  - manniL 1y ago
    Yes, existing tools are MIT and will stay MIT. Nothing changed thre.
- Muromec 1y ago
  I was on the conference where it was announced. They plan to finish rewriting all the eslint/tsc/prettier/bundler/nx/minifier stuff in rust and give it single config instead of all of those tools having its own ast parser, alias rules and 5 incompatible babel versions. If anything, FE tooling starts looking like it moves to more sane place. Also Anthony Fu is cool
  - staticelf 1y ago
    Yes but is it worth paying a monthly subscription in order to avoid some config files? I donno. Then you will have the problem in if things go wrong or if you do something very different it's closed source so it won't be easily fixed or prioritized since there is no community.
ttoinou 1y ago
I have a hard time understanding what Vite does, so Vite+...
- whstl 1y ago
  Vite is a Javascript bundler that abstracts transpilation/typechecking/minification/hot-reloading/etc, so you don't need a 300-line hand-crafted configuration line that constantly breaks, like it was in the past with Webpack. There's still (some) configuration but much less. Vite+ is a tool similar to Rust Cargo or Go's toolchain that handles building (via Vite), testing, linting and formatting.
huflungdung 1y ago
[dead]
shreddit 1y ago
Why does you landing page download 25MB of pictures?! 92 requests 22.6 MB transferred 25.2 MB resources Finish: 9.54 s DOMContentLoaded: 290 ms Load: 9.50 s
- epolanski 1y ago
  Do as I say not as I do.
- rk06 1y ago
  because it is a landing page. why would landing page not be prioritising beauty over size. honestly my standards have taken a lot of hit these days w.r.t. page size, so i don't think it is worse than average at least the page is a work of art
hv42 1y ago
I am wondering what vite+ will have that will really make it worth it compared to the "rstack" (i.e. rspack, rsbuild, rstest, rslint, etc.) rsbuild is already excellent and things like remote cache are on their roadmap?
- thiht 1y ago
  Familiarity I guess? I've never heard of rsbuild before. In comparison, the "Vite" name directly brings me joy and makes me think of high quality, enjoyable tooling.
  - hv42 1y ago
    They seem to have less marketing for sure. If you are migrating from webpack or create-react-app, rspack/rsbuild is a no brainer. (at least worth a try IMO)
    - rk06 1y ago
      if you are heavily on custom webpack config, then rspack would be your only practical option. for all other use cases like CRA migration, vite is much better and supported option as vite unlocks entirely different migration paths for your project
- EvanYou 1y ago
  Good question. The first and most important distinction is obviously which ecosystem you are more familiar / invested in (webpack vs. vite). It does make sense for projects deeply coupled to webpack to consider rspack first. Putting that aside: - Vite+ is a commercial offering with a company that can provide paid support. Rstack is a big corp by-product where their primary customers are internal teams. - The Vite ecosystem provides way more options in choice of meta frameworks (Nuxt, Astro, React Router, Tanstack Start, SvelteKit, SolidStart...), and 3rd party tooling integrations - While both written in Rust, our tools in general perform significantly better than rstack. With the upcoming full bundle mode, Vite 8 will be at least 2x faster than rsbuild across all categories (dev server start up, HMR, production build) - Vitest and Oxlint are mature and widely used in production. rstest and rslint are both quite new and not even feature complete.
epolanski 1y ago
When do they expect to launch it?
diiiimaaaa 1y ago
I recently had to setup another complex monorepo with eslint/vitest/vite/tsup/turborepo and it was such a pain. All the time either eslint breaks for some file, or some build breaks because of some obscure thing in tsconfig, turborepo behaves in a weird way, adding new packages is a pain, etc. Hopefully Evan can pull this off and we have simpler initial setup.
game_the0ry 1y ago
I like Vite a lot, but (some feedback from the team) you need to give me more marketing up front to convince me why I would want more javascript. I already feel like I have too much. The comments here would echo the same.
- hmokiguess 1y ago
  I honestly don't understand the point you are making. What do you mean?
- Muromec 1y ago
  Its actually more rust and less js.
ochronus 1y ago
https://xkcd.com/927/ https://xkcd.com/927/
vanni 1y ago
Relevant: Vite: The Documentary https://www.youtube.com/watch?v=bmWQqAKLgT4 https://www.youtube.com/watch?v=bmWQqAKLgT4
yencabulator 1y ago
Two questions: 1. This is a Vite rugpull, right? 2. What the hell do I migrate to to avoid the rugpull, now? Lots of stuff builds on top of Vite, and this is an incredibly bad move from the Vite people.
- rasso 1y ago
  It‘s not by the vite team.
  - yencabulator 1y ago
    Looks like the same people to me: https://vite.dev/team.html https://vite.dev/team.html https://voidzero.dev/team https://voidzero.dev/team Voidzero Inc owns the Vite trademark: https://tsdr.uspto.gov/#caseNumber=98845059&caseSearchType=US_APPLICATION&caseType=DEFAULT&searchType=statusSearch https://tsdr.uspto.gov/#caseNumber=98845059&caseSearchType=U...
    - rasso 1y ago
      Oh my… thanks for the research and sorry for my lazy assumption!
- yurishimo 1y ago
  1. No, they’ve been talking about it for months publicly. 2. Nothing because Vite is OSS and this is something extra on top for managing everything else people usually use on a project. Did you watch the keynote from the conference today? The conference attended by all the people who you see as great contributors to the Vite project? They want this. This is good for the ecosystem to maintain funding as a whole.
  - yencabulator 1y ago
    Just because it's a slow motion rugpull doesn't make something not a rugpull. I did not watch any keynote and frankly place exactly 0% faith in the words of the people behind this move. The rugpulls we have seen so far have all been shady business moves mostly by dishonest people, so that is my expectation. It's like every acquisition ever, they say nice words at the time it happens, reality unfolds later: https://ourincrediblejourney.tumblr.com/ https://ourincrediblejourney.tumblr.com/ I see nothing here but yet another Open Core project that will be utterly irrelevant in 1-3 years.
cadamsdotcom 1y ago
Stick around maybe 10-20 years and then - maybe - you’ll be a contender.
jonathanhefner 1y ago
> Vite Format: "More flexible line-wrapping" I would love more information about this feature! Bad line-wrapping is the reason I loathe Prettier.
- TheAlexLichter 1y ago
  Take a look at the formatter RFC https://github.com/oxc-project/oxc/discussions/13608 https://github.com/oxc-project/oxc/discussions/13608
watty 1y ago
Not shocking, a lot of time goes into making Vite and they need to make money. One approach is to setup consulting services. Looks like Void Zero's approach is to start building value-add tools and features on top of Vite that are no longer free. The decision that users must make now is whether it's worth the risk investing in Vite, assuming that more and more functionality will move to the paid tier.
- TheAlexLichter 1y ago
  Consulting doesn't scale though and draws resources from development itself, harming both the OSS and the business side. All functionality as part of OSS projects will stay there. OSS projects such as Vite, Vitest, Rolldown and Oxc will stay open source. Eventually, the (financial) success of Vite+ is directly tied to the health, stability, and adoption of the free, open-source Vite ecosystem, so the incentive is rather low.
selectnull 1y ago
I belong to the "small business" group and as such I would be entitled to "free" plan. But, I would actually prefer to pay and have the assurance that the team will be here to maintain it. Please list the prices.
- TheAlexLichter 1y ago
  Appreciate that! Prices and details will be known closer to launch, so stay tuned

109 points by sangeeth96 1y ago

rk06 1y ago

The Unified toolchain is an extremely ambitious project. when Rome announced their plan for unified toolchain, I expected it to fail as the next HN reader. and turned out to be right. Bun is also attempting it. Thye have made tremendous progress but they are also competing against node, and thus I don't expect to for bun to go mainstream. However, despite the difficulties, I strongly believe that Vite+ can achieve it. I strongly recommend all readers here to watch Vite documentary[0] that got released less than a day ago for vite's history and bacground of Vite+ [0] https://www.youtube.com/watch?v=bmWQqAKLgT4 https://www.youtube.com/watch?v=bmWQqAKLgT4

norman784 1y ago
Well, Rome failed because they run out of money while the project weren't finished yet. While Vite+ seems to have most of the things done already, so I'd consider it a success for now, what is left to see if that the companies using Vite already are willing to pay for Vite+.
- pavlov 1y ago
  > "Rome failed because they run out of money" The sestertius isn't what it used to be.
- debazel 1y ago
  Rome also failed because it was attempting to build everything (transpiler/bundler/linter/etc) from scratch. It was also unfortunately timed. When they started they were competing against webpack, but right around the start of the project compilers written in more performant languages like ESBuld and SWC start to take off and out compete Rome before it even got off the ground.
  - rk06 1y ago
    TIming was hardly an issue since they didn't produce anything important. moreover, their first focus was on formatter, which can be as low priority for any dev as it gets. Even Vite+ is focused on vite and rolldown first, and formatter last.
    - TheAlexLichter 1y ago
      And that is on purpose!
    - debazel 1y ago
      Sure, but a large part of why they never managed to produce anything useful is because SWC/ESBuild basically made the whole Rome architecture obsolete and killed all momentum around the project before they got anywhere.
      - rk06 1y ago
        what has SWC has to do with thier success or failure for Rome? Rome was VC funded, afaik, turbopack still persists despite it being effectively obsolete with vite
        debazel 1y ago
        Rome was going to be a whole toolchain built completely in Javascript. That was why they started with linting and formatting because they first had to implement the Javascript language parser and AST that was going to be the core of Rome. Linting and formatting was two easy things to start with while the ironed out the parser and AST implementation. But when SWC/Esbuild came around to prove how much faster and efficient the compilation can be when written in a more performant language like Rust or Go, all hype around Rome died because no one wanted another Javascript toolchain. Turbopack is backed by Vercel who obviously have a lot more capital behind them, but it's also built on Rust and at least has the potential to compete.

yakkomajuri 1y ago

I guess this is similar to what Astral is doing on the Python side? As far as Astral goes, so far they've distributed all the tooling separately but it seems they might be going towards consolidation as well.

yurishimo 1y ago
The Vite tooling is also available separately and is fully MIT open source. This "package" does the dirty work of tying the separate OSS packages together into a singular CLI/GUI tool.
- TheAlexLichter 1y ago
  + Adding a task runner with fine-grained caching (which isn't open source). All in a single dependency.

avhception 1y ago

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

johnnypangs 1y ago

Ehhhhh... what does this mean for the open source versions of all these libs? You could interpret some of the graphs as vite oss isn't getting rolldown. That would be disappointing but still okay.

whstl 1y ago
> You could interpret some of the graphs as vite oss isn't getting rolldown Vite already has rolldown support in the current version, it's just in alpha/test stage.
- johnnypangs 1y ago
  It seems to just be a plan at the moment although like you say you can test it out: https://vite.dev/guide/rolldown.html#how-to-try-rolldown https://vite.dev/guide/rolldown.html#how-to-try-rolldown Nothing is keeping them to this plan other though, I hope they do follow through. That would make the graph on the page misleading in the other direction though as the speed feature would be included in the non plus version. I want to also say I'm a happy vite user (and the other projects that team makes).
  - manniL 1y ago
    Nothing changes on VoidZero's commitment to open source. Vite 8 is still set to get Rolldown. I mentioned that also in my talks (e.g. https://youtu.be/fnyK-xXxVKU?t=3027 https://youtu.be/fnyK-xXxVKU?t=3027)
yurishimo 1y ago
Vite OSS is getting Rolldown; it will be part of Vite from version 8 onward. Rolldown itself is also 100% OSS.

bananapub 1y ago

just one more layer of tooling bro, just one more layer

manniL 1y ago
Nah, that's the last layer!
Muromec 1y ago
Its the opposite actually. Its about vertical integration of all tools and using the same foundational libraries in all of them. So its just vite calling oxlint built on oxc.

Galanwe 1y ago

I don't get it. If I'm looking for a new webdev stack, I would obviously want something free, open source. A big "Request early access" followed by a contact form at the top of the landing page is an instant redflag of vendor locking, who would ever want that?

CaptainOfCoit 1y ago
It's also explicitly not FOSS, "Vite+ will be source-available" it says on the page so effectively proprietary for all intents and purposes. A free pricing plan will be in place that will initially be very generous, but as time goes on and the business will need more money, it'll slowly get worse and worse. Eventually you'll need to migrate away or cough up serious money. So yeah, not sure who'd go for this.
- Cthulhu_ 1y ago
  Enterprise support. If an enterprise can spend less time on tooling setup and maintenance they can spend more on product development. Mind you we use NX at the moment and that was quick and easy enough to set up with no major issues for years now, so I wonder what the USP of this tool is. We also use Vite in some projects in combination with NX so maybe this is mainly aimed at that.
- Muromec 1y ago
  Oh I'm pretty sure my org will be happy to cough up the money the same way it pays for all kinds of other things supporting development. If anything, it could even save money on compute and net while doing it too. I'm concerned that it erodes trust into vite and makes all the other open source maintainers contributing to /the commons/ asking some questions. There is nothing really special about vite too. It's important, sure, but there is a lot of important open source projects that also need funding. Can all of them pull the same trick?
manniL 1y ago
Keep in mind that this is a super early preview. It will be source-available when stable. And it will be free for the community, while companies will have to pay.

__jonas 1y ago

I'm very happy with Vite, this toolchain on top of it looks useful too, I would have preferred all that to just be part of vite (similar to bun) but I guess there are good reasons to keep the scope of core vite smaller?

CaptainOfCoit 1y ago
Immediate business benefit that comes to mind is that you can make it proprietary/"source available" instead of FOSS and subsequently charge for it. You could charge for it while remaining FOSS and one big bundle in Vite, but businesses tend to prefer the first route for better or worse.
- __jonas 1y ago
  Oh I see, I missed the pricing section at the end, that does make sense. I had assumed it would be another FOSS tool.

andai 1y ago

It works with bun and deno too. That's really cool, I've never heard of a thing that works across runtimes like that.

petesergeant 1y ago

Vite has been a joy to use. Very interested in an all-in-one solution from that team.

nunobrito 1y ago

Don't get me wrong but at this point you might as well just use Java instead of javascript to build web pages. Vite is basically replicating what one would expect as normal behaviour from the JDK + IDE has been doing since years. Javascript was meant to be readable for an open web, nowadays it is compiled into a puddle of text. It is OK to reinvent the wheel, it just doesn't look much better than the old one.

romanovcode 1y ago
Using Java/.NET with server side rendered HTML + webpack/react for dynamic components (which nearly are non-existent with modern CSS). Works great.
- yurishimo 1y ago
  It entirely depends on the type of application you are building. Boring CRUD app that is rarely updated? Yea, server rendering is probably enough. But the requirements of "modern" software are always changing. Sure, the static table might be enough, but then some business person says, "It sure would be nice if I could check a little box in the table row or assign this user here..." and now you're adding little JS hacks. Again, not impossible, but at a certain scale, the ability to have infinite access to client driven reactivity becomes a real business empowerment. Given the interest in the JS working group to add reactive Signals to the core language, I suspect this will only become _more_ prevalent in the future. Maybe it will need less input from frameworks to do the same work and we can move back towards using built-in browser APIs, but the programming model itself works really well (so much so that SwiftUI uses a very similar reactive UI programming model). Again, I don't disagree with your point, just at a certain scale, it becomes a huge hassle to maintain. If people are going to use these tools and frameworks anyway, it helps the entire web to make them more efficient.
  - romanovcode 1y ago
    Hmm but that table would be actually what I would write in React most likely. Considering most tables want pagination, filtering and so on it would be dumb to use query-string params and reload the page. So this would actually fit perfectly. I have this set-up where .NET ViewHelper would do `RenderReactComponent('complexTableComponent', '.complex-table-component')` and it would load bundled react as 1st script and then this component as second script. If page does not need no react components it does not load any. If you have more than one it will still load the react itself only once. It is really amazingly working very, very well. And yes, if I would to build some kind of dashboard/email client or something I would say use React or Angular and API. But for regular website rendered HTML is king.

staticelf 1y ago

Interesting, I am a heavy user of vite today and the featureset is interesting but I don't really understand how it will differ from "normal" vite and why I would pay for it.

rk06 1y ago
On twitter, they said that there will be an announcement on monday. so we will find out then. previously (i.e. before current viteconf), Evan had said that existing OSS (vite and below) will remain OSS. only newer tooling will be monetised
- staticelf 1y ago
  Well sure, but will there be incentives to keep developing and improving vite? Since they will probably want to have subscribers they will have to do a rug pull and make vite less great than they could've since that is how every saas works.
- manniL 1y ago
  Yes, existing tools are MIT and will stay MIT. Nothing changed thre.
Muromec 1y ago
I was on the conference where it was announced. They plan to finish rewriting all the eslint/tsc/prettier/bundler/nx/minifier stuff in rust and give it single config instead of all of those tools having its own ast parser, alias rules and 5 incompatible babel versions. If anything, FE tooling starts looking like it moves to more sane place. Also Anthony Fu is cool
- staticelf 1y ago
  Yes but is it worth paying a monthly subscription in order to avoid some config files? I donno. Then you will have the problem in if things go wrong or if you do something very different it's closed source so it won't be easily fixed or prioritized since there is no community.

ttoinou 1y ago

I have a hard time understanding what Vite does, so Vite+...

whstl 1y ago
Vite is a Javascript bundler that abstracts transpilation/typechecking/minification/hot-reloading/etc, so you don't need a 300-line hand-crafted configuration line that constantly breaks, like it was in the past with Webpack. There's still (some) configuration but much less. Vite+ is a tool similar to Rust Cargo or Go's toolchain that handles building (via Vite), testing, linting and formatting.

huflungdung 1y ago

[dead]

shreddit 1y ago

Why does you landing page download 25MB of pictures?! 92 requests 22.6 MB transferred 25.2 MB resources Finish: 9.54 s DOMContentLoaded: 290 ms Load: 9.50 s

epolanski 1y ago
Do as I say not as I do.
rk06 1y ago
because it is a landing page. why would landing page not be prioritising beauty over size. honestly my standards have taken a lot of hit these days w.r.t. page size, so i don't think it is worse than average at least the page is a work of art

hv42 1y ago

I am wondering what vite+ will have that will really make it worth it compared to the "rstack" (i.e. rspack, rsbuild, rstest, rslint, etc.) rsbuild is already excellent and things like remote cache are on their roadmap?

thiht 1y ago
Familiarity I guess? I've never heard of rsbuild before. In comparison, the "Vite" name directly brings me joy and makes me think of high quality, enjoyable tooling.
- hv42 1y ago
  They seem to have less marketing for sure. If you are migrating from webpack or create-react-app, rspack/rsbuild is a no brainer. (at least worth a try IMO)
  - rk06 1y ago
    if you are heavily on custom webpack config, then rspack would be your only practical option. for all other use cases like CRA migration, vite is much better and supported option as vite unlocks entirely different migration paths for your project
EvanYou 1y ago
Good question. The first and most important distinction is obviously which ecosystem you are more familiar / invested in (webpack vs. vite). It does make sense for projects deeply coupled to webpack to consider rspack first. Putting that aside: - Vite+ is a commercial offering with a company that can provide paid support. Rstack is a big corp by-product where their primary customers are internal teams. - The Vite ecosystem provides way more options in choice of meta frameworks (Nuxt, Astro, React Router, Tanstack Start, SvelteKit, SolidStart...), and 3rd party tooling integrations - While both written in Rust, our tools in general perform significantly better than rstack. With the upcoming full bundle mode, Vite 8 will be at least 2x faster than rsbuild across all categories (dev server start up, HMR, production build) - Vitest and Oxlint are mature and widely used in production. rstest and rslint are both quite new and not even feature complete.

epolanski 1y ago

When do they expect to launch it?

diiiimaaaa 1y ago

I recently had to setup another complex monorepo with eslint/vitest/vite/tsup/turborepo and it was such a pain. All the time either eslint breaks for some file, or some build breaks because of some obscure thing in tsconfig, turborepo behaves in a weird way, adding new packages is a pain, etc. Hopefully Evan can pull this off and we have simpler initial setup.

game_the0ry 1y ago

I like Vite a lot, but (some feedback from the team) you need to give me more marketing up front to convince me why I would want more javascript. I already feel like I have too much. The comments here would echo the same.

hmokiguess 1y ago
I honestly don't understand the point you are making. What do you mean?
Muromec 1y ago
Its actually more rust and less js.

ochronus 1y ago

https://xkcd.com/927/ https://xkcd.com/927/

vanni 1y ago

Relevant: Vite: The Documentary https://www.youtube.com/watch?v=bmWQqAKLgT4 https://www.youtube.com/watch?v=bmWQqAKLgT4

yencabulator 1y ago

Two questions: 1. This is a Vite rugpull, right? 2. What the hell do I migrate to to avoid the rugpull, now? Lots of stuff builds on top of Vite, and this is an incredibly bad move from the Vite people.

rasso 1y ago
It‘s not by the vite team.
- yencabulator 1y ago
  Looks like the same people to me: https://vite.dev/team.html https://vite.dev/team.html https://voidzero.dev/team https://voidzero.dev/team Voidzero Inc owns the Vite trademark: https://tsdr.uspto.gov/#caseNumber=98845059&caseSearchType=US_APPLICATION&caseType=DEFAULT&searchType=statusSearch https://tsdr.uspto.gov/#caseNumber=98845059&caseSearchType=U...
  - rasso 1y ago
    Oh my… thanks for the research and sorry for my lazy assumption!
yurishimo 1y ago
1. No, they’ve been talking about it for months publicly. 2. Nothing because Vite is OSS and this is something extra on top for managing everything else people usually use on a project. Did you watch the keynote from the conference today? The conference attended by all the people who you see as great contributors to the Vite project? They want this. This is good for the ecosystem to maintain funding as a whole.
- yencabulator 1y ago
  Just because it's a slow motion rugpull doesn't make something not a rugpull. I did not watch any keynote and frankly place exactly 0% faith in the words of the people behind this move. The rugpulls we have seen so far have all been shady business moves mostly by dishonest people, so that is my expectation. It's like every acquisition ever, they say nice words at the time it happens, reality unfolds later: https://ourincrediblejourney.tumblr.com/ https://ourincrediblejourney.tumblr.com/ I see nothing here but yet another Open Core project that will be utterly irrelevant in 1-3 years.

cadamsdotcom 1y ago

Stick around maybe 10-20 years and then - maybe - you’ll be a contender.

jonathanhefner 1y ago

> Vite Format: "More flexible line-wrapping" I would love more information about this feature! Bad line-wrapping is the reason I loathe Prettier.

TheAlexLichter 1y ago
Take a look at the formatter RFC https://github.com/oxc-project/oxc/discussions/13608 https://github.com/oxc-project/oxc/discussions/13608

watty 1y ago

Not shocking, a lot of time goes into making Vite and they need to make money. One approach is to setup consulting services. Looks like Void Zero's approach is to start building value-add tools and features on top of Vite that are no longer free. The decision that users must make now is whether it's worth the risk investing in Vite, assuming that more and more functionality will move to the paid tier.

TheAlexLichter 1y ago
Consulting doesn't scale though and draws resources from development itself, harming both the OSS and the business side. All functionality as part of OSS projects will stay there. OSS projects such as Vite, Vitest, Rolldown and Oxc will stay open source. Eventually, the (financial) success of Vite+ is directly tied to the health, stability, and adoption of the free, open-source Vite ecosystem, so the incentive is rather low.

selectnull 1y ago

I belong to the "small business" group and as such I would be entitled to "free" plan. But, I would actually prefer to pay and have the assurance that the team will be here to maintain it. Please list the prices.

TheAlexLichter 1y ago
Appreciate that! Prices and details will be known closer to launch, so stay tuned