51–60 of 202 posts
Wait what, again? I thought we all silently agreed to use the mature/legacy frameworks React and Angular until the proper WASM arrives so that we could burn all of JS/CSS/HTML...
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.
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…
> Vite is powering a renewed innovation race in Web frameworks. Wait what, again? I thought we all silently agreed to use the mature/legacy frameworks React and Angular until the proper WASM arrives so that we could burn all of JS/CSS/HTML...
We did. But people without real problems to solve will continue reinventing the wheel, while we silently churn away on actual products with stable tooling.
Earlier quoted context omitted.
Probably this-- https://vitejs.dev/guide/migration.html#automatic-https-cert...
Thanks, that solved it, but now I have other errors like needing to install sass etc. V2 seemed much better now, it just worked, now I have to go installing everything and the kitchen sink. edit: fixed after reading docs. https://vitejs.dev/guide/features.html#css npm add -D sass
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?
In my experience, Vite offers a better onboarding process and has a more straightforward configuration format compared to ESBuild. You also get most of rollup's plugin ecosystem and a large amount of community tools made specifically for Vite (Vitest, ViteBook, vite-plugin-pwa, etc...). Also, I might be wrong about this but I don't think ESBuild has HMR, which really speeds up development. Overall, ESBuild feels like…
I suppose it wouldn't scale if the app got too big and complicated.
[1] https://github.com/skybrian/serialviz/blob/main/package.json
Earlier quoted context omitted.
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 incre…
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.
I've been considering switching to Vite because it should make the SSR + hydration config much simpler and I would get HMR (hot module reloading) which will probably speed my iteration times if it works as expected.
> 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.
Earlier quoted context omitted.
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?
For eg: Consider CRA dependency upgrade from webpack v4 to v5. That change broke a lot of apps due to node not being polyfilled.
If CRA did the change in minor version, then it would have result in breaking changes for many apps and would completely undermine semantic versioning