I think you need to have a demo use case in your app so people can better understand what this is about.

I tried to make an invoice document type. So far I got simple header data and line items and I created a method to add up line items to a total. It would be nice if methods could be triggered to run automatically. I can place buttons to run methods, but can I run a method at document update or field update?

Also I to speed up creation of methods you should have simple aggregation function like summing all items of a list (given a field name to sum over).

Well I'm proposing to have a workspace with everything structured indeed, where all the documents would be "programmable" and "queryable" and where unstructured data would simply be attachments of structured data.

At some point when uploading a new "file", I think the framework should systematically call a multimodal LLM to extract structured data from it, so that it can be queried from anywhere in the workspace. My main concern on this is that the LLM should stay local...

Yes you are right this is lacking a good and simple demo usecase, I'm working on it.

Yes, as you've seen, some field types have a limited set of "builtin methods" that I've added just for the demo, and List is clearly the one that should have much more ! (map, reduce, filter, sort, sum...).

And indeed, being able to call methods dynamically in "formulas" like Excel does, and not just when clicking on buttons (what excel calls "macros") is a must-have as well !

I'm super impressed. I love the names (text not string) and extra fields (like the multiple choice and tensor). But I'm a bit concerned about the complexity. Don't answer these, I figured it out, but this is how it felt: how do I make an array (numbered list) vs a named list (object)? I didn't realize the intro document itself was, well, a document. I was thinking it was a typical website with a sidebar. Script, whiteboard, simulator (??) I though json was just a hierarchy. Schema, Interface, raw data, json. Its a lot of jargon. Is a document a type of json object? Is there a fundamental difference between whiteboard file and a document file? Is a whiteboard a type of document? Can a document be a field in a document? When editing an item, do I need to fill out the interface, methods, snapshot, etc. Where is the save/submit button? (I known their isn't one, but I kinda expect a "I'm adding a new field, okay I'm done adding it and want to go back to a table-of–contents view") I think the UI needs to answer these because it feels overwhelming). You probably even explain it in text somewhere, but let's be real; IRL people aren't going to read the docs.

Good news is, I think its easy fixes; hide the templates the first time someone is making something (only let them make a doc). Hide the methods, snapshots, etc too. Wait till they've done some stuff. Change the "x" button to "save" even though its not really saving.

The windowing system is really impressive, and I've always loved the detached tables of MacOS's spreadsheets. But at the moment I think it adds to the overwhelming feeling.

Don't let my criticisms weigh you down though! I would've been happy if this had 1/10th of the features.

Yes you are right, the complexity at first sight is a problem. The onboarding journey should be clearer, and indeed there is too much jargon to digest before you can really start. That's also probably because it's more the basis of a framework than a concrete product to use as is (hence the rather detailed but probably too long documentation). All the fixes you mentioned would clearly improve this first impression. Thanks !

Even though I critiqued the UX, the UI itself is incredibly polished. Which is a a pretty big deal for a framework. Its also pretty rare for me to see that in hackernews UI demos.

In terms of being/not-being a product; really, the most exciting part (for me) would be having (just) the doc-editor as a web component. I'll ask in a separate reply about that since others might want to know.

I particularly like the schema editor -- would it by any chance be available as a component to be used elsewhere, ideally open-source? I've been looking for a good browser-based editor for JSON Schema (or any schema, as long as it's configurable), but nothing I found really fits the bill.

It does not rely on JSON schema at all, the idea was to build a representation that binds together data structure, views and behavior in a self-contained way (like .xlsx does).

There are a few tools that do enable to link JSON schema to views, like react-jsonschema-form (https://rjsf-team.github.io/react-jsonschema-form/) but you need to manage them separately, and they usually do not propose a way to add the fields "methods" (which was the feature I found interesting to make "dynamic" spreadsheets).

That being said, I think the framework should clearly propose an export from Schema to JSON Schema or Yaml at some point, just as you should be able to start building your Schema by importing a JSON Schema (and although there might be some gray zones between the 2).

No, sorry, it's not yet open-source, and currently there are some strong links between Document and Workspace (Links, Files...) that would need to be more "abstracted" to make the builder an independent component. But I hear you point ! (and all the comments in this thread are raising the same ! :) )

I'm aware of those, but I'm looking for a visual way to declare JSON Schemas, similar to the Schema view in your project.

But again, there would be some situations where the 2 representations would not be reconcilable: you would not be able to stream out views & methods to JSON Schema, and in the other way, some weakly declared heterogeneous types of json schema like oneOf, allOf, anyOf might not always be representable in this framework.

In terms of scope, you are thinking of both the "Editor" and the "Schema builder" ?

My initial intention was more to build a monolith app, like a simple version of MS Office for jsons. There are already some strong links between the notions of workspace and document: for example the Link field captures an id of another document or record that you have in your workspace, same for File and Image fields... (I guess a next step in the future would be to incorporate the notions of users & groups...). That could probably be abstracted by having something more plugin-based where you provide to the component your description for "what is another document" or "what is a file".

But I think I got your point as well that, if it is deemed to be a framework, it would be useful to let other platforms or verticalized apps use the same representation !