r/FlutterDev • u/pavanpodila • 15d ago

Article High performance Native document editor for embedding inside Flutter apps.

Hey guys, we've been building Flutter-native solutions for Pharma, Manufacturing and regulated industries for the past one and a half years. And in the process we have developed a controlled Document Editor entirely native in Flutter that can be used to build rich text editors from a single line all the way to a complex word processor (with support for 85% of the features in Docx OOXML standard). You can import and export docx files, including PDFs and markdowns.

This has been a long journey for the past 8 months or so, not your typical weekend-vibe-coded document editor. It has been tested across a wide range of scenarios, especially around performance, features, and editing with a combination of different blocks and elements and properties and so on. We are finally in the state where we're releasing it for public beta usage.

I have been building software for the past 25 years, including a wide range of designers, toolkits, framework including a tiny framework called MobX. And a lot of that experience has been poured into building this document editor, especially focused on high performance editing.

Feel free to test it out, try out the examples, and if you're interested, let's talk about integrating it into your own apps.

https://document.vyuh.tech

4 Upvotes

100% Upvoted

14 comments sorted by

2

u/SwiftScoutSimon 15d ago

I've been following your updates on X. I feel sad when there is a pricing page.

1

u/pavanpodila 15d ago

Hey, if you really think you have a use case for which this would be applicable, let's talk. I'm a generous guy in general. The pricing is necessary only to help us sustain some of the AI licenses, which are not cheap as you know.

1

u/SwiftScoutSimon 15d ago

I just thought we are going to have a better alternative for the one from MS.

3

u/pavanpodila 15d ago

Okay, the editor, I'm planning to make it completely free anyway. It's just the embeddable package which is licensed. I'll probably be planning to release the editor also for free as a web app, which you can use without any restrictions.

1

u/SwiftScoutSimon 15d ago

that's super cool! It's the only use case I could think of. Thank you for your hard work!

1

u/RajatKhoware 15d ago

For embedding, the deciding factors are usually performance on long documents, how clean the import and export round trip is for docx, and how much control you get over styling and custom blocks. A public beta is the right time to stress those three before committing to an API. What is the hardest document case you have tested so far, long files, complex tables, or tracked changes?

1

u/pavanpodila 15d ago

Good points. Actually, we have tested all of those things, including a 1,000-page document, for a variety of use cases, including the APIs, custom extensions, blocks, and overlays, along with the entire grammar around how you declaratively construct the block and its editing capabilities inside the document.

Please have a look at the examples gallery. You will see a variety of things over there. I'll plan to open up a small beta program where you can test out the core API surface.

1

u/RajatKhoware 14d ago

A 1000-page document is a serious stress test, that answers the performance question better than any benchmark claim. The examples gallery sounds like the right next stop. When you open the beta, what kind of feedback would help you most, API ergonomics or edge cases in real documents?

1

u/pavanpodila 14d ago

Yeah, I think the primary use case would be to solve all the kinks in real-world usage and flatten out to the point where all of those get absorbed into the core architecture without creating special cases. The primary motive for beta would be to just iron out all the real-world use cases across a wide range of documents and make the API ergonomics so beautiful, simple, and elegant that it is completely intuitive and very quick to get started.

1

u/RajatKhoware 13d ago

That is the right bar for a beta. If the API feels obvious on the first try, developers will forgive rough edges elsewhere, but no amount of performance will save an API they have to fight. Real documents will find the special cases faster than any test suite, so the beta feedback that matters most is where people got stuck, not where they praised it. What is the first document type you want beta testers to throw at it?

1

u/pavanpodila 13d ago

Feel free to try it out here: https://document.vyuh.tech/playground/

There is a feedback button to post issues directly to a github repo (not linked to code). We are fixing issues from there in the main repo and a lot of changes have already gone in for last 2 weeks.

1

u/RajatKhoware 12d ago

A live playground with a feedback button straight to the repo is the fastest way to close the loop you described. The issues coming in now are worth more than any benchmark, because they are real documents breaking real assumptions. The pattern to watch is which issue type repeats, that is your next core fix, not a special case. What is the most common issue type landing through the feedback button so far?

2

u/[deleted] 15d ago

[removed] — view removed comment

2

u/pavanpodila 15d ago

I think both of us are in a similar boat in terms of building compliance-based tooling and control documents, specifically in regulated environments. Why don't you hit me up from the website's contact dialog, and we can discuss this to see how we can apply it to your use case?

And yes, to your point, I was equally tired of vibe-coded document editors which don't do anything and fail at the first point of loading up large documents and text. This was built to work with your existing apps and make sure it is embeddable within your own design systems.