Live data from Hacker News

Vite 8.0 Is Out

vite.dev

171–180 of 216 posts

Re: Vite 8.0 Is Out

#172
post #60

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.

JavaScript was not supposed to a lot of things.

Well JavaScript was supposed to be a glue between browsers and Java Applets.

Re: Vite 8.0 Is Out

#173
post #161

Earlier quoted context omitted.

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 wi…

So you have free software that requires 2 GB of RAM and the alternative is $2k per month and you're complaining that the free solution is inefficient? Really? Why do you expect to be able to replace a 2k/month solution with a $10/month VPS?

Your criticism contradicts itself.

He's saying that the software seems free, but is so inefficient that it bloats other costs to run it. And he never said he wanted to replace $2K/month with $10/month.

Re: Vite 8.0 Is Out

#174

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…

Why are electron apps memory intensive compared to other cross platform frameworks. Is it language, UI system or legacy?

Loading a browser context isn't helping.

Re: Vite 8.0 Is Out

#175

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…

> Most production software is multiple orders of magnitude slower than it needs to be.

at least 100x slower than it needs to be?

Re: Vite 8.0 Is Out

#176

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…

Why are electron apps memory intensive compared to other cross platform frameworks. Is it language, UI system or legacy?

Electron apps tend to use a lot of memory because the framework favors developer productivity and portability over runtime efficiency.

- Every Electron app ships with its own copy of Chromium (for rendering the UI) and Node.js (for system APIs). So even simple apps start with a fairly large memory footprint. It also means that electron essentially ships 2 instances of v8 engine (JIT-compiler used in Chromium and NodeJS), which just goes to show how bloated it is.

- Electron renders the UI using HTML, CSS, and JavaScript. That means the app needs a DOM tree, CSS layout engine, and the browser rendering pipeline. Native frameworks use OS widgets, which are usually lighter and use less memory.

- Lastly the problem is the modern web dev ecosystem itself; it is not just Electron that prioritises developer experience over everything else. UI frameworks like React or Vue use things like a Virtual DOM to track UI changes. This helps developers build complex UIs faster, but it adds extra memory and runtime overhead compared to simpler approaches. And obviously don't get me started on npm and node_modules.

Re: Vite 8.0 Is Out

#177
post #124

Earlier quoted context omitted.

800 lines config to compile code that's later interpreted is wild. I get the general idea behind having a script instead of a static config, so you can do some runtime config (whether or not we should have runtime changes to config is a different conversation), but this is absurd. I'm a big believer in fully reviewing all LLM generated code, but if I had to generate and review a webpack config like this, my eyes woul…

No no no, the script on the link was BEFORE llms. That was how it used to be done before. That was the recommended facebook way. The LLM generated vite config is 20 lines

Oh yeah, I got that - my comment is a bit confusing reading it back. The fact we used to built trash like that blows my mind. Makes me content having been on the backend.

Re: Vite 8.0 Is Out

#178

Earlier quoted context omitted.

It blows my mind that there is a 12m build for a JavaScript application. How may lines of code is this app?

My banking site takes 10 seconds to LOAD...I hate thinking how long it must take them to compile it

I am still trying to work out what Teams is "setting up for me" when it takes several seconds from opening the bookmark in my browser to having a UI where I can read the chats. It's running on a PC that can render complex graphical scenes in real time but it takes half a minute to see "LGTM!". (Shaking head emoji goes here.)

Then again Teams is still barely an amateur compared to the incomprehensible slowness of Jira.

Re: Vite 8.0 Is Out

#179

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…

> Most production software is multiple orders of magnitude slower than it needs to be. at least 100x slower than it needs to be?

Easily. Lots of things can take 3ms that actually take 300ms. Happens all the time.

Re: Vite 8.0 Is Out

#180
post #51

Earlier quoted context omitted.

Your complaint is with Vite – famously incredibly simple and reliable to work with – using Rust, but you're bringing up webpack's complexity? Node dependencies are fine, add an npmrc file to have it default to exact versioning and you solve 90% of common day to day problems. It's not ideal, but nor is cargo's mystery meat approach to importing optional features from packages.

My remark, and not complaint, is that the fashion to rewrite everything in Rust across the JavaScript ecosystem proves the point of holding it wrong. Maybe leave JavaScript on the browser, where it belongs.

Rewriting build time tooling to Rust is leaving Javascript on the browser?
Post reply on HN