Does this use JSON Schema in any way? This looks like a perfect fit for it, much better than being "inspired by Typescript".
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've felt your exact pain: I can only give normal people spreadsheets, because they don't know how to interact with any other data structure. It's a serious problem.
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 !
As the basis for framework I think its amazing. It has everything I would've ever wanted and more.
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.
Do you think you'll ever break out the doc-editor into a standalone web component? Ex: Imagine if VS Code reworked its settings.json and used this as a UI instead. Is that within the scope of the project, or is this supposed to only be a monolith app?
By standalone web component do you mean like a React component that you can embed in your own app ? Or something more "bundled" like a VS Code extension ?
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 !
This is awesome. It's very similar to something I've been wanting to make just for my own personal use, but better. Is the source currently available, I'd love to mess around.
Does this use JSON Schema in any way? This looks like a perfect fit for it, much better than being "inspired by Typescript".
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.
Thanks for your feedback !
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 ! :) )
> There are a few tools that do enable to link JSON schema to views
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.
I've felt your exact pain: I can only give normal people spreadsheets, because they don't know how to interact with any other data structure. It's a serious problem.
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.
Many thanks for your feedback, very useful !
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 !
As the basis for framework I think its amazing. It has everything I would've ever wanted and more.
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.
OK, thanks for your words !
Do you think you'll ever break out the doc-editor into a standalone web component? Ex: Imagine if VS Code reworked its settings.json and used this as a UI instead. Is that within the scope of the project, or is this supposed to only be a monolith app?
By standalone web component do you mean like a React component that you can embed in your own app ? Or something more "bundled" like a VS Code extension ?
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 !
This is awesome. It's very similar to something I've been wanting to make just for my own personal use, but better. Is the source currently available, I'd love to mess around.
Thanks ! No, sorry, it's not yet open-source, but i think it will be at some point.