Live data from Hacker News

Reactive Clojure: A web language

hyperfiddle.notion.site

171–180 of 185 posts

Re: Reactive Clojure: A web language

#171
post #127
post #49

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

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.

Re: Reactive Clojure: A web language

#172
post #168
post #49

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.

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.

Re: Reactive Clojure: A web language

#173

Earlier 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.

I'd say commenting on Hackernews isn't building something, let alone something useful. So that's at least one thing you do that's not that.

Re: Reactive Clojure: A web language

#174

Earlier 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.…

Yes i agree

Re: Reactive Clojure: A web language

#175
post #104

Earlier 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.

preact is much simpler than react (~3KB), and whats weird, it's also faster

BTW: code is very easy to read/follow https://github.com/preactjs/preact/

Re: Reactive Clojure: A web language

#177

Earlier 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.

The question is, are bugs rare in rails because of or in spite of the code size? Obviously more code is more opportunity for mistakes, but more code is also the product of more users and more contributors poring over what’s there.

Re: Reactive Clojure: A web language

#178
post #172
post #168

Earlier 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…

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

Re: Reactive Clojure: A web language

#179
post #57

This 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!

Definitely will give it a go when I have some free time!

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

#180
This is very cool, and ambitious, but i have one major objection: the claim that web apps are an about unidirectional data flow from a managed data store to a consuming front end.

That'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.

Post reply on HN