How to create a ready html component from jsx ?

[wassfila]

How to create a ready html component from jsx ? (this is not about runtime hydrating an html tag with js)

[wassfila]

• react server side components https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html
• react in a web component https://reactjs.org/docs/web-components.html#using-react-in-your-web-components
• suport in nextjs react 18 https://nextjs.org/docs/advanced-features/react-18/server-components

[wassfila]

• Is Puppeteer a proper way to generate native web components from jsx ?
  • svelte can create spa out of the box

[wassfila]

check react server component, do they work with ssg ?

[wassfila]

https://astro.build/
https://deno.com/blog/fresh-is-stable

[wassfila]

Astro creates component from custom .astro format which is equivalent to .tsx and can input any .jsx or any framework as child component https://astro.build/

[wassfila]

deno fresh does exactly that returninh html from call to a page route which contains jsx
https://fresh.deno.dev/docs/getting-started/create-a-route

[wassfila]

frameworks like nextjs also return html, but to be clarified if it is not bloated woth client side navigation and vdom, of if those can be disabled

[wassfila]

Note about opinion on Astro

I think what Astro has, which is to me the most interesting, is to allow functional programming with html components, e.g. manipulate html with "pure" javascript on the server.

When I say "pure" javascript, I mean that all tricks someone learns in js, nodejs are applicable (functions abstractions => components with parameters) and the programing flow can scale naturally
to compare with React, the first thing that hits are states with concepts anchored very deep in the development flow that require a second brain and generates fatigue in the long run, scaling is obscure, and transposing very basic standard programming concepts are already broken from the start, such as attempting to control lifecycle of your component. I like react and use it myself a lot, but I keep it only for apps that need update from json data necessarily on the client, I avoid it where I can.
Svelte, Solid,... and variables to states bindings are also nice, but again the data flow is radically different from the start, and black magic is running behind the scene, might be more advanced even better, it's just not pure js, you need a new dedicated brain, sell your soul to a framework and re-write all your libraries, push all your friends to do the same and you don't have any guarantee on when the concept will stop scaling with complexity.
I'm personally disappointed from web standards that did not solve trivial issues that push us to need frameworks. I trust the quality of implemented standards more than frameworks, so Astro gives the best compromise to overcome standards limitations (allow htm components paradigm) without trying to lock you in a new environment you can't get out from. Basically the highest selling argument I'd have for Astro, is that it's easy to get out from if needed as your code has clear html/js similarities. Anyone you knows js/html can read Astro out of the box !