One huge thing that I feel nobody talks about about Svelte is that there is no easy way to pass components as props. Sure, there is slots and svelte:component but the ergonomics just don't match.
I see that as an advantage. Everytime I see components passed as props or a callback passed as child in react I regard it as a big red flag that something is wrong with the architecture of either the app or react itself.
It's funny; I often see it the opposite way. Passing components as props enables inversion of control and usually helps split responsibilities up more easily and generally avoids prop drilling or super components that do everything.
Yeah from a semantic standpoint it makes kind of sense sometimes but it just shows that jsx/xml is not the right abstraction level for the problem at hand.
If you compare xml style syntax to s-expressions there is a clear distinction between child nodes and attributes (a "bi-partite tree", not sure if the term exists). For markup like html where the child-data is the content and the attributes are meta-level annotations this makes sense. Even when looking at guidelikes for "how to design an xml schema/doctype" the responses are often like "use child elements for alle business data and attributes only for technical meta-data".
So from syntactical perspective there is a clear distinction between attributes and child elements. The main one I would say is that attributes are limited in the sub-structure they can contain (only primitive types or space separated lists).
The way react adopted the html/xml like syntax for the creation of javascript objects to allow the declaration of DOM nodes in a nicer way. On top of that react allows the creation of custom elements as functions and allows their usage via the same xml-like syntax.
But now as soon as these custom components have more complicated dependencies between each other the xml syntax gets (imo) misused as a poor dependency-injection layer. It's only possible because JSX allows for non-primitive attribute values and it sticks out like like a sore thumb because the semantics do not match the syntax (like defining a "+" operator that is not commutative).
In my opinion a better way would be curry the component creation or to introduce a real DI-layer for component configuration that is then used to load fully configured components that can then simply be composed in jsx.
