Live data from Hacker News

Parcel v2

parceljs.org

51–60 of 103 posts

Re: Parcel v2

#51
post #28
post #2

I moved from Parcel (v1) to ViteJS because it felt a bit faster. Is there a performance or other type comparison between Parcel and some of the newer bundlers? (I.e, vite, snowpack, etc..)

I really don't understand vite. They use esbuild under the hood for some of the tasks, but they still ultimately use rollup. I tried to use it for a project I'm working on and it was more than 50 times slower than esbuild. (esbuild took half a second, vite took 30 seconds).

Vite's main focus is on a fast dev server and provide ultra fast hmr.

However, it needs source (user code and npm packages) to be in ESM modules, so it uses esbuild for pre bundling npm packages.

And vite uses roll-up to create a production build with some parts done by esbuild

Re: Parcel v2

#52
post #28
post #2

I moved from Parcel (v1) to ViteJS because it felt a bit faster. Is there a performance or other type comparison between Parcel and some of the newer bundlers? (I.e, vite, snowpack, etc..)

I really don't understand vite. They use esbuild under the hood for some of the tasks, but they still ultimately use rollup. I tried to use it for a project I'm working on and it was more than 50 times slower than esbuild. (esbuild took half a second, vite took 30 seconds).

It uses esbuild for unbundled dev builds and Rollup for bundled production builds.

https://vitejs.dev/guide/why.html#why-bundle-for-production

Re: Parcel v2

#53

Earlier quoted context omitted.

vite uses Rollup, and I think it's probably better too. When I see zero configuration I become less interested in a project, because I like being able to configure things. Edit: I found this on Vite's website: "Vite plugins extends Rollup's well-designed plugin interface with a few extra Vite-specific options. As a result, you can write a Vite plugin once and have it work for both dev and build." https://vitejs.dev/g…

I don’t think zero configuration is mutually exclusive with full configuration control. Zero config is often just a design exercise in setting reasonable defaults on top of a configurable system.

It could be argued that Vite is zero config because it allows you to go without a configuration file, but it says "zero config" nowhere on the site. It isn't because I want there to always be some configuration that I avoid zero config, it's because I've seen some projects like Next.js reject requests for a configuration setting that I thought were good and it has turned me off to the idea of "zero config". https://github.com/vercel/next.js/issues/7315 https://github.com/vercel/next.js/issues/1109 https://github.com/vercel/next.js/issues/13268

Re: Parcel v2

#54
post #47

> An all new plugin system, which makes Parcel fully extensible. This allows Parcel to scale from small side projects to massive production applications with complex build requirements. Everything old is new again! Parcel embarks on the path that Webpack did, and it's only a matter of time before the plugins are doing more and more core work, and Parcel's successor will again rewrite them and bring those in to the co…

This comment by @stupidcar (December 5, 2017) [1] from the first Parceljs post seems pertinent. I’m not pasting the entire comment; visit the link below to read it: > The eternal cycle of developer tool bullshit: > 1. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!" > 2. "Introducing SuperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge…

I guess the whiggish interpretation is that if each step is an improvement then the cycle represents steady progress, if not arrived at as directly as could be hoped. Maybe a cynic says that the extensions are negative-sum, or the rewrite is (either to adopting teams, or to a fragmented wider community.)

I'm an optimist, though admittedly entirely ignorant of this project. I think some capacity is sometimes lost when new projects are started with new technologies that don't live up to their predecessors, but that accusations of tool choice being fashion-driven are mostly misplaced. There are real, tangible, frequent improvements, and disruption is probably the price of innovation. And it's a price you can mostly avoid paying if you want to keep using what you're using.

Re: Parcel v2

#55

Earlier quoted context omitted.

vite uses Rollup, and I think it's probably better too. When I see zero configuration I become less interested in a project, because I like being able to configure things. Edit: I found this on Vite's website: "Vite plugins extends Rollup's well-designed plugin interface with a few extra Vite-specific options. As a result, you can write a Vite plugin once and have it work for both dev and build." https://vitejs.dev/g…

Parcel 2 does both: it is useful out of the box, and many projects will never need to configure it, but v2 adds a complete plugin system that lets you override and configure everything too. :)

Good to hear! I'll give it a look.

Re: Parcel v2

#56
post #5

Earlier quoted context omitted.

the benchmark looks brutal to other bundler

Note that this benchmark is dominated by Terser for minification. All tools aside from ESBuild use it.

Why not minify with esbuild instead by default?

Re: Parcel v2

#57
post #4

Anyone here switch from Webpack to Parcel? Or, look into switching and decided not to? I recently upgraded Webpack from 4 to 5 and briefly looked for alternatives, but ultimately just decided to stick with Webpack since it works for us.

Moved from webpack to esbuild + postcss. Forced us to reduce our dependencies, and it also improved our iteration speed. Of course that comes with dropping the need for core-js and focusing on evergreen browsers that esbuild targets.

Re: Parcel v2

#58
post #56

Earlier quoted context omitted.

Note that this benchmark is dominated by Terser for minification. All tools aside from ESBuild use it.

Why not minify with esbuild instead by default?

esbuild tends to produce larger bundles due to https://github.com/evanw/esbuild/issues/639. Looks like there was recent activity though, so we need to re-test. Anyway, there's a plugin available for now: https://www.npmjs.com/package/@parcel/optimizer-esbuild. We're also excited about the SWC minifier project, which is basically a port of Terser to Rust.

Re: Parcel v2

#59
post #32

Earlier quoted context omitted.

My experience with the “Webpage tax” is every couple of weeks when I upgrade build tooling around one of my Webpack Workspaces, something somewhere silently breaks in the system outputs an exit 0 but with fundamental mistakes. Last week and experimental flag was implicitly enabled with a Webpage version upgrade that broke MiniCSSExtraPlugin (which why at v5 is this still a thing to output CSS as not JS?) and all of a…

Note that Parcel’s plugin system is completely different in v2 and the implicit loading is gone.

That wasn't my experience, but it's been several months since I tested v2. I may have had to specify which plugins to use, but downloading of random binaries was an issues -- albeit this is a larger NPM ecosystem issue assuming read-write capabilities, glibc, x86_64 arch, etc. I've even made some small contributions to Parcel, its blog, and wrote a plugin, but this was before I started using Nix for a lot of things and node-gyp does not like to play well.

That said, I very much preferred Parcel to Webpack as the JSON5 config was declarative and simpler and the HTML entry point.

Re: Parcel v2

#60
post #56

Earlier quoted context omitted.

Why not minify with esbuild instead by default?

esbuild tends to produce larger bundles due to https://github.com/evanw/esbuild/issues/639 . Looks like there was recent activity though, so we need to re-test. Anyway, there's a plugin available for now: https://www.npmjs.com/package/@parcel/optimizer-esbuild . We're also excited about the SWC minifier project, which is basically a port of Terser to Rust.

This link https://github.com/privatenumber/minification-benchmarks shows swc is still a work in progress.
Post reply on HN