Live data from Hacker News

Parcel v2

parceljs.org

71–80 of 103 posts

Re: Parcel v2

#71
post #25

Earlier quoted context omitted.

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

> 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. You don’t actually need any of these tools. But HMR is useful not because build time is slow (even if it often is), but because dev/validation iteration is slow too. TDD can improve some of that, but when you’re iterating on something interactive and want to validate the experience…

What do you mean by "dev/validation iteration"?

Re: Parcel v2

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

Is there any information other than this home page? like an announcement somewhere, a demo video, or anything similar?

Re: Parcel v2

#73
post #71

Earlier quoted context omitted.

> 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. You don’t actually need any of these tools. But HMR is useful not because build time is slow (even if it often is), but because dev/validation iteration is slow too. TDD can improve some of that, but when you’re iterating on something interactive and want to validate the experience…

What do you mean by "dev/validation iteration"?

Say you're developing a big form with lots of different inputs. When you're iterating on the form you don't want to lose all your form state because you edited some code.

When you make the change you want to see what that change does to your form in its current state.

Re: Parcel v2

#74
post #59

Earlier quoted context omitted.

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

Note that Devon Govett, who you replied to, is the main driving force behind Parcel.

Re: Parcel v2

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

Vite uses esbuild too.

https://vitejs.dev/guide/features.html#jsx

Re: Parcel v2

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

Vite only uses Rollup for the production build step. During development it uses ESBuild for pre-bundling, and then serves everything as native ESM, that's why it's so fast. They might get rid of Rollup in the future if ESBuild gains more features.

Re: Parcel v2

#77
post #29

Earlier quoted context omitted.

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?

>A free open source tool exists for you to use if it suits your needs.

I do not believe that webpack suits my needs, it is in my opinion incredibly inferior to Gulp. So Gulp suits my needs.

Nonetheless I have had to basically use nothing but webpack for the last 5-6 years unless I do something for myself! Why is that?

Well it turns out that when I go to work at some place they have set up everything with webpack, why? Well that's what everybody else does, nothing we can do about it now. Hardly anyone in the real world only uses tools because they suit their needs, they use the tools that have been chosen by someone else.

Ok, so then something goes wrong with webpack build, anyone at the place know the depths of webpack and how every different plugin/module is screwed together - nope, we use webpack here but have no webpack experts - so they spend some days fixing things. Or even worse we want something that there is no webpack solution for that we can find - either we need to fix it ourselves with a plugin / module / fork of plugin module we want to extend (after asking fruitlessly on StackOverflow if someone knows) or we have to do a horrible hack to fix it.

I am sure there are some webpack experts out there who take minutes to fix problems they encounter in webpack, but my experience is that a webpack problem any more complex than we don't have a plugin for that file extension seems to require a developer day to fix (not just me as the developer, other developers always seem to take the same amount of time).

now before someone jumps in and cleverly changes my complaints to use Gulp instead of webpack (if you weren't thinking of doing this you can stop reading now) - can you point out to having a similar experience with gulp? Because I can't, and if I wanted to write a gulp plugin (which I have done twice) it was insanely easy because all you have to do is to understand vinyl streams and that's it; everything in Gulp has the same model of how things work - that really speeds up problem solving time.

Re: Parcel v2

#78
post #48

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

And also go to a vacation at every release, because your config uses plugins that a) can’t keep up, b) can’t help but break previous version compat, and now it’s snafu for few months. And for beginners, good luck finding out the correct set of versions that support what you need simultaneously. One LARGE upside of all-in-one include-all packages is that you can’t find yourself in that sort of a gridlock.

Re: Parcel v2

#79

Earlier quoted context omitted.

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

>A free open source tool exists for you to use if it suits your needs. I do not believe that webpack suits my needs, it is in my opinion incredibly inferior to Gulp. So Gulp suits my needs. Nonetheless I have had to basically use nothing but webpack for the last 5-6 years unless I do something for myself! Why is that? Well it turns out that when I go to work at some place they have set up everything with webpack, why…

I'm still not understanding the problem. If webpack doesn't suit your needs then don't use it. If your employer's technical leadership picks technologies based on fashion rather than suitability for the problem that's not a failure of the technology, that same problem surrounds literally every popular technology irrespective of its technical properties.

Re: Parcel v2

#80
post #74
post #59

Earlier quoted context omitted.

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

Note that Devon Govett, who you replied to, is the main driving force behind Parcel.

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 than Webpack to be clear (and talking about the woes from Webpack was the main reason I commented). Now esbuild is on the front page and we can see some users saying it was a smart switch away from Webpack (https://news.ycombinator.com/item?id=28861732)

Post reply on HN