Vite 3.0
41–50 of 202 posts
Re: Vite 3.0
#42> We decided to release a new Vite major at least every year Isn’t this exhausting? Is it impossible to design good contracts without having to break compatibility every year? In most other language ecosystems it would convey incompetence.
Re: Vite 3.0
#43The landing page of Vite claims "Next Generation Frontend Tooling" but then go on to describe features that already have been existing for a good while (multiple years). What exactly is the "next generation" part here? The composition? That's also not new, so I think I'm either missing something very obvious, or they need to do a better job explaining how Vite is actually different.
"Native" support for modules and TypeScript, so during development there is no bundle process needed, which is usually the most time-consuming process.
Re: Vite 3.0
#44> We decided to release a new Vite major at least every year Isn’t this exhausting? Is it impossible to design good contracts without having to break compatibility every year? In most other language ecosystems it would convey incompetence.
As per semver, they need to update major version if one of their dependency(Rollup in this case) did a major upgrade.
Re: Vite 3.0
#45This being the case, I am not sure I'd really have a reason to migrate over to Vite on this project.
Re: Vite 3.0
#46Earlier quoted context omitted.
why are you assuming that a major release breaks compatibility?
Because that's the meaning of major version number. Additionally JS/npm modules are supposed to follow semver, and you increment the major version when you break compatibility. I get it, Linux does its own thing with versions, and so do browsers, so it's hip to just increment major whenever you feel like it apparently. EDIT: LOL at people downvoting GP because they dared to wonder if the frontend world needs another…
I have no knowledge of which convention Vite uses.
Re: Vite 3.0
#47I know that this is all about Vite but if you like Vite, I want to give a shout-out to Parcel[0] as well. Its a very similar philosophy, built on top of SWC[1] and has its own set of great optimizations. I've regularly gotten smaller overall bundle sizes with parcel than with Vite (though that gap is very narrow now) in my experience. I wish Parcel got more mention, especially in the React community (where it shines…
Parcel has been praised on here many times when it originally came out. I was an avid user but the nail in the coffin was the horrid and long release of v2 which took forever, the docs were in disarray, and overall just left a bad taste in my mouth. I also think there was some common issue where v1 didn’t support some version of postcss for quite some time and I and many others jumped ship to vite.
Common things that break: specific operators (?.), caching issues, missing modules in the output bundle, build errors, etc.
Re: Vite 3.0
#48I know that this is all about Vite but if you like Vite, I want to give a shout-out to Parcel[0] as well. Its a very similar philosophy, built on top of SWC[1] and has its own set of great optimizations. I've regularly gotten smaller overall bundle sizes with parcel than with Vite (though that gap is very narrow now) in my experience. I wish Parcel got more mention, especially in the React community (where it shines…
Parcel has been praised on here many times when it originally came out. I was an avid user but the nail in the coffin was the horrid and long release of v2 which took forever, the docs were in disarray, and overall just left a bad taste in my mouth. I also think there was some common issue where v1 didn’t support some version of postcss for quite some time and I and many others jumped ship to vite.
Re: Vite 3.0
#49Vite's really gaining traction, from the chatter I'm seeing. Seems pretty good in my initial trial of it - I'm hoping it spurs other tools to improve performance and dev experience.
Re: Vite 3.0
#50React Context HMR still has problem. Due to this problem, I think nextjs still the better choice for react dev. Maybe vite supports too many frameworks, do not have enough time to handle the react problems. [1]: https://github.com/vitejs/vite/issues/3301
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
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.