I’d do the multiplayer aspect first, that is the canvas and positions of each user.
Then I’d start adding components to the canvas and tracking those.
And finally I’d add metadata and other features to those components.
I don’t think in theory the base of the project would be that hard. It’s building those features that would be challenging, because there are a lot of small details that are important to designers.
I don’t think you need any libraries beyond whatever for wasm. Go concurrency is simple and straightforward. Could probably be done in a weekend.
I have not done anything with wasm specifically but I have built a real time collaboration tool backend using Go. It took like four days to put together the base functionality and another month to add all the features.
I could be totally wrong in my approach but I hope you figure it out and share it with us! Cheers
yeah, I think I like your approach, but the multiplayer aspect seems to be a great add-on, as opposed to a must-have feature to get the product started.
Both Go and Rust, and wasm are new to me - so i'm wondering about whether one is superior to the other.
I think figma has a lot of feature, and penpot seems a great replica of it, but I'm not too sure if the SVG + Clojurescript is a great way to build it..
I'm really looking for the core figma feature set to build.
1. Ability to have a canvas with zooms / freedom to create elemnets
2. Components and instances, and tree structured layers
3. Autolayout + CSS options. Frames and Pages
I think with the above 3, there's a viable basic feature set that would get one off the ground.
I did try the figma plugin apis, to extend native figma capabilities - but there's a limit to things you can do with it and it's getting to a point where more investment in the figma plugin seems a bit wasteful
Yeah, PenPot (mentioned in the comments below), seems to have chosen SVG as their choice of rendering.
But, looking at a few customer reviews - the performance issue seems to be noticable with the SVG approach (zooms are not clean, and more than 20 screens it starts feeling slow).
I don't have much experience with Rust besides just messing around, so in my case I picked something I know. Also it is a language I personally do not want to really go too deep into until I have a valid use case for it.
For most of my needs, Go offers an excellent ratio of developer experience, features, and performance.
I wouldn't say any language is superior or inferior - they all have a valid use case that makes sense. For me personally, I prefer to validate against the ratio I mentioned above.
That being said, Go concurrency is quite simple. It works well and offers great performance.
I’d do the multiplayer aspect first, that is the canvas and positions of each user.
Then I’d start adding components to the canvas and tracking those.
And finally I’d add metadata and other features to those components.
I don’t think in theory the base of the project would be that hard. It’s building those features that would be challenging, because there are a lot of small details that are important to designers.
I don’t think you need any libraries beyond whatever for wasm. Go concurrency is simple and straightforward. Could probably be done in a weekend.
I have not done anything with wasm specifically but I have built a real time collaboration tool backend using Go. It took like four days to put together the base functionality and another month to add all the features.
I could be totally wrong in my approach but I hope you figure it out and share it with us! Cheers