Our great sponsors
-
Graphite
2D raster & vector editor that melds traditional layers & tools with a modern node-based, non-destructive, procedural workflow.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
The web browser gives us an extremely frictionless development and deployment process. Our CI generates a fully deploy at a unique link for every commit which lets us open and test PRs with a single click. It deploys updates to users without needing to make them go through an updater. In these relatively early stages of our development process, the importance of the velocity that gives us cannot be understated. Plus, the ability for users to try it out in one second is quite helpful.
I've designed the whole architecture specifically to avoid the web UI "feeling like a web app" with the subtle latency of interacting with the site. I wrote all-custom UI components using the minimal amount of HTML and CSS to achieve the requirements instead of depending on an external component framework which always loves nesting dozens of `div`s inside each other to achieve what should be doable in one or two. And our highly-lightweight JS which calls into Rust (Wasm) lets it keep the slow logic out of slow JS. And we are using Svelte to move most of the frontend DOM management logic from runtime to compile time. This architecture really helps us keep performance levels as close as possible to feeling native despite using the web for its GUI rendering; and I believe it has succeeded at feeling responsive by comparison to most other web apps you use (even Slack, for example, which shouldn't be nearly as complex).
Web lets us build fast, deploy the latest version to users fast, leverage prevalent developer experience with HTML/CSS for creating GUIs, and avoid getting stuck in a box with Rust's currently-immature GUI ecosystem. That's the tradeoff we had to make early on, and it was a good decision. But we will eventually move towards a fully native version...
In the short term, we plan to use [Tauri](https://tauri.app/) which is sort of a hybrid between Electron and a native application. It uses the OS's webview to shrink the shipped binary to only a few megabytes and reuse shared memory resources with other webviews at runtime. It also runs all our Rust code natively instead of through WebAssembly so all the business logic in Graphite runs natively and only the thin UI layer becomes dependent on web tech for the GUI display.
In the long term, we plan to rewrite the entire GUI in [Xilem](https://github.com/linebender/xilem) which is the up-and-coming Rust GUI that I believe will finally get everything right, including performance (which is something many desktop GUI frameworks are actually bad it, and sometimes even worse than web). We'll still deploy a web version but at that point, it will become native-first.
Hopefully that roadmap and explanation of the architectural decisions clears up any worries about the short and long term state of our GUI.
The web browser gives us an extremely frictionless development and deployment process. Our CI generates a fully deploy at a unique link for every commit which lets us open and test PRs with a single click. It deploys updates to users without needing to make them go through an updater. In these relatively early stages of our development process, the importance of the velocity that gives us cannot be understated. Plus, the ability for users to try it out in one second is quite helpful.
I've designed the whole architecture specifically to avoid the web UI "feeling like a web app" with the subtle latency of interacting with the site. I wrote all-custom UI components using the minimal amount of HTML and CSS to achieve the requirements instead of depending on an external component framework which always loves nesting dozens of `div`s inside each other to achieve what should be doable in one or two. And our highly-lightweight JS which calls into Rust (Wasm) lets it keep the slow logic out of slow JS. And we are using Svelte to move most of the frontend DOM management logic from runtime to compile time. This architecture really helps us keep performance levels as close as possible to feeling native despite using the web for its GUI rendering; and I believe it has succeeded at feeling responsive by comparison to most other web apps you use (even Slack, for example, which shouldn't be nearly as complex).
Web lets us build fast, deploy the latest version to users fast, leverage prevalent developer experience with HTML/CSS for creating GUIs, and avoid getting stuck in a box with Rust's currently-immature GUI ecosystem. That's the tradeoff we had to make early on, and it was a good decision. But we will eventually move towards a fully native version...
In the short term, we plan to use [Tauri](https://tauri.app/) which is sort of a hybrid between Electron and a native application. It uses the OS's webview to shrink the shipped binary to only a few megabytes and reuse shared memory resources with other webviews at runtime. It also runs all our Rust code natively instead of through WebAssembly so all the business logic in Graphite runs natively and only the thin UI layer becomes dependent on web tech for the GUI display.
In the long term, we plan to rewrite the entire GUI in [Xilem](https://github.com/linebender/xilem) which is the up-and-coming Rust GUI that I believe will finally get everything right, including performance (which is something many desktop GUI frameworks are actually bad it, and sometimes even worse than web). We'll still deploy a web version but at that point, it will become native-first.
Hopefully that roadmap and explanation of the architectural decisions clears up any worries about the short and long term state of our GUI.