`plone.htmx` embryo

Announcements
1

Have you looked at HTMX ? It was the focus of a JetBrain web seminar organized by Paul Everitt.

HTMX shares so many principles with KSS that I had to try. (Plone OG will understand.)

For what I have seen until now, it is much better than KSS.

I have started to build plone.htmx as a foundation for my trial. See GitHub - plone/plone.htmx: HTMX support

Lemme know if code like below makes any sense.

<h1 class="htmx title">
<span tal:content="context/Title">title</span>
<button hx-get="replace_button" 
        hx-target="h1.htmx.title"
        hx-swap="outerHTML">Edit title</button>
</h1>

FTR, a click on the button triggers a HTTP GET request to the server (at replace_button).
The HTML fragment returned is swapped in place of h1.htmx.title outer HTML.

I am happy to answer questions if needed and to get help from others that want to avoid JS when writing UIs.

7 Likes
2

It was the focus of a JetBrain web seminar organized by Paul Everitt.

I have only a cursory knowledge of React and HTMX. For those who have a deeper and broader experience with both, how do they compare? That is, aside from the obvious syntax simplicity of HTMX.

For example, are there things that you can do in one and not the other? Or do more easily?

3

Building a React app means taking a lot in whereas HTMX (and KSS before it) let you add dynamic functionality in specific places without having to sell your soul :grinning_face_with_smiling_eyes:

4

I do not have deep experience nor with React, nor with HTMX. OTOH I have deep enough experience with JS to regret that our industry has gone down the road to make it the seemingly only choice to build nice UX.

This is why I have explored and enjoyed Elm. I do believe it is a great language but a too big leap for most programmers.

HTMX principles do resonate with me. Can HTML extensions be enough to build nice UX ? And in this way, guarantee that programmers can build on good foundations, the language(s) they already know ?

I really want to test this.

5

All I have to say is... yes please!!! (just recovering from fighting with React to render a list of members, took me a morning to write the restapi endpoint and then a few days to acclimatise to React and get comfortable with the action, reducer, dispatch, useSelector, keys for array items dance :woozy_face:). Finally got my endpoint working with Volto (I'm sure it will be faster the next time).

That HTMX snippet is much easier to read and think about for me.
Is this strictly Plone classic?
Do you have visions of somehow integrating with Volto?

In the meantime...
/me goes back to implementing my custom Volto frontend.

6

There's no escaping JS when developing for the web, one way or another. As far as I'm concerned, modern JS is quite nice. There are quirks, for sure, (bool([]) being true, for example), but for the regular things it's just fine. There is a learning curve... React, Redux, hooks, the new JS operators, etc. But Plone developers learn React extremely fast, I've seen this already with my colleagues, several times already. I mean, good programmers are good in any language and framework, but React is quite easy to learn, is well documented and has loads of built-in "rails" to keep beginners from making too much of a mess.

Let me point out that the Jquery equivalent of that htmx code is a oneliner and even automatically provided with things like Patterns, with a similar syntax. Once you try to model complex things, like the equivalent of the ObjectListWidget I'd expect that you quickly get bogged down into a mess of z3c.form, server-side schemas and widgets and so on. And to model individual fragments of a page, as server side pagelets? How do you coordinate state between them? So it will quickly become an "all or nothing" server-side replacement of an entire form "fragment". This thing has potential, but it would take a lot of work to reach the current state of Plone Classic interactivity in forms.

1 Like
7

I appreciate the wisdom in this quote. Nevertheless, I am all for technologies like Python that let you approach the complexity step by step instead of forcing you to swallow it all in a single bite.

In this context, server side rendered HTML has proven a very progressive learning curve.
And yes, server side rendering can also turn very complex as z3c.form users know very much.

The reason I am trying HTMX is to check how quickly I will bump into issues or how well it will fit in our beloved component architecture.

3 Likes
8

My goal is to check how possible it is to avoid React (and Vue and Angular and Svelte and Elm).

In this context, I will first try it with Plone classic only.

Now, if the trial is a success, it might make sense to check if and how htmx can be plugged into a React app like Volto and if they can collaborate.

9

I love the approach!

2 Likes
10

It's a nice approach.

However, just as a reminder, we already have something similar in Plone.
Demos — Patterns is part of Plone 6, GitHub - plone/plone.patternslib: An add-on to make patternslib patterns available within Plone 5. integrates it (an old version of Patternslib) in Plone 5.x and Mockup is based on it since quite some time.

What I do like with patternslib is that it uses semantic HTML whereever possible (e.g. the inject pattern uses the href or action attributes for AJAX calls, the pat-validation pattern uses HTML form validation related attributes).
As a developer I also like the thin wrapper to create a Pattern and that it provides the infrastructure to configure it via data attributes.

If you want to learn more check out the demos at Demos — Patterns , watch my Plone conf talks from 2020 and 2021 or read the source and examples at GitHub - Patternslib/Patterns: Library for quickly applying rich interaction patterns without the need to write any JavaScript. . Forget about the docs on Documentation — Patterns yet - they are out of date and needs to be reworked to reflect all the changes we made since late 2019.

2 Likes
11

My 2c: I haven't looked in-depth into htmlx to be honest. Though, we were heavily invested into Angular a long time ago and Angular shares one base design principle with htmlx, which is that you annotate HTML to execute JavaScript. This might sound like a neat idea at the beginning (like two-way binding :)). Though, you will end up learning a framework instead of learning to write proper JavaScript.

My awaken moment came when I was writing Angular 2+ components over and over again as HTML-like components and all I was doing was passing JSON structures as configuration. In any larger application, HTML-based components will become an overhead and it felt completely nuts to me at some point.

JavaScript is a reality, so my recommendation is to learn it properly from scratch without any framework. If you have to choose a framework, choose React. It is by far the most successful and widespread JS framework out there and is very close to plain JavaScript. React blew away any other framework and all the frameworks that came afterwards were heavily influenced by React (like Vue).

Even if React would die (which it won't anytime soon), you would still be able to pick up any other JS framework easily (e.g Vue is very close to React and it is relatively easy to switch I'd say). If you learn Angular or HTMLX, and in the end, you are left with nothing but useless conventions.

Of course, you can (and should) try out any new JS framework out there and toy around with it to learn. Though, when it comes to valid long-term choices I don't see a bright future for HTMLX. They made a very good marketing move by choosing the HTML name and making it look like it is a standard. Apart from that I don't see anything new.

Maybe I am missing an important point about HTMLX and I will deeply regret this comment (like the comment I made about React when it came out, you know: separations of concerns and stuff). Though I looked at the docs and stuff and I still have no clue why people are drawn to it in any way. If someone can explain to me the USP of HTMLX I'd love to hear it.

This is my personal opinion after working with most of the JS frameworks that popped up in recent years and making enough wrong framework decisions for a lifetime (at least I skipped KSS and patternslib/mockup though).

And BTW, that's just the JS framework battle side. There is more: we rewrote more than half of Plone in React in recent years and we have a sophisticated code base that will become Plone 6. This means you will have to work with React in the future if you do Plone.

Therefore, when you choose any framework other than React when working with Plone, you should have very substantial reasons for your choice. I don't see that killer reason for HTMLX tbh.

Regarding the learning curve: I trained people in Plone, Python, Angular 1, Angular 2+, React and Volto. I managed large teams of developers with different backgrounds in those languages and frameworks. React and Volto are a lot easier to pick up than anything we are used to in Plone. Yes, you have to give up the way you write HTML (this is why Vue and HTMLX and others still have traction).

Though, we can train people from zero (school) to become Plone 6 frontend devs in less than six months (meaning they do Plone projects on their own). That would be impossible with Plone Classic or any Plone-based technology.

You are a very smart guy Gotcha, trust me, you can learn React within a week (and it will be worth it). :slight_smile:

3 Likes
12

The important point you are missing here is that htmx is not a JS framework, it is just a way to call backend and insert the resulting html wherever you want in your page (like, for example, when you click the "Edit" button, instead of navigating to the edit view, it makes a call to the backend, gets the edit form and replace the main document with this form, all based on markup annotations).
So it is a way to build dynamic web pages without using any JS framework (all the HTML is still generated in the backend).
To be honest, personally, I am not a big fan of htmx (I might change my mind some day though), but I like any initiative trying to break the classical frontend build chain.

5 Likes
13

The comparison of HTMX is a bit of an apples and oranges one - they
don't aspire to do the same things.

It's not clear to me how the two could work together in the context of
Volto, but HTMX is very, very useful indeed for incrementally adding
functionality to classic Plone.

I've been using HTMX's predecessor, IntercoolerJS, in integration work
for a few years now, primarily to integrate Plone and web2py apps, and
it has worked really, really well. It coexists happily with existing JS,
it makes a whole bunch of stuff that ought to be simple, simple.

IntercoolerJS (and now HTMX) together with plone.restapi, have made
working with Plone with a TTW mindset fun again for me.

HTMX has definitely got a place in the mix for an integrator using
classic Plone.

[1] https://intercoolerjs.org/

3 Likes
14

Even if React would die (which it won't anytime soon)

I can't imagine the amount of screwup in such a huge piece of technology that would condemn React to its death. React is not "just another javascript library", it's a common investment done by the software giants. Even if some entities like Microsoft and Adobe will move to something else at some point, we're pretty safe for now.

As backend developers we don't usually follow what happens on the "frontend" side of the industry and we're also influenced by tech news sites, where React is the "safe but boring" and not the hot new thing. When it comes to actually building stuff and making long term plans, React is more than a fad.

1 Like
15

Newbie question: Is HTML still a big part of React ? Or is it anecdotal that React produces HTML and it could serialize to any other format ?

16

"rendering to HTML" is produced by the react-dom library. If you write a renderer, it can serialize to other formats. See GitHub - chentsulin/awesome-react-renderer: Awesome list of React Renderer

17

@gotcha picking up on this, I haven't tried it yet so take this with a huge heaping of salt...
There is something called the "client-side-template extension" for htmx - </> htmx ~ The client-side-templates Extension, this allows you to manipulate incoming JSON into html. Bascially, this approach would allow you to use the Plone REST API with htmx...
...
...
I think.

18

I did a tiny experiment with HTMX and the Plone REST API.
I consider this the "hello world" for using HTMX and HTMX's "client-side-template extension" to transform the JSON returned from the Plone REST API into HTML.

19

Here's a demo of HTMX retrieving data from the Plone API, we return the the admin portrait and other metadata:
htmxplonedemo

2 Likes