Clearly there's some overhead via the vDOM and simply using React-like templates when building large blocks of HTML. But if the bulk can be rendered server-side that overhead isn't an issue. So you can address this by simply reducing the data binding to the bare minimum of HTML that actually need to be interactive.
That way you can use the same templating and component systems app-wide but the default is still static-first.
That said - the Cons section notes: "The architecture is not suitable for highly interactive pages like social media apps which would probably require thousands of islands." But at that scale there's often far more performance concerns than vDOM vs compiler vs [some better optimized templating system], where the benefits aren't as straightforward (as linked below https://twitter.com/dan_abramov/status/1135423065570127872).
> Marko will recognize that the template fragment produces the same output every time and it will thus create the virtual DOM node once ... Rendering a static sub-tree has virtually zero cost. In addition, Marko will skip diffing/patching static sub-trees.
> Marko will also optimize static attributes on dynamic elements. [Static] attributes [are] only created once and [are] used for every render. In addition, no diffing/patching will happen for static attributes.
vdom is overhead server-side too. When rendering HTML on the server you really want to stream longer pre-allocated strings as much as possible. The serialization overhead of converting many small objects to individual HTML tags shows up in profiles. And when you want low latency and the ability to handle high loads, it matters.
PHP has many other problems. React was literally developed by arguably the largest PHP shop.
In terms of performance specifically you do a ton of unnecessary, redundant work, because you recreate the whole world and throw it away again with every request. PHP does it’s best to be a fast language and mitigate this issue, but it can’t really solve it.
Isn't this a core idea underneath the https://fresh.deno.dev/ "islands" and I believe the https://astro.build/ framework when they confronted issues around hydration/SSR?
https://www.patterns.dev/posts/islands-architecture/
Clearly there's some overhead via the vDOM and simply using React-like templates when building large blocks of HTML. But if the bulk can be rendered server-side that overhead isn't an issue. So you can address this by simply reducing the data binding to the bare minimum of HTML that actually need to be interactive.
That way you can use the same templating and component systems app-wide but the default is still static-first.
That said - the Cons section notes: "The architecture is not suitable for highly interactive pages like social media apps which would probably require thousands of islands." But at that scale there's often far more performance concerns than vDOM vs compiler vs [some better optimized templating system], where the benefits aren't as straightforward (as linked below https://twitter.com/dan_abramov/status/1135423065570127872).