Live data from Hacker News

Vite+ Beta

voidzero.dev

161–163 of 163 posts

Re: Vite+ Beta

#161
post #32

Earlier quoted context omitted.

I am actually pushing our frontend devs to remove more and more dependencies and leverage LLMs to just write the code instead of all the dumbass packages in hellscape of supply chain attacks via node/npm.

You are signing up for another hellscape of unmaintainable slop. Enable package cooldowns and only whitelist internal packages and you are better off than 90%

"Unmaintanable" by who? Vite is on its n-th major revision, yet as a user none of my pain points have been addressed and god-knows-what has been added. If that's "maintenance", I don't want it, because what I need out of Vite is trivially replaced. It's the same for most other dependencies. I need a particularly problem solved, but along with a dependency come the authors who, having solved the problem, continue to invent new problems, because they are emotionally invested in their work. I don't begrudge that, but there is a conflict of interest here.

Re: Vite+ Beta

#162

I have removed vite because dev build and reload is noticable slower than just esbuild and browser refresh. Vite does nothing for me that an LLM can not just trivially rebuild in a bespoke manner. YMMV

How do you bundle web workers that import dependencies? iirc the issue in esbuild for that is still open and users are manually building their workers as separate entry points, which is very fragile.

I build them as separate entry points. And to be clear, esbuild doesn't do everything for me, but the solution is bespoke script, not the whole of something like Vite.

Re: Vite+ Beta

#163
post #46

Earlier quoted context omitted.

I'm not very familiar with Rust, but doesn't cargo pull a lot of external dependencies for most projects? I really like how Go can do everything with just the standard library, but I wasn't aware Rust was similar. For typescript we've moved our stuff to bun. It has it's own risk management perspective compared to node, but at least it's now possible to build web services without having to rely on a bunch of external…

> without having to rely on a bunch of external dependencies. Which in our highly regulated business would require security policies for each dependency explaining the risks, why we accept them and how we mitigate them. How about the dependencies Bun is pulling? How did you ever managed to pass security policies with Bun which has so many segfaults that nobody even bothers to write CVEs for them.

> How about the dependencies Bun is pulling?

What dependencies? OpenSSL, libc or?

> segfaults

Those would not be a compliance issue though.

Post reply on HN