PW 3.0.189 – Core updates

[d'Hinnisdaël]

Another good option for partial HTML updates is morphdom which transforms the existing dom nodes to match the new incoming HTML without discarding any elements. That way, any dom events, scroll positions or css transition states will be kept on the existing elements. No specific markup required, nor changes to how you set up dom events. It's used in Phoenix LiveView which is pretty close to our use case (live updates from server-rendered templates).

[fuzendesign]

On 11/6/2021 at 4:29 AM, kongondo said:

One of the many reasons I like htmx. It reminds me of ProcessWire a lot. Out of the box all it does is give you the necessary tools then stays out of your way. Even the author, for some reason, reminds me of Ryan ?. 

So great to hear. I’ve been following HTMX for a while. I like the dev’s pragmatism. Makes me think of Ryan and PW also.

[fuzendesign]

On 11/5/2021 at 8:03 PM, Craig said:

I'd like to add another vote to the notion of using something like htmx or Unpoly - I like them, a lot. Having used them on various projects, both have pros and cons (like most things) and satisfy different use cases.

I know PW is quick, and the template caching improves on things, but I recently launched a site that made use of Unpoly's up-preload and up-instant functionality - the perceived speed of page loads makes it feel like a static site. The client's response on seeing the dev preview was "I was not expecting a like for like copy! Especially one that is that fast." (their emphasis; it was a redevelopment of a bad WordPress build).

With Unpoly, I find the modal, popup and drawer UI are great. Having those integrated with the dynamic functionality is a plus, and means I don't have to worry about whichever underlying CSS framework is being used or pulling in a separate dependency to provide that. It's not perfect; some interactions, particularly nested ones, need a bit more care to make sure the server responses and front-end attributes are all present and correct. I also make heavy use of the "compiler" functionality. This is essentially your "$(document).ready()" equivalent which lets you initialise your client-side components (like maps or colour pickers, for example) on both initial page load as well as any time they happen to be added to the page dynamically via AJAX as the result of an Unpoly request.

htmx sits at a bit of a lower level, and provides events and a plugin system to extend it and hook into different interactions. When you need to do client-side things, you will still need some javascript to get the job done; or you could use htmx's sister project _hyperscript.

Either way, I'd be happy to see any of these become part of the PW admin. ? 

Funny. Unpoly has been on my try list for months. I bookmark and articles I find. Same with HTMX.

[totally not an htmx shill]

On 11/13/2021 at 6:56 AM, d'Hinnisdaël said:

Another good option for partial HTML updates is morphdom which transforms the existing dom nodes to match the new incoming HTML without discarding any elements. That way, any dom events, scroll positions or css transition states will be kept on the existing elements. No specific markup required, nor changes to how you set up dom events. It's used in Phoenix LiveView which is pretty close to our use case (live updates from server-rendered templates).

htmx supports using morphdom for swapping with the morphdom-swap extension

agree 100% w/ @Craig's characterization of htmx as lower level than unpoly: it's an extension of HTML rather than a full framework (with, for example, a notion of layers).  That can be good or bad, depending on your needs.  Unpoly is a wonderful library that follows the same general html-oriented approach, but provides a lot more infrastructure baked into the core.  I think either one (or, hotwire, for that matter, which is even higher level than unpoly) is a great choice for html-oriented development.

I obviously prefer the lower-level "improve on HTML" approach, but they all have plusses and minuses.  I'm (all to) happy to chat about htmx either here, on the htmx discord, or anywhere else.

-t.totallyNotAnHtmxShill

[fuzendesign]

30 minutes ago, totally not an htmx shill said:

htmx supports using morphdom for swapping with the morphdom-swap extension

agree 100% w/ @Craig's characterization of htmx as lower level than unpoly: it's an extension of HTML rather than a full framework (with, for example, a notion of layers).  That can be good or bad, depending on your needs.  Unpoly is a wonderful library that follows the same general html-oriented approach, but provides a lot more infrastructure baked into the core.  I think either one (or, hotwire, for that matter, which is even higher level than unpoly) is a great choice for html-oriented development.

I obviously prefer the lower-level "improve on HTML" approach, but they all have plusses and minuses.  I'm (all to) happy to chat about htmx either here, on the htmx discord, or anywhere else.

-t.totallyNotAnHtmxShill

? Introduce yourself!

[totally not an htmx shill]

11 hours ago, fuzendesign said:

? Introduce yourself!

hi, my name is carson, and I created htmx

and, since we're here, hyperscript.org (for lunatics only)

[kongondo]

1 hour ago, totally not an htmx shill said:

hi, my name is carson, and I created htmx

Carson, what an honour to have you here! ?.

[szabesz]

As soon as one starts relying on HTMX, one needs to support the project, for one's own sake, I think:

• https://github.com/sponsors/bigskysoftware?frequency=recurring
• or:
• https://github.com/sponsors/bigskysoftware?frequency=one-time

5 hours ago, totally not an htmx shill said:

hi, my name is carson, and I created htmx

Welcome to the ProcessWire forums!

[totally not an htmx shill]

5 hours ago, szabesz said:

As soon as one starts relying on HTMX, one needs to support the project, for one's own sake, I think:

• https://github.com/sponsors/bigskysoftware?frequency=recurring
• or:
• https://github.com/sponsors/bigskysoftware?frequency=one-time

Welcome to the ProcessWire forums!

? I appreciate that, but htmx is fairly feature complete and is supported by my other work.  intercooler.js, the predecessor to htmx, has been up for nearly a decade without any sponsorships:

https://intercoolerjs.org

I don't anticipate htmx being any different, although I always do appreciate any sponsorships!

Thank you for the warm welcomes.  I don't know how useful I'll be, but I'll try to answer any questions I can around htmx as honestly as possible.

[fuzendesign]

15 hours ago, totally not an htmx shill said:

hi, my name is carson, and I created htmx

and, since we're here, hyperscript.org (for lunatics only)

There you go ?. Thanks for responding to my Reddit post. It **really** is an honor.

[kongondo]

48 minutes ago, totally not an htmx shill said:

Thank you for the warm welcomes.

That's the Locality of Behaviour here ?. Cheap one, I know, sorry, I couldn't help myself. 

4 hours ago, totally not an htmx shill said:

I'll try to answer any questions I can around htmx as honestly as possible.

Any chance you could please give us your thoughts on this one? 

On 11/9/2021 at 2:20 PM, ryan said:

Side note, but one issue I also noticed in coding ProDrafts live preview is that when you update an element that has JS events on it that were added in document.ready, then they no longer work. For instance, an images gallery might have events that make thumbnails open in a lightbox or something. When the images gallery live updates, the lightbox no longer works unless the events were added to the whole document. Does htmx have some magic for this kind of situation?

We have suggested onLoad and your example here on 3rd-party integration. Would you have other thoughts maybe? Thanks.

31 minutes ago, fuzendesign said:

Thanks for responding to my Reddit post.

Nice one! Yeah, Python has been getting all the love ?.

[totally not an htmx shill]

1 hour ago, kongondo said:

Side note, but one issue I also noticed in coding ProDrafts live preview is that when you update an element that has JS events on it that were added in document.ready, then they no longer work. For instance, an images gallery might have events that make thumbnails open in a lightbox or something. When the images gallery live updates, the lightbox no longer works unless the events were added to the whole document. Does htmx have some magic for this kind of situation?

Generally that's correct, htmx.onLoad() replaces the standard jQuery initalizer.  Only real trick is that you initialize stuff in the content passed in to the onLoad() callback, rather than initializing the whole document like you do normally in jquery:

Note that the query selector is run against the newly inserted `content` element, rather than globally, so you can initialize the library just for the new content that has been added to the DOM (and avoid accidental double-initialization of things.)

Alternatives are:

• using alpine to init the element on load
• using hyperscript to init the element on load

The first one is sane, but not how I would do it unless I already had alpine in my code base and I was comfortable with it.  The second one is insane and not recommended, but I do love hyperscript.

[Fuzen]

Great to see HTMX getting some love: 

 

[gmclelland]

Here's an article that talks about hot-reloading in Craft CMS using Alpine.js:

https://aaronmbushnell.com/hot-reloading-content-in-craft-cms-live-preview/

It also references an article about Statamic's live preview as well:

https://jacksleight.dev/posts/hot-reloading-statamic-s-live-preview-in-a-traditonal-mpa

Just thought I would share in case it is relevant? 

[bernhard]

Just want to mention that ProcessWire has had great frontend editing capabilities for years:

And for more complex content (like images) having a modal is not too bad in my opinion:

But yeah, I agree that the frontend editing tools could get some love and could be improved. For example the modal could have more events to listen to. And maybe instead of reloading the whole page it would be nice to just replace the corresponding block instead of refreshing the whole page.

On the other hand I'm not sure how much benefit that would really bring. A page reload is often helpful or even required (eg for loading different styles or scripts when something changed) and in my opinion it does not really hurt.

Compare this to what you linked to: https://aaronmbushnell.com/images/live-reload.mp4

What you see here is a problem that is quite underestimated in my opinion. The barrier between frontend and backend might be easy to grasp for us developers that built the website, but it's not so easy for clients. Which field ends up where in the final design? How does the field "headline" look? It's just text in the backend! You have no visual idea of the final result. And having all fields in a sidebar does not solve these problems in my opinion. I can't even see the changes that he makes for the "accordion"! I see him changing field values, but I don't see where that content is changed on the site...

With frontend editing you don't have these problems. Clients can just doubleclick on the text that they see and start typing ? 

Pssst: RockPageBuilder in action here ? Sign up for https://www.baumrock.com/rock-monthly/ if you want to get notified when I release it or write me a PM.