I am not sure I fully understand this so let me try to say what I understand. I guess the idea is to add capabilities to template languages. So control flow is one of those. Variables and closures are other capabilities. The core motivation behind this is that of course you can express any computation with a Turing-complete language (say JavaScript) while with a non-Turing-complete template language your computations are limited by definition. What you get in exchange of the language limitations is the ability of assert properties of your program (a template language is a programming language, and templates are code). One such property in our case is that it is hard to write a template program that does not terminate. So if you pass the parameters to the function the template describes, then you will get some output eventually. The same is not true with TypeScript for instance. You can write types that take the TypeScript compiler for a very very long ride. Most DSLs are not Turing-complete for that very reason. You want to know for sure that you can only write programs that terminates.
With that as a background, my understanding of your /let Marko syntax is that you are trying to add closures to the template language. That means being able to add constant/variables, and have a notion of scope. The idea is to have a template language that gets closer to a Turing-complete language so they can extend the computations that they can perform while still conserving some desirable properties. Not sure if I got that right. Language design means optimizing for some cases at the expense of some others. Most markup languages are not really optimized for variable declaration and handling.
But then if this is the story, this is what you have to explain. Comparing number of characters is not really insightful. Comparing syntax is not insightful either. What is insightful is the value of the new syntax, i.e. the new computations that it enables and that were not possible before.
Slot props are indeed clunky, but then you hardly reach for them. The cases where I had to use them was to build higher-order components, as a library author. For standard apps, I can't say I use the feature much. That is to say that most of the time you write easy to read code. And some of the time you use some convoluted syntax where some variable is defined in a child component, and then set in scope of the parent component through binding (<Hoverable let:hovering={active}> in Svelte). If you had to do this even reasonably often people would already be bitching about it all over the internet, which I am not aware that this happened. Which means that Svelte/Vue template languages is correctly designed vs. their use cases if few people complain about it.
So Marko may be optimized for some use cases, but it needs to explain what those use cases are, and why they are worth optimizing for, and the value that brings to users. A good syntax is simply one that people will like, because a language exists as an interface between users (developers) and machine. You can't only optimize for the machine (say, you make it easier for the machine to parse at the cost of the language user). Markdown is a good example of that. Markdown does not even have a grammar. There are alternatives to it that fell into oblivion while being much better in many ways (consistency, grammar, features, etc.) because Markdown felt more natural. reStructuredText is much better for documentation writing. And yet I still use Markdown for that.
I think you are mostly understanding what I'm describing but not connecting what this unlocks. I think this will be easier to show than explain so will have to wait a bit longer. I showcase it a bit in Marko: Designing a UI Language especially the last example, but this barely scratches the surface of what it would mean to develop in such a system.
As for the clunky syntax for slots, things like Web Components also have these sort of limitations and get by just fine. In a sense this isn't a must for Svelte or Vue and in the few places it happens people just jump through the hoops. However, having heavily used React this capability of JSX is really nice, and I immensely enjoy this in Solid. Having this encourages those sort of patterns. I feel this is significant, so I completely understand why one would want to write things this way. The in scoped variables are really free things and one of the things I like a lot about Solid, but making them tags makes this easier.
It's the type of thing you aren't going to miss if you never had it. But once you try you instantly feel how freeing it feels. Which means this will just take time. People hated JSX when they first saw it. I have no idea if people will buy into it, but this potentially is as paradigm altering. I'm going to write an article more on what I mean in a general sense without focusing on the syntax, because Solid has this quality too. But Marko fully embraces it in a way that only a dedicated DSL can.
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.
I am not sure I fully understand this so let me try to say what I understand. I guess the idea is to add capabilities to template languages. So control flow is one of those. Variables and closures are other capabilities. The core motivation behind this is that of course you can express any computation with a Turing-complete language (say JavaScript) while with a non-Turing-complete template language your computations are limited by definition. What you get in exchange of the language limitations is the ability of assert properties of your program (a template language is a programming language, and templates are code). One such property in our case is that it is hard to write a template program that does not terminate. So if you pass the parameters to the function the template describes, then you will get some output eventually. The same is not true with TypeScript for instance. You can write types that take the TypeScript compiler for a very very long ride. Most DSLs are not Turing-complete for that very reason. You want to know for sure that you can only write programs that terminates.
With that as a background, my understanding of your /let Marko syntax is that you are trying to add closures to the template language. That means being able to add constant/variables, and have a notion of scope. The idea is to have a template language that gets closer to a Turing-complete language so they can extend the computations that they can perform while still conserving some desirable properties. Not sure if I got that right. Language design means optimizing for some cases at the expense of some others. Most markup languages are not really optimized for variable declaration and handling.
But then if this is the story, this is what you have to explain. Comparing number of characters is not really insightful. Comparing syntax is not insightful either. What is insightful is the value of the new syntax, i.e. the new computations that it enables and that were not possible before.
Slot props are indeed clunky, but then you hardly reach for them. The cases where I had to use them was to build higher-order components, as a library author. For standard apps, I can't say I use the feature much. That is to say that most of the time you write easy to read code. And some of the time you use some convoluted syntax where some variable is defined in a child component, and then set in scope of the parent component through binding (
<Hoverable let:hovering={active}>in Svelte). If you had to do this even reasonably often people would already be bitching about it all over the internet, which I am not aware that this happened. Which means that Svelte/Vue template languages is correctly designed vs. their use cases if few people complain about it.So Marko may be optimized for some use cases, but it needs to explain what those use cases are, and why they are worth optimizing for, and the value that brings to users. A good syntax is simply one that people will like, because a language exists as an interface between users (developers) and machine. You can't only optimize for the machine (say, you make it easier for the machine to parse at the cost of the language user). Markdown is a good example of that. Markdown does not even have a grammar. There are alternatives to it that fell into oblivion while being much better in many ways (consistency, grammar, features, etc.) because Markdown felt more natural. reStructuredText is much better for documentation writing. And yet I still use Markdown for that.
I think you are mostly understanding what I'm describing but not connecting what this unlocks. I think this will be easier to show than explain so will have to wait a bit longer. I showcase it a bit in Marko: Designing a UI Language especially the last example, but this barely scratches the surface of what it would mean to develop in such a system.
As for the clunky syntax for slots, things like Web Components also have these sort of limitations and get by just fine. In a sense this isn't a must for Svelte or Vue and in the few places it happens people just jump through the hoops. However, having heavily used React this capability of JSX is really nice, and I immensely enjoy this in Solid. Having this encourages those sort of patterns. I feel this is significant, so I completely understand why one would want to write things this way. The in scoped variables are really free things and one of the things I like a lot about Solid, but making them tags makes this easier.
It's the type of thing you aren't going to miss if you never had it. But once you try you instantly feel how freeing it feels. Which means this will just take time. People hated JSX when they first saw it. I have no idea if people will buy into it, but this potentially is as paradigm altering. I'm going to write an article more on what I mean in a general sense without focusing on the syntax, because Solid has this quality too. But Marko fully embraces it in a way that only a dedicated DSL can.