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.
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.
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?
markdown-ui-widget-html-version-long
<button-group id=plan label=Plan choices="Brainstorm,Review,Launch" default=Brainstorm />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.
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.
https://www.timetler.com/2025/08/19/unlocking-rich-ui-compon...
- 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?
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/
I created a library for runtime MDX because of that: https://www.npmjs.com/package/react-markdown-with-mdx
I'm curious why you decided to go with a DSL instead of embedding an established language?
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.
Plus a little rsync script.
Hard for me to not look at this and find it all very silly.
"It won't scale" is how over engineered code gets written
To me this just reads like not getting the point.
Still looks like a solid tool tho in my opinion
[0]: mdwiki.info