yaoke259

will do

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.

I'm in Sydney and will be sleeping, will answer new questions in the morning!

real

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

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

yes like MDX, but not compiled :)

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???

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

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

I'm just too lazy lol, only wrote raw even listeners when I had no other choice ahahahaha. somehow my brain just did not make the connection

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

yes, very interesting area to be explored further

thanks!

thanks!

fixed

fixed

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.

I have fixed the home page bug, apologies

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...

I suppose a vanilla js version is possible? I'll need to look into this

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.

so runtime use cases like LLMs can be supported, in the Chat example you can interact with a real llm!

I designed it this way to be more markdown like, and without support for styling

html does not allow for event handling, this allows for secure listening of the events at runtime, which afaik is not possible with html

thanks :)

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.

Svelte, React and Vue allow for easier event handling, at least that was my rationale, is it possible to achieve the same with html?

interesting, I was not aware of this project. the UI side of my project is definitely not as polished haha