egui VS react-community-tools-practic

Anyone who's interested in the AccessKit integration can play with my work-in-progress branch: https://github.com/mwcampbell/egui/tree/accesskit

It's currently Windows-only, and I'm working on the big missing feature, which is text editing support.

> A core premise of Cocoa, and MVC in general, is that UIs are a projection of data into a different form of data, specifically bits on a screen.

This is a tangent, but the implicit assumption that the UI is visual is just begging for a response from an accessibility perspective, so here goes.

Accessibility is very much an afterthought in native GUIs, not only in Cocoa, but also in Windows with the UI Automation API, and AFAIK with other native accessibility APIs as well. With these APIs, the assistive technology (e.g. screen reader) pulls information from the application (usually via the GUI toolkit), through repeated calls to methods defined by the accessibility API. Often the AT has to do several such calls in a row (and those often translate to multiple IPC round trips, making things slow). And the UI might change between such calls; there's no guaranteed way to get a consistent snapshot of the whole thing, as there is with a visual frame. On the application/toolkit side, these methods may return different responses from one call to the next, and the application or toolkit has to fire the right events when things change.

The web improves on this, in that accessibility information is conveyed through HTML tags and attributes. And yes, this is included in the output of a React component's render function. So while in practice, implementing accessibility may still be an afterthought, it's not an architectural afterthought as it is in native platforms.

One of my goals in AccessKit [1] is to work around this shortcoming of native accessibility APIs, particularly for developers of cross-platform non-web GUI toolkits. In AccessKit, the toolkit pushes a full or incremental accessibility tree update to the AccessKit platform adapter, which maintains the full tree in memory and uses that to implement the platform accessibility API. This even works for immediate-mode GUIs, as one can see in my proof-of-concept integration with the Rust egui toolkit [2].

[1]: https://github.com/AccessKit/accesskit

[2]: https://github.com/mwcampbell/egui/tree/accesskit

I can also report some modest progress on my own work on accessibility of immediate-mode GUIs. I have a branch of the Rust egui library [1] that has basic accessibility on Windows using my AccessKit project [2]. I do have a long way to go to make this fully usable and ready to submit upstream, especially when taking non-Windows platforms into account.

[1]: https://github.com/mwcampbell/egui/tree/accesskit

[2]: https://github.com/AccessKit/accesskit

Eh, there was entirely valid reasons for the backlash :)

Redux _was_ overused in the first couple years. The original patterns _were_ very boilerplate-y. There _are_ a lot of other good tools for varying use cases that overlap with things that people have used Redux for: Context for prop drilling, React Query / Apollo for data fetching, Zustand/Jotai/Mobx/five-million-other-libs for state management.

Redux will never be the "must use this" lib again the way it was there for a couple years.

And that's a _good_ thing, because folks should take time to think about what problems they actually need to solve in their apps and pick the tools that work best for those problems.

But it's also true that Redux _is_ still a useful tool, and that RTK has addressed the pain points in using Redux. So, still very much a viable choice today, and the positive feedback we get on RTK daily shows that.

Really, the bigger issue today is that a lot of folks don't seem to understand the technical differences, tradeoffs, and intended use cases between a lot of these tools.

I wrote an extensive post describing the differences between Context and Redux to try to help with that:

- https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

I've also been trying to start up a community-driven site to list common tools for various use cases (state management, styling, build tools, data fetching, etc), to act as a resource to help clarify this sort of confusion:

- https://github.com/markerikson/react-community-tools-practic...

Sadly I haven't had time to push it forward myself due to all the other responsibilities and tasks on my todo list, but hopefully at some point we can get enough info filled in for it to be a real resources that we can point people to.

Good question!

The really short answer is: mostly looking at NPM download stats, Github "depended by" numbers, and random polls on Twitter.

Which are all _horribly_ flawed metrics, but they're also all we have to go by.

I wrote a couple longer comments on Reddit a while back that went into more details on some of the numbers and the potential flaws in using them:

- https://www.reddit.com/r/reactjs/comments/lcgqnd/state_manag...

- https://www.reddit.com/r/reactjs/comments/skbyb1/the_most_po...

and unfortunately you asking me about this is tempting me to turn those comments into a blog post with some additional thoughts :)

I'll definitely agree that Redux usage has peaked in _relative_ terms, although as you can see from the download numbers it seems to still be growing in _absolute_ terms. Also it's entirely possible that fewer new projects are choosing Redux.

Then again, how do we even count "usage" in the first place? I've seen Web3 app boilerplate repos that include Redux Toolkit. If 1000 people clone that repo and play with it, how do we compare that usage conceptually vs one app using Mobx that's been around for years and has a bunch of developers working on it daily?

As I've pointed out in a number of podcasts and articles: I'm not trying to convince people they _must_ use Redux, or even that they _should_ use Redux. I just want people to be aware that modern Redux is way easier than legacy Redux, that Redux _is_ still widely used and is a viable choice, and what some of the tradeoffs are when using Redux or any other state management library.

I've actually been trying to get the community to come together and work on a centralized site that would list tools in different use cases and categories such as state management, styling, data fetching, and build tooling, describe purpose / use cases / tradeoffs for each tool, and have that as a recognized resource for people to use when researching what to use for a project. You can see the original RFC discussion and prototype site here:

- https://github.com/markerikson/react-community-tools-practic...

- https://react-community-tools-practices-cheatsheet.netlify.a...

Sadly I haven't had time to push this forward, and it needs to have more people involved and helping fill out content on the various topics (not just me).