Similar thing in Go: https://github.com/theplant/htmlgo
Maud: A Rust macro for writing HTML
41–50 of 86 posts
Re: Maud: A Rust macro for writing HTML
#42People 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 don't hate js, I hate bloat, unnecessary dependencies, and unnecessary build tools. All I want to do to be able to use a html view lib is `import`.
Re: Maud: A Rust macro for writing HTML
#43Earlier quoted context omitted.
I get that, but Maud is not the first of its kind and the absence of similar engines in web development is a telltale sign it's not the optimal approach.
Well, as mentioned, I've yet to find something that can replace Maud without sacrificing it's advantages (in-code inheritance, code-sharing and compile-time type-safety). So even if it's not the "optimal approach" as you title it, it's the ergonomic approach for me because it doesn't get in my way.
For these requirements, it's indeed a good choice. It's just not a use case I've seen often.
Re: Maud: A Rust macro for writing HTML
#44Earlier quoted context omitted.
One of the huge advantages of Maud is that it keeps code and markup close together, so you can do things like having rust control structures determine what markup is used later on (for snippets or widgets, for example). Plus, Maud has a definitive speed advantage from what I've noticed. 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 t…
Askama should be comparable in speed and type safety? It probably doesn't integrate any better inline with source though (I've only used it with standalone template files). https://djc.github.io/askama/creating_templates.html#the-tem... Regardless, it's good to see some variety and experimentation like Maud in software design
Askama looks interesting, though the inheritance is a bit underdocumented.
Ideally, I'd imagine just making a "Global" struct, where I insert the current page context like so "Global" to get the final template. Though by the looks, it sounds more like LoginPage will simply have to have all the global context available via some attribute like "LoginPage.global".
Re: Maud: A Rust macro for writing HTML
#45Earlier quoted context omitted.
I don't think JSX is very readable. If you squint it may look like HTML, but when you try to actually read it, it's all off. Different attributes, bizarre templating, blurred line between rendering and code. The latter in practice is always a complex mix of view/state/ callbacks with react.
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 Velocity, or Jinja) (for me JSX is not a template syntax at all).
I think template languages are also prone to rendering / logic mix, I don't know what is an elegant solution to this problem apart from getting used to this reality. Maybe something like QML, using data models, instead of having a for loop to render lists for instance.
Re: Maud: A Rust macro for writing HTML
#46Similar thing in Go: https://github.com/theplant/htmlgo
The difference is that maud does most of the work compile-time, so `html! { div { "foo" } }` compiles into literal "foo" hardcoded in the program, without allocating intermediate HTMLTagBuilder objects.
Re: Maud: A Rust macro for writing HTML
#47Earlier quoted context omitted.
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 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...
Re: Maud: A Rust macro for writing HTML
#48Similar thing in Go: https://github.com/theplant/htmlgo
The difference is that maud does most of the work compile-time, so `html! { div { "foo" } }` compiles into literal " foo " hardcoded in the program, without allocating intermediate HTMLTagBuilder objects.
Another difference is htmlgo is just plain Go, no macros. So it plays nice with IDEs and other tooling.
Re: Maud: A Rust macro for writing HTML
#49Earlier 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…
> 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're in no way inherent to JSX. Is that what you meant?
I mean, I guess "blurred line between rendering and code" is less about the function implementation, and more about project / file organisation choices (including conventions of a frontend view framework community), but it's still certainly not inherent.
> I think template languages are also prone to rendering / logic mix
True. I think you do need a lot of discipline if you want to keep a clear and consistent separation, and it's also not always worthwhile (there's a codebase-approachability trade-off with abstraction & locality of context).
For arguments' sake though here is a quick-and-horribly-dirty example of JSX syntax separation (not recommended but demonstrative): https://codepen.io/lucideer/pen/jOZvwVz?editors=0010
Re: Maud: A Rust macro for writing HTML
#50People 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…
HTML Jinja templates are supported in many editors. Jinja + plain Python is my favorite way of building static web pages.