9 ms·

I don't understand the point of vite. I tried using it and the "build" took over 30 seconds. esbuilds takes less than 1 second for the same project. > esbuild

by hsn915 5y ago

I don't understand the point of vite. I tried using it and the "build" took over 30 seconds. esbuilds takes less than 1 second for the same project. > esbuild is not featureful enough for a lot of production use cases What makes you say that? I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production.

oefrha 5y ago
> I tried using it and the "build" took over 30 seconds. It hardly matters because it's very rare that you need to run build during development. Use dev. > I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production. https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuild https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...
- inopinatus 5y ago
  I read that as yet another 30 seconds for a CI or production build, on top of every other inefficient tool shipping with an inflated sense of necessity and no feel for devops concerns. Accepting such into your toolset remains a primary source of creeping bloat. The JS ecosystem is riddled with such pests, and (as with webpack) eradication from our workflows always proves by far the best policy.
  - oefrha 5y ago
    Sure, please contribute to esbuild so that it solves more of people's actual needs. It's not like Evan doesn't want to switch to esbuild in Vite completely. My link to "Why Not Bundle with esbuild?" should be a good start for where you should look.
- hsn915 5y ago
  > It hardly matters For the hundredth time: it does matter. Stop wasting people's time with slow tools and telling them it doesn't matter. That's not a way to treat your users. Your fancy hot module reloading is not what I want. What I want is to reload the page and see my changes. I've never seen a "hot reload" that works properly. The one some of co workers are using right now works like this: - You edit a file - You wait 5 seconds for the "instant" rebuild - The browser reloads the page 5 times - After a total of over 10 seconds, you can finally see the effects of your changes. Maybe vite's HMR is better, I will never know because I don't care. The link you sent has the following to answer why not esbuild: > some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling. But this is not true. It handles css and does code splitting. Now, you have to be very explicit about code splitting: you have to define other entry points that share the same libraries as the main program so that it forces those shared libraries into separate chunks. To have more chunks you have more entry points where each entry point uses just one or two libraries. Yes, it's not perfect, but it's not a blocker for getting to production. Where as the 30 seconds build is a total blocker for development iteration.
  - oefrha 5y ago
    > What I want is to reload the page and see my changes. And what other people want is to not having to reload everything, lose all state on the page and make API requests all over when they add a 2px margin. > I've never seen a "hot reload" that works properly. Yeah, you've never seen a hot reload that works properly means someone else can't develop something new that works. And whatever crappy workflow that you enjoy must be great for everyone else. Anyway, talking to close minded individuals is pointless, so this is it.
    - hsn915 5y ago
      > lose all state on the page and make API requests all over That's the difference. I don't make API request in local development mode. If I do, the response is instant. > Yeah, you've never seen a hot reload that works properly means someone else can't develop something new that works. It might work, but if the cost is increasing build time from 1 second to 30 seconds, it's not worth it.
  - DrammBA 5y ago
    Sample size of 1 here: My vite project hot reloads in a few milliseconds, keeps state, and shows me all recent changes with no issues. Sounds like your co-workers are using webpack-based hmr, that can become slow very fast.
ricardobeat 5y ago
ESBuild doesn't transpile your code down to ES5. If you're using any ES6 features - default params, template literals, arrow functions, let/const, spread, etc, your cut-off for browser support will be ~2017 (= no support for IE 11). swc (https://swc.rs https://swc.rs) does transpilation and it's as fast as esbuild. Setup is slightly more complex. I'm hoping esbuild will add ES5 transforms at some point, would much rather have a Go tool underneath.
- nicoburns 5y ago
  Plain esbuild is perfect for adding typescript support to node.js projects. We literally just run ’esbuild && node dist/run.js’
  - smt88 5y ago
    How is this different from `tsc && node dist/run.js`?
    - joshuacc 5y ago
      1. It’s much faster. 2. It won’t catch type errors. Regarding #2, I assume that things are set up so that type errors are caught in some other way, such as in CI or in a precommit hook.
      - christophilus 5y ago
        What I do is run esbuild and tsc (with no emit) in parallel in watch mode. That way, I get fast rebuilds and iterations, but still eventually see the errors spit out. My code editor catches 90% of the errors, but it’s definitely nice to have tsc catch the rest earlier than the CI process.
        tomnipotent 5y ago
        > My code editor catches 90% of the errors With or without strict mode enabled?
BiteCode_dev 5y ago
The purpose of vite is not to be fast for build, but to be a live reload instant dev platform. So you almost never run build. You code with vite's server, and it let you see the result instantly in the browser. You can use modules, modern js, and transpiled languages transparently. Then when you put in prod, you build once. 30s once a day doesn't matter.
- 3np 5y ago
  It does matter in a CI environment. Using a different build procedure there is not optimal.
  - BiteCode_dev 5y ago
    Optimal != Best for most people.
    - 3np 5y ago
      Best for most people != Best for everyone I mean, notepad.exe is arguably a better text editor for most people compared to anything else most of us are using. I'll happily take some minor overhead in build configuration over adding 30s+ to every automated build if it's not a personal or small-scale community project.

by hsn915 5y ago

oefrha 5y ago

> I tried using it and the "build" took over 30 seconds. It hardly matters because it's very rare that you need to run build during development. Use dev. > I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production. https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuild https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...

inopinatus 5y ago
I read that as yet another 30 seconds for a CI or production build, on top of every other inefficient tool shipping with an inflated sense of necessity and no feel for devops concerns. Accepting such into your toolset remains a primary source of creeping bloat. The JS ecosystem is riddled with such pests, and (as with webpack) eradication from our workflows always proves by far the best policy.
- oefrha 5y ago
  Sure, please contribute to esbuild so that it solves more of people's actual needs. It's not like Evan doesn't want to switch to esbuild in Vite completely. My link to "Why Not Bundle with esbuild?" should be a good start for where you should look.
hsn915 5y ago
> It hardly matters For the hundredth time: it does matter. Stop wasting people's time with slow tools and telling them it doesn't matter. That's not a way to treat your users. Your fancy hot module reloading is not what I want. What I want is to reload the page and see my changes. I've never seen a "hot reload" that works properly. The one some of co workers are using right now works like this: - You edit a file - You wait 5 seconds for the "instant" rebuild - The browser reloads the page 5 times - After a total of over 10 seconds, you can finally see the effects of your changes. Maybe vite's HMR is better, I will never know because I don't care. The link you sent has the following to answer why not esbuild: > some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling. But this is not true. It handles css and does code splitting. Now, you have to be very explicit about code splitting: you have to define other entry points that share the same libraries as the main program so that it forces those shared libraries into separate chunks. To have more chunks you have more entry points where each entry point uses just one or two libraries. Yes, it's not perfect, but it's not a blocker for getting to production. Where as the 30 seconds build is a total blocker for development iteration.
- oefrha 5y ago
  > What I want is to reload the page and see my changes. And what other people want is to not having to reload everything, lose all state on the page and make API requests all over when they add a 2px margin. > I've never seen a "hot reload" that works properly. Yeah, you've never seen a hot reload that works properly means someone else can't develop something new that works. And whatever crappy workflow that you enjoy must be great for everyone else. Anyway, talking to close minded individuals is pointless, so this is it.
  - hsn915 5y ago
    > lose all state on the page and make API requests all over That's the difference. I don't make API request in local development mode. If I do, the response is instant. > Yeah, you've never seen a hot reload that works properly means someone else can't develop something new that works. It might work, but if the cost is increasing build time from 1 second to 30 seconds, it's not worth it.
- DrammBA 5y ago
  Sample size of 1 here: My vite project hot reloads in a few milliseconds, keeps state, and shows me all recent changes with no issues. Sounds like your co-workers are using webpack-based hmr, that can become slow very fast.

ricardobeat 5y ago

ESBuild doesn't transpile your code down to ES5. If you're using any ES6 features - default params, template literals, arrow functions, let/const, spread, etc, your cut-off for browser support will be ~2017 (= no support for IE 11). swc (https://swc.rs https://swc.rs) does transpilation and it's as fast as esbuild. Setup is slightly more complex. I'm hoping esbuild will add ES5 transforms at some point, would much rather have a Go tool underneath.

nicoburns 5y ago
Plain esbuild is perfect for adding typescript support to node.js projects. We literally just run ’esbuild && node dist/run.js’
- smt88 5y ago
  How is this different from `tsc && node dist/run.js`?
  - joshuacc 5y ago
    1. It’s much faster. 2. It won’t catch type errors. Regarding #2, I assume that things are set up so that type errors are caught in some other way, such as in CI or in a precommit hook.
    - christophilus 5y ago
      What I do is run esbuild and tsc (with no emit) in parallel in watch mode. That way, I get fast rebuilds and iterations, but still eventually see the errors spit out. My code editor catches 90% of the errors, but it’s definitely nice to have tsc catch the rest earlier than the CI process.
      - tomnipotent 5y ago
        > My code editor catches 90% of the errors With or without strict mode enabled?

BiteCode_dev 5y ago

The purpose of vite is not to be fast for build, but to be a live reload instant dev platform. So you almost never run build. You code with vite's server, and it let you see the result instantly in the browser. You can use modules, modern js, and transpiled languages transparently. Then when you put in prod, you build once. 30s once a day doesn't matter.

3np 5y ago
It does matter in a CI environment. Using a different build procedure there is not optimal.
- BiteCode_dev 5y ago
  Optimal != Best for most people.
  - 3np 5y ago
    Best for most people != Best for everyone I mean, notepad.exe is arguably a better text editor for most people compared to anything else most of us are using. I'll happily take some minor overhead in build configuration over adding 30s+ to every automated build if it's not a personal or small-scale community project.