DEV Community

Discussion on: FLUURT: Re-inventing Marko

Collapse
 
wannabehexagon profile image
ItsThatHexagonGuy • Edited

Haha, that's a very interesting name! Saying "FLUURT engine" during discussions is definitely going to make a few people laugh.

Regardless, it's exciting to see progress and most of all the fact that Marko is solving problems in a different way. The syntax looks pretty intimidating though. It looks like a hybrid of JS and XML, like markup that is actually capable of expressing logic. Don't you think that'll make documentation efforts tougher?

I believe sub-component hydration will be a game-changer for depth-heavy components like pages. Do you think that because of this, progressive loading can be further improved? Like currently, you'd go from page -> general layout of the UI -> rest of the UI. Maybe with sub-component hydration, I can load less critical components like text for example the last while prioritizing interactive components like buttons?

Edit: Also, don't you think that the use of let/const as tags will introduce any confusion? From what I understand, they serve different purposes right?

Collapse
 
peerreynders profile image
peerreynders • Edited

It looks like a hybrid of JS and XML, like markup that is actually capable of expressing logic.

One of the problems with JSX is that people treat it as markup even when it's only an "XML-like syntax extension to ECMAScript". Similarly here - it's not markup.

Other than that templating systems like Nunjucks (based on Jinja) can accomodate a lot of logic (for better or worse) - so the proposed syntax just seems to cut down on the braces and percent characters and is in line with Marko's philosophy: Marko is HTML re-imagined as a language.

Also, don't you think that the use of let/const as tags will introduce any confusion? From what I understand, they serve different purposes right?

Perhaps initially. But eventually:

  • let - define new observable
  • const - define computed (i.e. has one or more dependencies)
Collapse
 
ryansolid profile image
Ryan Carniato • Edited

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.