Maybe off topic, but I’d kill for a HAML for TSX or Svelte! Working with HAML really did make building web app fun IMO. I can’t be the only one!
vue allows other languages in .vue files for both css & html similar to js
Marko – A declarative, HTML‑based language
121–130 of 189 posts
Re: Marko – A declarative, HTML‑based language
#122Earlier quoted context omitted.
I mostly agree with you but React isn’t just JavaScript. JSX is not JavaScript. It’s just that we’re so used to it we don’t consider it notable any more. Worth keeping in mind when you’re looking at a brand new framework.
Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach: var ListComponent = () => { let count = 0, selected = null return { view: ({attrs: {items}}) => m("div", [ m("p", "Clicked: " + count + " times"), m("ul", items.map(item => m("li", { onclick: () => { count++; selected = item }, style: {cursor: "pointer", color: item === selected ? "blue" : "black"} }, item) )), selected && m("p"…
fwiw I think this is worse than Marko in terms of syntax and certainly in terms of readability. For all its flaws, HTML / XML / like syntax is such a good declarative way of writing UI imo. React would not be as popular as it is today were it not for JSX. Like the other reply to your comment said: this is effectively identical to what JSX compiles to assuming your jsxPragma is `m`
Re: Marko – A declarative, HTML‑based language
#123Earlier quoted context omitted.
I mostly agree with you but React isn’t just JavaScript. JSX is not JavaScript. It’s just that we’re so used to it we don’t consider it notable any more. Worth keeping in mind when you’re looking at a brand new framework.
Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach: var ListComponent = () => { let count = 0, selected = null return { view: ({attrs: {items}}) => m("div", [ m("p", "Clicked: " + count + " times"), m("ul", items.map(item => m("li", { onclick: () => { count++; selected = item }, style: {cursor: "pointer", color: item === selected ? "blue" : "black"} }, item) )), selected && m("p"…
> Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach
Speaking of writing JS instead of JSX or your example, I like the vanjs.org approach:
const Hello = () => div(
p("Hello"),
ul(
li("World"),
li(a({href: "https://vanjs.org/"}, "VanJS")),
),
)
van.add(document.body, Hello())Re: Marko – A declarative, HTML‑based language
#124It looks interesting and in a past life I probably would have tried it out but do you know why I like React? Because it's just JavaScript. This ` ` and ` ` syntax is awful.
Do you really believe React is just javascript?
React is "just JavaScript" that you have to write in a very particular way, which the language in no way helps you enforce, for otherwise your "web app" will misbehave is bizarre and confusing ways.
Re: Marko – A declarative, HTML‑based language
#125I don't normally comment on formatting, but for a language I assume they're dog-fooding for the demo it's amusing that none of the gradient-backgrounded text renders visibly ("HTML-based", "building web apps", etc).
Re: Marko – A declarative, HTML‑based language
#126Earlier quoted context omitted.
I mostly agree with you but React isn’t just JavaScript. JSX is not JavaScript. It’s just that we’re so used to it we don’t consider it notable any more. Worth keeping in mind when you’re looking at a brand new framework.
Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach: var ListComponent = () => { let count = 0, selected = null return { view: ({attrs: {items}}) => m("div", [ m("p", "Clicked: " + count + " times"), m("ul", items.map(item => m("li", { onclick: () => { count++; selected = item }, style: {cursor: "pointer", color: item === selected ? "blue" : "black"} }, item) )), selected && m("p"…
Yes, I also like relying on just functions.
I have found aberdeenjs a better dx than hyperscript.
Re: Marko – A declarative, HTML‑based language
#127The 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.
I think I managed to combine three languages in one with Mint ( https://mint-lang.com/ ): 1. There is HTML (tags) with, but without interpolation {...} you can put string literals, variables and everything that type checks as HTML children. 2. There is CSS but only in style blocks where you can interpolate any expression you need and put in if and case expressions too. 3. There is the normal Mint code you write the l…
Your Mint language looks awesome! You’ve done a great job making it very seamless between the 3 languages. I had a couple thoughts regarding your css/styling though:
1. The one feature I prefer in Marko when compared to Mint is Marko’s nice ID and class syntax, rather than your custom selectors, so you can just use regular CSS (which seems to be advancing faster than the JS & HTML specs combined). You could get the scoping using shadow roots for your components (I’m sure this has flow on consequences, but given you own the language it’s probably better case than many others.)
2. Interpolating values directly in CSS blocks is something that a lot of HTML templating systems sort of give up on (see Astro going out of it’s way to make interpolating variables super verbose [0]), so I’m glad to see you do it. Does the value interpolation compile to CSS variables that are set on the component root (or somewhere else I suppose) as in Astro [0], or is it just simple interpolation? Additionally, I can’t help but notice your hash symbol would conflict with ID selectors, so is CSS nesting available?
Please don’t take this as criticism! I really like what you’ve done here and am very curious.
[0]: https://docs.astro.build/en/guides/styling/#css-variables
Re: Marko – A declarative, HTML‑based language
#128I love the landing page for this project. It's very engaging.
Re: Marko – A declarative, HTML‑based language
#129Earlier quoted context omitted.
I mean, you’re technically correct. But you’re also not understanding the point. What people mean when they say “React is just JavaScript” is… 1) JSX, more than any other templating system, is just HTML interleaved with JavaScript. It’s HTML, and anything between { and } is evaluated as JavaScript. 2) Inserting a React component’s “HTML tag” in your JSX is _actually_ the same as calling the JavaScript function. The H…
I don't think the syntactic sugar works how you describe. JSX components actually desugar to something like: {jsx(MyComponent, { attr: "yes" }) (Previously this function was called "React.createElement", but these days they have special functions that only the JSX compiler is allowed to use.) The extra layer of indirection is needed to do things like support hooks being called inside of MyComponent's function body, k…
I don't think that's true, you can write uncompiled createElement calls and everything still works fine.
Re: Marko – A declarative, HTML‑based language
#130This sort of stuff is just a big nope: Why make a special language? Just use HTML and TypeScript that will be compatible with editors, tooling, etc. This is the same mistake Imba made. It's a shame because the core of Marko looks phenomenal: streaming, fine-grained bundling, rendering performance, etc. Also not sure about the file-based routing of Marko Run. That was a big reason why I abandoned SvelteKit.
Let’s not pretend that useState() is plain TypeScript either. It’s a DSL in disguise.
JSX is amazing for stateless rendering of templates. Not so much for state management. That should really have been given a dedicated DSL. Here I think Marko did the right thing, why they then made even for-loops a dsl is more questionable.