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

So we have the following layers:

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

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

Custom elements/web components are just another layer of abstraction, and I'm also wondering "V2 will be pure js custom elements which can fall back to native html" how would you fall back to native html? custom elements depends on javascript, it's end game otherwise, you could setup some fallback markup but with no interaction

Testing myself, it seems to not work after a certain period of time - I'm curious what layer OP would start debugging this in or whether they should just do an entire rewrite!

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

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