Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maud: A Rust macro for writing HTML

maud.lambda.xyz

Post reply on HN
Print view View original

51–60 of 86 posts

Re: Maud: A Rust macro for writing HTML

#51

Post by nicoburns »

dgb23 wrote: post #37
capableweb wrote: post #28

Earlier quoted context omitted.

After you get a taste of the free world of hiccup/reagent where it's just vectors and maps to create HTML, its really hard to imagine going back to anything else. Being able to use the same programming language in your "HTML template" (which are just core data structures in a specific shape) as for the rest of your programming is just icing on the top. Small example for people to understand the difference: // HTML &…

I think the big differences don’t come out visually. In JSX you might be struggling with expressing certain things, because JS has a statement expression syntax. So you have to circumvent that. In Clojure everything is an expression already. In JSX you can manipulate components with HoCs. In Clojure it’s just data, no special ceremony needed. On the client, if you’re using React, you might use hooks to keep travk of…

Hopefully the limitations around expressions in JS will go away at some point and JS will become properly expression orientated. There are already proposals for this, although they currently seem to be stalled.

Re: Maud: A Rust macro for writing HTML

#52

Post by deepstack »

jraph wrote: post #45
lucideer wrote: post #40

Earlier quoted context omitted.

You're confusing JSX and the React target for JSX; only the latter has the problems you mention. This is a very common confusion because most people approach JSX via React, and as such never really grasp that JSX is a separate, independent thing. If you're interested in learning it standalone, I'd highly recommend working with either the Typescript `jsxFactory` compiler option, or the `@babel/plugin-transform-react-j…

Isn't JSX essentially syntax sugar for function calls (to a specific "create element" function), and therefore bound to code/rendering mix regardless of React? I see JSX syntax as fancy JS expressions. It seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue. The "opposite" approach being using a template language like the one in Svelte or Angular… or like PHP (or…

Hmm, I think a long time ago (around 2005 or 2006) JSX was briefly considered to be party of ES standard. It didn't make it, and shortly after FB introduced React.

Think it may have being easier if JSX is just included in ES as a standard. So yes and no, JSX introduced by FB via react is a just a syntax sugar, however the original JSX is a meant to be a ES standard, with each node as a tree structure.

https://www.ecma-international.org/publications-and-standard...

Re: Maud: A Rust macro for writing HTML

#53

Post by lucideer »

deepstack wrote: post #52
jraph wrote: post #45

Earlier quoted context omitted.

Isn't JSX essentially syntax sugar for function calls (to a specific "create element" function), and therefore bound to code/rendering mix regardless of React? I see JSX syntax as fancy JS expressions. It seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue. The "opposite" approach being using a template language like the one in Svelte or Angular… or like PHP (or…

Hmm, I think a long time ago (around 2005 or 2006) JSX was briefly considered to be party of ES standard. It didn't make it, and shortly after FB introduced React. Think it may have being easier if JSX is just included in ES as a standard. So yes and no, JSX introduced by FB via react is a just a syntax sugar, however the original JSX is a meant to be a ES standard, with each node as a tree structure. https://www.ecm…

You're describing E4X. E4X and JSX are both XML-inspired syntaxes, but beyond that have relatively little in common in how they function.

E4X was supported by Firefox for a while, but I think support was removed.

Re: Maud: A Rust macro for writing HTML

#54

Post by jraph »

lucideer wrote: post #49
jraph wrote: post #45

Earlier quoted context omitted.

Isn't JSX essentially syntax sugar for function calls (to a specific "create element" function), and therefore bound to code/rendering mix regardless of React? I see JSX syntax as fancy JS expressions. It seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue. The "opposite" approach being using a template language like the one in Svelte or Angular… or like PHP (or…

> 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 language is available in JSX tags and JSX tags can be used in Javascript code.

In contrast with HTML, where there is no way one can mix the logic and the UI because it is syntactically impossible. You have to get the DOM element from a script and to fill it data (well, actually, you can with the script tag and on* attributes, but let's consider HTML without them, only allowing script tags in for instance so our restricted version of HTML remains useful).

I think you need the rendering to be data, not code, to "forbid" this mix (and soon enough, you reinvent some kind of lisp I guess)

Re: Maud: A Rust macro for writing HTML

#55

Post by jraph »

deepstack wrote: post #52
jraph wrote: post #45

Earlier quoted context omitted.

Isn't JSX essentially syntax sugar for function calls (to a specific "create element" function), and therefore bound to code/rendering mix regardless of React? I see JSX syntax as fancy JS expressions. It seems like everything the parent said could apply to any use of JSX, except for the attribute naming issue. The "opposite" approach being using a template language like the one in Svelte or Angular… or like PHP (or…

Hmm, I think a long time ago (around 2005 or 2006) JSX was briefly considered to be party of ES standard. It didn't make it, and shortly after FB introduced React. Think it may have being easier if JSX is just included in ES as a standard. So yes and no, JSX introduced by FB via react is a just a syntax sugar, however the original JSX is a meant to be a ES standard, with each node as a tree structure. https://www.ecm…

The way I see it, syntax sugar can be part of the language proper.

For instance classes in JS are sugar syntax to define a function that defines fields in this and prototype members of this function.

Arrow functions are sugar syntax to define functions bound to a specific this.

async / await is sugar syntax for promises.

for..of is sugar syntax for iterating over an iterable.

Re: Maud: A Rust macro for writing HTML

#56

Post by rtpg »

Grimburger wrote: post #9

Maud is wonderful for small things like a stats page or dashboard. But once you start getting to a few pages it's so much less cognitive overhead to separate concerns out into proper html files/templating. It seems quite daunting to have a large project where all your html is inside rust files and a lot harder to find people who can work on it proficiently.

I do, in theory, understand separation of concerns.

But as someone who works on a sprawling set of template files with loads of sprinkled conditionals in a template language... the idea of using a "real language" for the templating, and in particular having type checking and proper abstraction tools (you can just write functions! No weird template tag tricks) is so much nicer to me.

HTML templates have always felt super brittle to me, basically at the level of C preprocessor programming. Even just with React/TS you can get away with so much with way more confidence given the typed backing.

Though I think that you _could_ get away with some nice tricks in Rust thanks to macros, where you ingest the template files and generate render functions with all the properties... or something like that.

Re: Maud: A Rust macro for writing HTML

#57

Post by My71staccount »

kamilafsar wrote: post #20

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…

No post body was provided.

Re: Maud: A Rust macro for writing HTML

#58

Post by pavpanchekha »

My71staccount wrote: post #57
kamilafsar wrote: post #20

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…

Quoted post unavailable.

Low-effort comments like these are not accepted on HN. Please only comment if you have something substantive to add to the conversation.

Re: Maud: A Rust macro for writing HTML

#59

Post by My71staccount »

vonadz wrote: post #19
Inviz wrote: post #15

Earlier quoted context omitted.

I wish it was still the consensus among JS devs. People are putting css into JS files, on top of html

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)

Re: Maud: A Rust macro for writing HTML

#60

Post by My71staccount »

pavpanchekha wrote: post #58
My71staccount wrote: post #57

Earlier quoted context omitted.

Quoted post unavailable.

Low-effort comments like these are not accepted on HN. Please only comment if you have something substantive to add to the conversation.

No post body was provided.
Post reply on HN