Live data from Hacker News

Parcel v2

parceljs.org

31–40 of 103 posts

Re: Parcel v2

#31
post #29

Earlier quoted context omitted.

Webpack is a pain to use I agree, I've never liked webpack. My comment is on the behavior of trying to look smart/funny(meme-y) while lacking actual substance.

When A points out a real problem, and B comments with "old man yelling at cloud". Who's the one exhibiting "problematic" behavior? I think it's B.

A free open source tool exists for you to use if it suits your needs. What exactly is the "real problem" here?

Re: Parcel v2

#32

I set up a new project on Parcel*. It was amazing at first for getting going quickly with minimal config, but became increasingly expensive to deal with. Every week or so I'd run into what I'm calling the "webpack tax" where I'd spend twice as long having to figure out how to do something as the price for not using webpack. Every tool out there has a 95% chance of having docs (or at least a blogpost or StackOverflow…

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 sudden I had no styles. It's in the CHANGELOG for a minor version bump but running NPM/Yarn upgrade gave me a broken build, and trying to tweak my build scripts to find the problem, I got styles outputting but no JavaScript was built. And this has happened on multiple occasions every couple of weeks/months where minor version upgrades to plugins gave me an exit 0 broken build.

Parcel’s implicit plugin loading with node-gyp and randomly-dowloading-from-the-internet binaries system (rightfully) does not play well with Nix.

Considering I’m not even leveraging code splitting or many of Webpack’s advanced features, I’m now investigating the cost of switching to something built on esbuild to lessen my Webpack burden and get much better build performance. Honestly makes me miss Tup and Make as front-end tooling exploded with complexity.

Re: Parcel v2

#33
post #29

Earlier quoted context omitted.

Webpack is a pain to use I agree, I've never liked webpack. My comment is on the behavior of trying to look smart/funny(meme-y) while lacking actual substance.

When A points out a real problem, and B comments with "old man yelling at cloud". Who's the one exhibiting "problematic" behavior? I think it's B.

[deleted]

Re: Parcel v2

#34
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).

As other comments have mentioned, they use Roll-up under the hood.

Re: Parcel v2

#35

I set up a new project on Parcel*. It was amazing at first for getting going quickly with minimal config, but became increasingly expensive to deal with. Every week or so I'd run into what I'm calling the "webpack tax" where I'd spend twice as long having to figure out how to do something as the price for not using webpack. Every tool out there has a 95% chance of having docs (or at least a blogpost or StackOverflow…

What things are you trying to do that’s not supported with parcel? I think sometimes we make super complex front end build configurations that don’t yield much benefit over something more simple.

Re: Parcel v2

#36
For a while now, I've been using esbuild (swc is an option too) and a few basic shell scripts. I don't miss anything, other than being able to take a break while build happens.

Re: Parcel v2

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

If you and your team know Webpack and the ecosystem of plugins well already, then stick with that. Setting up a new project does not take a lot of time for you I guess. Someone mentioned "webpack tax" when using Parcel, it is real. Parcel is nice, I like it, but you get more control with Webpack.

Re: Parcel v2

#38
post #32

I set up a new project on Parcel*. It was amazing at first for getting going quickly with minimal config, but became increasingly expensive to deal with. Every week or so I'd run into what I'm calling the "webpack tax" where I'd spend twice as long having to figure out how to do something as the price for not using webpack. Every tool out there has a 95% chance of having docs (or at least a blogpost or StackOverflow…

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.

Re: Parcel v2

#39

I think https://vitejs.dev/ is better. It pulls in a much smaller set of packages for a hello-world non-CRA react app. I think it was something like 1.3k lines of yarn.lock for Vite vs 6k lines for Parcel v2. JS projects shouldn't be bloated, even if this would get optimized-out for production. In the ideal world, you would use esbuild only, but you still need the other features for development: hot reload, hot modul…

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

Re: Parcel v2

#40
post #37
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.

If you and your team know Webpack and the ecosystem of plugins well already, then stick with that. Setting up a new project does not take a lot of time for you I guess. Someone mentioned "webpack tax" when using Parcel, it is real. Parcel is nice, I like it, but you get more control with Webpack.

This was true in Parcel 1, but v2’s plugin system is just as powerful as webpack’s. v2 is all about adding extensibility and control.
Post reply on HN