How do people using Vite deal with Common JS dependencies? As far as I tried, there were issues with those when using "vite dev". Sadly, at this point, I can't get rid of those (e.g. protobufs+grpc-web generated code).
Why we switched from Webpack to Vite
71–80 of 229 posts
Re: Why we switched from Webpack to Vite
#72Earlier quoted context omitted.
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?
Previously I've been a heavy user of Webpack + plugins, but I've now moved over to ESBuild for all new projects. This means letting go of many fancy features, but the overall complexity is so much reduced and I'm a lot happier. Before: Chain together style-loader, css-loader, postcss-loader and the MiniCssExtractPlugin in some weird way. So complicated to understand which PostCSS plugins interacts with resolving impo…
> In addition, now my JavaScript files are actually just JavaScript and I can be pretty sure that it will work with any new tooling without any problems.
That's been my feeling for years, too: if your team is less than, say, several dozen people there's a significant amount of merit to having something which doesn't require continous care and feeding for anyone to work, especially when it's combining a number of complex libraries with independent development teams.
Re: Why we switched from Webpack to Vite
#73Earlier 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.
I can remove babel in my code?
Re: Why we switched from Webpack to Vite
#74Re: Why we switched from Webpack to Vite
#75From the article, a good explainer: > Vite works by treating your source code and your dependencies differently. Unlike your source code, dependencies don't change nearly as often during development. Vite takes advantage of this fact by pre-bundling your dependencies using esbuild. Esbuild is a JS bundler written in Go that bundles dependencies 10-100x faster than JavaScript based alternatives like Webpack and Parcel…
I find it useful to have my vendor dependencies compiled and watched for debugging. There are always bugs in deps or poor error messages, and sometimes the dev tools debugger doesn’t work properly, so being able to modify a dev is nice.
Of course it would prob be better if this was a toggle.
I think webpack module federation may improve this situation too. I used webpack all plugin previously to speed up vendor dep compilation.
Thing about webpack though is it’s so complex how all this works that I always have to revisit it every few months to jog my memory.
We need simpler abstractions on top. Next is nice but still, if you need to dive deeper it’s painful.
I think in like 20 years time we will probably be able to get rid of all of this tool chain and the new kids will never know the pains we went through.
Re: Why we switched from Webpack to Vite
#76Webdev 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…
For personal projects I just use plain javaScript, ES5 even, without any compile steps, everything loads instantly and runs on every browser that supports JavaScript, and the development can be set up in any environment/OS without headaches.
I do use minification for production but that is not really necessary if the browser supports loading JS-script tags async (all major browsers). The bundle gets very small without any frameworks attached. Debugging is easy with the browser built in dev-tools - with small error messages that always have the correct line (eg. no source maps). I'm currently working on a 100,000+ line JS project that uses the plugin pattern with script tags and it's very manageable, adding new features is fast and fun.
There are of course trade-offs, I can't just "npm install react-x-y-z", but the browser API's are extensive, you can do just about anything on the front-end with just the native browser components and API's.
Re: Why we switched from Webpack to Vite
#77Earlier quoted context omitted.
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.
I can remove babel in my code?
It depends on your target platform: ES6 modules are basically supported in every browser I care about, so the major reason for Babel is JSX
Re: Why we switched from Webpack to Vite
#78I was a little surprised that Vite, which depends on esbuild and thus should know better, is written in Javascript. I presume this is a considered choice, and that what Vite does is unlikely to be on the critical path for edit/build/view cycle time…
The speedup from tools like esbuild, swc, etc. are not because of the language they were written in but because they're competing against Babel. Babel is this single-threaded highly-extensible behemoth. On top of this, you're encouraged to install dozens of plugins, and each plugin has access to global state. The new transpilers have worked around this problem by introducing various limitations. esbuild plugins liter…
Precisely. I'd advise having esbuild behind Babel if you really need an specific Babel plugin, for ex:
* Transform the file using esbuild first
* Then use Babel with that one specific plugin (Loadable Components, Styled Components, Apollo, React Refresh...)
This is much faster than letting Babel do all the work.
Re: Why we switched from Webpack to Vite
#79Webdev 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…
I knew someone would bring this comment. Webdev can be broken, but doesn't have to be. I am currently having fun & feeling productive on both a large team project and some small personal projects.
[deleted]
Re: Why we switched from Webpack to Vite
#80I 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…
I feel like there just needs to be a good plugin that gives you proper stats as to how long things are taking and tips to improve things.
It’s usually slow css loaders, or too-inclusive patterns for loaders ending up processing node_modules, and not good enough disk caching.
There is a plugin called smc to monitor loader execution time.
Dll plugin was the best speed up to avoid recompiling things that don’t change, but now module federation is suppose to be a better solution. Disk caching in v5 will also do great things.
Thing is, it’s so complicated to setup, and debugging it involves so much config tweaking ans waiting.
I think we are a few years out from when we have nice speedy builds in webpack with good abstractions.
But then it’s a question of whether people move away from webpack because we don’t need all the plugins and transpiration and want native compile speeds.
One thing for certain though is the hype cycle will continue on...