Separate templating from computing I'd assume.

Personally, I'd either just put the content in an ID-ed span and have a script to replace the content. Another, perhaps better, way is to use Alpine.JS which excels at this kind of stuff.

> I'd either just put the content in an ID-ed span and have a script to replace the content

And so your script is broken when someone else in your team (or maybe even yourself) renames or removes the ID and forgets to search in the whole project if some piece of code depends on this ID. JSX fixed all that mess 10+ years ago.

Yet you still need IDs for ARIA attributes, so now the JSX also needs a pile of shared variables

Either solution sounds more verbose than the example and require writing code in at least one other source file

But that separation is sometimes the point. A designer tweaking the looks has no chance to break the computation logic, and an engineer tweaking the computation part won't disrupt the design by mistake.

Terseness is good for code golf [1]. I disliked CoffeeScript after writing it for some time: nearly any typo can result in another syntactically correct program which, of course, does not what you wanted the original program to do, or fails the compilation in an unrelated place. A practical language has safety margins, aka some redundancy.

[1]: https://en.wikipedia.org/wiki/Code_golf#Dedicated_golfing_la...

Unless the designer removes the id, or the engineer introduces new output that is not styled.

But they're both framework-agnostic.

This snippet works with any framework and any build step.

  <script src="https://unpkg.com/alpinejs@3.x.x/dist/cdn.min.js" defer></script>
  <div x-data="{ 
    today: new Date().toDateString(),
    randomNum: Math.floor(Math.random() \* 100)
  }">
    <p>Today is <span x-text="today"></span></p>
    <p>Random number: <span x-text="randomNum"></span></p>
  </div>

I'll concede that Alpine.js is harder to understand and more verbose than Marko's syntax, but in order to use Marko you have to commit to the Marko framework. If you're willing to choose a framework solely for its JS-in-HTML capabilities, there are much better choices (like SvelteKit that handles JS-in-HTML wonderfully).

Fwiw, Marko predates svelte quiet significantly.

It was originally created by eBay iirc, back in 2014 or so.

It's syntax was even stranger back then, like writing "h1.myClass my header" to create a <h1 classes=myClass>my header</h1> and similar

You should give this a read, it explains why they chose to put everything within the markup

https://markojs.com/docs/explanation/separation-of-concerns