- 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?
yaoke259 · 3m ago
I'm already looking at a v2 implementation as some others have correctly pointed this out. Since I'm already relying on customElements and web components, I should make that first class and change the framework implementations into thin wrappers. V2 will be pure js custom elements which can fall back to native html. wrappers will be even more lightweight. Hopefully this design is a strict win
0points · 52s ago
The whole point of a build step here would be to _AVOID_ runtime rendering.
To me this just reads like not getting the point.
lelanthran · 2h ago
Maybe I'm not understanding, but why is this "Turn Markdown into React/Svelte/Vue UI" and not "Turn Markdown into HTML"?
I'm not seeing the value of generating React, Vue or Svelte as opposed to generating DOM components.
randomtoast · 1h ago
> Maybe I'm not understanding, but why is this "Turn Markdown into React/Svelte/Vue UI" and not "Turn Markdown into HTML"?
It's very simple: the post had not been upvoted to the front page with the title you suggested.
threetonesun · 1h ago
It's very silly. Given that Markdown fully supports HTML I have built sites using just Markdown + web components but that's... just how it works.
What's really needed is a better editor experience.
I suppose a vanilla js version is possible? I'll need to look into this
yaoke259 · 1h ago
Svelte, React and Vue allow for easier event handling, at least that was my rationale, is it possible to achieve the same with html?
lelanthran · 51m ago
> Svelte, React and Vue allow for easier event handling, at least that was my rationale, is it possible to achieve the same with html?
I'm not really sure how Svelte, React or Vue allow for easier event handling. I mean, what's harder with standard events in Vanilla JS? Sure, it's not perfect, but what exactly is easier in Svelte, React and Vue that makes the trade-off with VanillaJS a reasonable one?
Some more questions, if you don't mind:
1. I see that the event interface specifies detail with `id` and `value` fields. What is the reason for using this? The underlying event already has a target, which will have the id and the value fields anyway. Are the widget's in this system so different that they have different id fields to the DOM elements?
2. There does not appear to be a field in the emitted event for the event sub-name (other than the custom name in the event structure itself). What if a component needs to emit something other than a "click" event? Ordinarily we'd get the event name from the event itself, so the handler knows whether it is being called on "focus", "click" "activate", etc. This information is lost with a custom event.
3. I'm still confused why you can't emit DOM elements; I mean, if you said "can't do two-way data binding" or something along the similar lines, it'd (maybe) make sense, but your response makes me think that you have not even considered it. I feel, maybe wrongly, that this library is both unnecessarily crippled and over-engineered - it targets spaghetti-as-a-pattern React, but not the hierarchical DOM?
yaoke259 · 37m ago
Thanks for the questions and super valuable feedback! To be totally honest, I came from a Svelte/Framework background and just did not deeply consider/realise you can create a pure dom version and event handling with just plain js. It's definitely a valid point that I'll take into consideration into designing the next version. Currently it does seem a bit overengineered since the React, Vue and Svelte implementations are actually all wrappers over web components, and still potentially offer some (potential) advantages in advanced state management which I have not yet explored. I'll definitely look into this more deeply.
thrown-0825 · 1h ago
keywords for search optimization
npn · 5m ago
I'd rather convert them at build time, thank you.
ekusiadadus · 56m ago
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.
yaoke259 · 16m ago
thanks!
yaoke259 · 1h ago
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.
mike_hearn · 22m ago
It's very cool and the fact it has a spec is the icing on the cake. There could easy be implementations for other runtimes. Probably, given the spec, an LLM could generate such an implementation.
yaoke259 · 16m ago
thanks!
Chidex12 · 2m ago
How is that possible
Tade0 · 1h ago
For me it stops working after several clicks.
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?
freetonik · 1h ago
>For me it stops working after several clicks.
This has been my experience with many rich web apps in the last several years. I have a habit of pressing Cmd+R especially before doing something important, and it feels like rebooting a computer in Windows 95 days.
Tade0 · 4m ago
Over the course of the past several years I had to open devtools just to send the correct data several times already.
The worst offender was a banking web app that didn't have my country of birth(internationally recognised as independent since 1945) among the options in the form.
yaoke259 · 58m ago
This happened after I turned the demo site into Astro to demo all the frameworks at once. For some reason it messes with the hydration of the site, will keep debugging...
friendzis · 1h ago
Yes and no. Natural language processing querybox will be one of the interfaces for two reasons: some people already (still?) associate that with trustworthy search, however since it is like "I'm feeling lucky" button it is perfect place to hide paid advertisements.
On the other hand, your PO dismisses the value of windowshopping and I don't see good catalogs disappearing anytime soon.
mirkodrummer · 15m ago
We will then build LLMs hooks for letting the AI output a rich version of the summary data, aka an html table first and... here we go again ;) It could build his own table but it won't be what the x customer wants/needs. Anyways I don't believe the prediction in the first place because LLMs are lossy compressors(even RAG), form masks over structured data are loss less.
yaoke259 · 34m ago
fixed
cluckindan · 2h ago
That’s nice for the easy stuff, but forms for any real application always have conditionally visible/required/disabled inputs/options/fieldsets.
yaoke259 · 53m ago
I have fixed the home page bug, apologies
AbuAssar · 1h ago
I saw this coming as there is a need for a DSL that targets LLM-first and that it will be made in the near future.
and here it is
yaoke259 · 12m ago
yes, very interesting area to be explored further
chromehearts · 2h ago
I'm having trouble with some widget elements not registering events properly, especially the checklists.
Still looks like a solid tool tho in my opinion
yaoke259 · 1h ago
thanks :)
archerx · 1h ago
The lengths that people will go to just to not write HTML...
Check it twice, what the submission implements is writing all the UI in markdown, not mixing markdown with React.
Perhaps I don't know mdxjs enough but that's my impression.
onion2k · 1h ago
Markdown UI is loading a bunch of components and then displaying them where you want them by parsing some Markdown to figure out where they go.
MDX goes a step further by enabling you to actually write the component JSX in the Markdown as if it's React (rather than using ``` syntax). You can just display a component that was loaded from somewhere else. Basically, if you took the Markdown UI components as React components, you could use the runtime embed option from here: https://mdxjs.com/guides/embed/
yaoke259 · 1h ago
the reason I made it is that mdxjs (afaik) only works with a build step and locks the user into React, and you are still technically running code sent by the LLM, rather than a more secure static JSON like object.
No comments yet
aa-jv · 1h ago
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?
- 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.
I'm not seeing the value of generating React, Vue or Svelte as opposed to generating DOM components.
It's very simple: the post had not been upvoted to the front page with the title you suggested.
What's really needed is a better editor experience.
https://developer.mozilla.org/en-US/docs/Web/API/Event
I'm not really sure how Svelte, React or Vue allow for easier event handling. I mean, what's harder with standard events in Vanilla JS? Sure, it's not perfect, but what exactly is easier in Svelte, React and Vue that makes the trade-off with VanillaJS a reasonable one?
Some more questions, if you don't mind:
1. I see that the event interface specifies detail with `id` and `value` fields. What is the reason for using this? The underlying event already has a target, which will have the id and the value fields anyway. Are the widget's in this system so different that they have different id fields to the DOM elements?
2. There does not appear to be a field in the emitted event for the event sub-name (other than the custom name in the event structure itself). What if a component needs to emit something other than a "click" event? Ordinarily we'd get the event name from the event itself, so the handler knows whether it is being called on "focus", "click" "activate", etc. This information is lost with a custom event.
3. I'm still confused why you can't emit DOM elements; I mean, if you said "can't do two-way data binding" or something along the similar lines, it'd (maybe) make sense, but your response makes me think that you have not even considered it. I feel, maybe wrongly, that this library is both unnecessarily crippled and over-engineered - it targets spaghetti-as-a-pattern React, but not the hierarchical DOM?
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?
This has been my experience with many rich web apps in the last several years. I have a habit of pressing Cmd+R especially before doing something important, and it feels like rebooting a computer in Windows 95 days.
The worst offender was a banking web app that didn't have my country of birth(internationally recognised as independent since 1945) among the options in the form.
and here it is
Still looks like a solid tool tho in my opinion
Check it twice, what the submission implements is writing all the UI in markdown, not mixing markdown with React.
Perhaps I don't know mdxjs enough but that's my impression.
MDX goes a step further by enabling you to actually write the component JSX in the Markdown as if it's React (rather than using ``` syntax). You can just display a component that was loaded from somewhere else. Basically, if you took the Markdown UI components as React components, you could use the runtime embed option from here: https://mdxjs.com/guides/embed/
No comments yet