Why we switched from Webpack to Vite
blog.replit.com
blog.replit.com
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 bespoke webpack configuration. Some of the commenters here probably belong in this group. If you do (e.g. you tried to migrate and found roadblocks, or evaluated and concluded that Vite doesn't suite your needs), use webpack by all means! You are not Vite's target audience by design - and you should absolutely pick the right tool for the job.
However, in the context of the general web dev population, 90% of existing devs and 100% of beginners don't need or care about these long tail features. This is an estimation made based on years of experience working on vue-cli, which is webpack-based. (context: I'm also the author of Vue.js and vue-cli is downloaded more than 3 million times per month on npm). Vite is optimized for these common use cases, and we've heard many success stories of painlessly moving from vue-cli/CRA to Vite.
This is also why Vite is a good fit for Repl.it where majority of its use cases overlap with the target use cases of Vite.
That said, we are also seeing frameworks like Svelte/Solid/Marko building SSR meta frameworks on top of Vite, projects that were previously webpack-based offering alternative modes running on top of Vite (e.g. Nuxt, Storybook), so we believe Vite does cover quite a lot even for power users.
So - try it, and if it doesn't work for you, stick to webpack (specially if you have an existing project relying on specific webpack behavior). As many people said, webpack 5 has made decent performance gains, and if you are targeting modern browsers, consider replacing Babel/TS with esbuild. These should already get you pretty far.
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!
In the meanwhile, you can also consider:
- @web/test-runner (https://modern-web.dev/docs/test-runner/overview/)
- Cypress (both e2e and unit testing via its component test runner https://www.cypress.io/blog/2021/04/06/introducing-the-cypre...)
- Check out https://github.com/sodatea/vite-test-example for an example using the above.
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.
Long prosper the Evans :)
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...
Anyway since you are here is there any reason why Vite won't run with Vue 2.x? I tried Vue 3 with Vite and I was blown away how much dev time it saves. No startup time, no compile time.. but we have thousand and thousands of line of Vue 2 that isn't going to be ported to V3 anytime soon and it kills me that I have to waste so much time looking at webpack compiling all the vue files everytime I load it.
Is this technically impossible to make Vite work with Vue 2 or is it because the community has moved away from V2 and don't want to spend any time on V2 tooling? Thanks.
Now we only need something that is in the same vein for tooling that generates libraries. I currently am using TSDX but still have a lots of problems with it.
- 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 tooling ecosystem with more focus on efficiency and speed.
In addition to the UX win, and I wish we measured this, but I bet this saved us thousands of dollars in monthly cloud spend.
How is the configuration overhead? Is it relatively easy to get Vite + a custom react app template + tsx + testing up and running?
CRA is bloated, but still one of the fastest ways to get a "full app" up and running with React.
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 imports. I often need to look into the webpack.config.js to understand how everything work. After: Use PostCSS and its tooling for CSS. Yes, there's now a separate process I also need to run in order to watch and build CSS. Yes, I can no longer `import "./style.css"` from the JavaScript files. But it's so much easier to reason about! The CSS tooling creates a CSS file; the JavaScript tooling creates a JavaScript file. Do I want to build SVG sprites? Well, that can very easily be a separate script which I can debug independently and _not_ couple into my builder's plugin system.
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. Once the successor to ESBuild comes out I will most likely be able to point it at index.js and everything will work.
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.
As yet another tiny UI framework creator (forgojs.org), the switch to esbuild-loader was our best developer experience decision. create-forgo-app (our CRA equivalent) takes 3-4 seconds, and running it is instantaneous. Faster builds actually change the way developers write code.
It’s smart though. Despite having built webpack plugins myself, my main gripe with it was how overloaded it became.
I'm not in love but it's a core tool in almost all of my projects, personal and professional.
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.
https://webpack.js.org/blog/2020-10-10-webpack-5-release/#as...
Also if JSX or similar JS extensions are the only thing you need tramspiling for, you might want to look at Sucrase [1] as a fast alternative to Babel.
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.
(Obviously, that's neither here or there when we're talking about baselines for SPAs)
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.
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 need to take into account ligatures etc.
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.
See this[0] for reference. Note how the first byte must fall within a certain range in order to signal being a surrogate pair. This range quite deliberately falls outside the ASCII range. This fact is taken advantage of by JS parsers to make parsing of ASCII substrings faster by special casing that range, since checking for a valid character in the entire unicode range is quite a bit more expensive[1].
IMHO nitpicking about memory consumption of the underlying data structure is a bit meaningless, since the spec doesn't actually enforce any guarantees about memory layout. An implementation can take more memory for pointer to prototype, to cache hash code/length, etc, and there are also considerations such as whether the underlying data structure is polymorphic or monomorphic due to JIT, whether the string is boxed/unboxed, whether it's implemented in terms of C strings vs slices, etc.
Regardless, it doesn't change the fact that the octet sequence "hello world" takes 11 bytes in ASCII/UTF8 encoding (disregarding implementation metadata).
[0] https://github.com/jquery/esprima/blob/0911ad869928fd218371b...
[1] https://github.com/jquery/esprima/blob/0911ad869928fd218371b...
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.
Well they can't get worse than now... 234mb for a friggin hello world app
The hello world app is not going to be this big.
Better to look at how well they solve their problem space.
20:18:01 /tmp > echo 'public class HelloWorld {public static void main(String[] args) {System.out.println("Hello World!");}}' > HelloWorld.java
20:18:09 /tmp > javac HelloWorld.java
20:18:14 /tmp > java -Xmx1m HelloWorld
Hello World!The webdev ecosystem is so broken, it's no wonder so many websites deliver assets that are extremely suboptimally optimised, big unused blobs of assets /scripts slowing page load, optimising it all is actually made harder than coding it all.
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.
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.
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 enough from a bytecode for any arbitrary language that, at least to me the distinction matters. I can accept that it works well enough that most people don't care, even though I suspect most of the use cases for doing so (error checking, type checking) could be better served with linters or editor tools for JS itself.
But the decision to avoid actually writing javascript at all costs has contributed a great deal of complexity in the JS ecosystem, which translates into the bloat in the web that everyone complains about, because all of that javascript is wasting time and cycles simulating other languages.
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?
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.
I added the dependency by writing about three CMake lines.
And after that, it just works, for years.
I may have to add from 2, to 5 dependencies for a project, instead of the myriad of dependencies in JS. And they don't become obsolete and need an update each week.
It's a difference of some orders of magnitude, both in number and in upgrade frequency. This is a huge part of dependency management for me.
And there are C++ package managers like Conan, which solve your requirement of adding a dependency by just using the command line.
I will probably use Conan if I have to write C++ again.
Conan makes much of this easier, but is not really suited for large software projects with the problems mentioned above - in my experience.
About dependencies, if they can be found in the package manager then it goes that way. Else, they are a git submodule.
The most problematic has indeed been the C++ MySQL connector, because it has changed a bit over the last five years, so I had to edit the #include lines in the source code files.
When you are using git submodules as package manager, what do you do if the dependency doesn’t come with CMake files, but with autotools for example?
I think bazel is becoming a great solution for these problems if you align with their philosophy.
It... really doesn't? You generally have an entry point file - which can be any file, you just have to specify it to your build system - and import statements are followed from there on. If anything you could argue the JS build ecosystem is too flexible (which is one of the things esbuild is pushing back against). I've never heard someone criticize it for being too opinionated.
> For extra fun, some libraries don't build with build system a, others require build system b
I've literally never encountered this problem. Library authors virtually always ship least-common-denominator JS that will work without using a build system at all, and then build systems know how to handle lots of different variations of JS and converge them into a single representation. Compatibility is not an issue that exists in my experience.
> The webdev ecosystem is so broken, it's no wonder so many websites deliver assets that are extremely suboptimally optimised, big unused blobs of assets /scripts slowing page load, optimising it all is actually made harder than coding it all.
Now you're just airing your own personal beef which doesn't actually have anything to do with the original topic.
I don‘t mean to discuss which system is too complicated and which is not just to point out a lot of real world build systems are on that level.
Gradle wrapper is just a name for a script (automatically created by Gradle btw) which allows one not to have any kind of Gradle-related tooling installed on the machine (basically, to run build tasks you execute `./gradlew someTask`, and it takes care about downloading and running the appropriate Gradle version) - which I think is a clear benefit over the fact that you need to have `npm` installed system-wide or via a tool like NVM in order to build JS projects.
Gradle has its own warts, and a lot of them, but at least there is only one major build system in this area, and it is simply impossible for a library published to a Maven repo to be dependent on the build system it is built with.
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.
I wouldn’t give up all my structural type inference for the 1:1 you’re describing, but it is tempting.
* 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 making sure polyfills are not added in development
* Making sure you don't import the entirety of libraries like Lodash and MomentJS (prefer date-fns)
* [FUTURE] We'll soon be able to tell Webpack to output ES modules just like Vite [1]
Vite still has many problems:
* It just isn't suitable for proper server-side rendering, we'd need access to chunk names at build time
* It has a weird mix of own and Rollup config settings that seems somewhat unpredictable
* Many open issues regarding module imports, for ex, when a CJS module imports an ES one [2]
Our current bottleneck with Webpack is actually sass-loader, taking at least 70% of the time during a fresh build, and we'd have the same problem with Vite.
Something else that is worth pointing out is the ecosystem: Webpack's community has built tons of plugins for basically any use case you can imagine, and version 5 supports module federation, persistent caching, externals (very handy when doing SSR), customizable filename generators, performance hints, etc etc. Totally different game.
Try to keep your build config simple, avoid too many loaders, plugins, and you should be fine 99% of the time. If you hit a wall, install speed-measure-webpack-plugin to get some help.
[1] https://github.com/webpack/webpack/issues/2933
[2] https://github.com/vitejs/vite/issues?q=is%3Aissue+is%3Aopen...
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.
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...?
I believe that, at this point, people are just nitpicking. When working on a client-side-only app, Vite is faster, but not by that much. In one of our apps, I saw it starting up in 1s compared to 2s with Webpack, and reloads in 100ms compared to 250ms. This is a Preact/TS/Emotion app that outputs almost 7MB of assets, 61 files to be precise, and works on IE11. And I hadn't even tried persistent caching with it yet. Webpack 5 with esbuild is a fast-enough solution.
NextJS is a well-established tool now and version 10.2 uses Webpack 5 under the hood. V11 is looking insanely fast (I suspect they replaced Babel with esbuild, and did some witchery): https://twitter.com/shuding_/status/1378086219708473344.
So yeah, slow performance with Webpack is definitely caused by a bad set of loaders/plugins. Eject a CRA app and you'll see a monster coming out.
You can at later rollup hooks (it doesn't make sense to access chunks that don't exist yet).
Actually, there are SSR frameworks being built on top of Vite such as SvelteKit [1] or vite-plugin-ssr [2] (vite-plugin-ssr is not a framework but gives you a similar DX than Nuxt/Next.js; I'm its author), and many people are implementing custom SSR solutions.
Join our Discord #ssr channel and ask us questions https://discord.gg/PkbxgzPhJv ;-).
vite-plugin-ssr can't even be integrated with Vue Router (I saw you're working on deep integration though). They're both very rigid, early stage endeavours. [2] What happens, for ex, if you used nested lazy components in those pages, are they going to be included in the server render as well?
I mean, fair enough that there are people trying to do better, but it's extremely hard to find the right abstractions for such complex builds and Webpack is definitely on top here.
[1] https://github.com/sveltejs/kit/blob/5c2665ff2280947a2fc6001...
[2] https://github.com/brillout/vite-plugin-ssr/blob/master/src/...
I mean, if you think vite-plugin-ssr to be rigid, then Next.js should feel like a 2sqm prison cell to you ;-).
If you want more flexibility than vite-plugin-ssr then use Vite's native SSR API.
Whereas with webpack: good luck with 1. using two webpack configs (one for Node.js and one for the browser), 2. synchronising between these 2 webpack configs, 3. implementing server-side HMR; it's incredibly painful and can cost you many weeks of dev time... whereas Vite's SSR API does all of this for you for free.
Sure, things are early stage, but saying that webpack is "definitely" on top for SSR is wrong in virtually any possible way.
> 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.
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.
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.
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 handle a set of use cases you have.
I'm sure the next generation of build tools and bundlers will mature over time and we'll all get to enjoy the benefits of es modules, but right now webpack's mature plugin ecosystem, documentation, and stability makes it my default choice.
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 sort of insight into where the time is going, and even then it may not be especially actionable (or at least not obviously so). In our case, we were using a monorepo and we didn't have something like Bazel, so this was painful for backend engineers, data scientists, etc--not just frontend engineers.
Maybe our case was pathological, but we would have saved a ton of time moving to esbuild and building whatever additional features we needed from scratch.
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...
Especially as seeing that there is no good solution (but a lot of attempts at them), I feel it somewhat points to this overcomplexity being a problem central to Webpack.
I’m genuinely curious what simple site would cause a 30+ minute build? Is it just one of those things that grow over time?
Snowpack's latest releases have been... troublesome, but we've stuck with 3.0 and it's been good enough. It completely doesn't support some libraries, but other than that it's been tolerable. Knowing what I know now I probably wouldn't have invested in Snowpack quite yet.
Really hoping Snowpack stabilizes a bit more, or we'll probably just fall back to webpack (or maybe Vite?) again.
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.
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.
Most companies burn money on a total re-write when old tech gets too hard to support. Ember has never accepted this. I love that!
Totally! It's really impressive how they've adapted, evolved, and kept the framework going, so much that one of the most popular websites on the net has trusted it for their core site (linkedin).
I kind of fell into working w/ember because a startup I was at happened to be using it, and then it just became so familiar that I stuck with it. Really happy to see stuff like mho coming out & pushing the framework forward.
Honestly it's so good I wonder if it will undercut Deno a little bit by lowering the barrier for bootstrapping a TypeScript project
I would consider trying it if it has significant performance benefits over a manual Webpack config, especially one making use of esbuild-loader (https://github.com/privatenumber/esbuild-loader)
What is a "proper webpack config".
It's such a complex and arcane beast, that I doubt anyone could really figure out a "proper" way to do anything with it.
I'm sorry but you sound ignorant here. There are a lot of projects that can get away with around ~200 lines of simple Webpack configs.
And yes, Webpack is complex but an important part of that complexity is coming from the intrinsic complexity of the problem we call module bundling. You can see this complexity in older bundling solutions as well.
Regardless of whatever you'd like to believe, a lot of people figured out proper ways to do a lot of things with it. You may not be willing to deal with this yourself, that is understandable, but saying what you are saying about the most popular bundling tool in the ecosystem is a bit much.
I myself regularly write manual Webpack configs and usually ~200 lines of simple configs are enough for me, as well as very performant. And I know a lot of people like me.
Webpack is not perfect, and I'm not really a big fan, but come on. I guess what you have a problem with is people who write terrible Webpack configurations rather than Webpack itself. Maybe think about it.
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.
2. Write a new tool that is dead simple, opinionated (your opinions), convention over configuration, etc
3. Post to HN
4. Achieve adoption
5. As more people use the tool, feature creep ensues
6. In order to satisfy diverse use cases, make everything modular and configurable!
7. Tool slows and becomes impossible to manage
8. GOTO 1.
So, even if it were to support more features, it will still be a net gain over webpack.
Not to mention that vite uses esbuild which is 10-100x faster than next best
I believe esbuild authors (and Vite relies on esbuild in development) are adamant that they are not going to allow feature creep.
Of course the correct way would be to force the dependencies to support es.
But vite has now become default for me as well for new projects.
The only issues I had in the beginning was esbuild's compilation of typescript enums: the import order was off from time to time. Besides that, no issues. I am also super glad I do not need to configure webpack any longer.
(vite-plugin-ssr provides a similar DX than Nuxt/Next.js but as a simple do-one-thing-do-it-well Vite plugin. Vite has a powerful SSR native API which makes not only vite-plugin-ssr's source code lean & small but also enables you to easily implement your custom SSR solution.)
As a side project to investigate upgrading to Vue3 we used Vite and have never looked back. Everyone understands how it works and what the config does (probably because of its built in support for things like SCSS without requiring a chain of configuration) and everything runs much faster.
I still worry that Vite like webpack and other web build systems is doing a lot under the hood and it will get complex to maintain when we want to do something out of the ordinary and a more 'open' build system like Make and an obvious sequence of processing steps would be better.
So, ultimately I think the answer is to say, "No, solve my problem, not yours."
The switchover of build tools in JS land is insane. I get that this has concrete performance improvements over alternatives, but I wonder if the same effort put towards improving an existing toolchain wouldn't get you a lot of similar efforts without breaking everything yet again.
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 established tools such as webpack.
Yes, innovation is good and no one should tell someone what to do in their free time.
But it’s always going to be harder to build on top of old rather than to write something new, but what is new eventually becomes old...and the cycle repeats.
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.
Knowing that pretty much every Python dev knows how to use requests, Django, and NumPy means saving a huge amount of effort in retraining and fighting to pick and choose on choices of ultimately little value.
> Knowing that pretty much every Python dev knows how to use requests, Django, and NumPy
This isn't true, but even if I grant this to be true, you could just as accurately say pretty much every js dev knows node, axios and react.
None of these things compete with each other in any meaningful way.
This is just wrong. Django absolutely occupies the space as Flask, this is pretty obvious, but you're splitting hairs to defend your argument - the bottom line is that a Python developer building a web application has to decide if Django or Flask is a better choice for their engineering needs, you wouldn't use both (though you could, same as you could use react and vue together).
> Web2py is nonexistent
This is totally wrong. You can selectively discard every example that doesn't meet your arbitrary standard of popularity, but I could just as easily discard a criticism of Vite which is far more "non-existent" relative to webpack than web2py is to Django
> Numpy is a basic linear algebra library and Pandas is a high-level tabular data analysis library.
Once again you're splitting hairs. Yes, Pandas and Numpy have different specialties, but there is clear overlap between them and a developer who is unfamiliar with the ecosystem wouldn't necessarily understand why e.g. they might choose pandas dataframes vs numpy arrays, and this dynamic is also true in the JS world where different packages have overlap but particular specialties that make one more attractive than the other depending on the needs.
I believe vite does support cj's dependencies, you would need to file an issue on vite repo on why you are getting the error
Btw I interviewed at Notion but didn’t make the soft skill bar. Big fan of the product.
Vite + Typescript + Tailwind JIT = perfect imo.
If anyone has come up with a workaround, I'd love to here about it.
1. ES modules support has increased to all major evergreen browsers.
2. Esbuild has come out which shows faster results than tools (babel, typescript)
3. Improving current ones means supporting hacks and incorrect code patterns, which is not wanted.
The above factors has resulted in multiple build tools with vite being one of them
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…
This reads as a very acrimonious, biased take. Authors choose the tools they use based on a number of criteria and personal preferences. It's one thing to disagree with them, it's another to project judgement without knowing the why.
I would posit that perhaps they know better than you.
When pure performance is the concern it makes sense to go to a more performant language, like Go. But every time your JavaScript build tool moves away from JavaScript you close yourself off to a huge pool of potential code contributors and make it a lot more difficult to customise. So I think Vite has it just right: optimise the really intensive stuff, leave the rest more available and more editable.
The new transpilers have worked around this problem by introducing various limitations. esbuild plugins literally can't modify the AST. It's basically a way for you to run a command on a string/file. So sure, if you redefine the problem as string transforms rather than AST transforms, you can get an O(N) speedup...
* 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.
The roadblock lies in angular cli. angular cli is webapck based, and angular team will have to dedicate resources for the migration to vite.
Given the situation, i would say, using esbuild with webapck would be more cost effective
My first two thoughts were:
* Imagine all the smart people in webdev world would improve the existing tool rather than create a new one. [0]
* "if you do less, it will go faster". I.e. Vite is young and new, supports a subset of Webpack and of course boasts how fast it is. Yet my repos can't use it because it doesn't has the support it needs for my repo sizes with legacy stuff. Of course it is "on the roadmap" and by the time it will be supported Vite is as slow (if lucky) as Webpack. Doesn't matter though as a new tool will be there long before Vite reaches Webpack..
Yup. Getting old and also cynical in the evenings. Dammit!
A JS library calling a golang js-build tool to get the job done. Too funny.
(p.s. JS is not compiled)
(p.s. I'm aware)