5 ms·

Funnily enough, PHP (like, old school PHP) is a surprisingly neat fit for this style of programming when combined with htmx[0] Tiny amount of glue HTML attribu

by girvo 5y ago

Funnily enough, PHP (like, old school PHP) is a surprisingly neat fit for this style of programming when combined with htmx[0] Tiny amount of glue HTML attributes, a heap of partials that are your PHP files and you’re good to go. What is old is new again I suppose: we used to do this with PHP and jQuery once upon a time too — though LiveView and similar are far nicer of course. I’ve been working on some personal tools with nothing more than Deno and htmx. Works quite well for my needs! [0] https://htmx.org/ https://htmx.org/

mstef9 5y ago
I was going to say that I was surprised htmx wasn't mentioned in the article. It's backend-agnostic and extremely easy to use. Drop in Alpine.js and I think you have a really powerful setup without writing any JS. I've been using this with Go[0] and enjoying it. [0] https://github.com/mikestefanello/pagoda https://github.com/mikestefanello/pagoda
- harryvederci 5y ago
  Same here, big fan of htmx! I use it with lisp-like languages (Clojure, Janet). Those have html libraries that transform datastructures into html. So it doesn't feel like I'm writing html, while I'm pretending not to use JavaScript. It's glorious.
arjvik 5y ago
I think htmx.org got the HN Hug of Death
bob1029 5y ago
If someone took blazor away from me tomorrow, I'd probably consider PHP for a while. The most important part of the programming model is very similar in my experience. I could take a Razor component and convert it directly to a PHP partial pretty quickly.
piva00 5y ago
> What is old is new again I suppose: we used to do this with PHP and jQuery once upon a time too — though LiveView and similar are far nicer of course. I used to do the same with PHP + Prototype.js back in 2006-2007 before jQuery existed, including pretty weird hacks for non-AJAX supported browsers (using JS to append <script></script> from server-side to the DOM). Surely what is old is new again...
- girvo 5y ago
  I was the weirdo using Dojo back then, but once jQuery hit the scene and gained traction we jumped ship as soon as possible haha
stavros 5y ago
PHP, Django, Rails, whatever generates HTML, basically. I also slightly prefer Unpoly.com, because it takes whole pages instead of fragments. This means that if JS is disabled the site just keeps working, though with reloads.
- mstef9 5y ago
  You can achieve full support with JS disabled using HTMX as well. It takes a little more work but HTMX provides headers[0] which you can evaluate on the backend to determine if you should return a partial or not. If JS is disabled, the HTMX headers will be missing and you know it's not an HTMX request. [0] https://htmx.org/reference/#request_headers https://htmx.org/reference/#request_headers
  - stavros 5y ago
    Ah, that's a great idea, thanks!
NoGravitas 5y ago
I'm also very happy with htmx; I've used it with both Django and ASP.NET MVC. Factor out your partials wisely, and it really makes life easy.
wanderer_ 5y ago
Call me a heretic: I love PHP.
- ARandomerDude 5y ago
  Heretic!
- datavirtue 5y ago
  I think my next site is going to be php+Laravel. I had a lot of fun doing web dev in php. Nothing has matched that since. I never tried rails though. If I see another bumblefucked SPA I'm gonna cry.
robertoandred 5y ago
htmx's modal demo fails accessibility quite badly.
ledgerdev 5y ago
So, I have only been working in htmx for about a week on a multi step checkout app, and while it's been mostly awesome, I think I ran into the Achilles heel of htmx, form state and the back button. In short of you enter data into a form then htmx push navigate away, when you click the browser back button you get the dom as it was originally delivered from the server, without any data the user might have entered into text boxes. This is a show stopper problem and been working on work arounds, not sure any is good. Basically we have resorted to plain old full page reloads with client side redirect to resolve this.
- polyrand 5y ago
  The thing about HTMX is that the mental model about state should tend towards "the server is aware of everything". With the added benefit that you can achieve better RESTful URLs that respect the navigation actions. Without having tried this (but having used HTMX quite a lot), I would try the following (let me know if I didn't understand the problem correctly): Checkout has the following URLs, one for each step: * page.com/checkout (optionally with ?step=0) * page.com/checkout?step=1 * page.com/checkout?step=2 * page.com/checkout?step=3 Now you need 2 things: 1) Making sure the server knows how to render all those pages independently (like if the user does a hard-refresh or if they open that URL directly, without navigating to it through a link). Note: I believe this should be the default in any website if you respect the concept of a URL (whether client or server-side rendered). 2) If there's a form input at each step, the server needs to store that info and be aware that the user has an incomplete checkout. Now the user is at step=2 and presses the back button, or clicks on the step=1 link. In that case, the server should know the information stored in the point no. 2 above, and return an HTML form with the data pre-filled based on the last state. E.g: <input type="text" id="name" name="name" value="Foobar"> I think there are 3 main keys: 1. You need different URLs for each step. 2. Each URL should work both with HTMX (maybe using hx-push-url or the HX-Push header) and *without*. That is, any navigation to that page should also render the same HTML. 3. The server needs to be aware of the state. When a user requests page.com/checkout?step=2, the server should know if the HTML form requires pre-filled values. This increases a bit the complexity on the server, but I believe it reduces the client-side complexity a lot more.

by girvo 5y ago

mstef9 5y ago

I was going to say that I was surprised htmx wasn't mentioned in the article. It's backend-agnostic and extremely easy to use. Drop in Alpine.js and I think you have a really powerful setup without writing any JS. I've been using this with Go[0] and enjoying it. [0] https://github.com/mikestefanello/pagoda https://github.com/mikestefanello/pagoda

harryvederci 5y ago
Same here, big fan of htmx! I use it with lisp-like languages (Clojure, Janet). Those have html libraries that transform datastructures into html. So it doesn't feel like I'm writing html, while I'm pretending not to use JavaScript. It's glorious.

arjvik 5y ago

I think htmx.org got the HN Hug of Death

bob1029 5y ago

If someone took blazor away from me tomorrow, I'd probably consider PHP for a while. The most important part of the programming model is very similar in my experience. I could take a Razor component and convert it directly to a PHP partial pretty quickly.

piva00 5y ago

> What is old is new again I suppose: we used to do this with PHP and jQuery once upon a time too — though LiveView and similar are far nicer of course. I used to do the same with PHP + Prototype.js back in 2006-2007 before jQuery existed, including pretty weird hacks for non-AJAX supported browsers (using JS to append <script></script> from server-side to the DOM). Surely what is old is new again...

girvo 5y ago
I was the weirdo using Dojo back then, but once jQuery hit the scene and gained traction we jumped ship as soon as possible haha

stavros 5y ago

PHP, Django, Rails, whatever generates HTML, basically. I also slightly prefer Unpoly.com, because it takes whole pages instead of fragments. This means that if JS is disabled the site just keeps working, though with reloads.

mstef9 5y ago
You can achieve full support with JS disabled using HTMX as well. It takes a little more work but HTMX provides headers[0] which you can evaluate on the backend to determine if you should return a partial or not. If JS is disabled, the HTMX headers will be missing and you know it's not an HTMX request. [0] https://htmx.org/reference/#request_headers https://htmx.org/reference/#request_headers
- stavros 5y ago
  Ah, that's a great idea, thanks!

NoGravitas 5y ago

I'm also very happy with htmx; I've used it with both Django and ASP.NET MVC. Factor out your partials wisely, and it really makes life easy.

wanderer_ 5y ago

Call me a heretic: I love PHP.

ARandomerDude 5y ago
Heretic!
datavirtue 5y ago
I think my next site is going to be php+Laravel. I had a lot of fun doing web dev in php. Nothing has matched that since. I never tried rails though. If I see another bumblefucked SPA I'm gonna cry.

robertoandred 5y ago

htmx's modal demo fails accessibility quite badly.

ledgerdev 5y ago

So, I have only been working in htmx for about a week on a multi step checkout app, and while it's been mostly awesome, I think I ran into the Achilles heel of htmx, form state and the back button. In short of you enter data into a form then htmx push navigate away, when you click the browser back button you get the dom as it was originally delivered from the server, without any data the user might have entered into text boxes. This is a show stopper problem and been working on work arounds, not sure any is good. Basically we have resorted to plain old full page reloads with client side redirect to resolve this.

polyrand 5y ago
The thing about HTMX is that the mental model about state should tend towards "the server is aware of everything". With the added benefit that you can achieve better RESTful URLs that respect the navigation actions. Without having tried this (but having used HTMX quite a lot), I would try the following (let me know if I didn't understand the problem correctly): Checkout has the following URLs, one for each step: * page.com/checkout (optionally with ?step=0) * page.com/checkout?step=1 * page.com/checkout?step=2 * page.com/checkout?step=3 Now you need 2 things: 1) Making sure the server knows how to render all those pages independently (like if the user does a hard-refresh or if they open that URL directly, without navigating to it through a link). Note: I believe this should be the default in any website if you respect the concept of a URL (whether client or server-side rendered). 2) If there's a form input at each step, the server needs to store that info and be aware that the user has an incomplete checkout. Now the user is at step=2 and presses the back button, or clicks on the step=1 link. In that case, the server should know the information stored in the point no. 2 above, and return an HTML form with the data pre-filled based on the last state. E.g: <input type="text" id="name" name="name" value="Foobar"> I think there are 3 main keys: 1. You need different URLs for each step. 2. Each URL should work both with HTMX (maybe using hx-push-url or the HX-Push header) and *without*. That is, any navigation to that page should also render the same HTML. 3. The server needs to be aware of the state. When a user requests page.com/checkout?step=2, the server should know if the HTML form requires pre-filled values. This increases a bit the complexity on the server, but I believe it reduces the client-side complexity a lot more.