←back to thread

193 points yaoke259 | 1 comments | | HN request time: 0.001s | source
Show context
lelanthran ◴[] No.45024882[source]
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): >>45024990 #>>45025096 #>>45025261 #>>45025292 #>>45025332 #>>45029796 #>>45030644 #
yaoke259 ◴[] No.45025332[source]
Svelte, React and Vue allow for easier event handling, at least that was my rationale, is it possible to achieve the same with html?
replies(1): >>45025553 #
lelanthran ◴[] No.45025553[source]
> 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?

replies(2): >>45025676 #>>45026843 #
yaoke259 ◴[] No.45025676[source]
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.
replies(2): >>45026181 #>>45031586 #
1. tomByrer ◴[] No.45031586{3}[source]
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.