[HN Gopher] Parcel 2 Beta 3 - improved build performance
___________________________________________________________________
Parcel 2 Beta 3 - improved build performance
Author : bpierre
Score : 222 points
Date : 2021-05-20 15:31 UTC (7 hours ago)
(HTM) web link (v2.parceljs.org)
(TXT) w3m dump (v2.parceljs.org)
| MintsJohn wrote:
| 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/5294) . In the
| end I replaced parcel with webpack, less sexy but it's kind of
| the standard.
| dmix wrote:
| This is why it's dangerous using cutting edge software. All in
| all if they have a small team I'd also point them to v2 for a
| fixed problem.
|
| Rather than backport to some beta version.
|
| (Not giving Parcel zero blame in how ready they present
| themselves).
| rowanG077 wrote:
| Both issues you linked are about upgrading to newer versions.
| For these kind of issues saying use the new version is
| completely fine. There were no security risk. No bug that
| something essential isn't working. It literally please update
| the software so a new version of some dependency is supported.
| I would have done the same.
| maxwellwhite wrote:
| > 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
|
| You beat me to it here; it's a shame. That was my experience,
| too.
| jjeaff wrote:
| Ya, we are having the same problem. V1 has some broken parts,
| but so does V2 and documentation is sparse.
| Baconinus wrote:
| There's a roadmap section saying explicitly that they're not RC
| yet:
|
| 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".
| Omin wrote:
| 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).
| [deleted]
| devongovett wrote:
| 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.
| andrewmcwatters wrote:
| You don't have to be sorry, you're providing a high quality
| open-source product for free. It just is what it is.
|
| Addendum: I manage a very small open-source product
| (https://www.planimeter.org/grid-sdk/), and when you're
| creating something that competes with an established
| incumbent, all you can do is your best and focus on the most
| impactful features. Individuals like the one above saying
| things like, "I'll be avoiding parcel like the plague," is
| really disheartening, but try and focus on their concerns
| more than the actual words they use.
|
| Frustrated people are a goldmine for feedback that many
| projects simply do not receive. Take it in stride, know that
| you have something others do not, and use it to your
| advantage. It can be hard to separate your feelings from the
| words used, but there are diamonds there.
| eloff wrote:
| That's a healthy attitude, I'll try to remember that one
| next time I get harsh feedback.
|
| It's tough to separate my ego from my work.
| swyx wrote:
| for what its worth i think adobe pays devon to work on
| tooling (parcel and react aria|spectrum) somewhat full time
| and he even has a team around him. but no doubt its just
| extraordinarily hard to do regardless
| devongovett wrote:
| I am paid to work on react-aria/spectrum. Parcel is a
| side project.
| swyx wrote:
| thats... just incredibly impressive. hats off!
| danenania wrote:
| Great comment. I think this applies for pretty much all
| products or projects, especially in their early stages.
| There will always be people who don't get it or have
| different priorities. It's ok. When I showed people early
| versions of EnvKey[1], it felt like half loved it and half
| thought it was completely pointless. /shrug. At the time I
| found it discouraging, but now I see that getting even a
| single person to genuinely love what you've built is a
| major accomplishment and a really good sign that you're on
| the right track.
|
| If you can find one, you can find ten. If you can find ten,
| you can find a hundred. And so on.
|
| It's also extremely important to remember that the opposite
| of love is _not_ hate, negativity, or criticism. It's
| indifference. Harsh critics can become some of your best
| users /customers/advocates if you're able to learn from
| them and win them over.
|
| 1 - https://www.envkey.com
| MintsJohn wrote:
| Don't sweat it, in hindsight the tool just isn't for me
| (though it was great while it suited my needs). I'm affraid
| one reason for these issues is that parcel tries to do
| everything at once with as little configuration as possible.
| When it works: great. When it doesn't: not-so-great.
|
| Sure the out of date dependancies thing could be seen as a
| problem with post-css plugins that require a newer version,
| but the unfortunate fact is that in webdev land, everything
| seems to evolve at a breakneck pace, foregoing backwards
| compatability. And when some part doesn't match, the
| buildtool suddenly becomes unusable. (webpack is way less
| easy to setup, the flipside is you can for example choose
| your postcss version)
| aranchelk wrote:
| 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.
| Kaze404 wrote:
| 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 wrote:
| 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.
| bionhoward wrote:
| It's amazing how useful graphs are
| astraloverflow wrote:
| 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?
| Cu3PO42 wrote:
| 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?
| devongovett wrote:
| 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.
| tanaypingalkar wrote:
| Why you have concerns with native dependencies, it is just a
| transpiler and a dev dependencies. How it affect your project?
| thiht wrote:
| 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.
| danielEM wrote:
| Used parcel for quite some time, but switched some time ago to:
| https://esbuild.github.io/
|
| Wondering how new parcel performs against esbuild?
| sunsetSamurai wrote:
| 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 wrote:
| I wouldn't recommend setting it up yourself. Try Vite
| instead.
| mszcz wrote:
| Even as an exercise to understand how it works?
| mwcampbell wrote:
| > ~10x faster without Terser, and ~3x faster when minification is
| enabled
|
| Any plans to replace Terser with something in Rust?
| devongovett wrote:
| 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 wrote:
| Great news, but that PR just got merged a few hours ago!
|
| https://github.com/swc-project/swc/pull/1302
| jokethrowaway wrote:
| Wow, parcel is already insanely fast (coming from webpack), can't
| wait to see even more perf improvements.
|
| Amazing job
| DrBenCarson wrote:
| 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 wrote:
| So is this another independent JS compiler implementation
| comparable to ES Build?
| astraloverflow wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I use just esbuild for prod compilation. For dev we still
| use webpack (with webpack-esbuild since it's much faster
| than babel).
| vbsteven wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| phreack wrote:
| 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.
| mamcx wrote:
| I commit the mistake of doing SPA,
|
| ONCE.
|
| But happily revert back. I have a single build.sh script with
| the proper build steps (them are so simply that make or other
| thing is excessive).
|
| So, if you already know how do thing step by step, just do
| that!
| crooked-v wrote:
| 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
| ggregoire wrote:
| 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#recomme...
| Chris_Newton wrote:
| 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/
|
| 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 wrote:
| 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 wrote:
| 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!
| :-)
| dang wrote:
| Some past threads:
|
| _Parcel - Fast, zero-configuration web application bundler_ -
| 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 - July 2018 (91
| comments)
|
| _Parcel - A fast, zero configuration web application bundler_ -
| https://news.ycombinator.com/item?id=15853149 - Dec 2017 (163
| comments)
| phtrivier wrote:
| 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 wrote:
| 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.
| sunflowerdeath wrote:
| 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]
| devongovett wrote:
| 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 wrote:
| 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/blob/main/benchmark/b...
| jiofih wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2021-05-20 23:01 UTC)