Live data from Hacker News

Vite+ Beta

voidzero.dev

151–160 of 163 posts

Re: Vite+ Beta

#151

I appreciate the effort to bring things together in this but… > Vite+ will manage your global Node.js runtime and package manager. What? Why? You’re really going all-in if you adopt this; and… for what? A bit of cozy tooling around existing standard ways of doing things? Ok, sure; I like tools, like vite. …but even for an opinionated tool, this is extraordinarily opinionated. Like next.js Im skeptical. The pitch of b…

Seen this play out again and again: a tool becomes popular, starts incorporating other tools, including mananging language runtime versions. It wants to become the entire platform, to do everything with this one tool. After people get hooked and adapt their workflows to depend on it, inevitably it starts to enshittify. Repeat cycle with new tool.

Re: Vite+ Beta

#153

Can it be used for Node builds or browser-only same as Vite?

I'm always curious of the use case when someone proposes Node code bundling. What's the advantage? Obfuscation in SEA?

In my case, for my fullstack framework, I used vite on the server to add my own vite plugin, which can cut client-only code from server code. But it was really needed only when I use my framework with Vite. For example, if we use it with a clean bun setup, then I can do it with bun runtime plugins, which also allow me to modify code on the fly and do it really faster than vite. So I want to say that in server js code we may use vite to modify code during the dev/build process, and I have no idea what else we can use vite for in server/cli code

Re: Vite+ Beta

#154
post #124

Earlier quoted context omitted.

Yes, it's not boring if it's the new hotness

Okay, then how can something become boring? It needs to start as the new hotness? Does that imply that the people who use non-boring software are the ones who determine which things get to graduate to being boring?

Yeah, boring implies that it is predictable, proven and mostly unchanging. In software those almost always come with age.

Re: Vite+ Beta

#155

Earlier quoted context omitted.

Making all this (for example) work nicely together can be tricky: Vite, ESLint, Prettier, Typescript and React, especially if it's full stack with SSR. If you only focus on the front-end and remove Typescript from the equation it becomes easy enough. We'll have to see if Vite+ helps for the more complex cases.

Making all this (for example) work nicely together can be tricky: Vite, ESLint, Prettier, Typescript and React, especially if it's full stack with SSR. Although about 98%* of that is because ESLint keeps making breaking changes and getting everything else to work compatibly with ESLint requires 27,573* additional dependencies. Things I work on have been moving over to Biome recently (mostly these are Vue projects rat…

Lots of breaking changes but I like where they landed, the config file is now clearly an mjs, no longer a hidden file, allows JSX without a plugin. I reckon the best way to upgrade is to generate a new project that has everything configured and copy that and stay close to defaults unless there's a good reason not to.

Re: Vite+ Beta

#156
post #97

Earlier quoted context omitted.

I don't get how a test runner can be "ultra fast". Surely all the time is taken by the tests, not calling the test functions?

You'd be surprised https://github.com/artemave/node-test-runners-performance-co...

I expected Bun to be among the fastest and yes, I was not surprised.

Re: Vite+ Beta

#157
post #77

I am a big fan of Vite. But I have zero clue what those other tools are. I swear to God, I just put my head down to do some work and all the sudden, frontend tooling has evolved. I wonder if there is a push towards a "boring but works" stack.

I'm currently experimenting with a stack combining assistance, ASP.NET Razor Pages, and htmx, specifically to avoid dealing with the complexities of the modern frontend stack. AI eliminates a lot of the tedium, grinding tasks, while HTML partials and htmx complement each other perfectly. Not having to manage frontend framework, SSR states is incredibly liberating. Sprinkle in some vanillla js and redraw specific part…

You're on a good path.

While consulting, I have seen .NET + htmx in production, but it was an internal tool used by thousands of folks (HR system).

The 1ms response times and quick browser rendering due to no JS bloat put a smile on my face.

I have since been planning to give C# backend + htmx frontend a go for a CRUD demo.

Re: Vite+ Beta

#158

I appreciate the effort to bring things together in this but… > Vite+ will manage your global Node.js runtime and package manager. What? Why? You’re really going all-in if you adopt this; and… for what? A bit of cozy tooling around existing standard ways of doing things? Ok, sure; I like tools, like vite. …but even for an opinionated tool, this is extraordinarily opinionated. Like next.js Im skeptical. The pitch of b…

Seen this play out again and again: a tool becomes popular, starts incorporating other tools, including mananging language runtime versions. It wants to become the entire platform, to do everything with this one tool. After people get hooked and adapt their workflows to depend on it, inevitably it starts to enshittify. Repeat cycle with new tool.

That is one thing that makes me at least afraid of being too dependent of the uv in Python.

Re: Vite+ Beta

#159

Earlier quoted context omitted.

I went from 4 to 8 in a single step. I had to change 5 lines of config. Can we please stop the incessant belly-aching over problems that don't exist. I have to question if you even use these tools?

I'm glad that your trivial migration was trivial. All this was a big source of churn for plugins and frameworks: https://github.com/vitejs/vite/discussions/16358

All those APIs at that point were marked as experimental, and this is the place where things were ironed out. Churn should be expected when using an experimental API.
Post reply on HN