u/pavanpodila

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.

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.

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.

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.

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.

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.

We are still cleaning up the repo that will eventually be made public, but for now, use the traditional pub cache to look at the source.

Take a look at a production grade infinite canvas that we are using for the last year or so: https://diagram.vyuh.tech

it’s good work, no doubt about it. By the way, the Vyuh diagram also has free versions available on Pub.dev, which are being used to render gigantic workflows running into hundreds and even thousands of nodes, by the way. You can see the examples on the website and where we literally have thousand nodes and under such a large numbers using widgets is not practically useful and even possible.

The Vyuh diagram itself was built out of all the learnings from Vyuh node flow, where we initially used widgets and built an infinite canvas, and out of all those learnings we built a brand new rendering engine which has culminated into Vyuh diagram

Just use Vyuh Diagram: https://diagram.vyuh.tech

Awesome will try this out soon

I've been a long-time JetBrains user since 2006, for almost 20 years. In the last 1 or 2 years, I think JetBrains seems to have dropped the ball on how the IDE functions in the context of agents.

I tried Air, and it was not very satisfying to me. Since then, I switched completely to either Codex or Claude for most of my work, and I use their own harnesses to do it.

What I would love to see is JetBrains getting back into the game with Air and creating a harness so powerful that it can orchestrate tasks across models and do this seamlessly while maintaining git control and the ability to make quick edits in files where needed. The agents have to take center stage now, and the whole tab-based completion and autocomplete can go and disappear somewhere. You only need occasional edits where needed.

What I would really hope to see is an agent-first IDE that focuses more on orchestration and has a beautiful, highly visual harness so I can see things more clearly, like diagrams, rendered Markdown, and similar things. It should work very well across different models.

My 2c.

Great! thanks for considering the feedback.

You can combine this with sealed classes for a stricter type system

Totally. It's being used in production apps. Mostly feature complete at the moment

Sure, why don't you send me an email through the contact form? After that, we can set up a meeting, and I can walk you through some of the things that are possible with this. We are deliberately keeping it low key for now as it is being piloted with a few customers.

Yes, we have a complete stack that can do all of this, including:

• Creating workflows
• Driving it through an engine
• Form designers
• Report designers
• Dashboard designers

We build all of this as part of a composable ERP toolkit that we have been building for the past year. This is used right now in the pharma/manufacturing space for building regulated software. The good thing is the entire stack is Dart, front to back.

We are finding this stack much easier to maintain and easier to reason with AI. Because of the type safety, it also catches issues much earlier than waiting for runtime and praying that it will work.

You can have a quick look here: https://vyuh.tech/erp/

Filling forms could be your workflow step. Not built in though as it's more of a designer allowing you build your own runtime logic

We made heavy use of this in https://pub.dev/packages/vyuh\_node\_flow

I've had similar experiences with both. Definitely avoid AI loyalty. May the best tool win!

Let me know how it works out. We are constantly upgrading and enhancing this. Open to any quality of life improvements and suggestions

Yeah nowadays with AI the compliance checking becomes a little easier I think. What's important is to have a simpler mental model also about BPMN in terms of how the nodes work. I think in broad categories you only have activities, events, gateways. This is like the bulk of any BPMN workflow. If you can get that straight into your thinking and your mental models, I think we are good in general

I found the BPMN terminology and even the symbology a bit confusing so we chose to simplify things a little bit and not use excessive symbols to depict the behaviors and the types of nodes

Let me look into that