Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we switched from Webpack to Vite

blog.replit.com

Post reply on HN
Print view View original

61–70 of 229 posts

Re: Why we switched from Webpack to Vite

#61

Post by amasad »

sjaak wrote: post #57
amasad wrote: post #6

Some stats not mentioned in the post. Create React App (webpack) vs Vite (esbuild) on Replit containers: - 1 second start up time on Vite vs 15 seconds for CRA - React.js hello world project is 234mb on CRA and only 34mb on Vite - 1GB RAM for Vite dev server vs 3GB+ for CRA This is a perfect example of how fast and efficient tools can be, and I think we can do even better! Super excited about the future of JavaScript…

“Only” 34mb for a hello world project? I can’t tell if you’re being ironic but I hope so!

Nearly an order of magnitude reduction. What do you think of that?

Re: Why we switched from Webpack to Vite

#62

Post by desireco42 »

JMTQp8lwXL wrote: post #20
amasad wrote: post #6

Some stats not mentioned in the post. Create React App (webpack) vs Vite (esbuild) on Replit containers: - 1 second start up time on Vite vs 15 seconds for CRA - React.js hello world project is 234mb on CRA and only 34mb on Vite - 1GB RAM for Vite dev server vs 3GB+ for CRA This is a perfect example of how fast and efficient tools can be, and I think we can do even better! Super excited about the future of JavaScript…

As the "webpack" guy on my team, these numbers look extremely compelling, but I also know Webpack does a lot for us (e.g., through Webpack v4, it includes browserfied node libs as needed). Beyond node libs, there's a long tail of niche things that need to be taken of... am I trading coverage of that long tail for speed?

You still need webpack for production build :). So all is good.

Re: Why we switched from Webpack to Vite

#64

Post by deergomoo »

krapp wrote: post #47
napsterbr wrote: post #25

Earlier quoted context omitted.

> The webdev ecosystem is so broken Allow me to correct this statement: The Javascript ecosystem is so broken. Working with Clojurescript and Elm is an experience that will make most developers fall in love with web development again.

Hate to break it to you but Clojurescript, Elm and the whole paradigm of "compile to JS" languages are part of what is broken about the javascript ecosystem. So much unnecessary complexity and energy wasted making javascript pretend to be something it isn't and to make it do things it was never meant to do, pressing a small, simple and powerful scripting language into the service of the profane eldritch abomination t…

I dunno, I feel that’s like saying that Lisp and Haskell are part of what’s broken about the machine code ecosystem.

ClojureScript and Elm aren’t compile-to-JS languages for the sake of doing something weird, there’s just literally nothing else that will run in a browser (except wasm but probably best not to get into that).

Different programming languages exist for a multitude of valid reasons, the compiled output isn’t particularly important as long as it can express everything you need it to.

Re: Why we switched from Webpack to Vite

#65

Post by eliseumds »

earthboundkid wrote: post #53
eliseumds wrote: post #46

I literally just spent days trying out Vite and comparing it to Webpack 5, and I can comfortably say that they are in two very distinct leagues. It isn't fair to compare Vite to a CRA build with Webpack. You can greatly improve Webpack's performance by: * Making sure `mode` is set to "development" (don't specify it all if in doubt) * Ditching babel-loader and using esbuild-loader instead * Adjusting build targets and…

If you figure out how to get Webpack to solve all these issues, that makes one working Webpack installation. When Vite solves their issues, all Vite installations will have the issues solved.

Vite is not a completely opinionated tool. You can still customise its behaviour and use plugins, so both installations would have very similar vulnerabilities at the end. For SSR, you need a self-written server entry point.

Webpack 5 has introduced asset modules, so now you can safely ditch raw-loader, url-loader and file-loader. [1]

You might have NextJS or CRA in mind.

[1] https://webpack.js.org/guides/asset-modules/

Re: Why we switched from Webpack to Vite

#66

Post by the_gipsy »

Kaze404 wrote: post #50
the_gipsy wrote: post #40

Earlier quoted context omitted.

Then also make unit, integration, and e2e work with all the transpiling. Good luck with sourcemaps!

You enable sourcemaps on Webpack with `devtool = "eval-source-map"` in your config, and I'm not sure how you expect transpiling to be a problem with testing considering your tests are also transpiled.

Do you compile and run your unit tests with webpack?

Re: Why we switched from Webpack to Vite

#67

Post by wildpeaks »

fiddlerwoaroof wrote: post #23
amasad wrote: post #6

Some stats not mentioned in the post. Create React App (webpack) vs Vite (esbuild) on Replit containers: - 1 second start up time on Vite vs 15 seconds for CRA - React.js hello world project is 234mb on CRA and only 34mb on Vite - 1GB RAM for Vite dev server vs 3GB+ for CRA This is a perfect example of how fast and efficient tools can be, and I think we can do even better! Super excited about the future of JavaScript…

I’d like to see non-CRA numbers: I’ve found that a simple React + Webpack 5 project is not as bad to get off the ground as it used to be.

Exactly: 99% of the time, "webpack is slow" is just code for "I have Babel in my toolchain" and forgetting to set ts-loader as "transpile only".

Personally I removed it years ago, and Webpack 5 even allowed me to get rid of more loaders now that there are Assets Modules that automatically detect assets and webworkers using the "new URL()" syntax, and Typescript does everything else I need.

Re: Why we switched from Webpack to Vite

#68

Post by curun1r »

napsterbr wrote: post #25
MintsJohn wrote: post #22

Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For extra fun, some libraries don't build with build system a, others require build system b, when you're lucky enough to have a working mix, changing build systems is better to be avoided. Of course periodically the officially blessed build system for your used li…

> The webdev ecosystem is so broken Allow me to correct this statement: The Javascript ecosystem is so broken. Working with Clojurescript and Elm is an experience that will make most developers fall in love with web development again.

Also Trunk [0] for Rust-wasm web dev. It’s made me not hate doing the front end for my projects. I look forward to the Rust web ecosystem evolving to the point where I can recommend it in a work context.

[0] https://trunkrs.dev/

Re: Why we switched from Webpack to Vite

#70

Post by fiddlerwoaroof »

wildpeaks wrote: post #67
fiddlerwoaroof wrote: post #23

Earlier quoted context omitted.

I’d like to see non-CRA numbers: I’ve found that a simple React + Webpack 5 project is not as bad to get off the ground as it used to be.

Exactly: 99% of the time, "webpack is slow" is just code for "I have Babel in my toolchain" and forgetting to set ts-loader as "transpile only". Personally I removed it years ago, and Webpack 5 even allowed me to get rid of more loaders now that there are Assets Modules that automatically detect assets and webworkers using the "new URL()" syntax, and Typescript does everything else I need.

The new URL() thing is amazing
Post reply on HN