Show HN: Turn Markdown into React/Svelte/Vue UI at runtime, zero build step

This discussion revolves around a tool that converts Markdown into UI components for various JavaScript frameworks (React, Svelte, Vue), with significant debate on its necessity and approach.

Utility and Approach: Markdown vs. HTML/DOM

A primary theme is the comparison between generating framework-specific UIs from Markdown and simply generating HTML. Several users question the value proposition, arguing that standard HTML and the Document Object Model (DOM) are already robust and capable of handling interactivity and events.

• lelanthran expresses confusion: "Maybe I'm not understanding, but why is this 'Turn Markdown into React/Svelte/Vue UI' and not 'Turn Markdown into HTML'?" This sentiment is echoed in the question about the value of generating framework components versus DOM components.
• mpalmer clarifies this further: "Modern frontend frameworks wouldn't exist without JS events, not the other way around. You can absolutely do this with vanilla HTML+JS." They provide a MDN link to the Event API.
• paceaux elaborates on the capabilities of the DOM: "When HTML reaches the browser, all the markup is parsed, and the browser creates a Document Object Model... That object model is an extremely robust API that's loaded with tons of functionality, not the least of which is working with events." They conclude with a direct challenge to the premise: "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."
• archerx takes a critical stance: "The lengths that people will go to just to not write HTML..."
• codegladiator offers a more explicit comparison showing how a Markdown-UI-widget definition could be represented in a "long" HTML-version, suggesting a simpler alternative exists.
• jrm4 shares their simpler approach: "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."

Event Handling and Framework Interactivity

The discussion delves into the specifics of event handling, particularly in relation to the creator's (yaoke259) assertion that frameworks simplify this.

• yaoke259 initially stated: "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 directly challenges this: "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?"
• ysavir provides nuance on framework event handling, highlighting Vue's Options API as readable but criticizing React/Vue's Composition API for encouraging "spaghetti code." ysavir also offers an explanation for the framework approach to event handling being cleaner for the parent component developer: "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."
• yaoke259 acknowledges this feedback: "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."

Further questions arise regarding the structure of emitted events:

• lelanthran asks about the detail field with id and value and the absence of an event sub-name: "1. I see that the event interface specifies detail with id and value fields. What is the reason for using this? ... 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?"
• ysavir weighs in on the detail field, calling it "confusing and I rarely see it used these days." Regarding event sub-names, ysavir explains how frameworks handle this implicitly: "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... will specify some sort of 'on-change' attribute that listens for the 'change' event..."
• yaoke259 contemplates the detail field: "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."

Rationale for Framework Generation: SEO and LLM Integration

The creator explains their design choices, particularly concerning search engine optimization (SEO) and integration with Large Language Models (LLMs).

• thrown-0825 suggests a marketing angle: "keywords for search optimization."
• yaoke259 clarifies the LLM integration as a primary use case: "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." They later reiterate: "so runtime use cases like LLMs can be supported, in the Chat example you can interact with a real llm!"
• AbuAssar anticipates this trend: "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."
• hombre_fatal supports this view: "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."
• mike_hearn praises the spec: "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."

Runtime vs. Build Time

A significant debate point is the decision to perform the Markdown transformation at runtime rather than during a build step.

• _heimdall questions this: "Svelte, react, and vue all require a build step if I'm not mistaken. What's the value in delaying markdown transformation until runtime?"
• yaoke259 re-emphasizes the LLM use case for runtime transformation: "so runtime use cases like LLMs can be supported..."
• whalesalad counters that some frameworks don't strictly require a build step: "You can just include Vue on a page and go to town, no build step needed."
• 0points directly states their preference: "The whole point of a build step here would be to AVOID runtime rendering. To me this just reads like not getting the point."
• npn agrees, stating: "I'd rather convert them at build time, thank you."

The project creator, yaoke259, explains their rationale for avoiding a build step to better support LLM interaction at runtime.

Comparison to MDX and Web Components

Users draw parallels between the project and existing technologies like MDX and Web Components, debating the unique value proposition.

• onion2k suggests similarity to MDX: "This already exists in a mature state - https://mdxjs.com/"
• alfonsodev differentiates: "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."
• onion2k elaborates on MDX's capabilities, particularly runtime embedding.
• yaoke259 clarifies their distinction from MDX: "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."
• yaoke259 also reveals that the underlying implementation uses web components: "this actually uses web components under the hood! the dsl is more secure and easier to write." They later state plans for V2 to "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."
• mirkodrummer questions the "fallback to native HTML" concept for custom elements, noting that they rely on JavaScript. yaoke259 clarifies they meant fallback markup.
• littlecranky67 sees a resemblance to older projects: "Looks like a modern version of mdwiki [0]."

Stability, Bugs, and Real-World Deployment

Concerns are raised about the stability, bugginess, and practical deployment of such a tool.

• chromehearts reports specific issues: "I'm having trouble with some widget elements not registering events properly, especially the checklists."
• aa-jv also found a bug: "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?" yaoke259 confirms it was fixed.
• Tade0 experiences instability: "For me it stops working after several clicks." They also share an anecdote of needing to use devtools to fix form submission errors for a banking app, indicating a lack of faith in robust form handling.
• lelanthran shares a similar anecdote about a job application form missing their university, requiring devtools manipulation.
• bottlero_cket questions production use: "I always wonder if anyone deploys this stuff to prod…"
• archerx replies grimly: "The scary thing is they do."
• freetonik relates to the instability with a habit of hard-reloading. yaoke259 attributes a bug to Astro's hydration issues when demonstrating multiple frameworks.
• DetroitThrow experiences similar long-term instability and wonders about debugging or rewriting. yaoke259 confirms a V2 rewrite is planned due to Astro/custom element compatibility issues.

Broader UI/UX and Future of Interaction

The discussion touches on the future of user interfaces, the role of LLMs, and the perpetual complexity of web development.

• Tade0 muses on their project owner's prediction that LLM assistants might replace traditional catalog-building: "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?" They still see a place for forms in high-liability contexts.
• friendzis agrees that natural language query boxes will be an interface but also a place for advertising, while also defending the value of visual "windowshopping."
• mirkodrummer expresses skepticism about LLM-generated UIs being truly tailored, calling LLMs "lossy compressors," while forms offer "loss less" structured data.
• zoover2020 questions the scalability for "enterprise scale," which mkoryak dismisses as a common way over-engineered code is written, asking what enterprise uses "bespoke toy html from markdown."
• nisten speculates humorously: "Starting to look like AGI will be written in markdown."

The creator, yaoke259, acknowledges feedback pointing out over-engineering and plans a V2 focused on web components to address these concerns. They express gratitude for feedback and willingness to improve.