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

201–210 of 229 posts

Re: Why we switched from Webpack to Vite

#201

Post by arvinsim »

EvanYou wrote: post #127

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…

ViteJS is really faster compared to CRA that I previously used. It's really a breath of fresh air. Thanks for creating it!

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.

Re: Why we switched from Webpack to Vite

#202

Post by Secretmapper »

ballenf wrote: post #49
sunflowerdeath wrote: post #43

I have tried to use esbuild, and over the past 3 months I had at least a dozen times when it has compiled incorrect code that doesn't work or doesn't do what it's supposed to do. So despite the performance benefits, I was forced to go back to webpack, babel, and terser.

Any specific scenarios where it fails? We're using it across a wide codebase and several teams and I haven't seen or heard that issue.

For me personally, it's mainly CJS imports which I can't drop.

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.

Re: Why we switched from Webpack to Vite

#203

Post by sagacity »

nojvek wrote: post #186
EvanYou wrote: post #127

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…

Just want to say how coincidental it is to have Evan You for vite + vue, and Evan Wallace for esbuild and Figma. Long prosper the Evans :)

It seems you are quite the Evangelist.

Re: Why we switched from Webpack to Vite

#204

Post by azangru »

joshwa wrote: post #145

Ah, the classic build tool evolution cycle! 1. Become frustrated with complex build tool 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…

> feature creep ensues

I believe esbuild authors (and Vite relies on esbuild in development) are adamant that they are not going to allow feature creep.

Re: Why we switched from Webpack to Vite

#205

Post by eliseumds »

brillout wrote: post #193
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 just isn't suitable for proper server-side rendering, we'd need access to chunk names at build time 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…

Have you seen SvelteKit's source code? It looks like a toy project. [1]

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

Re: Why we switched from Webpack to Vite

#206

Post by girvo »

judofyr wrote: post #54
JMTQp8lwXL wrote: post #20

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

It’s funny to me that we’ve sort of ended up back where I started with Browserify and a seperate Less compile step, or even further back with require.js in some ways.

It’s smart though. Despite having built webpack plugins myself, my main gripe with it was how overloaded it became.

Re: Why we switched from Webpack to Vite

#207

Post by eliseumds »

viklove wrote: post #179
jeswin wrote: post #176

Earlier quoted context omitted.

This is excellent advice. There's something I really dislike about import "./style.css" into JS files - it just seems meaningless especially if you've worked with other languages/ecosystems. A great many tutorials default to this style, so it'll likely live on for a while. As yet another tiny UI framework creator (forgojs.org), the switch to esbuild-loader was our best developer experience decision. create-forgo-app…

One great problem it solves is namespacing all of your styles. I don't have to worry about classname collisions because the bundle handles it all for me. Instead of having one massive global stylesheet, I have a bunch of small, modular stylesheets that fit entirely on my display without scrolling, and I can reason about the output much easier than before.

Plus effortless code splitting.

Re: Why we switched from Webpack to Vite

#208

Post by lhorie »

IggleSniggle wrote: post #185
lhorie wrote: post #156

Earlier quoted context omitted.

No need to overcomplicate though. None of this applies to the ascii range, and we're just talking about storage in disk in the first place.

The 2-bit part applies, if not the rest, and it’s not really “on disk” but rather “memory for data type,” right? 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 thread was originally about CRA vs Vite size on disk (or implicitly, if we're applying it to real world applications, network cost in CI job startup times). And like I said, surrogate pairs don't apply to ASCII.

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

Re: Why we switched from Webpack to Vite

#209

Post by [deleted] »

vijaybritto wrote: post #32
JMTQp8lwXL wrote: post #20

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

You still can do polyfills manually via browserify packages

[deleted]

Re: Why we switched from Webpack to Vite

#210

Post by eliseumds »

RobertKerans wrote: post #128
simlevesque wrote: post #111

Earlier quoted context omitted.

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.

Correct.
Post reply on HN