Doesn't seem to work as intended - in the "Gather Quick Details" example form, if I change any value, that change is not updated in the results column. Am I missing something?
The other day my project owner remarked that in the future perhaps we won't be building catalogs of items like the one I am currently, but interrogate an LLM assistant for a summary of the data - no need for forms and such.
I don't know how accurate that prediction is, but it got me thinking: what if coding assistants are a dead end and what users will actually prefer is going to be just a text box where you type in your human-language query?
Forms are here to stay at least in any kind of government or legal document, as there's liability associated with any mistakes, but less consequential stuff?
Seems like some people are confused by the design decisions of using React/Svelte/Vue and using it at runtime. The use case I had in mind was LLM interaction, which you can try in the Chat Demo (running a real llm btw!). LLMs require secure, runtime, and minimal DSL to generate interactivity, hence markdown-ui.
I actually tried it out and it feels pretty good.
Especially with SvelteKit, where the library ecosystem is still somewhat limited, a library like this is really exciting.
I particularly love that it works at runtime, since implementing that myself would be a hassle—so I really appreciate it.
- One that parses markdown text and generates javascript code, be it React, Svelte or whatever. It must generate compiled react/svelte source, e.g. it cannot generate JSX
- The javascript code get executed at runtime which runs the chosen framework, but without a build step such frameworks won't generate optmized code. In the case of React even gives you the illusion that HTML rendering is in immediate mode but it actually
- Keep another layer that diffs some tree data in memory that eventually generate/manipulates DOM nodes which is retained mode rendering
- Which in turn calls native bindings with the rendering engine(be it Skia or whatever)
So this is like MDX, but compiled... I always liked MDX and think this is good way to boost Markdown because, often we don't need much more then Markdown.
31 comments
[ 4.0 ms ] story [ 51.6 ms ] threadStill looks like a solid tool tho in my opinion
I'm not seeing the value of generating React, Vue or Svelte as opposed to generating DOM components.
and here it is
The other day my project owner remarked that in the future perhaps we won't be building catalogs of items like the one I am currently, but interrogate an LLM assistant for a summary of the data - no need for forms and such.
I don't know how accurate that prediction is, but it got me thinking: what if coding assistants are a dead end and what users will actually prefer is going to be just a text box where you type in your human-language query?
Forms are here to stay at least in any kind of government or legal document, as there's liability associated with any mistakes, but less consequential stuff?
- One that parses markdown text and generates javascript code, be it React, Svelte or whatever. It must generate compiled react/svelte source, e.g. it cannot generate JSX
- The javascript code get executed at runtime which runs the chosen framework, but without a build step such frameworks won't generate optmized code. In the case of React even gives you the illusion that HTML rendering is in immediate mode but it actually
- Keep another layer that diffs some tree data in memory that eventually generate/manipulates DOM nodes which is retained mode rendering
- Which in turn calls native bindings with the rendering engine(be it Skia or whatever)
- Which in turn calls OS apis and so on...
I'm asking sincerely: where are we going?
To me this just reads like not getting the point.
Plus a little rsync script.
Hard for me to not look at this and find it all very silly.
[0]: mdwiki.info