Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reactive Clojure: A web language

hyperfiddle.notion.site

Post reply on HN
Print view View original

151–160 of 185 posts

Re: Reactive Clojure: A web language

#151

Post by pjgalbraith »

steelbrain wrote: post #107
Zababa wrote: post #104

Earlier quoted context omitted.

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

LoC != Complexity. React has one job, and it does it really well, part of that 350k lines of code is a LOT of tests. Just because it has those tests doesn’t mean it’s “much more complex”. My two cents :)

Good point I checked and it's nowhere near 350k LOC. React is a monorepo here are some numbers for the main packages, excluding tests:

react = 3k

react-dom = 15k

Re: Reactive Clojure: A web language

#152

Post by weavejester »

Zelphyr wrote: post #9
mjburgess wrote: post #4

Finally the problem which PHP solved more than two decades ago has been solved again. How do we include server-side code in client-side code? Do we build the client-side on the sever, and render? Why no, that would be PHP. Let's build the client-side in the browser, and rig a series of complex code-generating primitives disguised by the beauty of a language, to AJAX our way to a presumably good-enough solution. I thi…

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.

Re: Reactive Clojure: A web language

#153

Post by chitowneats »

weavejester wrote: post #150
Diggsey wrote: post #143

Earlier quoted context omitted.

Deleting a database is probably a bad example, but my point still stands: even if you are not trasferring code back and forth, runtime state is enough to be a problem. What if your runtime state includes an `is_authorized` flag or similar? How do you guarantee that this state remains server-side when the entire language conflates server/client side code? For this to work, there needs to be language-level support for…

If the compiler is separating server-side code from client-side code, then it's also separating out symbol bindings as well. So it knows where symbols are bound, and where they are referenced, and it can use this to limit information flow. For example: (client (let [token (get-client-token)] (server (let [username (get-username db token)] (client (dom/p "Hello " username)))))) The compiler can infer that token is def…

Compile-time macros do indeed seem to be what provides the necessary client/server separation for sensitive data.

That does mean you are trusting the library to implement these macros correctly. In that sense, data security for these symbol bindings is a responsibility of the library, and therefore a risk, as is called out lower on the page.

Once the library is complete however, and a larger part of the community has been able to inspect it, this type of bug should not be an issue. It's one of the most fundamental concerns of the library.

Re: Reactive Clojure: A web language

#154

Post by Kaze404 »

hungryforcodes wrote: post #74
Kaze404 wrote: post #67

Earlier quoted context omitted.

Because software engineers are known for being people who are averse to learning and trying new things out.

As opposed to actually spending their time building useful practical things?

I hope you don't live every second of your life building useful practical things.

Re: Reactive Clojure: A web language

#156

Post by sooheon »

cabalamat wrote: post #125
delegate wrote: post #27

This is not reinvention of PHP as some are commenting. In fact I think this is extremely cool. If I understand it correctly, it allows you to achieve reactive data flow in a single page app without any boilerplate. Meaning - you update the database on the server and all the relevant UI(s) will automatically receive the updated data and re-render only the parts of the UI that display that data. This would require a to…

> you update the database on the server and all the relevant UI(s) will automatically receive the updated data and re-render only the parts of the UI that display that data. I really don't like that idea. It seems to me inefficient and error prone. Let's say you're updating a database. You add some records to one table, and you update some records to some other tables. If the program automagically updates the UI, the…

From submission:

"Sounds really slow and chatty right? Actually, NO!

This is not RPC or ORM. The key is to make the language, compiler and runtime in charge of the network, like the JVM owns the heap. Idealized client/server network IO (better than could ever be coded by hand) is an explicit design goal.

How does it work? Functional programming:

- `photon/defn` is a macro that compiles Clojure syntax (s-expressions) to a dataflow signal graph (DAG). - The DAG is lifted and compiled into Missionary reactive signals. Missionary manages reactive execution (incremental maintenance such that a small adjustment to inputs results in a small adjustment to outputs)."

Re: Reactive Clojure: A web language

#157

Post by sooheon »

throwamon wrote: post #147

Interesting how no one has mentioned Fulcro. There seems to be a lot of overlap between the two. Anyone who has used both and mind comparing them? https://fulcro.fulcrologic.com/

Yeah Fulcro has been building up their implementation of these ideas for ages, and used in anger, I think most famously by nubank.

From https://book.fulcrologic.com:

"The core ideas are as follows:

Graphs and Graph Queries are a great way to generalize data models.

UI trees are directed graphs that can easily be "fed" from graph queries.

User-driven operations are modeled as transactions whose values are simply data (that look like calls).

Arbitrary graphs of data from the server need to be normalized (as in database normalization):

UI trees often repeat parts of the graph.

Local Manipulation of data obtained from a graph needs to be de-duped.

Composition is King. Seamless composition is a key component of software sustainability."

Re: Reactive Clojure: A web language

#158

Post by amw-zero »

I’m very into stuff like this, and I really can’t make heads or tails of what this post is about. There’s a ton of hand waving, and a ton of words, but why not use them to explain exactly what this thing is doing?

Re: Reactive Clojure: A web language

#159

Post by chii »

zero_iq wrote: post #101
zaksingh wrote: post #37

So from what I can tell this is conceptually similar to the LiveView model, except that the problem is approached from the perspective of the SPA/client stack instead of the SSR stack. It’s a refreshing idea that I’ve never seen executed like this before. However I think it’s missing the point of de-coupling. Security would be very hard to reason about, as would handling of intermittent network connections when the r…

Mr first thought reading the article was security. After a quick ctrl-f, it was a little disconcerting to find that the only mention of security is in a tacked-on bullet list under the heading "risks"...

why is this any different from any other web api security concerns?
Post reply on HN