This does look interesting. I don't see a difference between this and any other server-side templating language though. I actually need an isomorphic representation on the client and server. (this is what makes renderToString() valuable) I guess I could be extremely careful in writing the server output, and writing the client output to match, but at that point, I'd be writing it twice... and I could use any language... unfortunately, it'd probably end up being Handlebars.
It's for client side, not for server side. It's compiled into Wasm and delivered to client. You can use same code for server-side pre-rendering (for faster loading or for search engine indexing), but it is not main goal of Yew.
You should look at the all-F# SAFE Stack, then. It uses F# and .net core for the whole application and supports elm-style UI programming on the client side with react and server side rendering:
https://github.com/fable-compiler/fable-react/blob/master/do...
I'm not very familiar with the React ecosystem but I thought the entire point was letting the client-side handle rendering and passing structured data via API calls? renderToString() sounds like it's doing what every scripting language and templating framework has been doing for the past 20 years?
Look up server-side rendering in React. The major benefits are better/faster first page load experience and better SEO, especially for crawlers that don't have good JavaScript support. This way you can run the same code on the client or server depending on the circumstances.
The fringe benefit being I don't have to represent my app twice (once for server-side markup, the second for client-side JSX). As the size of any give app grows, keeping things in sync would be a nightmare.