UIs are not pure functions of the model

• accesskit

  24 923 8.8 Rust

  UI accessibility infrastructure across platforms and programming languages

  

> 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

• egui

  3 1 0.0 Rust

  egui: an easy-to-use immediate mode GUI in pure Rust (by mwcampbell)

> 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

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• wordsmith

  3 0 0.0 Clojure

  How many words can you think of?

I explored a little what it would mean to use pure functions to generate state for a game that has a little physics: https://github.com/celwell/wordsmith/blob/master/src/cljs/wo...

• react-community-tools-practices-cheatsheet

  10 325 0.0 JavaScript

  Descriptions and use cases for common tools and practices in the React community

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

• react-community-tools-practic

  2 - -

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

• SaaSHub

  www.saashub.com featured

  SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  

Suggest a related project