DEV Community

Discussion on: Of Chickens and Pigs - The Dilemma of Creator Self Promotion

 
brucou profile image
brucou • Edited

Svelte-like but not Svelte?

Svelte syntax is more like

<script>
    let cats = [
        { id: 'J---aiyznGQ', name: 'Keyboard Cat' },
        { id: 'z_AbfPXTKms', name: 'Maru' },
        { id: 'OUtn3pvWmpg', name: 'Henri The Existential Cat' }
    ];
</script>

<h1>The Famous Cats of YouTube</h1>

<ul>
    {#each cats as { id, name }, i}
        <li><a target="_blank" href="https://www.youtube.com/watch?v={id}">
            {i + 1}: {name}
        </a></li>
    {/each}
</ul>
Enter fullscreen mode Exit fullscreen mode

Arguing about syntax is like arguing about musical taste or preferred colors. That said, it is easier to sell something if you conform to the buyers taste rather than convincing the buyer to adapt to yours. Unless there are some very obvious or large advantages, you will have trouble convincing people to make a step toward you. And the Marko advantage here, if any, is at best small.

What makes Svelte so natural is that its template provides both cohesion (logic, styles, and markup in one place) and a separation of concerns (each concern is expressed in its own DSL which is custom-made for each purpose) that maximizes declarativeness.

Thread Thread
 
ryansolid profile image
Ryan Carniato • Edited

The problem is what you posted isn't equivalent. Change <for> to <custom-list>. And try it again. This isn't about built-in control flow only but allowing extensibility. That's what I meant when I said people using Svelte or Vue might not recognize it since it less common usage. But their solutions there are clunkier. In fact Svelte would look exactly like what I wrote with a few more curly braces. Slot Props. Vue is just as clunky.

The copy-paste distance is the same. HTML doesn't have control flow nor does it have refs. The static parts are the same. It is only the enhanced syntax that is different. Vue put its control flow on the elements so I can see an argument for that as it only takes adding attributes but the distance to Svelte is the same.

This idea of copy and paste from SO has been in Marko's advertising since the beginning and usually the first thing listed. And it's true. Of course, if the impression isn't that, that is unfortunate, but isn't based on reality. I'm looking forward to the next version of Marko, as the new syntax means we won't be overloading HTML syntax with our own semantics but giving them explicit syntax. This should remove moments of confusion around how certain attributes have different behavior than you'd expect from an attribue.

As for the benefits they considerable. On the surface we get most of the advantages of JSX without being JSX, in terms of patterns you'd use as Component composition. I enjoy that benefit immensely in Solid and it is similar here. You could do the same in Vue or Svelte but it's clunky as I demonstrated.

But Marko is taking this even further when you consider the approach to using markup for hooks. Granular reactivity allows us to basically unhinge updates from the components. This has a few big advantages. I've shown a few in Solid mostly in terms of performance and consistent model (no hook rules etc).

But in Marko's case with the compiler and cross template analysis allows things like automatic sub-component hydration. Ship minimal possible JavaScript. It also opens up compiled away reactivity like Svelte but in a granular way that isn't limited to component scope. Basically combining the advantages of both Svelte and Solid.

More so as tags co-location feels more natural than it does with libraries like Solid that break back into the JS even though they can accomplish the same. You can nest state creation under a for loop without breaking out different components and have the lifecycle handled implicitly. This removes duplicate logic between the code and the template. Only a library with granular reactivity can do this, and with Marko using tags it is all homogenous. This means a cut/paste refactor story that is pretty much unmatched. It's a return to writing basically markup templates without any thought into how they are broken up. Components are just not a real thing. You organize code by how it makes sense and do contiguous cut/paste without worrying your code will behave differently.

The hurdle of course is people's initial reaction to the syntax. The problem is we haven't found existing syntax that does this better. I'd be open to it. The last thing I want is to make adoption a hurdle because of something like this. Vue and Svelte just aren't good here.

Honestly, JSX is the best but there is value here keeping it more restrictive. While I've shown with Solid that distinction in the client is basically pointless (ie.. the notion that Svelte or Vue templates are some how more performant than JSX), on the server is more cutthroat and there is a very simple benefit. for is considerably faster than map so compiling maps to for makes a sizable difference. And that is something you can do with built-in control flow helpers.

The real problem is having to explain all this. The final result is something really quite powerful and you will soon even forget the syntax once it is familiar as it is terse and directed. Less special cases, specific behaviors. But people are predisposed not to like it as I've been seeing. My hope is when they see it in action it will click.

But throwing that example up on Twitter made it clearer for me. After dozens of responses, no one could come up with anything better. And it was much clearer how the Svelte/Vue syntax was undesirable. I'm always looking at ways to make this better, but when the problem is laid out (in more detail than I have here) I'm yet to get better feedback than basically what David said above. More or less "well you are right, but I really dislike that slash" and then we go through the rest of the characters and play around a bit and end up at the same place.

I've gone through this process a number of times now and it results in people begrudgingly admitting Marko's syntax makes complete sense for the use case. I don't like that it's begrudgingly. So we need to focus on turning the whole thing into a positive before people get hung up on it and change the discussion to showcase the incredible things Marko can do that no one else can.

Thread Thread
 
brucou profile image
brucou • Edited

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.

Thread Thread
 
ryansolid profile image
Ryan Carniato

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.