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

131–140 of 229 posts

Re: Why we switched from Webpack to Vite

#131

Post by RobertKerans »

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.

Yep, I needed to put together a Webpack build tool chain for React last month & thought it was going to be a bit of a nightmare and it just...wasn't. Tiny bit of fiddling, but generally easy -- that was with a fairly complex setup in terms of the project structure and rules around deployment, so quite impressed after a few years of avoiding it due to how much I hated the song and dance over setting it up.

Re: Why we switched from Webpack to Vite

#132

Post by kklisura »

lhorie wrote: post #74
amasad wrote: post #61

Earlier quoted context omitted.

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

They probably mean that "hello world".length == 11 // bytes

Is it? I know there's no sizeof, but what would be sizeof(char) in JS? 1 byte?

Re: Why we switched from Webpack to Vite

#133

Post by krapp »

zachrose wrote: post #124
krapp wrote: post #117

Earlier quoted context omitted.

> I dunno, I feel that’s like saying that Lisp and Haskell are part of what’s broken about the machine code ecosystem. It would be if machine code were another high-level text-based language completely unrelated to either Lisp or Haskell with its own semantics, execution model and type system rather than a more directly machine-readable format of those languages themselves. Javascript is fundamentally different enoug…

> But the decision to avoid actually writing javascript at all costs Who's JavaScript is it anyway? ES7? ES6? Internet Explorer 11's? How do you isolate things for the sake of unit tests and then bring them together into a performant build?

>Who's JavaScript is it anyway? ES7? ES6? Internet Explorer 11's?

Cross-browser compatible Javascript was a solved problem when JQuery and shimming came along.

>How do you isolate things for the sake of unit tests and then bring them together into a performant build?

Use one of the many unit testing libraries and frameworks that already exist for Javascript.

Re: Why we switched from Webpack to Vite

#134

Post by danieka »

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…

Hi Evan!

I just wanted to thank you for your contributions to frontend development. Vue has had a huge positive impact on my day-to-day work. For me it’s truly a joy to work with and I am in debt to you and all Vue contributors. Vite makes me exited about tooling in a way that hasn’t happen in quite a while. Speed is indeed a feature.

So thank you for the great work you are doing and keep it up!

Re: Why we switched from Webpack to Vite

#136

Post by nogridbag »

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…

Evan, thanks for your work on Vite. We adopted Vite early on for a large Vue project. My main concern is the testing story. Any ETA on when we'd see official support for something like Jest?

Re: Why we switched from Webpack to Vite

#137

Post by valdiorn »

ng12 wrote: post #101
mariusmg wrote: post #91

Earlier quoted context omitted.

>Super excited about the future of JavaScript tooling ecosystem with more focus on efficiency and speed. Well they can't get worse than now... 234mb for a friggin hello world app

Would you count the size of the JVM when you do Hello World in Java?

you could and it would still be much smaller.

Re: Why we switched from Webpack to Vite

#139

Post by ryansolid »

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…

Core team on Marko and author of Solid. Vite is exactly the sort of project we've been looking for.

Sure I love coming up with the perfect Rollup setups to produce the smallest application bundles. But Vite closed the loop we were looking for in terms of offering low config client/server applications with both ease of use and great flexibility.

You can see the focus and care put into Vite to make it easier to address the complexity of configuration. We still have plugins/starter templates for Webpack and Rollup, but for the average developer getting started with these frameworks Vite just gives so much out of the box. It really gives the ease of something like Parcel, with the ability to expand. This makes it far superior to solutions like CRA which forced monkey patching or ejection.

We've already seen through meta-frameworks like Next that there is a big desire here, and what at one point seemed like a huge undertaking for a historically single developer project like Solid, is suddenly becoming a reality. And others have the ability to build and share these setups as well.

Evan and the rest of those working on Vite have my thanks and my gratitude.

Re: Why we switched from Webpack to Vite

#140

Post by colordrops »

gregfagan wrote: post #125
colordrops wrote: post #85

What about using native es6 imports cached by a service worker? If you don't have to support old browsers, this is a much better option than a compile step. Just pull from git and load it in your browser, no complications eating a weekend reading through docs and shotgun debugging.

Can you share more about your setup?

I can't share code yet but we are working on potentially open sourcing it. We have a no-build policy, so just raw JS. Using an in-house web component framework similar to LitElement. There is a minimal deploy step that creates a manifest that hashes all files in the repo, and the service worker uses this manifest to determine if a file is cached or not, and serves it up if so. Service workers can intercept network requests so they work great for this. The win here is if you change a couple files, only those files need to be downloaded and cached.
Post reply on HN