VSCode is a webapp [1], that is most often used wrapped in a shell that lets it act as a desktop app.
Even if you do consider it separate from webapps, it should still work with tab navigation and screen readers, which rendering to `<canvas>` doesn't allow for (at least without some very hacky workarounds).
Flutter faces a similar problem; to render cross-platform, they use a custom layer not standard to the system, and then try to emulate all the behaviors of a native app, which often feels broken and unnatural and is wasted work because the engineers are just rewriting and reshipping everything the platform already offers—at the cost of accessibility and general user experience.
This is a very interesting idea that could save a lot of time and pain in big projects.
The example shown reminds me pf Zed's CRDTs [1], and their journey to build a fine-grained version control system for agentic development [2]—I imagine this work could prove useful to the Zed/Cursor team, and likely shares a lot of functionality with DeltaDB [2].
What else do you build on the web with a UI framework if not a website? If you're making a distinction between websites and webapps, it's equally important for both to be accessible and work as expected with a browser.
That's a fair point, especially considering everything else you get with the plan.
However, the pricing is still a far cry from non-decentralized solutions (for example, MUX's free plan offers 100K minutes per month [1]) and so the only other selling point is joining the fediverse—which is a good thing, but hard to get people to convert on (in Bluesky's case the turmoil that is now X was required).
It's a great idea and challenging YouTube's monopoly is noble, but I don't see how the economics work out. The current pricing [1] charges $20/month for videos up to 20 minutes of video, which is reasonable but still far too expensive for most people to use.
It's a great first step, but I struggle to see who this would be used by. So far Bluesky seems to be the only decentralized platform that's broken into the mainstream, and it'll only be more difficult for the video market.
It's a nice idea, but the execution is taking the wrong path in my opinion. By rendering everything to a `<canvas>` they're sacrificing any hope of accessibility and compatibility with browser standards for UX.
I would have much preferred a React-Native-style approach, where they render to true HTML instead. Even then, WASM files are too heavy for quick loading times without good internet (and sometimes even with).
The projects I see that would most benefit from something like this are complex internal apps that need to be used in different places but aren't worth porting over/rewriting, but they would also suffer from terrible UX given the constraints of this design.
For all other projects, it makes for more sense to use React Native.
Great framework: one additional factor that should be considered (maybe this is implicit) is the platform you're building for.
You can run lots of languages on the web now thanks to WASM, but it's very hard to justify something other than TypeScript. If you're building a cross-platform app, React Native is the modern standard.
If you're building something similar to what everyone else is building (from a technical viewpoint), use the tech they use.
Even if you do consider it separate from webapps, it should still work with tab navigation and screen readers, which rendering to `<canvas>` doesn't allow for (at least without some very hacky workarounds).
Flutter faces a similar problem; to render cross-platform, they use a custom layer not standard to the system, and then try to emulate all the behaviors of a native app, which often feels broken and unnatural and is wasted work because the engineers are just rewriting and reshipping everything the platform already offers—at the cost of accessibility and general user experience.
- [1]: https://vscode.dev