Claiming "this is PHP" misses the point entirely, which is turning PHP-like templates into apps that can react to user input

There has got to be a better way of achieving reactive templates than what is described in this project though.

I think Phoenix LiveView (posted recently on HN: https://fly.io/blog/how-we-got-to-liveview/) and Rails Hotwire (https://hotwired.dev/) are the main alternatives that have momentum right now.

The general idea being to abstract away the difference between client and server code, so that you can write code that handles both, in a single file.

> There has got to be a better way

What's offensive about the OP to you? Is it just that you don't like functional programming / Clojure (fair, that's ultimately a matter of taste / aesthetics at some level)? Or is there something about the technical implementation you think is suboptimal?

Thank you for posting those two, I wanted to post them but I don't comment often. Wanted to chip in another contemporary: edelvalle/reactor, which is inspired by LiveView[0].

[0]: https://github.com/edelvalle/reactor

I am using Hotwire for a project, and I'm learning Elixir and Phoenix on the side. Finding edelvalle/reactor was immediately helpful to me though, because I cut my teeth on Python/Django, so reading a Python reference implementation helps me learn nuts and bolts of libraries, faster. (so, I figure that this might help someone else grok how these approaches work.)

Thanks for sharing - I currently work with Django so I'm very happy to see an equivalent library in that ecosystem.

Have you found any issues with Reactor, areas where it's behind Hotwire, etc?

I mean sure but you can’t get over the need to have a two way pipe of some kind to pass events server <-> client. Like no matter what you’ve got two balls of state with bidirectional relationships between them.

What if we put a DOM API into php with a few state hooks? Does that solve it? Because the GP is right, this is PHP.

PHP doesn't reactively and selectively propagate changes between client and server, nor would it be feasible to write such a library in PHP itself. You could maybe achieve something similar with code generation of PHP and JS.

But are you sure propagating changes is desirable ? It looks like a different architecture than the web to me

The use-case here is that the interface is highly interactive and coordinated. The suggested approach and library tries to blur the line between the logical components of client, server and database. Whether that is desirable depends entirely on what the assumptions of your web application are.

You can use SSE with PHP to propagate changes.

That would be a building block to achieve something similar.

Implementing this would however smear your logic all over your client and server and require careful plumbing. SSE doesn't come without caveats either.

The suggested approach here is to abstract away from that plumbing and move to a more declarative, composable expression. Whether you want that or not really depends. I see this as a specialized paradigm to solve a specific category of problems.

You can avoid that just using SSE to notify (no data) the frontend to rerender, you can still render everything in the backend.

Hate towards PHP has absolutely nothing to do with how easy web things are to deploy on it.

There's theoretically some performance benefit to rendering client side over ajax because the pages can be trivially cached, though you then run into the issue of pages being placeholders for a moment while the subsequent request(s!) run. Hence the UX anti-pattern of skeleton screens.

I don’t care for skeleton screens much in any case, but there’s no reason why skeleton screens couldn’t be limited to client-side page loads while the client waits for the data. The server could and should still fetch all the data and send down a fully-rendered page.

I will be so relieved when that anti-pattern goes away.

I really love Clojure--it's a joy to use but, you're right.

Maybe I'm misunderstanding this project but it seems like abstractions on top of abstractions and has little to do with being a "web language". That was PHP, for better or for worse.

You're misunderstanding. The project is proposing writing client-side code and server-side code in the same expression, then having a compiler automatically separate the two parts out and determine how they should communicate.

PHP lets you have a piece of server code that can see the local variables of the client code it's enclosed in? And it's all reactive?

That's amazing!

Regardless of whether PHP solved this particular problem, it also caused a lot of its own due to numerous security issues and documentation that encouraged unsafe use of libraries, until recently.

The pragmatism of rasmus, and how bemused he was that people were using his language to program (vs. template), meant that the BDFL was not a great advocate of the PHP model.

The model is this: run-once-and-die + build-it-on-the-server.

Those two ideas are extremely powerful, a little like immutability, in that they rule out a huge number of issues. The issue with PHP wasn't this model which became associated with the morass of amateurs using the language. A shame.