We do share some of these concerns. In the next article I'm going to focus squarely on syntax. I think that the XML syntax for Marko has always been a bit of a barrier and at certain point to reach our goals it just made sense to embrace it. The hope is now that people have seen primitives like Hooks or the Composition API this will be an easy translation. These systems always have framework specificity no matter how we try to hide them. Svelte's $ sign has both assignment and function call semantics. This isn't really any different.
let and const is an interesting choice too. But I think you will find as we show more examples and you get a chance to try writing the code they actually make more sense than you'd expect. In our reactive world there are mutable bindings and constant bindings. This might be a bit too cerebral to translate but our hope is that you won't be thinking much about this as you get going.
What we hope that will help documentation is reining in all the current syntax Marko has into a consolidated set, that is both used internally by Marko and externally in end-user code. As always part of the reason to showcase this stuff early is to get feedback so we can make improvements.
Subcomponent Hydration is case that definitely is for more complicated sites and applications. Marko already aggressively partially hydrates, but we still see so many places due to component boundaries we need to ship more JS than we'd like. The only place you absolutely need to share the full JS is where the client is responsible for rendering, like under a conditional or dynamic loop. There are many places where the parent components are stateful, or have events etc, but 3 quarters of their template is still static. Maybe there are nested components on the static side as well. This way we choose to not include any of that code. It isn't enough to identify this is the beginning of the dynamic Island.
This can inform hydration strategy definitely. However, we do see value in separating the mechanics here from the UX. Sometimes arbitrary cascading loading/hydration is not desirable so expect to see more control over async boundaries and placeholders in this next version. There are few different ways to attack progressive hydration and we will be looking at them. But the first big win is to just combine our streaming with this new ability to ship less JS hydration code.
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.
We do share some of these concerns. In the next article I'm going to focus squarely on syntax. I think that the XML syntax for Marko has always been a bit of a barrier and at certain point to reach our goals it just made sense to embrace it. The hope is now that people have seen primitives like Hooks or the Composition API this will be an easy translation. These systems always have framework specificity no matter how we try to hide them. Svelte's $ sign has both assignment and function call semantics. This isn't really any different.
letandconstis an interesting choice too. But I think you will find as we show more examples and you get a chance to try writing the code they actually make more sense than you'd expect. In our reactive world there are mutable bindings and constant bindings. This might be a bit too cerebral to translate but our hope is that you won't be thinking much about this as you get going.What we hope that will help documentation is reining in all the current syntax Marko has into a consolidated set, that is both used internally by Marko and externally in end-user code. As always part of the reason to showcase this stuff early is to get feedback so we can make improvements.
Subcomponent Hydration is case that definitely is for more complicated sites and applications. Marko already aggressively partially hydrates, but we still see so many places due to component boundaries we need to ship more JS than we'd like. The only place you absolutely need to share the full JS is where the client is responsible for rendering, like under a conditional or dynamic loop. There are many places where the parent components are stateful, or have events etc, but 3 quarters of their template is still static. Maybe there are nested components on the static side as well. This way we choose to not include any of that code. It isn't enough to identify this is the beginning of the dynamic Island.
This can inform hydration strategy definitely. However, we do see value in separating the mechanics here from the UX. Sometimes arbitrary cascading loading/hydration is not desirable so expect to see more control over async boundaries and placeholders in this next version. There are few different ways to attack progressive hydration and we will be looking at them. But the first big win is to just combine our streaming with this new ability to ship less JS hydration code.