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.
replies(7):
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.
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?
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.
The charitable take: many of the younger f/end devs don't really know that $FRAMEWORK gets turned into Javascript. I've worked with one dev in the past 5 months who did not realise that Javascript is the underlying target of "compiling" their react project.
The uncharitable take: This was vibe-coded from a set of specs.
> 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.
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.
Like, I get it, it's no different than starting with a high level language like JavaScript itself, but just wow. I remember when we didn't have these frameworks at all, when they were just about adding the missing stuff to js or making things a little easier for people in that world. Didn't realise we had moved on so far.
I'm not being critical btw, from the down votes I guess it came across that I was being down on OP but I'm genuinely just so surprised.
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.