21 ms·

Parcel v2

224 points by jacobwg 5y ago

cetra3 5y ago
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..)
- devit 5y ago
  https://esbuild.github.io/faq/#benchmark-details 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.
  - scottlamb 5y ago
    > 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/ https://parceljs.org/blog/beta3/
  - tuananh 5y ago
    the benchmark looks brutal to other bundler
    - devongovett 5y ago
      Note that this benchmark is dominated by Terser for minification. All tools aside from ESBuild use it.
      - kabber 5y ago
        Why not minify with esbuild instead by default?
        devongovett 5y ago
        esbuild tends to produce larger bundles due to https://github.com/evanw/esbuild/issues/639 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 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.
        kabber 5y ago
        This link https://github.com/privatenumber/minification-benchmarks https://github.com/privatenumber/minification-benchmarks shows swc is still a work in progress.
  - silasb 5y ago
    Probably should add https://bun.sh/ https://bun.sh/ to the list as well, it's early but has some potential.
    - hsn915 5y ago
      Is there any information other than this home page? like an announcement somewhere, a demo video, or anything similar?
    - 1_player 5y ago
      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.
  - isthisreality 5y ago
    to be fair, that's without Parcel 2's cache, which surely improves build times considerably
- hsn915 5y ago
  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).
  - andrew_ 5y ago
    As other comments have mentioned, they use Roll-up under the hood.
  - rk06 5y ago
    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
  - dcre 5y ago
    It uses esbuild for unbundled dev builds and Rollup for bundled production builds. https://vitejs.dev/guide/why.html#why-bundle-for-production https://vitejs.dev/guide/why.html#why-bundle-for-production
  - isthisreality 5y ago
    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).
mrgalaxy 5y ago
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.
- hoten 5y ago
  I switched from Parcel (v1; had trouble upgrading) to esbuild for my web game, and it's been much simpler. And faster, obviously. If you don't care about having a large plug-in ecosystem, or things like image optimization being handled directly by your bundler (and other stuff, from scanning the linked article), I'd say just go with esbuild
  - mrgalaxy 5y ago
    esbuild definitely caught my eye. I'm now noticing they support CSS and static files, which I guess I didn't realize. Is it easy to setup and configure? Because that is the one part of Webpack I cannot stand.
    - hoten 5y ago
      The documentation is top notch. I was able to learn it and switch over to it in about an hour or two for a moderately complex codebase targeting both Node and the web, and using Workers and some code splitting.
    - hsn915 5y ago
      esbuild is not really configuration based like webpack. It takes some config options but you either specify them via the command line or write your own script to build up the config object. (they have a js and go api). It's so much nicer to use than all the other bundlers. EDIT: To clarify, the dev experience is: - You start with just the basic bundler with simple options you specify on the command line or maybe in a shell script. - Then you want to do a few more things, so you turn the shell script into a nodejs script (or a Go program). - You get to make the build script as simple or complex as you want. To your own discretion and to fit your use case.
csense 5y ago
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.
- igreulich 5y ago
  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.
AaronFriel 5y ago
> 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 core.
- izelnakri 5y ago
  controversial comments always make the first page/gets the most attention. I suggest you refrain from them because I found your comment pointless/fake and wrong after using both tools & webpack plugins for many years.
  - AaronFriel 5y ago
    I'm sorry you felt that an observation on the cyclical nature of technology tools was controversial, pointless, fake, and wrong. I think it's pretty impressive if my comment was all of those things.
  - hsn915 5y ago
    I think anyone who has the misfortune of having to deal with webpack knows the pain very well.
    - izelnakri 5y ago
      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.
      - hsn915 5y ago
        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.
jkrubin 5y ago
I would like to see a comprehensive benchmark of parcel v2 and vite.
clmcleod 5y ago
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#issuecomment-926796897 https://github.com/parcel-bundler/parcel/issues/6002#issueco.... We tried switching to Parcel v2 but we had to downgrade back to v1.
- russelg 5y ago
  I also ran into issues like this while trying to migrate to Parcel 2.
dang 5y ago
Previous thread: Parcel 2 Beta 3 – improved build performance - https://news.ycombinator.com/item?id=27222460 https://news.ycombinator.com/item?id=27222460 - May 2021 (69 comments) Also related: Parcel – Fast, zero-configuration web application bundler - https://news.ycombinator.com/item?id=21961963 https://news.ycombinator.com/item?id=21961963 - Jan 2020 (201 comments) Parcel: Fast, zero configuration web application bundler - https://news.ycombinator.com/item?id=17547433 https://news.ycombinator.com/item?id=17547433 - July 2018 (91 comments) Parcel – A fast, zero configuration web application bundler - https://news.ycombinator.com/item?id=15853149 https://news.ycombinator.com/item?id=15853149 - Dec 2017 (163 comments)
- cies 5y ago
  Currently on HN's first page (and related): Esbuild – An extremely fast JavaScript bundler https://news.ycombinator.com/item?id=28860713 https://news.ycombinator.com/item?id=28860713
herpderperator 5y ago
I think https://vitejs.dev/ 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 module repalcement, and pretty error pages when you cause a RuntimeError.
- benatkin 5y ago
  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/guide/api-plugin.html https://vitejs.dev/guide/api-plugin.html
  - devongovett 5y ago
    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. :)
    - benatkin 5y ago
      Good to hear! I'll give it a look.
  - catlifeonmars 5y ago
    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.
    - benatkin 5y ago
nsonha 5y ago
Used v1 mainly for quick prototyping and playing around with new tech (had rust and fable which I was interested in at the time). Look like they've been removed from official support so at least it's no longer zero config to play with. Having said if this turns out to be a low hassle tool to build library then I might use it. My pain point is the boilerplates involved in building libraries. For apps, I'm pretty happy with nextjs default.
fishtoaster 5y ago
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 answer somewhere) showing how to set it up in webpack. Then there's a 50% chance there'll be docs for how to set it up if you're using CRA. And if you're using anything else (eg Parcel), you've got a 30% chance at best to have docs on how to make it work. Hopefully this situation improves as more competitors (like Parcel and Esbuild) mature, but at the moment I'd be pretty hesitant to build on anything that's not webpack or webpack based unless you're a lot more confident figuring out build tool setup from first principles than I am. * V2, about a year ago, since my options were between the non-production-ready v2 and the explicitly unsupported v1.
- toastal 5y ago
  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.
  - devongovett 5y ago
jeswin 5y ago
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.
willio58 5y ago
My team’s been using parcel for Wordpress dev of all things. The switch to v2 has been interesting.. overall very happy with parcel v2 though, it magically fixed a bunch of issues that we just kind of lived with in v1.
taitems 5y ago
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/ https://esbuild.github.io/
- devongovett 5y ago
  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.
- FinalBriefing 5y ago
  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.
  - akvadrako 5y ago
    Vite uses esbuild too. https://vitejs.dev/guide/features.html#jsx https://vitejs.dev/guide/features.html#jsx
  - Xevi 5y ago
    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.
    - FinalBriefing 5y ago
      oh, cool! I didn't realize that. Then yea, I am very impressed by esbuild's performance.
kabes 5y ago
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?
jbverschoor 5y ago
> The zero configuration build tool for the web.JavaScript.CSS.HTML.TypeScript.React.images.SASS.SVG.Vue.libraries.Less.CoffeeScript.Node.Stylus.Pug.Electron.Elm.WebGL.extensions.GraphQL.MDX.XML. Parcel combines a great out-of-the-box development experience with a scalable architecture that can take your project from just getting started to massive production application. Very unclear what it does, until I tried to copy/paste the title. That changing word should just be a list.
- Shish2k 5y ago
  It’s a web build tool, which does basically the same thing as every other web build tool — it takes a bunch of developer-friendly inputs (multiple files, typescript, JSX, scss, raw images) and turns them into browser-friendly outputs (single-file, vanilla JS, vanilla CSS, optimised images) The selling point for parcel is that it does the above with zero configuration (you point it at your input directory and it automatically figures out which compilers / optimisers to use -- other builders typically require hours of googling for / installing / configuring / debugging plugins)

224 points by jacobwg 5y ago

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

devit 5y ago
https://esbuild.github.io/faq/#benchmark-details 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.
- scottlamb 5y ago
  > 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/ https://parceljs.org/blog/beta3/
- tuananh 5y ago
  the benchmark looks brutal to other bundler
  - devongovett 5y ago
    Note that this benchmark is dominated by Terser for minification. All tools aside from ESBuild use it.
    - kabber 5y ago
      Why not minify with esbuild instead by default?
      - devongovett 5y ago
        esbuild tends to produce larger bundles due to https://github.com/evanw/esbuild/issues/639 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 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.
        kabber 5y ago
        This link https://github.com/privatenumber/minification-benchmarks https://github.com/privatenumber/minification-benchmarks shows swc is still a work in progress.
- silasb 5y ago
  Probably should add https://bun.sh/ https://bun.sh/ to the list as well, it's early but has some potential.
  - hsn915 5y ago
    Is there any information other than this home page? like an announcement somewhere, a demo video, or anything similar?
  - 1_player 5y ago
    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.
- isthisreality 5y ago
  to be fair, that's without Parcel 2's cache, which surely improves build times considerably
hsn915 5y ago
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).
- andrew_ 5y ago
  As other comments have mentioned, they use Roll-up under the hood.
- rk06 5y ago
  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
- dcre 5y ago
  It uses esbuild for unbundled dev builds and Rollup for bundled production builds. https://vitejs.dev/guide/why.html#why-bundle-for-production https://vitejs.dev/guide/why.html#why-bundle-for-production
- isthisreality 5y ago
  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).

mrgalaxy 5y ago

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.

hoten 5y ago
I switched from Parcel (v1; had trouble upgrading) to esbuild for my web game, and it's been much simpler. And faster, obviously. If you don't care about having a large plug-in ecosystem, or things like image optimization being handled directly by your bundler (and other stuff, from scanning the linked article), I'd say just go with esbuild
- mrgalaxy 5y ago
  esbuild definitely caught my eye. I'm now noticing they support CSS and static files, which I guess I didn't realize. Is it easy to setup and configure? Because that is the one part of Webpack I cannot stand.
  - hoten 5y ago
    The documentation is top notch. I was able to learn it and switch over to it in about an hour or two for a moderately complex codebase targeting both Node and the web, and using Workers and some code splitting.
  - hsn915 5y ago
    esbuild is not really configuration based like webpack. It takes some config options but you either specify them via the command line or write your own script to build up the config object. (they have a js and go api). It's so much nicer to use than all the other bundlers. EDIT: To clarify, the dev experience is: - You start with just the basic bundler with simple options you specify on the command line or maybe in a shell script. - Then you want to do a few more things, so you turn the shell script into a nodejs script (or a Go program). - You get to make the build script as simple or complex as you want. To your own discretion and to fit your use case.

csense 5y ago

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.

igreulich 5y ago
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.

AaronFriel 5y ago

> 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 core.

izelnakri 5y ago
controversial comments always make the first page/gets the most attention. I suggest you refrain from them because I found your comment pointless/fake and wrong after using both tools & webpack plugins for many years.
- AaronFriel 5y ago
  I'm sorry you felt that an observation on the cyclical nature of technology tools was controversial, pointless, fake, and wrong. I think it's pretty impressive if my comment was all of those things.
- hsn915 5y ago
  I think anyone who has the misfortune of having to deal with webpack knows the pain very well.
  - izelnakri 5y ago
    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.
    - hsn915 5y ago
      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.

jkrubin 5y ago

I would like to see a comprehensive benchmark of parcel v2 and vite.

clmcleod 5y ago

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#issuecomment-926796897 https://github.com/parcel-bundler/parcel/issues/6002#issueco.... We tried switching to Parcel v2 but we had to downgrade back to v1.

russelg 5y ago
I also ran into issues like this while trying to migrate to Parcel 2.

dang 5y ago

Previous thread: Parcel 2 Beta 3 – improved build performance - https://news.ycombinator.com/item?id=27222460 https://news.ycombinator.com/item?id=27222460 - May 2021 (69 comments) Also related: Parcel – Fast, zero-configuration web application bundler - https://news.ycombinator.com/item?id=21961963 https://news.ycombinator.com/item?id=21961963 - Jan 2020 (201 comments) Parcel: Fast, zero configuration web application bundler - https://news.ycombinator.com/item?id=17547433 https://news.ycombinator.com/item?id=17547433 - July 2018 (91 comments) Parcel – A fast, zero configuration web application bundler - https://news.ycombinator.com/item?id=15853149 https://news.ycombinator.com/item?id=15853149 - Dec 2017 (163 comments)

cies 5y ago
Currently on HN's first page (and related): Esbuild – An extremely fast JavaScript bundler https://news.ycombinator.com/item?id=28860713 https://news.ycombinator.com/item?id=28860713

herpderperator 5y ago

I think https://vitejs.dev/ 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 module repalcement, and pretty error pages when you cause a RuntimeError.

benatkin 5y ago
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/guide/api-plugin.html https://vitejs.dev/guide/api-plugin.html
- devongovett 5y ago
  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. :)
  - benatkin 5y ago
    Good to hear! I'll give it a look.
- catlifeonmars 5y ago
  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.
  - benatkin 5y ago

nsonha 5y ago

Used v1 mainly for quick prototyping and playing around with new tech (had rust and fable which I was interested in at the time). Look like they've been removed from official support so at least it's no longer zero config to play with. Having said if this turns out to be a low hassle tool to build library then I might use it. My pain point is the boilerplates involved in building libraries. For apps, I'm pretty happy with nextjs default.

fishtoaster 5y ago

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 answer somewhere) showing how to set it up in webpack. Then there's a 50% chance there'll be docs for how to set it up if you're using CRA. And if you're using anything else (eg Parcel), you've got a 30% chance at best to have docs on how to make it work. Hopefully this situation improves as more competitors (like Parcel and Esbuild) mature, but at the moment I'd be pretty hesitant to build on anything that's not webpack or webpack based unless you're a lot more confident figuring out build tool setup from first principles than I am. * V2, about a year ago, since my options were between the non-production-ready v2 and the explicitly unsupported v1.

toastal 5y ago
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.
- devongovett 5y ago

jeswin 5y ago

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.

willio58 5y ago

My team’s been using parcel for Wordpress dev of all things. The switch to v2 has been interesting.. overall very happy with parcel v2 though, it magically fixed a bunch of issues that we just kind of lived with in v1.

taitems 5y ago

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/ https://esbuild.github.io/

devongovett 5y ago
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.
FinalBriefing 5y ago
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.
- akvadrako 5y ago
  Vite uses esbuild too. https://vitejs.dev/guide/features.html#jsx https://vitejs.dev/guide/features.html#jsx
- Xevi 5y ago
  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.
  - FinalBriefing 5y ago
    oh, cool! I didn't realize that. Then yea, I am very impressed by esbuild's performance.

kabes 5y ago

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?

jbverschoor 5y ago

> The zero configuration build tool for the web.JavaScript.CSS.HTML.TypeScript.React.images.SASS.SVG.Vue.libraries.Less.CoffeeScript.Node.Stylus.Pug.Electron.Elm.WebGL.extensions.GraphQL.MDX.XML. Parcel combines a great out-of-the-box development experience with a scalable architecture that can take your project from just getting started to massive production application. Very unclear what it does, until I tried to copy/paste the title. That changing word should just be a list.

Shish2k 5y ago
It’s a web build tool, which does basically the same thing as every other web build tool — it takes a bunch of developer-friendly inputs (multiple files, typescript, JSX, scss, raw images) and turns them into browser-friendly outputs (single-file, vanilla JS, vanilla CSS, optimised images) The selling point for parcel is that it does the above with zero configuration (you point it at your input directory and it automatically figures out which compilers / optimisers to use -- other builders typically require hours of googling for / installing / configuring / debugging plugins)