12 ms·

Parcel 2 Beta 3 – improved build performance

248 points by bpierre 5y ago

bionhoward 5y ago
It's amazing how useful graphs are
DrBenCarson 5y ago
Awesome to see progress on this front making it into tools devs use day-to-day. Babel compilation is, by far, the slowest part of our full-stack build. That includes turning java source into jvm bytecode.
eberkund 5y ago
So is this another independent JS compiler implementation comparable to ES Build?
- astraloverflow 5y ago
  Yes, Parcel is now using SWC under the hood which is written in Rust (esbuild is written in Go), and is esbuild's main competitor/alternative.
  - megaman821 5y ago
    Are they competitors? I thought SWC is a transpiler and ESBuild is a buildtool. I think any tree-shaking or code splitting that Parcel has is being done somewhere else.
    - astraloverflow 5y ago
      True, but how many projects will use either one directly and not as a part of a larger toolkit like vitejs and now parcel?
      - Aeolun 5y ago
        I use just esbuild for prod compilation. For dev we still use webpack (with webpack-esbuild since it’s much faster than babel).
        vbsteven 5y ago
        Is it a good idea to use a completely different compiler toolchain for dev vs prod? I don't know enough about their internals but that seems like a recipe for weird behavior in production.
        riquito 5y ago
        It's a tradeoff. Given that you have a staging environment that behaves like production, you want dev to be the fastest environment as possible, so that you can iterate quickly to develop features and fix bugs, and validate them later on staging. Of course, the closer you are to prod the better, but when you have to chose for dev between speed vs reliability and the difference is high, speed is better (higher morale, more features deployed, the occasional bugs related to the different environments that were not catched by staging (why? need one more test) can be quickly fixed - most of the time)
      - qbasic_forever 5y ago
        esbuild is perfect for adding to a go server app that needs to do some basic bundling. Just add it as a go module dependency, add a few go generate comments to use it to bundle your JS code, and you're done--you don't need nodejs or anything else installed.
    - qbasic_forever 5y ago
      esbuild does transpiling too, for example it can pull out typescript annotations or handle JSX transforms. It doesn't support transpiling down to ES5 though like swc. In general both tools are pretty similar, when you get down to it they're just a class of tool to take JS code, produce a AST, and then perform various transformations to the AST and write it back out as JS.
deleted 5y ago
[deleted]
astraloverflow 5y ago
It's so encouraging to see esbuild and swc grow in popularity, along with the lightweight dev build vs full production build approach. I made the switch from Parcel v1 to vitejs recently on some personal projects and seeing how fast it starts up and processes changes still has me feeling excited. I wonder how many other frontend tool would be good fits for being written in rust or go. And how long before this approach becomes the de facto industry standard?
- rk06 5y ago
  Hopefully within a year or two. Most of the devs would use build higher level build tool like vite, create-react-app or custom build pipeline. Thus only small number of devs, who are directly involved in build process, need to make the change.
Chris_Newton 5y ago
I’m happy to see this. After a breaking change in a Parcel (v1) update caused us some trouble a little while back, we took the opportunity to start trying out Parcel 2. At the time, source maps were broken and the fix went in just after the beta release we were using, but the pace of development since then has been impressive. The SWC-based transpilation looks like another big improvement. For anyone else who had a similar configuration to us, with some Babel packages installed to support Jest for running tests regardless of what Parcel was doing with the main build process, this also looks interesting, though we haven’t tried it yet: https://swc.rs/docs/usage-swc-jest/ https://swc.rs/docs/usage-swc-jest/ Edit: We have now tried it, but sadly several tests broke due to parsing problems. The cause remains a mystery so far, because the offending lines are in our application code and not our test files, and that same code does appear to build OK via Parcel. So it appears that SWC itself, at least as Parcel is using it, can parse everything involved, but for some reason to be determined, installing @swc/* packages directly as devDependencies and configuring the Jest transform for the relevant source files to use @swc/jest is not a drop-in replacement for the Jest+Babel combination we were using before. If anyone else has had more luck getting this working, and similarly getting ESLint to work well without needing Babel packages after moving other tools to use SWC, details would be appreciated! Otherwise, it looks like we’ll still need Babel for now to run the testing and linting tools, even if Parcel is using SWC for its builds.
- devongovett 5y ago
  I started prototyping a @parcel/jest preset and a @parcel/register package that would help with this. Basically it would use Parcel for builds when using other tools like testing frameworks. Potentially we could do something for ESLint as well. It's probably a post-2.0 feature, but hopefully that could help simplify this a bit.
  - Chris_Newton 5y ago
    I think that would be useful eventually, but unfortunately my experience trying beta 3 this evening has been disastrous, so I’d definitely encourage you to focus on stability and reliability of the main build system first. Right now, it seems the only way to successfully build our code using beta 3 is to have none of the old Babel-related packages and config around any more, but that means we can’t use other essentials like Jest or ESLint that also rely on Babel. So unfortunately it looks like our current choices with Parcel are using Parcel 1 (recently broken in many ways as other comments have noted), Parcel 2 beta 2 (which was mostly working OK for us, though sourcemaps were broken) or Parcel 2 beta 3 (doesn’t look viable at all based on tonight’s experiments). Right now this project is only at prototype-to-MVP stage in a stealth-mode startup, so it’s worth spending some of our time to experiment with different tools and infrastructure if it gets us to a good set-up for the long term, but I hope you get to production-ready before we do! :-)
MintsJohn 5y ago
Could be nice but I'll be avoiding parcel like the plague after being confronted by its complete lack of maintenance of parcel v1 while v2 is in beta, and not the working kind of beta, the broken kind, while the solution to old problems is "use parcel 2" (https://github.com/parcel-bundler/parcel/issues/5695 https://github.com/parcel-bundler/parcel/issues/5695 https://github.com/parcel-bundler/parcel/issues/5294 https://github.com/parcel-bundler/parcel/issues/5294) . In the end I replaced parcel with webpack, less sexy but it's kind of the standard.
- jjeaff 5y ago
  Ya, we are having the same problem. V1 has some broken parts, but so does V2 and documentation is sparse.
- Baconinus 5y ago
  There's a roadmap section saying explicitly that they're not RC yet: https://v2.parceljs.org/blog/beta3/#roadmap https://v2.parceljs.org/blog/beta3/#roadmap So it was expected that they would be breaking stuff on their way. I would rather say "I'll keep an eye on Parcel until it becomes stable".
  - deleted 5y ago
    [deleted]
  - Omin 5y ago
    This information shouldn't be hidden in some document, it should be one of the first things they tell you about in their README and through their versioning (0.1 and 0.2 instead of 1.0 and 2.0).
- devongovett 5y ago
  Sorry about that. It's difficult to maintain effectively two large open source projects like this simultaneously, especially since this is a side project for most of us. We've probably dropped the ball a little, especially since v2 has taken a long time to build. But the good news is we are getting very close. Docs and migration guides are our main priorities next.
aranchelk 5y ago
This looks very promising. Parcel is currently the slowest part of my build process, compiling to JS and running tests is an order of magnitude faster. Regardless I’ve found Parcel v1 to be very useful and entirely worth the wait time.
danielEM 5y ago
Used parcel for quite some time, but switched some time ago to: https://esbuild.github.io/ https://esbuild.github.io/ Wondering how new parcel performs against esbuild?
- sunsetSamurai 5y ago
  Hi, I'm kinda new to the web development world, do you have a guide on how to set up esbuild to compile and minimize a project built with typescript and sass?
  - ianschmitz 5y ago
    I wouldn't recommend setting it up yourself. Try Vite instead.
    - mszcz 5y ago
      Even as an exercise to understand how it works?
    - AriaMinaei 5y ago
      For a beginner, I wouldn't recommend vite just yet. There are still rough edges (like browser load time being unbearably slow): https://github.com/vitejs/vite/issues/3208 https://github.com/vitejs/vite/issues/3208 If you're starting out, I'd suggest spending more of your time in a higher level of the stack (like writing application code, learning React/etc), rather than spending time deeper down in the plumbing, especially if you're using cutting-edge pieces in the build pipeline.
mwcampbell 5y ago
> ~10x faster without Terser, and ~3x faster when minification is enabled Any plans to replace Terser with something in Rust?
- devongovett 5y ago
  Indeed. There is currently an SWC minifier project that is in progress. The maintainer of Terser is helping with it, and the Parcel team will likely help with that as well after we ship the stable Parcel 2 release. :)
  - httgp 5y ago
    Great news, but that PR just got merged a few hours ago! https://github.com/swc-project/swc/pull/1302 https://github.com/swc-project/swc/pull/1302
sunflowerdeath 5y ago
Obviously, it's great that we get tools that provides such improvements, but somehow I feel that JS should not be that slow. I expect it to be about 3 to 5 times slower than lower-level languages, but when the difference exceeds 10 times, it means that the Babel's code is not written very efficiently. Another thing, is that usually you only need to optimize a few critical places, and that will give the biggest improvement. So I wonder if it is possible to optimize or rewrite some parts of Babel into a faster language, but keep all of its extensibility and ecosystem. Maybe projects like esbuild or swc will provide insights for Babels' team.
- deleted 5y ago
  [deleted]
- devongovett 5y ago
  Yep, this is true. In fact, we already improved performance by over 25x by optimizing algorithms in JavaScript. As covered in the blog post, this rewrite was motivated by more than just performance and does include algorithmic improvements as well. We figured that while we were rewriting we might as well also use a language with more predictable performance traits. But, your points about extensibility does still stand, and that's something we hope to look into more in the future.
- hajile 5y ago
  Sucrase is what you're looking for. When converting to ES6+, it's actually almost 2x as fast as esbuild on a single thread (though slower in aggregate). As they point out, there's a JIT warmup time. Testing against small projects that don't allow this makes JS transpilers look much worse than they actually are in real-world projects. https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase/blob/main/benchmark/benchmark.ts https://github.com/alangpierce/sucrase/blob/main/benchmark/b...
  - jiofih 5y ago
    Sucrase is quite fast indeed, but some of the trade-offs make it a very difficult choice. It will silently compile invalid JS, and is not easily extensible, so you’ll end up bringing in more tooling on top of it to support things like css modules or a framework like svelte. I don’t think it will survive for long. It’s for good reason that the docs end on this note: > You should think carefully before using Sucrase in production. Sucrase is mostly beneficial in development, and in many cases, Babel or tsc will be more suitable for production builds.
Kaze404 5y ago
The biggest upside of Parcel to me is not speed (though that's a nice bonus). What I like the most about it is the fact that literally all I need to use it is run `parcel public/index.html` and it'll figure out the technology I'm using and just work. Both in React and Elm, it's made the friction of starting a new app much more tolerable, considering now I don't need to bring all the baggage that `crate-react-app` and the likes carry. Thank you!
- alephu5 5y ago
  I used it when I was getting into frontend development, after years in the backend, and loved parcel for this reason. Webpack struck me as lunacy. Unfortunately nowadays I work with create-react-app or Gatsby because parcel gives me huge bundles, or breaks with tree-shaking on. Really excited about parcel 2 though, I tried the alpha and it didn't work for me but hopefully this does.
dang 5y ago
Some past threads: 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)
phtrivier 5y ago
Not sure where it's positionned in the build process, so the question might be silly, but : would it be something that a project like, say, 'create-react-app' could choose to integrate instead of / next to whatever they're using ? Or does it preclude using some popular framework / library that reserve it for greenfield projects ?
Zababa 5y ago
I really like how Go and Rust are enabling a new generation of dev tools. I don't know if it's because they're popular at the moment and the open source ecosystem is growing so lots of people use them, or if it's a more real trend. Still, I think they both have qualities to make this kind of tools easier to make than before.
Cu3PO42 5y ago
I'm always happy to hear about performance improvements to JS dev tooling. In recent years significant improvements have already been made, but it's still... slow. However, I have concerns about using Rust here. Not because it's Rust specifically, but because it means yet another native dependency. I've done my best to eliminate any native code from projects because they would always cause problems sooner or later. Mostly later when coming back to an old project. Are there any plans to optionally ship the compiler as WASM to avoid this?
- tanaypingalkar 5y ago
  Why you have concerns with native dependencies, it is just a transpiler and a dev dependencies. How it affect your project?
  - Cu3PO42 5y ago
    It affects me and other people working on it. I have to make sure the systems running the dependencies have an appropriate Python and C(++) toolchain installed. If they use Node bindings, they will probably need to be updated for newer versions of Node. When I come back to the project after some time, the first thing I need to do is update dependencies. I often had colleagues on whose devices some dependency would just refuse to compile for one reason or another. Sure, this isn't the greatest problem in the Node ecosystem right now, but it's painful enough that I would rather not deal with it.
- devongovett 5y ago
  We will have a WASM build, yes. Mainly for running in the browser or on platforms we don't build for. In our tests so far, it is significantly slower though (e.g. ~30%) so it's a tradeoff.
  - Cu3PO42 5y ago
    That's great to hear! I might be willing to take that penalty depending on the size of the project to avoid any future incompatibilities.
jokethrowaway 5y ago
Wow, parcel is already insanely fast (coming from webpack), can't wait to see even more perf improvements. Amazing job
thiht 5y ago
I don't know if it's just me but I find migrating from Parcel 1 to 2 exceedingly hard and frustrating. I tried a few times for the previous betas, and just spend 2 more hours trying and still failed. I'd love to finally benefiting from tree shaking and faster build times but I can't get anything to work. I hope they'll improve for the stable version, because Parcel 1 promise was that it just magically worked, which it did! I'd hate for Parcel 2 to regress on this side.
phreack 5y ago
Hah, I literally spent a day trying to use parcel to optimize a good old fashioned HTML+CSS+JS static site that's not an SPA. Webpack would be a pain to set up and all other bundlers were lacking for such an use case. Parcel 1 worked great on my machine, and then on the server decided to flatten all files to a single folder - effectively breaking the site. I had no clue as to why, probably something related to having low memory, and the reigning response on the issue tracker was 'forget about v1, use Parcel v2'. So I tried installing and running it on my machine but it would get stuck building unless I gave it a '--no-cache' option (took a while to figure that out), and then on the server the thing wouldn't even (npm) install. Each time I tried it failed kind of differently, mostly because of node-gyp, other times because of weird GLIBC. After all that I just gave up, maybe in a month I'll be in the mood to set up the Webpack madness - but it's more likely I'll end up rewriting the whole site as an SPA because the bundler gods demand it be so.
- crooked-v 5y ago
  If you decide to do an SPA, I'd recommend Next.js, because even if you use zero of the features and just put everything in a single index.jsx component, it does all the Webpack stuff for you. It also has some other useful stuff like easy support for rendering plain Markdown files into static files at build time, so you can use it as a more capable alternative to tools like Jekyll [1]. [1]: https://nextjs.org/blog/markdown https://nextjs.org/blog/markdown
  - ggregoire 5y ago
    Just use create-react-app if you don't need any of the features provided by next.js. https://reactjs.org/docs/create-a-new-react-app.html#recommended-toolchains https://reactjs.org/docs/create-a-new-react-app.html#recomme...
  - phreack 5y ago
    Yeah, I love next.js. I'm much more willing to go that route than fight Webpack.
- mamcx 5y ago
dgreensp 5y ago
I used Parcel 1 for several months on personal projects before getting frustrated and switching back to Webpack. Having spent all those hours getting Parcel to work for me and troubleshooting it, and ultimately failing to adopt it, I'd like to say I learned something. In particular, it clarified my own values about writing software for other people to use. I think Parcel 1's biggest issue was being really ambitious, and then never reaching maturity, in that it had bugs that weren't fixed. It wasn't maintained. So it had its own file watcher, for example, I believe, which is great in theory, but not when it's buggy and unmaintained. My personal style would be if I'm going to write my own version of something, write it in a really high-quality way, and keep it simple, either in API or implementation. Maybe reuse the same module for Parcel 2 and improve it, keeping the same API, or if I'm going to rewrite it, use the rewritten module in Parcel 1, or something. I wouldn't just write my own library for X, and Y, and Z, and put it out there, get a lot of people using it, and then move on. I love writing my own versions of things and taking on fun and ambitious projects, but I'd rather nobody use the code I write in my spare time, for free, and don't want to maintain, than create a liability for people. Another issue I ran into is Parcel insisted on running "npm install", which was a feature that you couldn't turn off even if it didn't suit your project structure. This violates a few principles of mine. It's an attempt to be "magical" in order to reduce the amount of configuration. "Magic" is not a good thing. Think about what makes a magic trick a magic trick: obfuscation. It's magic because you don't know what's happening, but you get one moment of delight out of it. Overall it increases complexity; it's the opposite of making things simple. Rich Hickey talks about how "simplicity" properly means simplicity of behavior, not fewer words on the screen. Keep the tool simple and understandable, and the way you instruct it what to do simple and understandable. If you want something to work well out of the box, by all means, build popular things like TypeScript into the core; have sensible defaults and explain what they are. But configuring a piece of software is a dialogue where you learn what the capabilities of the program are. There's no place for "do what I mean" in good UX. Also, build tools should not treat development as something that happens from a unix shell, and try to "automate" it by shelling out to this and that. That's error-prone and likely not to be very universal or focused. Imagine if Webpack's core shelled out to "git" or something (to make up a random example). It would be ridiculous. The biggest way to improve on Webpack IMO would be to make something that is both easy to get started with and easier to understand and customize for professional developers. Keep in mind that Webpack has been mature now for a long time, and it has extensive docs and guides, and tons of plugins, and you can write your own plugins without too much fuss... any alternative that is buggy (until further notice, maybe years from now if ever) and poorly documented (until further notice, ditto), and not inherently simpler or easier to understand or troubleshoot, while also having less of an ecosystem of available plugins, etc. is just not a good substitute.

248 points by bpierre 5y ago

It's amazing how useful graphs are

Awesome to see progress on this front making it into tools devs use day-to-day. Babel compilation is, by far, the slowest part of our full-stack build. That includes turning java source into jvm bytecode.

eberkund 5y ago

So is this another independent JS compiler implementation comparable to ES Build?

astraloverflow 5y ago
Yes, Parcel is now using SWC under the hood which is written in Rust (esbuild is written in Go), and is esbuild's main competitor/alternative.
- megaman821 5y ago
  Are they competitors? I thought SWC is a transpiler and ESBuild is a buildtool. I think any tree-shaking or code splitting that Parcel has is being done somewhere else.
  - astraloverflow 5y ago
    True, but how many projects will use either one directly and not as a part of a larger toolkit like vitejs and now parcel?
    - Aeolun 5y ago
      I use just esbuild for prod compilation. For dev we still use webpack (with webpack-esbuild since it’s much faster than babel).
      - vbsteven 5y ago
        Is it a good idea to use a completely different compiler toolchain for dev vs prod? I don't know enough about their internals but that seems like a recipe for weird behavior in production.
        riquito 5y ago
        It's a tradeoff. Given that you have a staging environment that behaves like production, you want dev to be the fastest environment as possible, so that you can iterate quickly to develop features and fix bugs, and validate them later on staging. Of course, the closer you are to prod the better, but when you have to chose for dev between speed vs reliability and the difference is high, speed is better (higher morale, more features deployed, the occasional bugs related to the different environments that were not catched by staging (why? need one more test) can be quickly fixed - most of the time)
    - qbasic_forever 5y ago
      esbuild is perfect for adding to a go server app that needs to do some basic bundling. Just add it as a go module dependency, add a few go generate comments to use it to bundle your JS code, and you're done--you don't need nodejs or anything else installed.
  - qbasic_forever 5y ago
    esbuild does transpiling too, for example it can pull out typescript annotations or handle JSX transforms. It doesn't support transpiling down to ES5 though like swc. In general both tools are pretty similar, when you get down to it they're just a class of tool to take JS code, produce a AST, and then perform various transformations to the AST and write it back out as JS.

deleted 5y ago

[deleted]

astraloverflow 5y ago

It's so encouraging to see esbuild and swc grow in popularity, along with the lightweight dev build vs full production build approach. I made the switch from Parcel v1 to vitejs recently on some personal projects and seeing how fast it starts up and processes changes still has me feeling excited. I wonder how many other frontend tool would be good fits for being written in rust or go. And how long before this approach becomes the de facto industry standard?

rk06 5y ago
Hopefully within a year or two. Most of the devs would use build higher level build tool like vite, create-react-app or custom build pipeline. Thus only small number of devs, who are directly involved in build process, need to make the change.

Chris_Newton 5y ago

I’m happy to see this. After a breaking change in a Parcel (v1) update caused us some trouble a little while back, we took the opportunity to start trying out Parcel 2. At the time, source maps were broken and the fix went in just after the beta release we were using, but the pace of development since then has been impressive. The SWC-based transpilation looks like another big improvement. For anyone else who had a similar configuration to us, with some Babel packages installed to support Jest for running tests regardless of what Parcel was doing with the main build process, this also looks interesting, though we haven’t tried it yet: https://swc.rs/docs/usage-swc-jest/ https://swc.rs/docs/usage-swc-jest/ Edit: We have now tried it, but sadly several tests broke due to parsing problems. The cause remains a mystery so far, because the offending lines are in our application code and not our test files, and that same code does appear to build OK via Parcel. So it appears that SWC itself, at least as Parcel is using it, can parse everything involved, but for some reason to be determined, installing @swc/* packages directly as devDependencies and configuring the Jest transform for the relevant source files to use @swc/jest is not a drop-in replacement for the Jest+Babel combination we were using before. If anyone else has had more luck getting this working, and similarly getting ESLint to work well without needing Babel packages after moving other tools to use SWC, details would be appreciated! Otherwise, it looks like we’ll still need Babel for now to run the testing and linting tools, even if Parcel is using SWC for its builds.

devongovett 5y ago
I started prototyping a @parcel/jest preset and a @parcel/register package that would help with this. Basically it would use Parcel for builds when using other tools like testing frameworks. Potentially we could do something for ESLint as well. It's probably a post-2.0 feature, but hopefully that could help simplify this a bit.
- Chris_Newton 5y ago
  I think that would be useful eventually, but unfortunately my experience trying beta 3 this evening has been disastrous, so I’d definitely encourage you to focus on stability and reliability of the main build system first. Right now, it seems the only way to successfully build our code using beta 3 is to have none of the old Babel-related packages and config around any more, but that means we can’t use other essentials like Jest or ESLint that also rely on Babel. So unfortunately it looks like our current choices with Parcel are using Parcel 1 (recently broken in many ways as other comments have noted), Parcel 2 beta 2 (which was mostly working OK for us, though sourcemaps were broken) or Parcel 2 beta 3 (doesn’t look viable at all based on tonight’s experiments). Right now this project is only at prototype-to-MVP stage in a stealth-mode startup, so it’s worth spending some of our time to experiment with different tools and infrastructure if it gets us to a good set-up for the long term, but I hope you get to production-ready before we do! :-)

MintsJohn 5y ago

Could be nice but I'll be avoiding parcel like the plague after being confronted by its complete lack of maintenance of parcel v1 while v2 is in beta, and not the working kind of beta, the broken kind, while the solution to old problems is "use parcel 2" (https://github.com/parcel-bundler/parcel/issues/5695 https://github.com/parcel-bundler/parcel/issues/5695 https://github.com/parcel-bundler/parcel/issues/5294 https://github.com/parcel-bundler/parcel/issues/5294) . In the end I replaced parcel with webpack, less sexy but it's kind of the standard.

jjeaff 5y ago
Ya, we are having the same problem. V1 has some broken parts, but so does V2 and documentation is sparse.
Baconinus 5y ago
There's a roadmap section saying explicitly that they're not RC yet: https://v2.parceljs.org/blog/beta3/#roadmap https://v2.parceljs.org/blog/beta3/#roadmap So it was expected that they would be breaking stuff on their way. I would rather say "I'll keep an eye on Parcel until it becomes stable".
- deleted 5y ago
  [deleted]
- Omin 5y ago
  This information shouldn't be hidden in some document, it should be one of the first things they tell you about in their README and through their versioning (0.1 and 0.2 instead of 1.0 and 2.0).
devongovett 5y ago
Sorry about that. It's difficult to maintain effectively two large open source projects like this simultaneously, especially since this is a side project for most of us. We've probably dropped the ball a little, especially since v2 has taken a long time to build. But the good news is we are getting very close. Docs and migration guides are our main priorities next.

aranchelk 5y ago

This looks very promising. Parcel is currently the slowest part of my build process, compiling to JS and running tests is an order of magnitude faster. Regardless I’ve found Parcel v1 to be very useful and entirely worth the wait time.

danielEM 5y ago

Used parcel for quite some time, but switched some time ago to: https://esbuild.github.io/ https://esbuild.github.io/ Wondering how new parcel performs against esbuild?

sunsetSamurai 5y ago
Hi, I'm kinda new to the web development world, do you have a guide on how to set up esbuild to compile and minimize a project built with typescript and sass?
- ianschmitz 5y ago
  I wouldn't recommend setting it up yourself. Try Vite instead.
  - mszcz 5y ago
    Even as an exercise to understand how it works?
  - AriaMinaei 5y ago
    For a beginner, I wouldn't recommend vite just yet. There are still rough edges (like browser load time being unbearably slow): https://github.com/vitejs/vite/issues/3208 https://github.com/vitejs/vite/issues/3208 If you're starting out, I'd suggest spending more of your time in a higher level of the stack (like writing application code, learning React/etc), rather than spending time deeper down in the plumbing, especially if you're using cutting-edge pieces in the build pipeline.

mwcampbell 5y ago

> ~10x faster without Terser, and ~3x faster when minification is enabled Any plans to replace Terser with something in Rust?

devongovett 5y ago
Indeed. There is currently an SWC minifier project that is in progress. The maintainer of Terser is helping with it, and the Parcel team will likely help with that as well after we ship the stable Parcel 2 release. :)
- httgp 5y ago
  Great news, but that PR just got merged a few hours ago! https://github.com/swc-project/swc/pull/1302 https://github.com/swc-project/swc/pull/1302

sunflowerdeath 5y ago

Obviously, it's great that we get tools that provides such improvements, but somehow I feel that JS should not be that slow. I expect it to be about 3 to 5 times slower than lower-level languages, but when the difference exceeds 10 times, it means that the Babel's code is not written very efficiently. Another thing, is that usually you only need to optimize a few critical places, and that will give the biggest improvement. So I wonder if it is possible to optimize or rewrite some parts of Babel into a faster language, but keep all of its extensibility and ecosystem. Maybe projects like esbuild or swc will provide insights for Babels' team.

deleted 5y ago
[deleted]
devongovett 5y ago
Yep, this is true. In fact, we already improved performance by over 25x by optimizing algorithms in JavaScript. As covered in the blog post, this rewrite was motivated by more than just performance and does include algorithmic improvements as well. We figured that while we were rewriting we might as well also use a language with more predictable performance traits. But, your points about extensibility does still stand, and that's something we hope to look into more in the future.
hajile 5y ago
Sucrase is what you're looking for. When converting to ES6+, it's actually almost 2x as fast as esbuild on a single thread (though slower in aggregate). As they point out, there's a JIT warmup time. Testing against small projects that don't allow this makes JS transpilers look much worse than they actually are in real-world projects. https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase/blob/main/benchmark/benchmark.ts https://github.com/alangpierce/sucrase/blob/main/benchmark/b...
- jiofih 5y ago
  Sucrase is quite fast indeed, but some of the trade-offs make it a very difficult choice. It will silently compile invalid JS, and is not easily extensible, so you’ll end up bringing in more tooling on top of it to support things like css modules or a framework like svelte. I don’t think it will survive for long. It’s for good reason that the docs end on this note: > You should think carefully before using Sucrase in production. Sucrase is mostly beneficial in development, and in many cases, Babel or tsc will be more suitable for production builds.

Kaze404 5y ago

The biggest upside of Parcel to me is not speed (though that's a nice bonus). What I like the most about it is the fact that literally all I need to use it is run `parcel public/index.html` and it'll figure out the technology I'm using and just work. Both in React and Elm, it's made the friction of starting a new app much more tolerable, considering now I don't need to bring all the baggage that `crate-react-app` and the likes carry. Thank you!

alephu5 5y ago
I used it when I was getting into frontend development, after years in the backend, and loved parcel for this reason. Webpack struck me as lunacy. Unfortunately nowadays I work with create-react-app or Gatsby because parcel gives me huge bundles, or breaks with tree-shaking on. Really excited about parcel 2 though, I tried the alpha and it didn't work for me but hopefully this does.

dang 5y ago

Some past threads: 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)

phtrivier 5y ago

Not sure where it's positionned in the build process, so the question might be silly, but : would it be something that a project like, say, 'create-react-app' could choose to integrate instead of / next to whatever they're using ? Or does it preclude using some popular framework / library that reserve it for greenfield projects ?

Zababa 5y ago

I really like how Go and Rust are enabling a new generation of dev tools. I don't know if it's because they're popular at the moment and the open source ecosystem is growing so lots of people use them, or if it's a more real trend. Still, I think they both have qualities to make this kind of tools easier to make than before.

Cu3PO42 5y ago

I'm always happy to hear about performance improvements to JS dev tooling. In recent years significant improvements have already been made, but it's still... slow. However, I have concerns about using Rust here. Not because it's Rust specifically, but because it means yet another native dependency. I've done my best to eliminate any native code from projects because they would always cause problems sooner or later. Mostly later when coming back to an old project. Are there any plans to optionally ship the compiler as WASM to avoid this?

tanaypingalkar 5y ago
Why you have concerns with native dependencies, it is just a transpiler and a dev dependencies. How it affect your project?
- Cu3PO42 5y ago
  It affects me and other people working on it. I have to make sure the systems running the dependencies have an appropriate Python and C(++) toolchain installed. If they use Node bindings, they will probably need to be updated for newer versions of Node. When I come back to the project after some time, the first thing I need to do is update dependencies. I often had colleagues on whose devices some dependency would just refuse to compile for one reason or another. Sure, this isn't the greatest problem in the Node ecosystem right now, but it's painful enough that I would rather not deal with it.
devongovett 5y ago
We will have a WASM build, yes. Mainly for running in the browser or on platforms we don't build for. In our tests so far, it is significantly slower though (e.g. ~30%) so it's a tradeoff.
- Cu3PO42 5y ago
  That's great to hear! I might be willing to take that penalty depending on the size of the project to avoid any future incompatibilities.

jokethrowaway 5y ago

Wow, parcel is already insanely fast (coming from webpack), can't wait to see even more perf improvements. Amazing job

thiht 5y ago

I don't know if it's just me but I find migrating from Parcel 1 to 2 exceedingly hard and frustrating. I tried a few times for the previous betas, and just spend 2 more hours trying and still failed. I'd love to finally benefiting from tree shaking and faster build times but I can't get anything to work. I hope they'll improve for the stable version, because Parcel 1 promise was that it just magically worked, which it did! I'd hate for Parcel 2 to regress on this side.

phreack 5y ago

Hah, I literally spent a day trying to use parcel to optimize a good old fashioned HTML+CSS+JS static site that's not an SPA. Webpack would be a pain to set up and all other bundlers were lacking for such an use case. Parcel 1 worked great on my machine, and then on the server decided to flatten all files to a single folder - effectively breaking the site. I had no clue as to why, probably something related to having low memory, and the reigning response on the issue tracker was 'forget about v1, use Parcel v2'. So I tried installing and running it on my machine but it would get stuck building unless I gave it a '--no-cache' option (took a while to figure that out), and then on the server the thing wouldn't even (npm) install. Each time I tried it failed kind of differently, mostly because of node-gyp, other times because of weird GLIBC. After all that I just gave up, maybe in a month I'll be in the mood to set up the Webpack madness - but it's more likely I'll end up rewriting the whole site as an SPA because the bundler gods demand it be so.

crooked-v 5y ago
If you decide to do an SPA, I'd recommend Next.js, because even if you use zero of the features and just put everything in a single index.jsx component, it does all the Webpack stuff for you. It also has some other useful stuff like easy support for rendering plain Markdown files into static files at build time, so you can use it as a more capable alternative to tools like Jekyll [1]. [1]: https://nextjs.org/blog/markdown https://nextjs.org/blog/markdown
- ggregoire 5y ago
  Just use create-react-app if you don't need any of the features provided by next.js. https://reactjs.org/docs/create-a-new-react-app.html#recommended-toolchains https://reactjs.org/docs/create-a-new-react-app.html#recomme...
- phreack 5y ago
  Yeah, I love next.js. I'm much more willing to go that route than fight Webpack.
mamcx 5y ago

dgreensp 5y ago

I used Parcel 1 for several months on personal projects before getting frustrated and switching back to Webpack. Having spent all those hours getting Parcel to work for me and troubleshooting it, and ultimately failing to adopt it, I'd like to say I learned something. In particular, it clarified my own values about writing software for other people to use. I think Parcel 1's biggest issue was being really ambitious, and then never reaching maturity, in that it had bugs that weren't fixed. It wasn't maintained. So it had its own file watcher, for example, I believe, which is great in theory, but not when it's buggy and unmaintained. My personal style would be if I'm going to write my own version of something, write it in a really high-quality way, and keep it simple, either in API or implementation. Maybe reuse the same module for Parcel 2 and improve it, keeping the same API, or if I'm going to rewrite it, use the rewritten module in Parcel 1, or something. I wouldn't just write my own library for X, and Y, and Z, and put it out there, get a lot of people using it, and then move on. I love writing my own versions of things and taking on fun and ambitious projects, but I'd rather nobody use the code I write in my spare time, for free, and don't want to maintain, than create a liability for people. Another issue I ran into is Parcel insisted on running "npm install", which was a feature that you couldn't turn off even if it didn't suit your project structure. This violates a few principles of mine. It's an attempt to be "magical" in order to reduce the amount of configuration. "Magic" is not a good thing. Think about what makes a magic trick a magic trick: obfuscation. It's magic because you don't know what's happening, but you get one moment of delight out of it. Overall it increases complexity; it's the opposite of making things simple. Rich Hickey talks about how "simplicity" properly means simplicity of behavior, not fewer words on the screen. Keep the tool simple and understandable, and the way you instruct it what to do simple and understandable. If you want something to work well out of the box, by all means, build popular things like TypeScript into the core; have sensible defaults and explain what they are. But configuring a piece of software is a dialogue where you learn what the capabilities of the program are. There's no place for "do what I mean" in good UX. Also, build tools should not treat development as something that happens from a unix shell, and try to "automate" it by shelling out to this and that. That's error-prone and likely not to be very universal or focused. Imagine if Webpack's core shelled out to "git" or something (to make up a random example). It would be ridiculous. The biggest way to improve on Webpack IMO would be to make something that is both easy to get started with and easier to understand and customize for professional developers. Keep in mind that Webpack has been mature now for a long time, and it has extensive docs and guides, and tons of plugins, and you can write your own plugins without too much fuss... any alternative that is buggy (until further notice, maybe years from now if ever) and poorly documented (until further notice, ditto), and not inherently simpler or easier to understand or troubleshoot, while also having less of an ecosystem of available plugins, etc. is just not a good substitute.