How to promote one's work? That is indeed a terrific question. One issue that many creators find is that the skills to promote are not the same you need to create, and you often need both when you only have one at the beginning.
Well you live you learn. Twitter doesn't come with a manual, so you can only learn as you go. That makes me think that if there is something to learn, there probably is a book (if not a thousand books) about it -- and a million self-proclaimed gurus.
It is true that reactions on social media are often more dramatic than in real life. I am afraid that as we spend more of our time on social media, it will end up being more common to see the same dramatic reactions in real life. As you correctly mentioned, there are a ton of people who mean nothing more to you than their moniker, and vice versa. This favors that. If it is your boss that is being a pain in an unholy place, I bet that you adjust your reaction. If it is your colleague, you adjust yet again.
I personally believe that the promotion medium with the largest reach (say the TV of tech) are probably conferences. So get a talk on Solid (or else) in one of those. You work for ebay god damn it. Many conferences will take you just based on that. You were in a punk band. Many conferences will take you even if just as a DJ (kidding). Then you do 3 conferences in the year, and you will know if you have something of interest or not, because it will have been exposed to enough eyes to make an idea.
The same advice that applies to Solid applies to Marko by the way. Marko has terrific tech and nobody knows about it. You guys need a dev rel or similar figure. And you need to start putting out articles out there and doing presentations in conferences because that spot you could have is used by other people to present their own rediscovery as the second coming. Also as I said, you get feedback, a lot of it, and that is quite important.
Ahhhh, this is all true say. Cheers to you good sir. Also to you Marko folk: he's right...you got so much good...but you're in need of a dev rel genius and your templating engine needs...I don't know but I can't look at it #sorrynotsorry. Such an underrated (and OG) piece of tech.
Hey hey, cool it with the Marko bashing on syntax. I presented the alternatives and they were all arguably worse. The problem is Marko wants to use a syntax more like JSX but without the JS.
Applying the same patterns using Vue's or Svelte's APIs are clunky. Not that Vue or Svelte's templates aren't slick, but that the primary use case for Marko, which is "Scoped Slots", are the arguably ugliest and most verbose part of their template syntax. For them it is an edge case so that is fine but Marko you would be using it all the time.
Svelte-like:
Marko:
But yes definitely. Marketing and promotion seem to be issues for projects I'm involved in. Marko did do some conference talks before, let's see how we can get back in that circuit.
Ok, ok, I retract that comment. It's not terrible it's just the slash throws me off. Looking at those two comparisons side by side certainly helps. I do prefer how much tighter/concise Marko is at least in this example. Svelte takes more effort and is more verbose in doing the same thing.
<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>
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.
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.
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.
How to promote one's work? That is indeed a terrific question. One issue that many creators find is that the skills to promote are not the same you need to create, and you often need both when you only have one at the beginning.
Well you live you learn. Twitter doesn't come with a manual, so you can only learn as you go. That makes me think that if there is something to learn, there probably is a book (if not a thousand books) about it -- and a million self-proclaimed gurus.
It is true that reactions on social media are often more dramatic than in real life. I am afraid that as we spend more of our time on social media, it will end up being more common to see the same dramatic reactions in real life. As you correctly mentioned, there are a ton of people who mean nothing more to you than their moniker, and vice versa. This favors that. If it is your boss that is being a pain in an unholy place, I bet that you adjust your reaction. If it is your colleague, you adjust yet again.
I personally believe that the promotion medium with the largest reach (say the TV of tech) are probably conferences. So get a talk on Solid (or else) in one of those. You work for ebay god damn it. Many conferences will take you just based on that. You were in a punk band. Many conferences will take you even if just as a DJ (kidding). Then you do 3 conferences in the year, and you will know if you have something of interest or not, because it will have been exposed to enough eyes to make an idea.
The same advice that applies to Solid applies to Marko by the way. Marko has terrific tech and nobody knows about it. You guys need a dev rel or similar figure. And you need to start putting out articles out there and doing presentations in conferences because that spot you could have is used by other people to present their own rediscovery as the second coming. Also as I said, you get feedback, a lot of it, and that is quite important.
I am sure there are other things. Keep on trying!
Ahhhh, this is all true say. Cheers to you good sir. Also to you Marko folk: he's right...you got so much good...but you're in need of a dev rel genius and your templating engine needs...I don't know but I can't look at it #sorrynotsorry. Such an underrated (and OG) piece of tech.
Hey hey, cool it with the Marko bashing on syntax. I presented the alternatives and they were all arguably worse. The problem is Marko wants to use a syntax more like JSX but without the JS.
Applying the same patterns using Vue's or Svelte's APIs are clunky. Not that Vue or Svelte's templates aren't slick, but that the primary use case for Marko, which is "Scoped Slots", are the arguably ugliest and most verbose part of their template syntax. For them it is an edge case so that is fine but Marko you would be using it all the time.
Svelte-like:
Marko:
But yes definitely. Marketing and promotion seem to be issues for projects I'm involved in. Marko did do some conference talks before, let's see how we can get back in that circuit.
Ok, ok, I retract that comment. It's not terrible it's just the slash throws me off. Looking at those two comparisons side by side certainly helps. I do prefer how much tighter/concise Marko is at least in this example. Svelte takes more effort and is more verbose in doing the same thing.
Point taken!
Svelte-like but not Svelte?
Svelte syntax is more like
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.
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.
foris considerably faster thanmapso compiling maps toformakes 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.
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.