egui
vite
egui | vite | |
---|---|---|
3 | 795 | |
1 | 65,146 | |
- | 1.5% | |
0.0 | 9.9 | |
5 days ago | 4 days ago | |
Rust | TypeScript | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
egui
-
Why Rust?
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.
-
UIs are not pure functions of the model
> 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
-
Raygui – A simple and easy-to-use immediate-mode GUI library
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
vite
-
Comparing Hattip vs. Express.js for modern app development
As of this writing, initializing a Hattip project requires some manual commands. However, keep in mind that a zero-config development environment based on Vite is in the works.
-
React TypeScript - Vite + React
import { defineConfig } from 'vite' import react from '@vitejs/plugin-react' // https://vitejs.dev/config/ export default defineConfig({ plugins: [react()], server: { port: 4200, } })
-
I Disappear
For the frontend of "I Disappear," I leverage the automated build & deploy system provided by Netlify, which seamlessly integrates with Vite. This setup ensures that every deployment is optimized for performance, utilizing Vite’s modern build tools to enhance speed and efficiency.
-
FlowDiver: The Road to SSR - Part 1
Given our team's collective proficiency within the React ecosystem, we decided to leverage this expertise for our project. Initially, we contemplated utilizing Next.js; however, due to the limited practical experience with this technology among key engineers and the pressing timeline to develop the first prototype, we opted for a Single Page Application(SPA) approach. For bundling, we selected Vite, primarily due to its super fast build times, simplicity of configuration, and potential for a nearly seamless transition to server-side rendering.
-
Inflight Magazine no. 9
We are continuing to add new project templates for various types of projects, and we've recently created one for the infamous combination of React with Vite tooling.
-
Top 12+ Battle-Tested React Boilerplates for 2024
Vite focuses on providing an extremely fast development server and workflow speed in web development. It uses its own ES module imports during development, speeding up the startup time.
-
Vite vs Nextjs: Which one is right for you?
Vite and Next.js are both top 5 modern development framework right now. They are both great depending on your use case so we’ll discuss 4 areas: Architecture, main features, developer experience and production readiness. After learning about these we’ll have a better idea of which one is best for your project.
-
Setup React Typescript with Vite & ESLint
import { defineConfig } from 'vite' import react from '@vitejs/plugin-react-swc' import path from 'path' // https://vitejs.dev/config/ export default defineConfig({ plugins: [react()], server: { port: 3000 }, css: { devSourcemap: true }, resolve: { alias: { '~': path.resolve(__dirname, './src') } } })
-
Approaches to Styling React Components, Best Use Cases
I am currently utilizing Vite:
-
Getting started with TiniJS framework
Homepage: https://vitejs.dev/