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

81–86 of 86 posts

Re: Maud: A Rust macro for writing HTML

#81

Post by the_gipsy »

lucideer wrote: post #79
the_gipsy wrote: post #78

Earlier quoted context omitted.

I stand corrected about JSX attribute renaming! However I still see it being applied in practice for 99% of JSX use cases. The problem with "only expressions in brackets" is that then you can write code in the template, but it's massively different to regular code. Worst of both worlds: code in templates and weird subset of code.

> you can write code in the template If this is undesirable as a feature, then yes, JSX is not an appropriate choice. JSX is the furthest thing from logic-less templating. But that's a deliberate design decision. > it's massively different to regular code It's not. It's just regular code - there are no differences. > weird subset of code It's not weird. It's any JS expression. All JSX brackets are values, and JS stat…

> It's not. It's just regular code - there are no differences.

> All statements in JS can be expressed as expressions directly (ternary/array methods) or indirectly (nested within a function expression), so there's no loss of functionality - it's not even really a subset in that sense.

Do you not see the contradiction?

Re: Maud: A Rust macro for writing HTML

#82

Post by tialaramex »

pornel wrote: post #47
tialaramex wrote: post #38

Earlier quoted context omitted.

println! is only a declarative macro, whereas Maud is a proc macro. The declarative macros aren't too head-twisting for tools, they just expand as declared, this can sometimes have a few surprising effects but generally it is very manageable. Procedural macros have essentially unlimited power and thus are sometimes entirely impossible to analyse.

println! depends on a proc macro: https://doc.rust-lang.org/stable/src/core/macros/mod.rs.html...

I see a built-in there. Are you really seeing a proc macro?

Re: Maud: A Rust macro for writing HTML

#83

Post by lucideer »

the_gipsy wrote: post #81
lucideer wrote: post #79

Earlier quoted context omitted.

> you can write code in the template If this is undesirable as a feature, then yes, JSX is not an appropriate choice. JSX is the furthest thing from logic-less templating. But that's a deliberate design decision. > it's massively different to regular code It's not. It's just regular code - there are no differences. > weird subset of code It's not weird. It's any JS expression. All JSX brackets are values, and JS stat…

> It's not. It's just regular code - there are no differences. > All statements in JS can be expressed as expressions directly (ternary/array methods) or indirectly (nested within a function expression), so there's no loss of functionality - it's not even really a subset in that sense. Do you not see the contradiction?

Let me phrase it in a slightly different way:

Vanilla javascript assignments can be any expression.

JSX assignments (the brackets) can be any expression.

There's no weirdness nor extra limitations to JSX assignments compared to normal vanilla JS. It works exactly the same.

If you think not being able to assign JS blocks is weird you're going to have to explain to me what this piece of JS code would do:

  const val = if (x

Re: Maud: A Rust macro for writing HTML

#84

Post by dochtman »

zaarn wrote: post #26
dochtman wrote: post #24

Earlier quoted context omitted.

> Sadly, there isn't any great alternative for making performant HTML templates in Rust from what I've seen, a lot of the other HTML templating libs aren't that great comparatively. Which others have you tried, and why do you think they're not great?

I've tried handlebars and liquid. They're okayish, but both slow and don't have any compiletime help or typing when I tried them. Horroshow, ructe, typed-html and yarte were okay but inheritance was underdocumented (or generally not as well documented), which is a big no for me. And a few only give minor-quality help at compile time. Maud on the other hand has decent compiletime help and doesn't require a lot of docu…

I created Askama (which yarte forked), the inheritance docs aren't great but also not too bad. Curious why you didn't try it?

Re: Maud: A Rust macro for writing HTML

#85

Post by zaarn »

dochtman wrote: post #84
zaarn wrote: post #26

Earlier quoted context omitted.

I've tried handlebars and liquid. They're okayish, but both slow and don't have any compiletime help or typing when I tried them. Horroshow, ructe, typed-html and yarte were okay but inheritance was underdocumented (or generally not as well documented), which is a big no for me. And a few only give minor-quality help at compile time. Maud on the other hand has decent compiletime help and doesn't require a lot of docu…

I created Askama (which yarte forked), the inheritance docs aren't great but also not too bad. Curious why you didn't try it?

I haven't found askama yet, or rather, discovered it through HN here, I don't check the arewewebyet.org site too often and it's my main source of frameworks to find.

My main worry on things is that I'd rather like being able to express the inheritance in the type system through generics. Ie, having a top level "Page" struct in which I can start putting the various subparts needed to render a page. It seems askama is doing it the other way round with a "parent" member needed in the child page.

Re: Maud: A Rust macro for writing HTML

#86

Post by the_gipsy »

lucideer wrote: post #83
the_gipsy wrote: post #81

Earlier quoted context omitted.

> It's not. It's just regular code - there are no differences. > All statements in JS can be expressed as expressions directly (ternary/array methods) or indirectly (nested within a function expression), so there's no loss of functionality - it's not even really a subset in that sense. Do you not see the contradiction?

Let me phrase it in a slightly different way: Vanilla javascript assignments can be any expression. JSX assignments (the brackets) can be any expression. There's no weirdness nor extra limitations to JSX assignments compared to normal vanilla JS. It works exactly the same. If you think not being able to assign JS blocks is weird you're going to have to explain to me what this piece of JS code would do: const val = if…

You're just stating the difference between a statement and an expression. FYI, other languages (e.g. rust) have embraced the "everything is an expression" and it works extremely well, where JSX wouldn't be so awkward (in this aspect) and we could write something like:

    {if (list?.length > 0) {
      list.map(e => {
        if (e.items.length) {
          Excellent!
        } else {
          Not good.
        }
      });
    } else {
      Nothin to see.
    }}
Now, if you want to write this in actual JSX, you have to do this:

    {(!!list && list.length) // awkward way of writing code
      ? list.map(e => {
          if (e.items?.length) { // normal way of writing code
            return Excellent!;
          } else {
            return Not good.;
          }
        })
      : Nothin to see.
    }
Do you see the contradiction of being forced to use only expressions, only in some places? And this happens all the time. The most frequent thing we do in UI is rendering lists, so we use `.map` with "regular" code constantly, mixed with the awkward "expressions only" areas. Sure, the reason is that JavaScript is like that, but that doesn't make JSX any better.
Post reply on HN