Hacker News Reader

Comment by causal | Hacker News Reader

I always feel like these HTMX examples just shift complexity to other parts of the stack. JSX is a really elegant way to avoid templating, but we're back to templating with HTMX, and you can easily reintroduce a complex set of libraries just trying to handle that with any scale.

Routing, state management, auth, components, theming, API access, and more are all still problems that people add libraries for and those problems don't go away just because you've abandoned the ecosystem with the most libraries.

View on HN

I feel like a lot of the arguments for HTMX are simply delight in having "permission" to build MPAs again. Backend stacks are historically good at routing/state management/auth and more, everything old is new again. But also, yes, not everything needs to be a SPA and maybe we've just reached the point to start asking again "why is this a SPA?"

> JSX is a really elegant way to avoid templating

JSX is still a templating language. It's just an "inverted one" where the templates are embedded in scripts rather than the other way around. That said, I do think it is a very elegant templating system, especially because it can be type checked with Typescript. TSX is a massive improvement on most template compilers in part because it has such a massive types ecosystem today.

(My own efforts in "post-React"/"post-Angular" have been TSX-based. I've got a Knockout-inspired view engine with a single runtime dependency on RxJS. It has a developer experience similar to React, but isn't a virtual DOM, and has some some interesting tricks up its sleeve. I'm really happy with TSX as the template language for it.)

Agreed. I also think React did the world a favor by making functional programming a little more mainstream, which is part of what makes JSX/TSX feel so magical when it works.

> JSX is still a templating language

No, it isn't a templating language, it's still just JavaScript - calls to createElement or _jsx or other function with some syntactic sugar to make it look like HTML.

> with some syntactic sugar

isn't that what a templating language is?

No. Do you seriously don't understand the difference between JSX, a simple syntax extension that compiles to JavaScript function calls, and a templating language, for example Vue's templating syntax [1] or EJS [2] ?

[1] https://vuejs.org/guide/essentials/template-syntax [2] https://ejs.co/

Rather than acting like OP is stupid for not seeing the difference, why don't you enlighten us?

From where I'm sitting it looks like maybe you're describing a difference in complexity levels? Vue compiles to a representation that is less obviously related to the template? Or what?

I, like OP, am genuinely unsure what distinction you're drawing. It seems like you might just feel that templates are icky and jsx isn't icky.

It's trivial. JSX is just syntactic sugar for JavaScript, and templating languages aren't that. They also aren't just syntactic sugar. It's literally apples and oranges. I ask again, what is difficult to understand about this? Or do you think it's not true?

You may have stricter internal boundaries of what constitutes a "language" than many of us do. Languages are a spectrum and I find there are few hard boundaries in practice. Depending on how you define "syntactic sugar" (and I believe it is a much harder thing to define than you may expect) every language is just "syntactic sugar" for some form of machine code.

JSX is a language that takes XML-influenced templates embedded in JS files and compiles that to JS files. EJS is a template language that can embed JS snippets and compiles that to JS files (or interprets it at runtime, though the distinction between compilers and interpreters I think is largely irrelevant here). They both have the same general target compiled language, and they both have similar transformations from an original document to a new process. The biggest difference I mentioned is an "inversion" of what people think of as a template language (the template being the "focus" and scripting it being secondary/embedded), but I don't think that disqualifies it as a template language.

Subjective feelings of "syntax sugar" or not, JSX is a language intended to write templates in. That's a "template language" by tautology, if not also by definition.

No, JSX is syntactic sugar and nothing more, it requires no context, you can "transpile" it from memory. In my code I sometimes explicitly use React.createElement calls, when using JSX is not that useful, because it's always just writing JavaScript, not writing templates; it's just code. Template languages also add different semantics, e.g. those EJS <% or <%_ tags - you can't express them in some equivalent JavaScript code (don't confuse it with compiling the template to some code, that's something completely different).

If JSX was exactly the same feature-wise, but was part of the core JS spec, would JS+JSX suddenly become a "templating language" then?

Agreed. When you just need a tiny bit of interactivity I can see the value in htmx. However, leveraging html as a dsl is bound to be limiting

here's an example of a fairly interactive site that switched to htmx with significant savings:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

htmx triggers and responds to events, which can be used to integrate it into more interactive experiences, e.g.

https://htmx.org/examples/sortable/

You do collapse an implementation layer by using HATEOAS[1], which can save overall complexity in the system:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

It's mainly an interactivity/simplicity tradeoff, sometimes the right trade other times not. A lot of people are using JSX on the server side w/htmx because it's a good and familiar templating option on the server side.

[1] - https://htmx.org/essays/hateoas/

Wait did I just get a response from Carson himself? :)

Though my comment belies it I'm a big fan of the work - I started following Intercooler a decade ago and I'm happy to see how far things have come.

I'm curious about HTMX + JSX, any recommended examples there?

:) hono has a demo using it:

https://hono.dev/examples/htmx

> JSX is a really elegant way to avoid templating, but we're back to templating with HTMX

Not necessarily. There are libraries in all mainstream languages that let you embed HTML generation directly in your backend server itself, without using a templating engine. Some examples:

Python: https://htpy.dev/

Scala: https://com-lihaoyi.github.io/scalatags/

OCaml: https://yawaramin.github.io/dream-html/ (that's mine)

> Routing, state management, auth, components, theming, API access, and more are all still problems that people add libraries for and those problems don't go away

Actually they kinda do go away. Have you ever tried Ruby on Rails? It does all this out of the box.

> Routing, state management, auth, components, theming, API access, and more are all still problems that people add libraries for

A lot of this goes away if you choose a server-side framework that handles its own routing, auth, api, templates etc. And the state management also goes away if you don't need complex stateful widgets on the frontend.

> And the state management also goes away if you don't need complex stateful widgets on the frontend.

Browsers come with a very limited selection of widgets, almost everything I make requires at least one custom widget, usually significantly more than one. How can you possibly know when you start a project that you won't need to make any complex stateful widgets?

If they really are that complex, then use react for them. One of the biggest issues I have always had with react proponents is the "well if I need react for X then I might as well build the whole thing in react."

Islands Architecture is really not complicated. The bulk of your app can be very simple hypermedia exchanges and components and when you need a really fancy widget, load it and mount it where it needs to be.

You can build a complex stateful widget in a MPA.

I don't even know what problem this author has with React and how switching to HTMX is going to help them (after reading the article twice).

> Some of the worst offenders in this respect were wouter (a React router package) and TanStackQuery (which I was using to fetch, cache and manage state from the backend).

Ok so don't use wouter and TanStackQuery...?

For the past 4 years, most objections to HTMX have come in the form of your comment. A look from afar, trying to speculate on what development must be like.

After 4 years of mature devs taking it for a spin and reporting back with a thumb up, maybe it's best to try to actually use it in a project of your own and see how close your predictions match reality.

Perhaps you even have experience with it of course. In which case, it'd be interesting/useful to voice your objections more specifically.

But for those problems there are decades old frameworks like django and Ruby on rails, laravel etc that solve these issues in a simpler way

Reply on news.ycombinator.com