Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vite 8.0 Is Out

vite.dev

Post reply on HN
Print view View original

151–160 of 216 posts

Re: Vite 8.0 Is Out

#151

Post by vite_throwaway »

iainmerrick wrote: post #143
vite_throwaway wrote: post #132

I have a small React project using vite 7 and have the following in my config so that vite interprets ".js" files as JSX: // See https://github.com/vitejs/vite/discussions/14652 esbuild: { loader: "jsx", include: /.*\.jsx?$/, exclude: [], }, optimizeDeps: { esbuildOptions: { loader: { ".js": "jsx", }, }, }, Note the comment at the top. I had no idea how to come up with this config by checking the documentation pages…

Sorry if this comes across as overly facetious — I’m sure you have a reason for doing it that way! — but would it not be easier just to bow to convention and rename your .js files to .jsx?

Probably. It's just that I've always used .js for my projects (decades). Such a rename would likely result in configuration changes to the other tools I use, but indeed they are better documented. When faced with a multiplicity of conventions I pick one and stick to it; the tools are flexible enough to work with it I'm sure, the real issue is of discoverability.

Re: Vite 8.0 Is Out

#152

Post by upsuper »

I contributed this change in Vite 8:

> Wasm SSR support: .wasm?init imports now work in SSR environments, expanding Vite's WebAssembly feature to server-side rendering.

While the process was relatively slow, I really appreciate the extra effort that the team have put on even this minor feature add. They not only guided me towards more compatible and idiomatic approach, but also added docs and helped keeping the code up to date before merging.

Re: Vite 8.0 Is Out

#153

Post by xxpor »

Zopieux wrote: post #100
raydenvm wrote: post #80

Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take." We planned our work around it, joked about creating breaks, and built entire caching layers to work around it. Kudos to the Vite maintainers!

I wonder what will be the parallel hindsight about waste, but for matrix multiplications, in a few years.

The economic incentives line up much better there. You charge for tokens -> cost is GPUs -> you work very hard to keep GPUs utilized 100% and get max tokens out of those cycles.

Compare this to essentially any modern business app, the product being sold has very little relationship with CPU cycles, or the CPU cycles are SO cheap relative to what you're getting paid, no one cares to optimize.

Re: Vite 8.0 Is Out

#154

Post by useftmly »

lioeters wrote: post #146
useftmly wrote: post #140

[flagged]

That's the boat I'm in with several static sites, from tens to hundreds of pages, build on Next.js and stuck a few major versions behind because I didn't have the motivation to upgrade them. One of these days I'll roll up my sleeves and convert them to Vite, and finally be free of that awful framework.

[flagged]

Re: Vite 8.0 Is Out

#155

Post by BoorishBears »

littlecranky67 wrote: post #67
gherkinnn wrote: post #26

Earlier quoted context omitted.

It's the Vercel way to first run broken previews for several years. Next started with Turbopack alpha as a Webpack alternative in Next 13 (October 2022) and finally marked Turbopack as stable and default in Next 16 (October 2025). They also ran sketchy benchmarks against Vite back in 2022 [0]. Next's caching has a terrible history [1], it is demonstrably slow [2] (HN discussion [3]), RSCs had glaring security holes […

Any suggestions to replace NextJS when you only use static export (no SSR)?

I'm surprised anyone's using Next for static exports when they've left dynamic paths broken for years.

I recently migrated to Tanstack for this and confirm it's been strictly better so far, especially having dynamic paths in my use-case (makes a hybrid app much more realistic)

Re: Vite 8.0 Is Out

#156

Post by BoorishBears »

robertlagrant wrote: post #86
drawfloat wrote: post #46

Earlier quoted context omitted.

Vercel has slowly taken over Facebook's position as being the employer of the main developers of React. There's a debate to be had over how much they 'control' it or not, but the fact create-next-app is the first recommended option on the official installation page now does show it's had an impact. 5 or so years ago, Next was a pretty solid option to quickly build up a non SPA, when combined with the static export fu…

I'm trying to build a nextjs app and it's quite painful. It seems to be more and more focused on SSR, which I don't care about (looking for a static app that calls separate API endpoints). That would have been fine in the NextJS I remember from a few years ago, where static and SSR seemed equally viable, but I can't be bothered now. I'm going to try Tanstack Start.

99% of what you see with the word "server" vs "client" is actually orthogonal to SSR is that wasn't clear.

The React team (really Vercel + Shopify) decided to use the supremely misleading names "Server Component" and "Client Component" for two things that do not affect CSR vs SSR.

Even if you label the root of your app "use client" (thus opting out of all the new complexity around RSC and server actions), it's still getting rendered server side.

Re: Vite 8.0 Is Out

#157

Post by BoorishBears »

Griffinsauce wrote: post #35
flowerbreeze wrote: post #28

Earlier quoted context omitted.

I'm being rather snarky here, but the main point of front-end JS UI frameworks is to exist and to survive in their environment. For this purpose they have evolved to form a parasymbiotic relationship with others in their environment, for example with influencers. The frameworks with the best influencers win out over older ones that do not have the novelty value anymore and fail to attract the best influencers.

This could also apply to the recent wave of hate towards Next.

My 10 minute Next build was replaced with a 1 minute 30 second Vite build.

And such an extrodinary different is usually holding the tool wrong, but Next has years old open issues for many of the causes here (like forced output tracing) and has just ignored them. Possibly because the Next team's preferred deployment environment isn't affected?

Re: Vite 8.0 Is Out

#158

Post by skydhash »

awongh wrote: post #139
semiquaver wrote: post #131

Earlier quoted context omitted.

The waste of slow JS bundles is nothing compared to the cost of bloated interpreted runtimes or inefficient abstractions. Most production software is multiple orders of magnitude slower than it needs to be. Just look at all the electron apps that use multiple GB of ram doing nothing and are laggier than similar software written 40 years ago despite having access to an incredibly luxurious amount of resources from any…

I guess there's the distinction between capacity that could be taken up by other things, and free capacity that doesn't necessarily cost anything. For a server built in the cloud those cycles could actually be taken up by other things, freeing the system and bringing costs down. For a client computer running electron, as long as the user doesn't have so many electro apps open that their computer slows down noticeably…

It’s more likely that Electron app uses poor code and have supply chain issue (npm,…). Also loading a whole web engine in memory is not cheap. The space could have been used to cache files, but it’s not, which is inneficient especially when laptops’ uptime is generally higher.

Re: Vite 8.0 Is Out

#159

Post by bovermyer »

upsuper wrote: post #152

I contributed this change in Vite 8: > Wasm SSR support: .wasm?init imports now work in SSR environments, expanding Vite's WebAssembly feature to server-side rendering. While the process was relatively slow, I really appreciate the extra effort that the team have put on even this minor feature add. They not only guided me towards more compatible and idiomatic approach, but also added docs and helped keeping the code…

This is a fun insight, thank you for sharing that!

I like Vite as a tool, but knowing that the Vite folks actually care about helping others learn and contribute is awesome.

Re: Vite 8.0 Is Out

#160

Post by jhgb »

mexicocitinluez wrote: post #109
vbezhenar wrote: post #53

Earlier quoted context omitted.

It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me. Web development should strive to launch unchanged sources in the browser. TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.

> It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me. You're not actually suggesting that technology can't evolve are you? Especially one whose original design goals were to process basic forms and are now being used to build full-blown apps? It's absolutely wild to me that with everything that has happened in the last 2 decades with regard to the web th…

If you want to make ultra-complicated clients, I assume that's what WebAssembly is heading towards. And it doesn't limit you to a poorly evolved language that wasn't intended for ultra-complicated software in the first place, or even force you to use that poorly evolved language on a server if you need to run the same logic in both places.
Post reply on HN