I wish it didn't run in a web browser. I know that makes it easy to get working for everyone, but I have never once been able to use a browser-dependent app for anything that wasn't trivial -- and I have tried.
Indeed but by using Rust the project isn't painting itself into a corner. I seriously doubt the promised native versions will be simply shoved into Electron. Making it available on the web makes it easy to try which will help build the project.
Indeed. Not a fan of 'cloud'-based software or apps, because I know where it leads. Ultimate control over my usage by that corporation, and denial of future access through subscription models. Has happened before, and will happen again as everyone lets them get away with it.
This is not exclusive to web apps though (especially open source ones)? I don't see how what you said doesn't apply to the Adobe suite which is native.
It is not a question about the app being cloud based or local, it's more a question about the openness of the file format. With a standardized file format you can always change to another software.
Onshape is professional 3D mechanical CAD in a browser. It’s not at all trivial. Figma is professional graphic/interaction design that’s definitely not trivial. Onshape was acquired by PTC (makers of Creo) and Figma is being acquired by Adobe.
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.
I was unaware that this was still in an early stage of development and am glad to hear of plans to move forward on a native app.
> Hopefully that roadmap and explanation of the architectural decisions clears up any worries about the short and long term state of our GUI.
Yes.
To expound on my original complaint about web apps in general, my main problems with them are:
* responsiveness -- specifically latency when using the gui, as well as the long staggering pauses when I don't know if I am waiting for the server to respond or if there is an app hiccup or if the thing is frozen (the random long unresponsive breaks is what made me unable to use Roboflow, for instance)
* file management -- having to do everything in the browser is frustrating because of the way the browser is separate from the OS and makes everything an 'app'. Having to import files to some server to work on them is annoying when they are right here in my system. I also like to manage the files in a specific way and have access to program and preference files and know where everything is stored (if it crashes I can find the temp files, for instance). Sandboxing the app from the OS is the opposite of how I want a desktop application to behave
* portability / offline use -- I don't want to login to use an application. I don't want my files on a cloud and I want to be able to use the application forever, even if the original company is defunct
I hope this sheds light on where I am coming from. It seems you thought of at least a few of these issues and are mitigating them.
