Live data from Hacker News

Vite 3.0

vitejs.dev

111–120 of 202 posts

Re: Vite 3.0

#111
post #94

I can't keep up with this stuff anymore. As a former "full stack" dev, I just quit the frontend part altogether and I'm now just focusing on the backend. It's just too much and changing too fast.

Our frontend is mostly class-based react components compiled with webpack 4 and babel 6 (for context: those are old versions). and guess what? it all just works. new 3rd party components also just work. adding modern hooks-based functional components just works. and everything that worked 5 years ago still just works. I think the JS our tooling emits is backward compatible with IE9 and up, which is ridiculous and was…

> just don't upgrade random tooling all the time and you're good.

Good luck with that in the NPM ecosystem

Re: Vite 3.0

#112

Earlier quoted context omitted.

1. I upgraded a huge application from Vite 2 to Vite 3 with literally no change. 2. Nobody forces you to upgrade, that's how semver works.

1) If it didn't break backwards compat why did it bump the major version? 2) Constantly pushing major versions in order to ignore backwards compatibility and pass that problem on to consumers might not break semver but you're still wasting my time by expecting me to clean up your mess if I choose to depend on your library. (Which I won't) Or are you suggesting vite will backport security patches indefinitely?

It broke backwards compatibility in the sense that the minimum NodeJS version was incremented.

Re: Vite 3.0

#113

I tried using ESBuild directly for a small web app and it seems pretty nice. What would using Vite on top of it give me?

I was curious as well. I think this answers the question: https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil... > While esbuild is blazing fast and is already a very capable bundler for libraries, some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling. For the time being, Rollup is more mature and flexible in these regards.…

Code splitting is supported just fine for ESM bundles[1] (and there is little reason to use other formats nowadays), CSS handling works ok as well. I have been using ESBuild since forever and the only instability that I experienced was around sourcemap generation early on.

[1] https://esbuild.github.io/api/#splitting

Re: Vite 3.0

#116

Earlier quoted context omitted.

Our frontend is mostly class-based react components compiled with webpack 4 and babel 6 (for context: those are old versions). and guess what? it all just works. new 3rd party components also just work. adding modern hooks-based functional components just works. and everything that worked 5 years ago still just works. I think the JS our tooling emits is backward compatible with IE9 and up, which is ridiculous and was…

> just don't upgrade random tooling all the time and you're good. Good luck with that in the NPM ecosystem

Why so?

Re: Vite 3.0

#117
post #30

Earlier quoted context omitted.

Vite is framework agnostic. Framework specific work is spearheaded by framework specific community or core authors in some cases (solid, astro) React falters because there are not many community contributing towards react integration. Note: Vite team has done their job for react, but react itself has many concerns particularly due to commonjs that a dedicated person (or team) is needed for react

>Vite is framework agnostic. Framework specific work is spearheaded by framework specific community or core authors in some cases (solid, astro) This is like saying NPM is language agnostic. Sure, technically it is. But we all know what it was built for and what the community is geared toward.

It's a JavaScript bundler. If a framework is doing weird stuff with imports, or using legacy module builds, that's on the framework to fix...or not.

Angular is the same way, it has its own compiler and relies on custom build-time code to work. That's also why it isn't picked up by a lot of newer build tools that generally just work with normal JS.

Re: Vite 3.0

#118

Earlier quoted context omitted.

> just don't upgrade random tooling all the time and you're good. Good luck with that in the NPM ecosystem

Why so?

If you care a little bit about those critical / major security vulnerability alerts, and are working with NPM professionally, I shouldn't need to answer the question. If you are not, it's because NPM moves very fast, you can lock in your dependencies but soon enough they'll start signaling vulnerabilities.

Re: Vite 3.0

#119

I had no idea so many other frameworks are using Vite as their default. Event server-side frameworks are picking it up! Has Webpack really been dethroned as the go-to bundler?

> Has Webpack really been dethroned as the go-to bundler? At this point yes. I'm sure there are still some things that you will need Webpack for, but in my experience I have yet to find one of those instances. Vite is not just way way way faster than Webpack, it's also way simpler. Configuring a React project from scratch with Webpack is an undertaking, especially if you're not seasoned with Webpack configurations. V…

Nice! Each time I tried out a new bundler (Parcel comes to mind), we hit issues where their configuration hasn't been sufficient for some niche stuff I learned to expect Webpack to handle. I can't think of any specific examples, but I'm sure you've seen something similar.

Vite has been great in the vanilla and Vue projects I've used it for. I didn't think the speed bump would be as noticeable as it was. I'm really happy to hear it is getting more usage in frameworks like Laravel.

Re: Vite 3.0

#120
post #101
post #94

I can't keep up with this stuff anymore. As a former "full stack" dev, I just quit the frontend part altogether and I'm now just focusing on the backend. It's just too much and changing too fast.

What technologies are you working with on backend? I'm pondering to abandon frontend too.

Well, I'm employed as a software architect and we're currently using Spring and Symfony. Very different languages and very similar frameworks. In my free time I play around with Go and some NextJS stuff.
Post reply on HN