Graphite: Open-source raster and vector 2D graphics editor

Whenever I read emotional adjectives like “delightful” (or worse, “beautiful”), I can’t take a project description seriously. Show me why I should be delighted, don’t tell me that I will. Because you don’t know me, and you should let me judge on my own. Such marketing language reads more like wishful thinking than anything persuasive.

To their credit, this may be the only Rust project that does not say "blazing fast" on the home page.

This. I want to see screenshots and demo videos. At least they don’t have the explainer videos with the tall characters dancing around with quotes about innovation and synergy, or the talking head interviews with C-level execs talking about ROI.

This was my exact thought. I was very on board until I read this and got ick'd out.

But they haven't mentioned blazingly fast on their website... not sure if the actual downloadable binary is even written in Rust.

Hi, Graphite creator and website author here. I 100% agree with you since I am very bothered by marketing copy that's painfully obviously written by a nontechnical marketing team, and I want to avoid that here.

But... I guess it's hard being on the other end when actually writing copy so I've failed to design text which can be highly terse and also descriptive of complex concepts without turning into paragraph-long explainers. I know what Graphite is in my head, but conveying that to newcomers is really challenging! But clearly I need to try again.

Is there any chance you'd be willing to reach out to me, ideally on Discord but email also works, and let me use you to test my copy to a fresh pair of eyes? Basically as a B.S. detector :) I'm currently working on a new revamp to the website with many new pages, so having a fresh perspective and some ideas how to make things more direct (but not necessarily overly technical, since it should be digestible to artists also) and less marketing-ey, I'd find that highly valuable.

Adobe used to have an app called Fireworks that was great for non-artists. They got it when they bought Macromedia. Too bad they killed it. I hope Graphite will replace it.

> Or that Illustrator and Photoshop would be combined into a single app

This is why I have been using Affinity. Very well done integration of vector and image capabilities. However, their development has slowed significantly in recent years despite having a great product.

I hope that Graphite can be something new and become the blender of 2D image editing. There is nothing really out there right now that has the professional features of paid applications.

".... usable instantly through a web browser or an upcoming native client on Windows, Mac, and Linux."

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.

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.

It’s also now a Code Review platform (https://graphite.dev/) but your example was my first thought as well.

More like somewhere between Photoshop and Illustrator

It's more like they are trying to bring the nose-based workflow to 2D art.

It's already very common in 3D and VFX.

We're in the process of refactoring a whole lot of code from the pre-node graph MVP implementation to the node graph version, while mainly aiming to avoid losing functionality in the process and not prioritizing new functionality quite as much yet. You can import or draw an image, though, and then right click in the node graph and search for certain effects and filters (similar to Photoshop's adjustment layers) and insert them in the chain of nodes. But to become actually useful, we need a bigger and more thought-out family of nodes combined with tools which automatically insert and update the nodes for you through the means of using the tools and doing lasso/marquee-style selections. Those are all a few months away on the roadmap, but it should be a lot more powerful and novel by then.

The file format will have its own built-in version control in the future, but I believe we are planning to use an ASCII representation so it could also theoretically be version controlled externally. The current `.graphite` files are entirely a temporary format. Once we finish the aforementioned refactor, we will design and implement a proper file format that ensures backwards compatibility (something the current files don't manage at all), it will be called `.gdd` (Graphite design document).

I'm working on a 2d vector editor that'll have that. It's basically a normal editor but where all properties can be expressions that refer to data or other objects. My first target use is for data visualization. What use cases are you interested in?

Not exactly CAD style constraints but close - https://cuttle.xyz/

Yes, that is very much the plan! I'm glad you asked because it's good to know people are needing that functionality in the real world. It'll probably start out with simple constraints but ideally turn to the constraint stack system like that in Fusion 360 and other CAD software over time. (I need to actually learn Fusion 360 so I have firsthand experience with that, though, plus then I could finally stop just lazily using Blender for all my 3D printing models.)

Not so much constraints per-se, but from a CAD drafting perspective I use Illustrator with Astute's SubScribe [1] plugin (used to be free) and Hot Door's CADTools [2] (one-time cost ~$300). The former is lightweight (e.g. tangency/perpendicular, orient tools) which is pretty nice (especially if you have extend path options from VectorScribe, a separate plugin of theirs). The latter is very robust and probably has some features most people wouldn't need, but lets you get pretty technical with designs.

There's a new UI tool called Dora [3] that has a simple yet novel constraint system that you might like. Tool is still early alpha but growing quickly.

That being said, Graphite's node-based system makes it a viable foundation to build this on! I've helped contribute to the project and Keavon (the creator) definitely has some thoughts on constraint nodes (e.g. for snapping, but also for restraint/relationships).

[1]: https://astutegraphics.com/plugins/subscribe [2]: https://www.hotdoor.com/cadtools/ [3]: https://www.dora.run/

Plug-ins will (at least for the foreseeable future) take the form of writing custom nodes in Rust. That code will automatically compile to CPU and GPU (unless it requires an allocator or other things not possible on a GPU architecture). In the future that will extend to custom viewport tools, custom panels, etc. either through a traditional plug-in API or maybe even through defining all that in the node graph itself, since the graph is basically its own programming language.

We will probably also need to have bindings into a Python API since Python is so popular among technical artists. Precisely how that will be done is yet to be determined, since we have a lot to do before reaching that point.