p “Today is {Date.today}”,
  p “Random number: {(^100).pick}”

Thought I would share this example as written in Raku using https://harcstack.org

> I already disliked that immensely in PHP. Not going back to that spaghetti mesh-up.

That looks like a pretty normal template to me and nothing like plain PHP templates? What do you mean by "spaghetti mesh-up"?

Is there any significant difference between that and

    element.innerHTML=`
      <p>Today is ${new Date().toDateString()}</p>
      <p>Random number: ${Math.floor(Math.random() * 100)}</p>
    `

(ideally .setHTML() when it's available)

At that point I think I'd have a skeleton html file that fetches a JS that does it all. I'd take JS with embedded HTML over HTML with embedded JS.

Isn't it wonderful that we live in a world where both ways can exist together, along with a myriad of other ideas for how to do the exact same thing?

The point is that both ways contain the same "spaghetti" that the OP is complaining about and that it's unclear what alternative they actually prefer.

No.

But you can write dreadful code in any language

this comment really proves that people do not consider the information presented to them

marko is not comparable to php

it is much closer to svelte

i used to sympathize with people complaining about js-fatigue, but at some point its a skill issue

Marko is server side. How is that closer to svelte?

Svelte can also be used for SSR

How would you prefer to write those examples?

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

LLMs can make use of documentation and example code.

But because of LLMs there will be less example code

Yes. I understand second order context pollution.

You two are complaining about different things. Note how the parent mentioned PHP as the reference.

I think the grand takeaway is that people like to complain