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

131–140 of 216 posts

Re: Vite 8.0 Is Out

#131

Post by semiquaver »

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!

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 sane historical perspective.

Re: Vite 8.0 Is Out

#132

Post by vite_throwaway »

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 of vite and its various related tools. Luckily I found the GitHub issue and someone else had come up with the right incantation.

Now this new vite uses new tools, and their documentation is still lacking. I spent half an hour trying to figure out how vite (and related tools that I had to navigate and try to piece a coherent view of: esbuild, oxc, rolldown, etc.) might be convinced, but gave up and stayed with vite 7.

Someone could respond with a working solution and it would help, sure, but these tools sure as hell have documentation issues.

Re: Vite 8.0 Is Out

#133

Post by esafak »

jillesvangurp wrote: post #98
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!

Build performance has been a pet topic for me for quite some time when I realized I was wasting so much times waiting for stuff to build 14 years ago. The problem is especially endemic in the Java world. But also in the backend world in general. I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decad…

Kotlin compiles fast; I don't have any problems with ktor. Spring Boot and Rust do not.

Re: Vite 8.0 Is Out

#134

Post by codetantra »

CalRobert wrote: post #24
codetantra wrote: post #23

Earlier quoted context omitted.

After Tanstack Start, Next.js seems even less intuitive. While it remains a viable option due to its established momentum, it feels quite alien to backend devs, esp with its unconventional defaults.

It feels like Wordpress inasmuch as it’s shoving a tool in places that don’t make sense. React is great for SPAs but if I wanted pre-rendered static content I’d use a different tool.

If you are dealing with a static site then Astro makes more sense. Renders to just plain HTML while still allowing you to provide interactivity for part of page components using React or any framework by creating what Astro calls an island. You get best of both worlds, rich interactiveness by using JS and plain HTML/CSS where you need static.

Re: Vite 8.0 Is Out

#135

Post by rk06 »

throwaway290 wrote: post #99
rk06 wrote: post #85

Earlier quoted context omitted.

it is not. lack of plugin support is sufficient to block adoptions among other things.

but it has plugin support? what kind of plugins you mean?

look at plugin api limiation here:

https://esbuild.github.io/plugins/#svelte-plugin

esbuild's plugin support is limited which is why vite had to use rollup for prod build.

Re: Vite 8.0 Is Out

#136

Post by spiros »

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…

The solution here is working for me: https://github.com/vitejs/vite/discussions/21505

Though sometimes oxc complains about JSX in JS when running vite, but it still works fine.

Re: Vite 8.0 Is Out

#137

Post by shimman »

semiquaver wrote: post #131
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!

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…

Something I realized while doing more political campaign work is how inefficient most self hosted solutions are. Things like plausible or umami (analytics) require at least 2 gigs of ram, postiz (scheduled social media planner) requires 2 gigs of ram, etc.

It all slowly adds up where you think a simple $10 VPS with 2 gigs of ram is enough but it's not, especially if you want a team of 10-30ish to work sporadically within the same box.

There can be a lot of major wins by rewriting these programs in more efficient languages like Go or Rust. It would make self hosting more maintainable and break away from the consulting class that often has worse solutions at way higher prices (for an example, one consulting group sells software similar to postiz but for $2k/month).

Re: Vite 8.0 Is Out

#139

Post by awongh »

semiquaver wrote: post #131
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!

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, that inefficency might not matter that much.

Another aspect is that the devices get cheaper and faster so today's slow electron app might run fine on a system that is a few years away, and that capacity was never going to be taken up by anything else on the end user's device.

Post reply on HN