To your first question I meant that when you hoist the static template parts(for cloning) you can just not ship them if the component is "Server" or "Stateful". In all cases the render code is basically hydration.
So if something is "Server" you don't have anything to hydrate and your component is basically a no-op. The only code it would have had to clone the node can safely not be included. With "Stateful" it is the similar, but you still walk to add the dynamic parts. You don't ship the static parts. With "Client" though you need to send the static parts since it needs to be able to re-create that part of the template.
The fact that the decision not to send the template is relatively easy and without almost any other code modification you achieve the 3 tiers since the hydration code is mostly what you would have generated anyway. I was just pointing out that "Server" components could be bucketed in with stateful since really only difference between the 3 is include template or not which only the latter does.
In reality we can do this at a subcomponent level since it isn't the Component that is "Client" but rather the control flow branch. But I thought it was easier to talk in terms of components. With proper analysis we can choose exactly which sub-template parts need static templates or not.
With a Component architecture like you might find in a VDOM you actually need to not include the "Server" components in the re-render tree. Current Marko uses a trick where we identify all the topmost "Stateful" components and forward the props up to them and basically treat them like their own entries. The thing is once we are stateful we depend on diffs so all "Stateful" components are "Client" components. Which means you lose the ability for "Server" components to exist under "Stateful" components. In the more granular approach you could have a lot more static stuff under "Stateful" components as long as it doesn't fall under a "Client" control flow branch which is why we are much more excited about this newer approach.
On the comment on interactivity. To be fair there might be something in HTMX that I wasn't seeing. I was just thinking about like Hotwire and the like. Basically a server template that doesn't take the potential for persistent client state in mind will need to go somewhere else.
React Server Components seem to be a way of making this separation in the same tree. But I think a lot of the angle being taken with a lot of JS libraries is to simplify things by abstracting out the server vs client bits behind common interface. Like if you are loading data from the API vs the Database that piece can be hidden behind your useResource hook. I guess there is some complication there but I'm very interested in this follow the data sort of thing where the component doesn't care where it's rendered. That might be idealistic but I'm thinking I'm liking the potential to write our components once at design time and have the compiler split it out. You only can do that if you write your components the way you would in the client as pure templates are insufficient. Of course Marko's newer approach is that these are same thing so I mean there is that.
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.
To your first question I meant that when you hoist the static template parts(for cloning) you can just not ship them if the component is "Server" or "Stateful". In all cases the render code is basically hydration.
So if something is "Server" you don't have anything to hydrate and your component is basically a no-op. The only code it would have had to clone the node can safely not be included. With "Stateful" it is the similar, but you still walk to add the dynamic parts. You don't ship the static parts. With "Client" though you need to send the static parts since it needs to be able to re-create that part of the template.
The fact that the decision not to send the template is relatively easy and without almost any other code modification you achieve the 3 tiers since the hydration code is mostly what you would have generated anyway. I was just pointing out that "Server" components could be bucketed in with stateful since really only difference between the 3 is include template or not which only the latter does.
In reality we can do this at a subcomponent level since it isn't the Component that is "Client" but rather the control flow branch. But I thought it was easier to talk in terms of components. With proper analysis we can choose exactly which sub-template parts need static templates or not.
With a Component architecture like you might find in a VDOM you actually need to not include the "Server" components in the re-render tree. Current Marko uses a trick where we identify all the topmost "Stateful" components and forward the props up to them and basically treat them like their own entries. The thing is once we are stateful we depend on diffs so all "Stateful" components are "Client" components. Which means you lose the ability for "Server" components to exist under "Stateful" components. In the more granular approach you could have a lot more static stuff under "Stateful" components as long as it doesn't fall under a "Client" control flow branch which is why we are much more excited about this newer approach.
On the comment on interactivity. To be fair there might be something in HTMX that I wasn't seeing. I was just thinking about like Hotwire and the like. Basically a server template that doesn't take the potential for persistent client state in mind will need to go somewhere else.
React Server Components seem to be a way of making this separation in the same tree. But I think a lot of the angle being taken with a lot of JS libraries is to simplify things by abstracting out the server vs client bits behind common interface. Like if you are loading data from the API vs the Database that piece can be hidden behind your
useResourcehook. I guess there is some complication there but I'm very interested in this follow the data sort of thing where the component doesn't care where it's rendered. That might be idealistic but I'm thinking I'm liking the potential to write our components once at design time and have the compiler split it out. You only can do that if you write your components the way you would in the client as pure templates are insufficient. Of course Marko's newer approach is that these are same thing so I mean there is that.