[flagged]
Vite 8.0 Is Out
171–180 of 216 posts
Re: Vite 8.0 Is Out
#172Earlier 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.
Re: Vite 8.0 Is Out
#173Earlier 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?
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
#174Earlier 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?
Re: Vite 8.0 Is Out
#175Yeah, 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…
at least 100x slower than it needs to be?
Re: Vite 8.0 Is Out
#176Earlier 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?
- 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
#177Earlier 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
Re: Vite 8.0 Is Out
#178Earlier 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
Then again Teams is still barely an amateur compared to the incomprehensible slowness of Jira.
Re: Vite 8.0 Is Out
#179Earlier 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?
Re: Vite 8.0 Is Out
#180Earlier 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.