Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parcel v2

parceljs.org

Post reply on HN
Print view View original

61–70 of 103 posts

Re: Parcel v2

#61

Post by FinalBriefing »

meowtimemania wrote: post #35
fishtoaster wrote: post #19

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.

This has been my experience, too. Great for getting started quickly on straight-forward projects or prototyping, but even simple projects hit snags.

If you're certain it covers all of your requirements out of the box, it's a great option. Otherwise...you're probably better off configuring Webpack from the start. I've never hit an issue with Webpack that can't be solved (an likely it has already been solved by someone else).

Re: Parcel v2

#62

Post by sk55 »

fishtoaster wrote: post #19

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…

This echoes my experience as well.

Re: Parcel v2

#63

Post by nextaccountic »

AaronFriel wrote: post #8

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

Who cares? As long as the tools are improving, this shouldn't matter.

Re: Parcel v2

#64

Post by foota »

AaronFriel wrote: post #8

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

At least the core gets better with each new system :-) I joke, but only somewhat.

Re: Parcel v2

#65

Post by taitems »

I was put onto the incredibly fast esbuild[1] by a colleague and have used it here and there for open source packages. I'd been keen to understand which release of Parcel v2 they benchmarked against as they claim 0.37s to 39.28s on their home page?

[1] https://esbuild.github.io/

Re: Parcel v2

#66

Post by FinalBriefing »

duiker101 wrote: post #50
AnonHP wrote: post #47

Earlier quoted context omitted.

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…

The other day I was playing around with parcel V2 and I ended up having to write a config file for something that I believe was included in v1... The whole point of parcel for me was avoiding config files... I feel like this release is missing the point

I think they discovered that if a library tries to provide "zero config", users quickly end up needing to configure something, or reconfigure something else.

I still don't think that Parcel is right for me given how comfortable I am with Webpack, but I welcome a "simpler config" option. Provide language support, but don't assume I want to use Babel, or PostCSS, or any other build tool.

Re: Parcel v2

#67

Post by FinalBriefing »

taitems wrote: post #65

I was put onto the incredibly fast esbuild[1] by a colleague and have used it here and there for open source packages. I'd been keen to understand which release of Parcel v2 they benchmarked against as they claim 0.37s to 39.28s on their home page? [1] https://esbuild.github.io/

Those are some really impressive numbers.

I was really impressed with the speed of Vite, which uses Rollup under the hood. I never had any real complains about Webpack's speed until I tried Vite out. In my experience with Vue apps, the difference between Vite (Rollup) and Webpack was much greater than esbuild's data shows.

Re: Parcel v2

#68

Post by devongovett »

taitems wrote: post #65

I was put onto the incredibly fast esbuild[1] by a colleague and have used it here and there for open source packages. I'd been keen to understand which release of Parcel v2 they benchmarked against as they claim 0.37s to 39.28s on their home page? [1] https://esbuild.github.io/

I commented elsewhere in this thread but that benchmark is really measuring the performance of Terser, which is used by all of the other tools listed there. Parcel has improved somewhat since that benchmark was last updated but until terser is replaced there’s no competition.

Re: Parcel v2

#69

Post by kabes »

So, with most of this discussion leaning towards esbuild/vite because it's simpler and much faster. What are the reasons one would use parcel instead of esbuild?

Re: Parcel v2

#70

Post by k3liutZu »

jjeaff wrote: post #48
AaronFriel wrote: post #8

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

I could be wrong, but I don't think webpack ever "just worked" right out of the box to the extent that parceljs does. I was in the middle of all kinds of gulp and webpack configuration when I discovered parcel a few years ago. A single command "parcel watch *.html" just worked. It detected that I was using react, followed the js includes and all the other dependencies and handled hot reloading and typescript and all…

> My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack.

Uff, really hits the nail on the head from my experience with setting projects in the early webpack days.

Post reply on HN