Live data from Hacker News

Parcel v2

parceljs.org

91–100 of 103 posts

Re: Parcel v2

#91
post #20
post #3

Earlier quoted context omitted.

https://esbuild.github.io/faq/#benchmark-details has Parcel 2 benchmarks. The summary is that you should use esbuild (or swc/spack when ready) for new projects and probably switch existing ones as well if feasible. It's possible that the Parcel 2 version they used is not the released one, so maybe it improved.

Probably should add https://bun.sh/ to the list as well, it's early but has some potential.

Doesn't seem to be open source, only has a macOS binary, you need to request "early access" by joining their Discord... what's their target audience here? Certainly not web developers.

Re: Parcel v2

#92

It’s worth noting that Parcel v2 still needs work to support some basic use cases. For instance, it does not correctly build a Sass file that pulls in Bootstrap imports from NPM: https://github.com/parcel-bundler/parcel/issues/6002#issueco... . We tried switching to Parcel v2 but we had to downgrade back to v1.

I also ran into issues like this while trying to migrate to Parcel 2.

Re: Parcel v2

#93
So what exactly is Parcel? The website says it has "a new JavaScript compiler written in Rust" but I thought JavaScript was an interpreted language?

The JavaScript ecosystem is so dang confusing. I'm glad I'm not a frontend dev who has to deal with that hot mess.

Re: Parcel v2

#94
post #82
post #80

Earlier quoted context omitted.

And? I just looked up my old package.json and see the NPM script use `parcel build --no-autoinstall ...` and a pinned version `2.0.0-beta.3.1` which to me says there some genuine autoinstall going on, which is what I meant by "implicit plugin loading", loading/installing some plugins from the ether. Perhaps my wording wasn't clear, but it still was an issue for me. Parcel in my experience still came with less issues…

Just thought the additional context could help the conversation :)

Also as the esbuild thread alluded, Phoenix (Elixir) and Rails alpha are switching to esbuild because of how many issues were raised in their projects related to things breaking in the Webpack tooling.

Re: Parcel v2

#95
post #93

So what exactly is Parcel? The website says it has "a new JavaScript compiler written in Rust" but I thought JavaScript was an interpreted language? The JavaScript ecosystem is so dang confusing. I'm glad I'm not a frontend dev who has to deal with that hot mess.

Calling it a compiler is not great IMO, but it is a js bundler/transpiler.

You set it up, and write your js code, and parcel spits out the final, ready to embed in your html file, js and css assets.

That's oversimplified, but the basics all the same.

Re: Parcel v2

#96
post #3
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..)

https://esbuild.github.io/faq/#benchmark-details has Parcel 2 benchmarks. The summary is that you should use esbuild (or swc/spack when ready) for new projects and probably switch existing ones as well if feasible. It's possible that the Parcel 2 version they used is not the released one, so maybe it improved.

to be fair, that's without Parcel 2's cache, which surely improves build times considerably

Re: Parcel v2

#97
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 goal is a mixture of speed and flexibility. Rollup's plugin system provides the flexibility in exchange for slower build times, but that doesn't affect development speed, because Vite doesn't bundle anything in development (apart from CommonJS dependencies, which are pre-bundled with esbuild).

Re: Parcel v2

#98
post #25

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…

In the real world, you can use esbuild only. You actually don't need hot reload or hot module replacement. esbuild is so fast you can just reload the page and it reloads instantly. hot reload is really bad with slow bundlers. One of the projects I have to maintain at work has this hot reload feature. Here's how it goes: I edit a sass file, it recompiles in the background for 5 seconds, then reloads 4 or 5 times. Why?…

Sounds like you have auto save on.

Re: Parcel v2

#99
post #3
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..)

https://esbuild.github.io/faq/#benchmark-details has Parcel 2 benchmarks. The summary is that you should use esbuild (or swc/spack when ready) for new projects and probably switch existing ones as well if feasible. It's possible that the Parcel 2 version they used is not the released one, so maybe it improved.

> It's possible that the Parcel 2 version they used is not the released one, so maybe it improved.

I'd guess so because of timing and because the Parcel 2 beta 3 announcement [1] says "10x faster JavaScript compiler written in Rust [...] on top of the SWC compiler". Likely the esbuild folks benchmarked against beta 2 or earlier.

[1] https://parceljs.org/blog/beta3/

Re: Parcel v2

#100
post #84

Earlier quoted context omitted.

Are you serious? Here's how you sound to me: My poop is on the street. If you like it, you can use it. If you don't like, don't use it. What's your problem? If someone shoves my poop down your throat and you don't like it, that's not a failure of my poop. That's a failure of human relationships.

Your analogy is laughably absurd. Poop on the street is a public health hazard, someone shoving poop down your throat is assault. Comparing such things to free open-source software is borderline trolling.

Isn't it great that you can refute any analogy by finding a literal difference between the analogy and thing being explained?
Post reply on HN