> 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...
>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.
Vite 3.0
161–170 of 202 posts
Re: Vite 3.0
#162I 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?
Webpack really messed up IMO -- v5 took a really, really long time to drop because they were making huge changes ostensibly for performance... and then when it came out it actually made performance worse for many projects. I think they've fixed that now, but the damage is done. I think building js in js is just not fast enough anymore, everyone is moving towards compiled languages for building their apps. The next wi…
I've been experimenting with some stuff using esbuild directly in a "targeted" way that builds only a few things with most stuff just Typescript transpilation only (again). I've almost got a feeling the next winner may just be Typescript+esbuild, but not at all because esbuild is fast or written in Go. It may still be Typescript+rollup, given the hints of what's coming in the next Rollup major. (Typescript is still in JS and getting faster every release, with incremental build support for large projects getting better all the time. Rollup is still in JS and still a decent esbuild competitor.) In a "no build"/"targeted build" world it's not really speed that matters but a minimal, targeted API that's easy to automate as you choose targets to build and it may be the case that the time of the "kitchen sink plus a million plugins" builder is over.
Re: Vite 3.0
#163Earlier 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…
How do you know they use semver? Major version is just a marketing thing for many frameworks. Node is one of them too. Even Go, one of the most boring (in the good sense) languages, considered to do the same thing at some point (when included generics).
Re: Vite 3.0
#164I tried using ESBuild directly for a small web app and it seems pretty nice. What would using Vite on top of it give me?
A dev server with hot reloading is the big thing vite adds IMHO, at least for your day to day use. It also adds rollup and a more uniform plugin system for your production builds but really the dev server experience is where vite excels. If you just want esbuild + hot reloading then dev-server-esbuild might be a good option: https://modern-web.dev/docs/dev-server/plugins/esbuild/ But really vite isn't much more compl…
"scripts": {
"build": "esbuild src/app.ts src/app.css --bundle --sourcemap --outdir=site",
"dev": "npm run build -- --servedir=site",
}
Unless you mean something different by "hot reloading" than "recompile on page reload?"Re: Vite 3.0
#165> Vite’s default dev server port is now 5173. That's a very strange change
Re: Vite 3.0
#166Earlier quoted context omitted.
A dev server with hot reloading is the big thing vite adds IMHO, at least for your day to day use. It also adds rollup and a more uniform plugin system for your production builds but really the dev server experience is where vite excels. If you just want esbuild + hot reloading then dev-server-esbuild might be a good option: https://modern-web.dev/docs/dev-server/plugins/esbuild/ But really vite isn't much more compl…
At least for a small site, you don't actually need a plugin to get hot reloading using esbuild: "scripts": { "build": "esbuild src/app.ts src/app.css --bundle --sourcemap --outdir=site", "dev": "npm run build -- --servedir=site", } Unless you mean something different by "hot reloading" than "recompile on page reload?"
Re: Vite 3.0
#167Re: Vite 3.0
#168Earlier quoted context omitted.
>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.
This comment and the parent's tells me that neither of you know what vite does or have used it before, if you're implying that it's not fixing "real problems." Webpack is slow due to being written in JS, so when a bundler comes along written in Go and makes builds 10x faster, that is solving a "real problem."
So it sounds like Webpack was never really mature, or too late in getting ported to Go before Vite took over?
Re: Vite 3.0
#169> 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...
The description is maybe a little misleading. Vite is a development experience improvement for existing frontend frameworks; most people using it are on React or Vue (which is the other of the "big 3" along with React and Angular). It's about making projects build and start faster.
Re: Vite 3.0
#170Earlier quoted context omitted.
This comment and the parent's tells me that neither of you know what vite does or have used it before, if you're implying that it's not fixing "real problems." Webpack is slow due to being written in JS, so when a bundler comes along written in Go and makes builds 10x faster, that is solving a "real problem."
> Webpack is slow So it sounds like Webpack was never really mature, or too late in getting ported to Go before Vite took over?