Earlier quoted context omitted.
Don't blame Marko for this type of abomination. This is basically fancy react JSX. ITS just bizzare people want to parse JavaScript at the same instance they're parsing html. Also, LLMs are going to destroy any new framework. Someone's gonna need to figure out how to integrate these things into new tools. LLMs suck but it'll be much worse if they freeze innovations cause they're too expensive to chase the new hotness…
LLMs can make use of documentation and example code.
Marko – A declarative, HTML‑based language
21–30 of 189 posts
Re: Marko – A declarative, HTML‑based language
#22The problem when taking several languages and mixing them together this way is that the result is supposed to have brevity, but it’s actually unreadable. You need slash to mean something grammatical, colon has to say something, you can speak “open brace” in a way that anticipates; @ means “at”. This code looks more like a compression scheme.
Re: Marko – A declarative, HTML‑based language
#23Today is ${new Date().toDateString()} Random number: ${Math.floor(Math.random() * 100)} Sorry, I don't like it. I already disliked that immensely in PHP. Not going back to that spaghetti mesh-up. The intro is also incorrect in my opinion. It writes a "HTML-based language", but this is more a hybrid of HTML and JavaScript. Why is JavaScript not mentioned in the intro?
element.innerHTML=`
Today is ${new Date().toDateString()}
Random number: ${Math.floor(Math.random() * 100)}
`
(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.
Re: Marko – A declarative, HTML‑based language
#24This is actually quite cool - JS inside HTML, rather than the more React-y HTML inside JS. As I understand it, Ryan Carniato was a major part of this project, and later went on to lead SolidJS, which goes back to the React style HTML in JS. Has he spoken at all about why he went back to that templating style?
• JSX is well understood by a lot of developers • support is already built in to text editors • it is understood by typescript
Re: Marko – A declarative, HTML‑based language
#25Earlier quoted context omitted.
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…
Re: Marko – A declarative, HTML‑based language
#26Today is ${new Date().toDateString()} Random number: ${Math.floor(Math.random() * 100)} Sorry, I don't like it. I already disliked that immensely in PHP. Not going back to that spaghetti mesh-up. The intro is also incorrect in my opinion. It writes a "HTML-based language", but this is more a hybrid of HTML and JavaScript. Why is JavaScript not mentioned in the intro?
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
Re: Marko – A declarative, HTML‑based language
#27Earlier quoted context omitted.
Don't blame Marko for this type of abomination. This is basically fancy react JSX. ITS just bizzare people want to parse JavaScript at the same instance they're parsing html. Also, LLMs are going to destroy any new framework. Someone's gonna need to figure out how to integrate these things into new tools. LLMs suck but it'll be much worse if they freeze innovations cause they're too expensive to chase the new hotness…
LLMs can make use of documentation and example code.
Re: Marko – A declarative, HTML‑based language
#28Earlier quoted context omitted.
Don't blame Marko for this type of abomination. This is basically fancy react JSX. ITS just bizzare people want to parse JavaScript at the same instance they're parsing html. Also, LLMs are going to destroy any new framework. Someone's gonna need to figure out how to integrate these things into new tools. LLMs suck but it'll be much worse if they freeze innovations cause they're too expensive to chase the new hotness…
You two are complaining about different things. Note how the parent mentioned PHP as the reference.
Re: Marko – A declarative, HTML‑based language
#29Earlier quoted context omitted.
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.
Either solution sounds more verbose than the example and require writing code in at least one other source file
This snippet works with any framework and any build step.
Today is
Random number:
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).Re: Marko – A declarative, HTML‑based language
#30The problem when taking several languages and mixing them together this way is that the result is supposed to have brevity, but it’s actually unreadable. You need slash to mean something grammatical, colon has to say something, you can speak “open brace” in a way that anticipates; @ means “at”. This code looks more like a compression scheme.
Edit: typo