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

91–100 of 229 posts

Re: Why we switched from Webpack to Vite

#91

Post by mariusmg »

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…

>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

Re: Why we switched from Webpack to Vite

#93

Post by theon144 »

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…

>* It has a weird mix of own and Rollup config settings that seems somewhat unpredictable

Oh god, this is a giant red flag. This is precisely one of my biggest gripes with Quasar (a Vue framework), which, on top of webpack/vue adds its own config that are intermingled with vue's and webpack's, and its honestly a mess, and oftentimes just straight up makes problems harder to solve.

I am obviously not railing against config dedicated to a single tool in a toolchain, but the way you described it rings a bell, especially the "unpredictability".

>* Many open issues regarding module imports, for ex, when a CJS module imports an ES one

This also seems to confirm my and other's suspicion, that the tool isn't really "deliver-grade".

>If you hit a wall, install speed-measure-webpack-plugin to get some help.

But on the other hand, this is at least the fifth plugin I have heard someone recommend, dedicated just to profiling Webpack.

What do you think about the time difference shown in the article? I sort of feel it's a bit disingenuous since the test included a lot of other variables, but it seems hard to argue against it if it's this plain. Is this a config issue, or a "most commonly used loader" issue...?

Re: Why we switched from Webpack to Vite

#94

Post by andrewmcwatters »

My position on web development for even consulting projects is just to not use build processes as much as possible. I still end up using them for things like JSX, but I don’t bundle anymore, nor do any web projects I build require installation out of the box.

I’ve found that by doing so, I can just basically ignore, for years on end, all of the peddlers pushing how their projects make development easier or faster or some nonsense.

You know what’s easiest and fastest? Flat files in a good directory structure with some getting started template.

That’s it. The fastest build times are the ones that don’t exist. Period.

Web development is as complicated as you choose to make it. Very few fields work like this.

Re: Why we switched from Webpack to Vite

#95

Post by root_axis »

vaughan wrote: post #89
root_axis wrote: post #17

Earlier quoted context omitted.

That's the beauty of it, if the concrete performance improvements don't seem like a worthwhile tradeoff you don't have to use it. The idea that everyone should just contribute to one package instead of creating their own solutions is just silly, we are not able to dictate what people code up in their own time. Besides, there are dozens and sometimes hundreds of active contributors to every popular open source package…

A counter point would be to look at the Python ecosystem. They have many fewer libraries but the ones they have are very well maintained and widely adopted. JS/Node is full of unmaintained projects that people inevitably need to migrate away from. Of all the new choices in bundlers today, it’s also inevitable that some won’t work out, yet they will drive hype and adoption, which could have been spent on already estab…

> A counter point would be to look at the Python ecosystem. They have many fewer libraries but the ones they have are very well maintained and widely adopted.

So what? It is what it is - the python ecosystem faces completely different challenges than the JS ecosystem, if the browsers exclusively ran Python instead of JS it would be the exact same situation for Python.

> JS/Node is full of unmaintained projects that people inevitably need to migrate away from

This isn't true. jQuery, Angular.js, Angular, React, Vue etc are all still maintained (check their githubs if you are in doubt) and all still work just fine, so if you want to use the same tooling you did a decade ago that's totally possible.

> it’s always going to be harder to build on top of old rather than to write something new

So what? If you want to contribute to old projects instead of writing something new you're free to do that, and if you don't like new stuff you don't have to use it, complaining about this stuff is just pointless contrarianism, but of course, you're free to do that too.

Re: Why we switched from Webpack to Vite

#96

Post by koolba »

mariusmg wrote: post #91
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…

>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

It’s more of a hello import the world.

Re: Why we switched from Webpack to Vite

#97

Post by rgovostes »

When I learned about Prolog in university I had a "eureka" moment where I wondered why I was spending all this time learning to implement algorithms in imperative code, when I could just express the output I want and then let some über constraint solver figure out how to produce it. How liberating declarative programming would be if only we started coding with it more.

When I try to use Webpack, as I click through obsolete StackOverflow posts, trying to figure out the right key-value pairs to get the output I want, I realize how mistaken I was. I hope build tools for the web become less "magical" and more predictable and debuggable, even if it means discarding their declarative form.

Re: Why we switched from Webpack to Vite

#98

Post by shakow »

andrewmcwatters wrote: post #94

My position on web development for even consulting projects is just to not use build processes as much as possible. I still end up using them for things like JSX, but I don’t bundle anymore, nor do any web projects I build require installation out of the box. I’ve found that by doing so, I can just basically ignore, for years on end, all of the peddlers pushing how their projects make development easier or faster or…

> Very few fields work like this.

Quite the opposite; I would argue that webdev is basically rediscovering the whole shebang, but decades later.

Modern webdev with transpilation, linking, pruning, compilation to WASM etc. starts to dreadfully look like the classical native development paradigm.

Re: Why we switched from Webpack to Vite

#99

Post by willhoyle »

throwaway894345 wrote: post #39
larrymyers wrote: post #35

I tried out both snowpack and esbuild recently, and while the approach of using es modules was neat, these tools are still wildly immature compared to webpack. Need to handle non-js assets in your bundle? Need to integrate into both node and browser environments? You should stick with webpack. Any time you lose waiting for webpack to run you will get back 10x over by not fighting with your tooling because it doesn't…

> Any time you lose waiting for webpack to run you will get back 10x over by not fighting with your tooling because it doesn't handle a set of use cases you have. Generally I think this is good advice for tools--stick with the mature thing. But my former company's webpack builds were 30+ minutes for a relatively simple site. No doubt something was misconfigured, but you really have to be a webpack expert to get any s…

> my former company's webpack builds were 30+ minutes for a relatively simple site

I’m genuinely curious what simple site would cause a 30+ minute build? Is it just one of those things that grow over time?

Re: Why we switched from Webpack to Vite

#100

Post by spoiler »

mariusmg wrote: post #91
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…

>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

It's worth noting that the tooling and build systems are that big. They include type definitions, binaries, scss preprocessors, typescript compiler, linter, and a lot of other tools to enhance DX. Some of them might include other non-code resources.

The hello world app is not going to be this big.

Post reply on HN