HNHacker News
TopNewBestAskShowJobs

rabisg

2 karma · joined January 5, 2013

submissionscomments
rabisg··on OpenUI: Open Standard for Generative UI
The language is platform independent and the parsers and renderers are open source with the intention of letting people fork out into their own language. Would love your support in extending it to other platforms
rabisg··on OpenUI: Open Standard for Generative UI
Hey @bel8 Founder of Thesys here - company behind OpenUI. its designed to be very customizable but if you hit a roadblock please open an issue on GH and we'd be happy to patch it
rabisg··on We rewrote our Rust WASM parser in TypeScript and it got faster
My experience is from trying to get the React Native example to work with OpenUI. Felt Sonnet/Opus was much better at figuring out whats wrong with the current React implementation and fixing it than it was with React Native

But yes I see what you mean and I think people are trying to solve it with skills and harnesses at the application layer but its not there yet

rabisg··on We rewrote our Rust WASM parser in TypeScript and it got faster
We tried all formats - XML, json, jsonl, even toon - before deciding that we need to invest in OpenUI Lang

The primary motivation was speed and schema cohesion. We were running a JSON based format, Thesys C1, in production for a year before we realized we cannot add features fast enough because we were fighting the LLMs at multiple levels. It's probably too much to write in a comment but we'd like to write about the motivation and all the things we tried ona a separate blog soon

rabisg··on We rewrote our Rust WASM parser in TypeScript and it got faster
Haven't looked in depth but yes it feels like they are solving the same problem.

This is an alternative to json-render by Vercel or A2UI by Google which I'm guessing the flutter implementation is based on

rabisg··on We rewrote our Rust WASM parser in TypeScript and it got faster
as an author of the blog - ouch did a little bit more than prompt claude but a lot of claude prompting was definitely involved

I understand your frustration with AI writing though. We are a small team and given our roadmap it was either use LLMs to help collate all the internal benchmark results file into a blog or never write it so we chose the former. This was a genuinely surprising and counterintuitive result for us, which is why we wanted to share it. Happy to clarify any of the numbers if helpful.

rabisg··on We rewrote our Rust WASM parser in TypeScript and it got faster
(author here) We'd be really surprised if a rewrite could fix the boundary tax but if it does, we'd happily move over to it. People (including me) really underestimate how insanely fast browser's JSON.parse is
rabisg··on We rewrote our Rust WASM parser in TypeScript and it got faster
Its the library that bridges the gap between LLMs and live UI. Best example would be to imagine you want to build interactive charts within your AI agent (like Claude)

The most obvious approach would be to let LLMs generate code and render it but that introduces problems like safety, UI consistency and speed. OpenUI solves those problems and provides a safe, consistent and token optimized runtime for the LLMs to render live UI

rabisg··on We rewrote our Rust WASM parser in TypeScript and it got faster
One of the authors here. While that’s generally true, in this case it wasn’t time that helped us learn what worked. It was a nagging sense that the architecture wasn’t right, just days before launch, along with heavy instrumentation to test our assumptions.
rabisg··on We rewrote our Rust WASM parser in TypeScript and it got faster
The last part is really interesting. It feels like the whole world will soon become Python/JS because thats what LLMs are good at. Very few people will then take the pain of optimizing it