Live data from Hacker News

Maud: A Rust macro for writing HTML

maud.lambda.xyz

61–70 of 86 posts

Re: Maud: A Rust macro for writing HTML

#61

People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenly for MSFT implementing it into TS as a first-class citizen. It's just so much more readable. Scala is the only other language I know of which has some kind of XML/HTML syntax support (scala.xml). (But it looks like it got removed. [2]) [1] https://reactjs.org…

I was there when E4X was introduced, about 20 years ago. It lasted about 5 whole years before people started to think it was old and crufty.

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...

Re: Maud: A Rust macro for writing HTML

#62
post #54

Earlier quoted context omitted.

> Isn't JSX essentially syntax sugar for function calls Yes. Which makes any issues the gp mentioned entirely up to the implementation of that function call. > seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue If by "could apply", you mean anyone could write a function that has those issues, then yes I guess. My point was that if you want to avoid those, they'r…

I think I don't agree: I think the possibility of mixing rendering and logic is inherent to JSX. While users of the syntax can probably (deliberately) avoid mixing rendering and logic too much, there's no implementation of JSX that can prevent its users from mixing the logic and the rendering if they want to do so: it will always be possible for a user to mix the JSX tags with arbitrary Javascript because the full JS…

I guess I’m not sure what you want though. If you want to render things dynamically, that dynamism has to live somewhere. And wherever that is, it’s possible to abuse. For example, what does “fill in the data” really mean? For a non-trivial app it has to mean the ability to generate fresh markup from your data, and that process can mix concerns.

Re: Maud: A Rust macro for writing HTML

#63
post #54

Earlier quoted context omitted.

> Isn't JSX essentially syntax sugar for function calls Yes. Which makes any issues the gp mentioned entirely up to the implementation of that function call. > seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue If by "could apply", you mean anyone could write a function that has those issues, then yes I guess. My point was that if you want to avoid those, they'r…

I think I don't agree: I think the possibility of mixing rendering and logic is inherent to JSX. While users of the syntax can probably (deliberately) avoid mixing rendering and logic too much, there's no implementation of JSX that can prevent its users from mixing the logic and the rendering if they want to do so: it will always be possible for a user to mix the JSX tags with arbitrary Javascript because the full JS…

> there's no implementation of JSX that can prevent its users from mixing the logic and the rendering if they want to do so: it will always be possible for a user to mix the JSX tags with arbitrary Javascript because the full JS language is available in JSX tags and JSX tags can be used in Javascript code.

That's fair. If that's what you're looking for, then JSX is not the answer. I don't think we disagree though - I was merely pointing out separation is possible (even if not strictly enforced).

Personally, I am a fan of the component-driven model (criticised above for "blurring the lines"). As I mentioned, it's a trade-off, and I think any potential "blurriness" is far outweighed by the context and reduced abstraction wins from a code-readability & codebase approachability perspective. Heavily separated templating efforts often leads to codebases with deeply nested hierarchies for views -vs- controller logic that require having 4+ split pane editors open just to understand extremely local snippets of data flow. This is particularly egregious when e.g. trying to audit codebases for injection mitigation.

Re: Maud: A Rust macro for writing HTML

#64
post #8

Earlier quoted context omitted.

Totally agree, macros are the worst Rust feature for me, they are way too powerful and break the tooling, e.g. fmt or language server. https://rust-analyzer.github.io/blog/2021/11/21/ides-and-mac...

It ultimately depends on how they're written. println! is a macro, and doesn't "break the tooling". on the other end of the spectrum, using a crate like demonstrate (unit testing) produces hard to understand errors and slows down the IDE. I don't remember experiencing Rust Analyzer crashes for a long time, though (I do remember some in the past).

> println! is a macro, and doesn't "break the tooling"

I like, use, and write macros, but this isn't fully true. For example, recent Rust versions allow writing identifiers directly in the format string:

    println!("{some_identifier}")
However, this breaks rust-analyzer's ability to rename variables [1].

[1]: https://github.com/rust-lang/rust-analyzer/issues/11260#

Re: Maud: A Rust macro for writing HTML

#65

People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenly for MSFT implementing it into TS as a first-class citizen. It's just so much more readable. Scala is the only other language I know of which has some kind of XML/HTML syntax support (scala.xml). (But it looks like it got removed. [2]) [1] https://reactjs.org…

To me JSX is the opposite of what Maud (Kotlinx.html, Elm's HTML lib, Haskell's type-of-html) does. In Maud you write "just code", and "as code". In traditional template engines you have a big string with holes, if-elses and loops. In JSX you write templates as if it is a traditional templating engine, but under the hood it gets translated to JS-code.

Somehow JSX seems to be "worst of both worlds" to me.

Some of these HTML-templates-as-code libs (like Kotlinx.html) are generated from a formal HTML specification. This is really nice, and makes it more type safe (only allow tag nesting that is allowed, and only allow attributes that are allowed; ofcourse with escape hatches).

Re: Maud: A Rust macro for writing HTML

#66

People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenly for MSFT implementing it into TS as a first-class citizen. It's just so much more readable. Scala is the only other language I know of which has some kind of XML/HTML syntax support (scala.xml). (But it looks like it got removed. [2]) [1] https://reactjs.org…

Related library in Rust: https://docs.rs/typed-html/latest/typed_html/

Re: Maud: A Rust macro for writing HTML

#68

People like to hate everything related to JS these days. But when I see libs like these I'm just very grateful for the person(s) who invented JSX [1]. And evenly for MSFT implementing it into TS as a first-class citizen. It's just so much more readable. Scala is the only other language I know of which has some kind of XML/HTML syntax support (scala.xml). (But it looks like it got removed. [2]) [1] https://reactjs.org…

> Scala is the only other language I know of which has some kind of XML/HTML syntax support

Visual Basic .NET has XML literal support [1].

[1]: https://docs.microsoft.com/en-us/dotnet/visual-basic/program...

Re: Maud: A Rust macro for writing HTML

#69
post #19

Earlier quoted context omitted.

I think it isn't the consensus anymore because there isn't actually a "correct" solution. It's too subject to personal preference. For example, I prefer having HTML + CSS + JS all in the same file because then I know everything relevant to the component or page I'm working on is right there. I do concede that it can get extremely unwieldy if you don't separate out components though.

There is a correct solution (the one you're not doing)

Sure, just like there's a correct IDE.

Re: Maud: A Rust macro for writing HTML

#70

The given example seems harder to write than the correspondig html. What's the point, then? All these opening and closing quotes are pointless. Why don't write a single string with the verbatim html inside?

Because you can do things like have a loop that generates list items, for example?
Post reply on HN