Live data from Hacker News

Vite 3.0

vitejs.dev

41–50 of 202 posts

Re: Vite 3.0

#42
post #31

> 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

#43

The 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.

What exactly is the "next generation" part here?

"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
post #42
post #31

> 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.

If their own public API hasn't changed, why would semver require that?

Re: Vite 3.0

#45
I am currently using WebPack to package a multi-page web app. Build times are relatively quick, and when developing I am using a feature that does an incremental rebuild when files are changed and that's quite fast at this point.

This 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

#46
post #37

Earlier 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…

That's one meaning of major version number. The original meaning is simply a release that is significantly different from the previous one. It's also possible to maintain more than one version number: a marketing version and an internal version (Windows did this famously where Windows 7 is actually version 6.1, Windows 8 is 6.2). Then there's a convention where the major version is the year number and it simply increases on Jan 1st, etc.

I have no knowledge of which convention Vite uses.

Re: Vite 3.0

#47

I 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.

I have been using Parcel for years now, the biggest issue: many weird bugs and things break which each update.

Common things that break: specific operators (?.), caching issues, missing modules in the output bundle, build errors, etc.

Re: Vite 3.0

#48

I 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.

Agree with this strongly. Also, it's great to have a zero-config tool like Parcel, but it needs to have a path from zero-config to "some config" as your project grows. I found this very difficult and jumped to Vite.

Re: Vite 3.0

#49

Vite'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.

[deleted]

Re: Vite 3.0

#50
post #30
post #15

React 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

>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.

Post reply on HN