devongovett

Thanks for the feedback!

1. We decided to start simple for the first release but it’s definitely possible to add something like asChild if the need arises. There are some tradeoffs to this though, eg it’s easier to mess up the DOM structure required for accessibility. There are some other approaches we’ll be documenting for this as well.

2. TS should be easier now. All the docs examples are now written in TS so you can see where the interfaces are imported from.

3. Yeah prop naming is a trade off. When we started, we decided to make all of the components follow a consistent naming convention. The DOM is quite limited in its functionality (eg you can only submit strings and not more complex objects) and we knew we’d need quite a bit more capability so we decided not to follow it in some areas. But we know integrating with form libraries is a pain point and we might have some documentation or helpers for that in the future.

If you have a trigger inside a nested scrollable region, and the popover pops out of this region, then if the trigger is scrolled out of view the popover cannot be anchored to it anymore.

This was an intentional choice. Repositioning when an outer element scrolls is pretty janky in some cases because scroll events don’t fire at 60fps. Also it’s not possible at all in other cases, like if the trigger goes completely out of view. We used to close the popover in this case but this caused usability problems. The new behavior of preventing scroll actually matches native platforms like macOS and helps with these issues. I get that it’s a little opinionated but it was thoroughly considered, not just done out of laziness. More details in this answer: https://github.com/adobe/react-spectrum/discussions/3802#dis...

In Parcel 2, you can configure everything.

Parcel 2 solved this though. You can override pretty much everything if you want now.

We actually already have! I contributed hwb() color support as part of my work on Parcel CSS, and it shipped in Firefox 96! https://github.com/servo/rust-cssparser/commit/62d63fea751df...

Yes, there is a WASM build used by the demo: https://parcel-css.vercel.app

Not sure if we could reuse these packages though, since we'd need to expose an API from Rust to JS anyway.

Hi, author of Parcel CSS here.

I have been thinking about implementing the CSS OM spec as the JS API. This is the same API that browsers expose for manipulating stylesheets. The advantage of this is that we don't need to invent something custom. Still thinking through options. https://github.com/parcel-bundler/parcel-css/issues/5

That said, I think I'd want to keep the use cases for JS plugins limited, because it will affect performance significantly. So, if it's something that exists in an official CSS spec somewhere (even if draft), or a really common transformation, it should be implemented in Rust. An example of this is the support for the CSS nesting spec. Ideally, we'd try to keep the amount of custom syntax being invented around CSS to a minimum and stick to standard CSS syntax wherever possible though.

I work on React Aria. Adobe is a big company and there are many teams using different technologies. In general, some very new parts of creative cloud chose to use web components, but the majority of teams are using React, and I don't foresee that changing anytime soon. It's definitely not a company wide shift if you got that impression from the Photoshop article. Ideally we'd collaborate more, but... big company silos.

Haha yes it is. We have to do a ton of manual testing to ensure consistency and compatibility across many devices, browsers, and screen readers.

Some of my tweets showing how we do this:

- https://twitter.com/devongovett/status/1318600389462126592 - https://twitter.com/devongovett/status/1270410802395111424 - https://twitter.com/devongovett/status/1318676759080968193

Yeah ComboBox is one of the most difficult. We wrote a post about the work that went into ours. https://react-spectrum.adobe.com/blog/building-a-combobox.ht...

If you want a bundler built using SWC as a base today, check out Parcel: https://parceljs.org

And Parcel: https://parceljs.org

Next.js still uses webpack. They basically replaced Babel with SWC.

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.

esbuild tends to produce larger bundles due to 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. We're also excited about the SWC minifier project, which is basically a port of Terser to Rust.

In v2, there is no transpilation unless you add a browserslist config.

Note that this benchmark is dominated by Terser for minification. All tools aside from ESBuild use it.

This was true in Parcel 1, but v2’s plugin system is just as powerful as webpack’s. v2 is all about adding extensibility and control.

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

Note that Parcel’s plugin system is completely different in v2 and the implicit loading is gone.

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.

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.

I am paid to work on react-aria/spectrum. Parcel is a side project.

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.

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

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.

Yeah it's pretty bad to have accessibility be a mode though. Also, since it's completely non-standard, the usual screen reader navigation keys don't work as expected and users have to learn a completely custom interface. Better than nothing but it's not great.

This is very bad for accessibility. Rendering things in canvas means there is no DOM, which means nothing for screen readers to read. To be fair, the old google docs editor was also very bad for a11y, but at least there was potential to improve it. This removes that option. They could have worked with the Chrome team to help improve standards for everyone, but decided to reimplement the rendering engine from scratch without regard for accessibility. I'm very disappointed that this wasn't flagged at a company the size of Google.

Hi, Parcel maintainer here. v2 will be released very shortly. We are ~1 month away from rc. Also, we should have a very big announcement about build perf in the next couple days. Apologies for the long pre-release cycle but I think the light is finally at the end of the tunnel. :)