Earlier quoted context omitted.
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
Reactive Clojure: A web language
171–180 of 185 posts
Re: Reactive Clojure: A web language
#172Earlier quoted context omitted.
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.
You can use SSE with PHP to propagate changes.
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.
Re: Reactive Clojure: A web language
#173Earlier quoted context omitted.
I hope you don't live every second of your life building useful practical things.
I do actually. What else are you supposed to do with your time? Life is short, best to use it.
Re: Reactive Clojure: A web language
#174Earlier quoted context omitted.
nothing forbids the system to give mechanisms defining rapid sequences of changes, kinda like debounce in js
I think the main risk for this kind of framework is that you spend as much time ironing out these kinds of "edge cases" (debounce, transition states, error states, transactions, authorization, url bar state, scroll bar position, paging, efficient re-renders, etc. etc.), which in practice are crucial to most non-trivial software, as you would have just writing the usual boilerplate and retaining fine-grained control.…
Re: Reactive Clojure: A web language
#175Earlier quoted context omitted.
At first glance, this appears to be much more complex. React is a relatively simple DOM diffing library. Rails is a closer comparison, especially with whatever their live-view implementation is. This appears to be doing a lot more than React, at least, including network communication, and database change event propagation. The odds seem much higher that stuff will go wrong, especially under load, and be pretty diffic…
> At first glance, this appears to be much more complex. React is a relatively simple DOM diffing library. Their implementation is 2k lines of code. The React repo has 350k lines of code. The Rails repo has 336k lines of code (both of those according to tokei). Of course this includes tests, lots of other stuff, etc. But still, that's two orders of magnitude.
BTW: code is very easy to read/follow https://github.com/preactjs/preact/
Re: Reactive Clojure: A web language
#176Re: Reactive Clojure: A web language
#177Earlier quoted context omitted.
Sure. But I’d question two things: 1) How often do you actually need to read your framework. I used rails for years and read probably less than 2KLOC out of it, ditto with Java and Spring. Good documentation beats out small code bases. 2) How much of the size difference between these two is down to age and uses? Is React so big because it’s unfocused or poorly written, or is that a consequence of it being used by so…
> How often do you actually need to read your framework. This brings us full circle to the question that started this conversation branch: > it’s great until you hit a bug, and then you realize you have no idea what’s going on under all the automagical stuff With React and Rails, "hitting a bug" is apparently rare. Maybe we should wait before assuming it will be any different with this Reactive Clojure framework.
Re: Reactive Clojure: A web language
#178Earlier quoted context omitted.
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…
Re: Reactive Clojure: A web language
#179This syntax is insanely hard to read, is non-standard, and is unclear what is server side and what is client side processed without purple and red highlighting. Maybe I’ve been in Node.js land too long, but I don’t get why this is better for my productivity or my ability to create efficient web apps.
It's not hard to read, but it's just that you aren't used to it. Try Clojure without this "hard to read" mindset and see how great Lisp as tools are!
Also, I can’t edit it right now, but would like to apologize for saying it’s “insanely hard to read”. That was rather harsh and uncalled for.
Re: Reactive Clojure: A web language
#180That's not the kind of apps I want to build. I want workspaces where I can make and edit and work freely. I don't care to be online to do it, and conserving bandwidth is not a constraint that should define how I use it.
The DAG goes from me to me.