Live data from Hacker News

Why we switched from Webpack to Vite

blog.replit.com

161–170 of 229 posts

Re: Why we switched from Webpack to Vite

#161
post #121

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). https://github.com/ef4/mho https://www.youtube.com/watch?v=09USvAy7w9g https://sqwok.im/p/TleLmpJ9BF…

I used to not get Ember but of all the frameworks its users love it the most. I remember when Ember was the "cool" framework almost ten years ago. The community has evolved it and kept it relevant which is truly impressive. Ember entered the world at a time Backbone.js was cutting edge. Ember is still relevant and has adopted modern best practices, moved to TypeScript, and most importantly provided an easy upgrade pa…

> 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.

Re: Why we switched from Webpack to Vite

#162
post #160
post #47

Earlier quoted context omitted.

Hate to break it to you but Clojurescript, Elm and the whole paradigm of "compile to JS" languages are part of what is broken about the javascript ecosystem. So much unnecessary complexity and energy wasted making javascript pretend to be something it isn't and to make it do things it was never meant to do, pressing a small, simple and powerful scripting language into the service of the profane eldritch abomination t…

Hate to break it to you, but what you call "Enterprise Development" is really just "large software projects", for which many find the "simple and powerful scripting language" inadequate.

But those projects use that "simple and powerful scripting language" anyway, so clearly it is adequate.

Re: Why we switched from Webpack to Vite

#163

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 ob…

Apropos of that, Yarn allows use of Prolog to ensure constraints across dependencies

Re: Why we switched from Webpack to Vite

#164

Webdev 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…

FE web developer is one of a kind and there are good reasons for that. I keep seeing the same responses pop up all the time so I decided to write my thoughts down on why FE web dev is a black swan in software development: https://erock.io/2021/03/27/my-love-letter-to-front-end-web-...

Re: Why we switched from Webpack to Vite

#165

Earlier quoted context omitted.

> 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?

I wasn’t a frontend developer, so I’m not familiar with the details, but it seemed to be pretty slow from the start, but compounded as our app grew in size. I.e., there was some large coefficient associated with our web pack configuration.

How large was the bundle at the end? I'm not going to claim that webpack is fast for large applications, but I've never seen a build take longer than 3 minutes and this is for applications where our own source code was at the MB scale.

Re: Why we switched from Webpack to Vite

#166
post #162
post #160

Earlier quoted context omitted.

Hate to break it to you, but what you call "Enterprise Development" is really just "large software projects", for which many find the "simple and powerful scripting language" inadequate.

But those projects use that "simple and powerful scripting language" anyway, so clearly it is adequate.

Are you using JavaScript when you are using TypeScript? I guess so, to some degree. The additional tooling complexity is just not that significant compared to the gains of a language that compiles to JavaScript vs using vanilla JavaScript.

Re: Why we switched from Webpack to Vite

#167
post #89

Earlier quoted context omitted.

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 p…

It isn't contrariarism. The end result is that most JS libraries are immature, have complex edge cases that can only be fulfilled by one package but not from another similar package, and that old packages don't evolve to adapt to new paradigms.

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.

Re: Why we switched from Webpack to Vite

#168

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?

Do you mean testing Vite itself or incorporating jest for frontend stuff as a build step?

Re: Why we switched from Webpack to Vite

#169

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…

If someone is already comfortable with webpack or something else and has no complaints or issues with it, how would you sell them on trying vite?

At this point I don't think I really want to "sell" it to anyone. I've got enough things to maintain so I'd rather just have users who use Vite because they actually like it rather than people switching from webpack just out of FOMO.

Re: Why we switched from Webpack to Vite

#170
post #165

Earlier quoted context omitted.

I wasn’t a frontend developer, so I’m not familiar with the details, but it seemed to be pretty slow from the start, but compounded as our app grew in size. I.e., there was some large coefficient associated with our web pack configuration.

How large was the bundle at the end? I'm not going to claim that webpack is fast for large applications, but I've never seen a build take longer than 3 minutes and this is for applications where our own source code was at the MB scale.

I don’t recall. We split it into multiple bundles in hopes of improving speed, but I don’t know the sizes in any case.
Post reply on HN