In the Ember.js ecosystem there's a really exciting new build tool project called "mho", that replaces webpack and uses a novel strategy running in a service worker to interpret native javascript modules with minimal overhead & near instant rebuilds (disclaimer I'm not familiar with how snowpack works under the hood).
Why we switched from Webpack to Vite
121–130 of 229 posts
Re: Why we switched from Webpack to Vite
#122Earlier quoted context omitted.
Python is a C core that takes Python code and spits out bytecode to interpret and run said Python. What esbuild is doing is not much different than any other interpreted language. (p.s. JS is not compiled)
It's not much different but yet it needs a solution built in another language to "build" it. I understand the process is not much different from other scripted languages but I find it funny that JS cannot reasonably do this itself. (p.s. I'm aware)
Well, it's wrong to say that it "can't reasonably do this itself" since JS building itself is actually the status quo and has been for years, this particular solution is just a new take with an aim for improved performance.
Re: Why we switched from Webpack to Vite
#123My 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.
...which is essentially cargo cult programming, since browsers work in an entirely different way (perhaps with the exception of WASM because of how it's designed).
Re: Why we switched from Webpack to Vite
#124Earlier 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. 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 is…
> 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?
Re: Why we switched from Webpack to Vite
#125What 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?
Re: Why we switched from Webpack to Vite
#126Earlier quoted context omitted.
They probably mean that "hello world".length == 11 // bytes
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.
But why would you? This is the silliest way to judge something ever: what practical web application is anyone routinely building with no CSS, web workers etc.
Re: Why we switched from Webpack to Vite
#127Author 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 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.
Re: Why we switched from Webpack to Vite
#128Earlier quoted context omitted.
You still need webpack for production build :). So all is good.
Why can't you use esbuild for production builds ?
Tree shaking isn't sorted, so can't currently get an bundle optimised to same extent as you do with Webpack/Rollup et al. It'll come, but not quite there yet.
Re: Why we switched from Webpack to Vite
#129Earlier quoted context omitted.
They probably mean that "hello world".length == 11 // bytes
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)
Re: Why we switched from Webpack to Vite
#130I wonder why all these new bundlers don't provide a webpack-compatible API to entice new users. I can't take the risk of investing in a new tool only to find that I can't migrate the last 20% key features that I need. I also don't have the bandwidth to constantly switch between vite, webpack, parcel, etc. every time I switch to a different project.
Snowpack (which also uses esbuild internally) has a webpack compatibility extension: https://www.npmjs.com/package/@snowpack/plugin-webpack -
FWIW that plugin does not make your existing webpack-based code magically work in snowpack. It's just using webpack to bundle your snowpack-based code.