The thing I like about isServer is generally I think this gets buried in a service.
My personal perspective is that isServer prompts the whole Replace Conditional with Polymorphism scenario - or in this case don't complect things that are separate.
I think a case can be made that isServer is symptomatic of a design error. CSR frameworks deliberately design around components being client centric: components are created on the client, live on the client and die on the client.
Introducing SSR and Server-Side Components violates that fundamental assumption of CSR design. Typically addressing such a "design error" without fundamentally changing the underlying design leads to accidental complexity. And I think that's what's happening with React - its core is taking on more and more complexity to accommodate the illusion of its (beloved) abstraction while having to deal with the realities of its operational environment.
Contrast that with a framework that from the get-go frames the problem entirely differently:
Server side: Component needs to be rendered and perhaps some initial UI state. No behaviour required.
Client side: Component is already rendered and perhaps has some initial UI state. UI state dependent behaviour still needs to be bound to it.
Client side: Component is created entirely on the client.
CSR frameworks only worry about the last case - they are "incorrectly framed" to address the the other two cases down the road (with predictable consequences).
Marko's split works because it uses Single File Components. Not something we will see JSX libraries pick up.
My view is that it works for Marko because the template can be factored out as a commonality between the server (as an HTML fragment) and the client (as a DOM fragment). The issue is that most JSX code conflates code to control templating with code to enable interaction behaviour. Code to control templating is needed on both the server and client side. Interaction behaviour is purely a client-side aspect - therefore should be optionally injected (perhaps at compile-time) into rendering.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My personal perspective is that
isServerprompts the whole Replace Conditional with Polymorphism scenario - or in this case don't complect things that are separate.I think a case can be made that
isServeris symptomatic of a design error. CSR frameworks deliberately design around components being client centric: components are created on the client, live on the client and die on the client.Introducing SSR and Server-Side Components violates that fundamental assumption of CSR design. Typically addressing such a "design error" without fundamentally changing the underlying design leads to accidental complexity. And I think that's what's happening with React - its core is taking on more and more complexity to accommodate the illusion of its (beloved) abstraction while having to deal with the realities of its operational environment.
Contrast that with a framework that from the get-go frames the problem entirely differently:
CSR frameworks only worry about the last case - they are "incorrectly framed" to address the the other two cases down the road (with predictable consequences).
My view is that it works for Marko because the template can be factored out as a commonality between the server (as an HTML fragment) and the client (as a DOM fragment). The issue is that most JSX code conflates code to control templating with code to enable interaction behaviour. Code to control templating is needed on both the server and client side. Interaction behaviour is purely a client-side aspect - therefore should be optionally injected (perhaps at compile-time) into rendering.