Live data from Hacker News

Vite 3.0

vitejs.dev

161–170 of 202 posts

Re: Vite 3.0

#161

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

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

Re: Vite 3.0

#162

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?

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 don't think just building JS is slow, I think the issue is that most of the ecosystem is ready to move on to more "no build" scenarios now that ES modules are supported everywhere that matters [0] [1] (Node 12+). Webpack still doesn't seem to have much of an ESM "native" approach/roadmap. Snowpack had a relatively good ESM "native" approach, but appears finished and points to Vite now. Vite isn't entirely ESM "native" yet, but there's more work there mentioned in these release notes and it definitely appears to be in their roadmap/planning horizon. I'm curiously following Vite, but so far it smells to me more of a webpack too much of the kitchen sink "fork" than not still for the "no build"/"targeted build" world.

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.

[0] https://caniuse.com/es6-module

[1] https://caniuse.com/es6-module-dynamic-import

Re: Vite 3.0

#163
post #37

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…

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

npm itself assumes projects use semver, so it's generally a useful assumption in the JS ecosystem at this point now that npm is the primary package manager for all things JS that JS packages follow semver.

https://docs.npmjs.com/about-semantic-versioning

Re: Vite 3.0

#164

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?

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

#166

Earlier 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?"

They mean recompile on file save and hot-patch the frontend without reloading. See: https://main.vitejs.dev/guide/features.html#hot-module-repla...

Re: Vite 3.0

#168

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

> Webpack is slow

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.

For clarification, isn't it true that you can only use Vite with Vue and React, and not Angular. Angular is too tied to WebPack (At least not today) I am not entirely sure, so I wanted to ask.

Re: Vite 3.0

#170

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

The latter mainly. The biggest reason is that JS is too slow compared to other languages, especially compiled ones like Go or Rust. So writing developer tools in JS already made them slow.
Post reply on HN