> Given that Markdown fully supports HTML I have built sites using just Markdown + web components but that's... just how it works.
Agreed. My blog is a single shell script that runs pandoc on all the files in a subdir, generates a new .md file for table of contents, and then uses pandoc to generate a ToC.html file.
That doesn't mean that my the site uses no Javascript - the magic of web components means that I can place `<some-custom-component> ...` in the middle of my .md content and have interactive components in the resulting html.
What would be really useful is decent tooling for this sort of authoring.
this actually uses web components under the hood! the dsl is more secure and easier to write (at least in my opinion). For v2 I'll make the whole design/architecture more polished and web-component oriented, possibly with some sort of verifier/editor support???
The browser itself brings so much functionality that you can do stuff like check the status of the battery; create, save, and access files; get someone's precise lattitude and longitude; and _create and subscribe to streams_.
I'm not sure what you mean by, "html does not allow for event handling," ... but if HTML exists in a browser at all, there's plenty of event handling to go around.
> 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?
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.
While yea it is nice to directly deliver to HTML (I've done it many times), reality is most UI is in other framework languages. Plus I think a strong use-case is making output / browsing inside UI AI interfaces, which are also likely in a framework.
You provided enough for others who really care to add a direct-to-HTML plugin/fork if they so choose. Many of us want to use frameworks.
Happy to give you my spin on this. I use Vue, but in personal projects I mix Vue and vanilla JS according to page complexity. On pages that need more state management and would benefit from orderly code (such as the Options API for Vue), I use Vue. For simpler, shallower functionality I use plain JS. I want to emphasize my callout of Vue's Options API, which provides for very nice and easy to read structure to the code. React and Vue's current Composition API, I feel, look like and encourage spaghetti code. But hey, people get better typescript coverage, I guess?
> 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?
This is something I rarely use in Vue anymore. I think back in the day, when Angular first emerged and pushed these sort of frameworks, there was a philosophy towards making components embed in code as if they were HTML native elements, and not needing to write JS around the event. If I remember correctly, providing a value field isn't asking it for the value of the event. It's specifying which value in memory should be set to the output of the event... But my memory is dodgy on that. It's confusing and I rarely see it used these days, but maybe that's reflective on the projects I've worked on.
> 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.
Can you expand on the usecase here? Ordinarily, at least in Vue, there's no need to know the name of the event currently being triggered. The component emits a "change" event (or whatever you call it) and the parent component, when setting up the child component, will specify some sort of 'on-change' attribute that listens for the 'change' event and says which function should be evoked as the callback to it. So basically, instead of having to write `document.getElementById('foo').on('change', respondToFoo)`, you simply write `on-change='respondtoFoo'` directly on the element in the HTML.
It's not the world's biggest win, but it does reduce the amount of code our eyes having sift through in reading the JS, and attaches the event details directly to the element(s) they relate to, which I've found to be more readable.
> 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?
You can, at least in Vue, but it's working against the grain. There's two reasons why:
1. Separation of presentation and state. These frameworks like to keep the HTML/DOM as simple presentation tools, and store logic and data separately. So when triggering events, we want to be emitting the important data as data, and not be concerned with the presentational layer from which that data may have originated.
2. Reusability of components. Emiting dom elements creates a more tightly coupled environment where there are a lot of expectations of the object being emitted (and little assurance as to what that object contains). By only exposing data and leaving the DOM element behind, it's easier for invoking components to use that data without having to hold expectations of the data structures being passed through.
These are all great points too! so in your opinion should I still keep the {id, value} encapsulated event system, it offers less control, but a minimal api shape for easy handling at the application level
The value of generating framework components is that you can integrate the rendering with those frameworks. I've been working on a library to do exactly with a custom MDX pipeline: https://www.npmjs.com/package/react-markdown-with-mdx
- 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)
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
Custom elements/web components are just another layer of abstraction, and I'm also wondering "V2 will be pure js custom elements which can fall back to native html" how would you fall back to native html? custom elements depends on javascript, it's end game otherwise, you could setup some fallback markup but with no interaction
Yes fallback markup is what I meant, and yes, it would not be super useful if JS is entirely disabled. I figured custom elements would be good since they can encapsulate state and styling, allowing for slightly more sophisticated behaviour compared to raw dom elements
Testing myself, it seems to not work after a certain period of time - I'm curious what layer OP would start debugging this in or whether they should just do an entire rewrite!
am going to do a rewrite for v2. For some reason custom elements and astro don't play well with each other for me. I believe this issue does not happen on Sveltekit, Next etc. but this project is very young so bear with me
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.
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.
Sometimes I've made little things that I envision for a specific purpose and then think that use case is only MY intention and in theory could be used more broadly. These are tiny little personal projects I'm thinking about so they never end up getting real feedback. But without a firm alternative use-case I've wondered if it's better to just frame it specifically for the one I have.
yes, that was! and I totally understand what you mean. Whilst building this I've often wondered if other people have totally unrelated use cases for it
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.
Well, they want to be able to parse and render on the fly. Their chat example is a good example of this, linked from the navbar where the LLM is instructed to use their DSL and they can render UI from it which is an interesting application.
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?
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.
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.
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.
> Over the course of the past several years I had to open devtools just to send the correct data several times already.
I recently did this for a job application (some third-party was used to capture applicant details): the drop down of local universities ("where did you complete this degree?") was missing my university.
So I added it in via devtools, hit submit, and now am on the third interview :-)
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...
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.
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.
MDX is not secure by default, you'd be executing arbitrary JS code potentially sent by untrustworthy sources, which is advised against in the MDX website.
This is great and all but won't scale (as in, enterprise scale). I understand the knee-jerk reaction but at this point it misses the point about what is trying to be achieved here
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/
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.
MDX parses JSX so it's compatible with any JSX runtime, not just react.
You're right that MDX executes arbitrary code because it supports the `import` and string interpolation of MDX and performs unsafe evals.
Because those evals aren't safe to use at runtime, I actually created a library that uses the MDX parser to support the static subset of JSX (which is very similar to HTML making it static and secure): https://www.npmjs.com/package/react-markdown-with-mdx
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.
> 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.
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.
> Given that Markdown fully supports HTML I have built sites using just Markdown + web components but that's... just how it works.
Agreed. My blog is a single shell script that runs pandoc on all the files in a subdir, generates a new .md file for table of contents, and then uses pandoc to generate a ToC.html file.
That doesn't mean that my the site uses no Javascript - the magic of web components means that I can place `<some-custom-component> ...` in the middle of my .md content and have interactive components in the resulting html.
What would be really useful is decent tooling for this sort of authoring.
Nice discussion on this here just a couple weeks ago: https://news.ycombinator.com/item?id=44865997
this actually uses web components under the hood! the dsl is more secure and easier to write (at least in my opinion). For v2 I'll make the whole design/architecture more polished and web-component oriented, possibly with some sort of verifier/editor support???
It tickled me seeing the streaming example, thinking about how much better HTML deals with streaming
html does not allow for event handling, this allows for secure listening of the events at runtime, which afaik is not possible with html
You really might want to look into what the DOM is and how it works.
When HTML reaches the browser, all the markup is parsed, and the browser creates a Document Object Model (https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob...). That object model is an extremely robust API that's loaded with tons of functionality, not the least of which is working with events (https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob...).
The browser itself brings so much functionality that you can do stuff like check the status of the battery; create, save, and access files; get someone's precise lattitude and longitude; and _create and subscribe to streams_.
I'm not sure what you mean by, "html does not allow for event handling," ... but if HTML exists in a browser at all, there's plenty of event handling to go around.
Modern frontend frameworks wouldn't exist without JS events, not the other way around. You can absolutely do this with vanilla HTML+JS.
https://developer.mozilla.org/en-US/docs/Web/API/Event
I suppose a vanilla js version is possible? I'll need to look into this
Svelte, React and Vue allow for easier event handling, at least that was my rationale, is it possible to achieve the same with html?
> 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?
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.
eh, you're cool, don't worry about the naysayers
While yea it is nice to directly deliver to HTML (I've done it many times), reality is most UI is in other framework languages. Plus I think a strong use-case is making output / browsing inside UI AI interfaces, which are also likely in a framework.
You provided enough for others who really care to add a direct-to-HTML plugin/fork if they so choose. Many of us want to use frameworks.
Happy to give you my spin on this. I use Vue, but in personal projects I mix Vue and vanilla JS according to page complexity. On pages that need more state management and would benefit from orderly code (such as the Options API for Vue), I use Vue. For simpler, shallower functionality I use plain JS. I want to emphasize my callout of Vue's Options API, which provides for very nice and easy to read structure to the code. React and Vue's current Composition API, I feel, look like and encourage spaghetti code. But hey, people get better typescript coverage, I guess?
> 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?
This is something I rarely use in Vue anymore. I think back in the day, when Angular first emerged and pushed these sort of frameworks, there was a philosophy towards making components embed in code as if they were HTML native elements, and not needing to write JS around the event. If I remember correctly, providing a value field isn't asking it for the value of the event. It's specifying which value in memory should be set to the output of the event... But my memory is dodgy on that. It's confusing and I rarely see it used these days, but maybe that's reflective on the projects I've worked on.
> 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.
Can you expand on the usecase here? Ordinarily, at least in Vue, there's no need to know the name of the event currently being triggered. The component emits a "change" event (or whatever you call it) and the parent component, when setting up the child component, will specify some sort of 'on-change' attribute that listens for the 'change' event and says which function should be evoked as the callback to it. So basically, instead of having to write `document.getElementById('foo').on('change', respondToFoo)`, you simply write `on-change='respondtoFoo'` directly on the element in the HTML.
It's not the world's biggest win, but it does reduce the amount of code our eyes having sift through in reading the JS, and attaches the event details directly to the element(s) they relate to, which I've found to be more readable.
> 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?
You can, at least in Vue, but it's working against the grain. There's two reasons why:
1. Separation of presentation and state. These frameworks like to keep the HTML/DOM as simple presentation tools, and store logic and data separately. So when triggering events, we want to be emitting the important data as data, and not be concerned with the presentational layer from which that data may have originated.
2. Reusability of components. Emiting dom elements creates a more tightly coupled environment where there are a lot of expectations of the object being emitted (and little assurance as to what that object contains). By only exposing data and leaving the DOM element behind, it's easier for invoking components to use that data without having to hold expectations of the data structures being passed through.
These are all great points too! so in your opinion should I still keep the {id, value} encapsulated event system, it offers less control, but a minimal api shape for easy handling at the application level
The value of generating framework components is that you can integrate the rendering with those frameworks. I've been working on a library to do exactly with a custom MDX pipeline: https://www.npmjs.com/package/react-markdown-with-mdx
BTW: If you want "Turn Markdown into HTML at runtime" there's https://casual-effects.com/markdeep/
keywords for search optimization
So we have the following layers:
- 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?
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
Custom elements/web components are just another layer of abstraction, and I'm also wondering "V2 will be pure js custom elements which can fall back to native html" how would you fall back to native html? custom elements depends on javascript, it's end game otherwise, you could setup some fallback markup but with no interaction
Yes fallback markup is what I meant, and yes, it would not be super useful if JS is entirely disabled. I figured custom elements would be good since they can encapsulate state and styling, allowing for slightly more sophisticated behaviour compared to raw dom elements
Testing myself, it seems to not work after a certain period of time - I'm curious what layer OP would start debugging this in or whether they should just do an entire rewrite!
am going to do a rewrite for v2. For some reason custom elements and astro don't play well with each other for me. I believe this issue does not happen on Sveltekit, Next etc. but this project is very young so bear with me
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.
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.
thanks!
Was that the initial motivation?
Sometimes I've made little things that I envision for a specific purpose and then think that use case is only MY intention and in theory could be used more broadly. These are tiny little personal projects I'm thinking about so they never end up getting real feedback. But without a firm alternative use-case I've wondered if it's better to just frame it specifically for the one I have.
yes, that was! and I totally understand what you mean. Whilst building this I've often wondered if other people have totally unrelated use cases for it
Working on the same thing :) Glad to see more people working on this too!
https://www.timetler.com/2025/08/19/unlocking-rich-ui-compon...
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.
thanks!
The whole point of a build step here would be to _AVOID_ runtime rendering.
To me this just reads like not getting the point.
Well, they want to be able to parse and render on the fly. Their chat example is a good example of this, linked from the navbar where the LLM is instructed to use their DSL and they can render UI from it which is an interesting application.
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?
fixed
That’s nice for the easy stuff, but forms for any real application always have conditionally visible/required/disabled inputs/options/fieldsets.
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.
MDX does needs to be done at compile time because MDX contains unsafe evals in its syntax via imports and string interpolation.
I created a library for runtime MDX because of that: https://www.npmjs.com/package/react-markdown-with-mdx
yes like MDX, but not compiled :)
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?
>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.
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.
> Over the course of the past several years I had to open devtools just to send the correct data several times already.
I recently did this for a job application (some third-party was used to capture applicant details): the drop down of local universities ("where did you complete this degree?") was missing my university.
So I added it in via devtools, hit submit, and now am on the third interview :-)
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...
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.
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.
fixed
I've been working on a similar project using MDX as the parser to enable runtime static JSX tags in markdown: https://www.timetler.com/2025/08/19/unlocking-rich-ui-compon...
I'm curious why you decided to go with a DSL instead of embedding an established language?
MDX is not secure by default, you'd be executing arbitrary JS code potentially sent by untrustworthy sources, which is advised against in the MDX website.
> you'd be executing arbitrary JS code potentially sent by untrustworthy sources
On the other hand, this is true of every web site using a JS-world framework, and worse, even static sites if they use JS ad scripts.
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
thanks :)
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
yes, very interesting area to be explored further
I personally just use comrak (rust crate) with my actix server and akshama dynamic template, works great
Meanwhile, I'm over here going from https://zim-wiki.org -> HTML
Plus a little rsync script.
Hard for me to not look at this and find it all very silly.
This is great and all but won't scale (as in, enterprise scale). I understand the knee-jerk reaction but at this point it misses the point about what is trying to be achieved here
What enterprise uses a free open source github project to make bespoke toy html from markdown?
"It won't scale" is how over engineered code gets written
I've used similar software before and it surprises you how many open source dependencies I've seen in enterprise
The lengths that people will go to just to not write HTML...
> ```markdown-ui-widget { "type": "button-group", "id": "plan", "label": "Plan", "choices": ["Brainstorm", "Review", "Launch"], "default": "Brainstorm" } ```
I designed it this way to be more markdown like, and without support for styling
That's not even valid HTML...
I always wonder if anyone deploys this stuff to prod…
The scary thing is they do.
HTML was a mistake. I think banning XML would make the world a better place.
so you don’t use websites?
How would I be here if I didn't?
How do you think the page was rendered?
with an old mistake of a language
Starting to look like AGI will be written in markdown
real
This already exists in a mature state - https://mdxjs.com/
To me it has nothing to do with mdxjs.
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.
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/
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 and yes.
MDX parses JSX so it's compatible with any JSX runtime, not just react.
You're right that MDX executes arbitrary code because it supports the `import` and string interpolation of MDX and performs unsafe evals.
Because those evals aren't safe to use at runtime, I actually created a library that uses the MDX parser to support the static subset of JSX (which is very similar to HTML making it static and secure): https://www.npmjs.com/package/react-markdown-with-mdx
Suggestion: social card thingy so when it is linked to in Discord, X, etc, there will be a better looking link.
will do
I'm in Sydney and will be sleeping, will answer new questions in the morning!
Markdown form renderer, now we need a simple validator.
I'd rather convert them at build time, thank you.
I have fixed the home page bug, apologies
Looks like a modern version of mdwiki [0]
[0]: mdwiki.info
streaming not good and smooth. You should check out streamdown.ai
How is that possible
Svelte, react, and vue all require a build step if I'm not mistaken. What's the value in delaying markdown transformation until runtime?
so runtime use cases like LLMs can be supported, in the Chat example you can interact with a real llm!
You can just include Vue on a page and go to town, no build step needed.
Oh nice! I mostly use svelte and react, shouldn't have assumed Vue requires a build as well.
Only if you're using jsx