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

181–190 of 229 posts

Re: Why we switched from Webpack to Vite

#181

Post by wruza »

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!

Considering that projects nowadays have all dependencies installed into their folders, what else is both viable and much smaller? If we had to install everything required for a hello.c into c_modules, including a compiler, libc, etc, it wouldn’t take less than 34mb.

Of course a counter argument is that you don’t usually swap C compilers between projects and libc is stable af, but if a toolchain and/or stdlib was constantly changing and subject to non-compat, you’d have to.

Re: Why we switched from Webpack to Vite

#183

Post by nine_k »

lhorie wrote: post #129
nine_k wrote: post #84

Earlier quoted context omitted.

Most of the build tooling gets installed along the way. The compiled JS is hundreds of bytes at most, usually because React creates a bunch of boilerplate for you (a basic CSS file, an application, a web worker, etc) which you may remove.

Well, that's part of the jab: that you ostensibly don't need build tooling for an interpreted language, and further, that you don't even need an interpreted language in the first place considering we're talking about a platform that can do UI out of the box via a declarative language. (Obviously, that's neither here or there when we're talking about baselines for SPAs)

ES6 is a compile target.

The actual languages are often Typescript and jsx, to say nothing of the Svelte compiler or Elm.

You can write vanilla JS without all that, of course.

Re: Why we switched from Webpack to Vite

#184

Post by nojvek »

Esbuild is an amazing piece of software. At recurrency.ai we had an app that took almost 5 minutes to compile on stock create-react-app setup.

We moved it to webpack and used esbuild-loader and esbuild minifier. Still using webpack because we needed less and styled-component transforms. Esbuild doesn’t support hot reloading. Also I have a lot of experience tweaking webpack so I’m sticking with it.

Our build times went down to 15-30 seconds. That’s with full minification and sourcemaps.

I did try stock esbuild and that did it in 2 seconds. Webpack adds quite a bit of overhead.

From 5 minutes to 30 seconds without breaking any user facing functionality is still a big win.

Dev loop on hot reload is 100-300ms. Just feels amazing.

Re: Why we switched from Webpack to Vite

#185

Post by IggleSniggle »

lhorie wrote: post #156
IggleSniggle wrote: post #149

Earlier quoted context omitted.

The answer to this question is complicated. JavaScript char encoding is roughly UTF-16, which is 2-bytes, but the byte you read may have been part of a surrogate so, depending on your first one, you must read the next 2 bytes to complete your character. And of course, this basic explanation doesn’t really do justice to answering your question, because depending on your definition of what a “character” is, you may nee…

No need to overcomplicate though. None of this applies to the ascii range, and we're just talking about storage in disk in the first place.

The 2-bit part applies, if not the rest, and it’s not really “on disk” but rather “memory for data type,” right?

Given the nature of the questions, I presumed they were interested in knowing “how does JavaScript load strings into memory, anyway?”

And to answer that question, your rough heuristic should be “2 bytes per character” not 1, even for ascii range. That just leads to additional questions, though, because of the oddity of it.

In order to achieve the ability to do Unicode, there’s a reserved set of values within that 2-bytes, to allow you to extend the encoding to reach Unicode.

Back to the original measurement, for the string “hello world”, I believe a JavaScript `sizeof`, if it existed, would report 24 bytes (22 for the characters, and 2 (give or take) for either the NULL character or for a length header.

Re: Why we switched from Webpack to Vite

#186

Post by nojvek »

EvanYou wrote: post #127

Author of Vite here. I see many people evaluating Vite as a webpack replacement, so I want to clarify the goal of the project here: It is NOT Vite's goal to completely replace webpack. There are probably a small number of features/capabilities that some existing webpack projects rely on that doesn't exist in Vite, but those features are in the long tail and are only needed by a small number of power users who write b…

Just want to say how coincidental it is to have Evan You for vite + vue, and Evan Wallace for esbuild and Figma.

Long prosper the Evans :)

Re: Why we switched from Webpack to Vite

#187

Post by nojvek »

sunflowerdeath wrote: post #43

I have tried to use esbuild, and over the past 3 months I had at least a dozen times when it has compiled incorrect code that doesn't work or doesn't do what it's supposed to do. So despite the performance benefits, I was forced to go back to webpack, babel, and terser.

Do you have any repros? So far I’ve found esbuild give the correct output.

Re: Why we switched from Webpack to Vite

#188

Post by tomcam »

nojvek wrote: post #186
EvanYou wrote: post #127

Author of Vite here. I see many people evaluating Vite as a webpack replacement, so I want to clarify the goal of the project here: It is NOT Vite's goal to completely replace webpack. There are probably a small number of features/capabilities that some existing webpack projects rely on that doesn't exist in Vite, but those features are in the long tail and are only needed by a small number of power users who write b…

Just want to say how coincidental it is to have Evan You for vite + vue, and Evan Wallace for esbuild and Figma. Long prosper the Evans :)

Just wait until the alpha release of EvanScript.

Re: Why we switched from Webpack to Vite

#189

Post by nojvek »

jitl wrote: post #48

We just switched from TypeScript/ts-node to esbuild for server-side code at Notion; it's been great. Would love to see the same kind of speed wins for our clients :')

Do you prebuild and run or use some kind of node -r (module register).

Btw I interviewed at Notion but didn’t make the soft skill bar. Big fan of the product.

Re: Why we switched from Webpack to Vite

#190

Post by robpalmer »

nojvek wrote: post #186
EvanYou wrote: post #127

Author of Vite here. I see many people evaluating Vite as a webpack replacement, so I want to clarify the goal of the project here: It is NOT Vite's goal to completely replace webpack. There are probably a small number of features/capabilities that some existing webpack projects rely on that doesn't exist in Vite, but those features are in the long tail and are only needed by a small number of power users who write b…

Just want to say how coincidental it is to have Evan You for vite + vue, and Evan Wallace for esbuild and Figma. Long prosper the Evans :)

There is at least one more Evan working in this space who should be on that list.

Evan Martin created the Ninja build system and works on making JavaScript builds fast at Google. He has blogged about it here:

http://neugierig.org/software/blog/2020/10/scaling-typescrip...

Post reply on HN