We've thought about this. Site has an "early startup" vibe (because it is an early startup). It's hard to know exactly how to reach the next level. Maybe just building more content? We're definitely not just dabbling with the idea or pulling the plug.
Yes, just make the content. Inspire others how they can use your product.
How do you imagine the customer journey goes? For me I would not consider to use Figma as a starting point to design a website, and not knowing the market too well I am wondering how common is Figma for marketing websites (that seems the main target audience I assume). But nevertheless, it seems to make sense to follow your vision on this.
We're not sure. WebGPU seemed too early to us. But as I got deeper into WebGL, the ability to do more arbitrary computation sounded more and more appealing. I wouldn't be surprised if migrated down the road.
We've only focused on latin script so far. We'll expand over time.
You actually just found a bug in our text editing. Cut/copy/paste is supposed to work. We've always tested with hotkeys instead of right clicking. So thanks for the bug report :)
Thanks! Yeah, text rendering nearly killed me. And all I did was latin script. I even punted on ligatures for now. I'm insanely impressed by the people who made full text support.
And maybe it sounds silly, but we don't personally feel pure love for technology. We're obsessed with a vision. And we've decided to conquer any technical challenge to make it real.
We already do lots of rendering to cached images. It's not a panacea. It saves you from unnecessary recomputing. But many actions update the rendered state per-frame. Zooming is a great example. You can't cache it at every resolution.
Maybe there's a way and we didn't find it? We looked at every example we could find. There's a lot of canvas apps without WebGL. But they're all orders of magnitude behind the Figma benchmark. Everything not using WebGL felt noticeably less smooth.
And in our user testing, our texting editing is already past the valley :)
True, but you don't need everything at max resolution simultaneously, so you can update your caches according to the current zoom level and thus get infinite zooming if you want.
At a large zoom level, few things get into the viewport, so it shouldn't cause troubles. My guess is that the troublesome scenario is when you zoom out (so that lots of pages can get rendered simultaneously), not when you zoom in?
Do you have any plans to open source / license the core rendering engine. Seems very useful for rendering in other contexts like textures for animations.
We weren't planning on it. It's not very clean or transferrable. We really hacked it together. We'd have to do a ton of work to make it useful for anyone.
You can use window.open to create a child window whose DOM is writable by the main thread of the parent window. You can then mount a React root in the child and go off to the races.
This issue with this strategy is usually over reliance on 3rd party code that assumes that globalThis.window is the only window, and event handlers don’t end up working or something.
If you are using good libraries that really understand the DOM (React itself handles this well) or you write things yourself, it’s a bit of bother to add “target window” as a parameter to various functions that were previously using the global but quite doable.
I built an electron app that has one “root” window that is hidden that I use to spawn child windows without needing to load an entire new web page & instance of the JS bundle into each window. I used Tldraw and had to do some patch-package to fix global window assumptions in a few places.
reply