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

121–130 of 185 posts

Re: Reactive Clojure: A web language

#121

Post by askonomm »

j45 wrote: post #82

Am I missing something or is reactive clojure a web framework for a language too? I don’t recall Clojure being a web centric language like PHP, ASP, etc.

ClojureScript (JS target) is as web-centric as you can think, with what you can write front-end apps, Node.js apps, React and React Native apps, using Clojure.

Clojure (JVM target) can do back-end web as well as Java can, as well as anything else that Java can.

Clojure is a general-purpose programming language, so it can do pretty much anything.

Re: Reactive Clojure: A web language

#124

Post by tshaddox »

cosmotic wrote: post #18
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…

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.

Re: Reactive Clojure: A web language

#125

Post by cabalamat »

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, then on the first change it will attempt to update the UI (causing lots of processing) , then on the 2nd change to the database it'll update the UI again, and on and on for each change.

Wouldn't it be better to make all your changes to the database then only after that run an updatePage() funiction that updates the web page?

Re: Reactive Clojure: A web language

#126

Post by agumonkey »

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…

nothing forbids the system to give mechanisms defining rapid sequences of changes, kinda like debounce in js

Re: Reactive Clojure: A web language

#127

Post by slim »

dgb23 wrote: post #49
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…

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

Re: Reactive Clojure: A web language

#128

Post by quickthrower2 »

marstall wrote: post #6

As a web developer with 25 years of experience and (I thought) up to the minute skills ... I have no idea what any of that means but it sounds cool and important and I want to try it.

You don’t have to know everything you see. If you find it interesting then cool but don’t feel compelled to learn every web thing, it’s a never ending rabbit hole.

Re: Reactive Clojure: A web language

#129

Post by nickkell »

Zababa wrote: post #116
steelbrain wrote: post #107

Earlier quoted context omitted.

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 :)

After a naive removal of the tests (every folder and files that contains tests was deleted), React still has 190k lines of code. > React has one job, and it does it really well I'm not sure I agree. It's hard to compare without a minimal copy of React to see how small it can get, but I'm guessing it could be an order of magnitude smaller. For example, React supports different ways of doing things (class components, f…

I’m going to keep scrolling in search of a shorter comment

Re: Reactive Clojure: A web language

#130

Post by manmal »

ashtonkem wrote: post #120
manmal wrote: post #85

Earlier quoted context omitted.

How is this different from any other framework? Try fixing a React or Rails bug. At least their system is only 2k LOC, which will presumably be well documented.

Clojure tends to be a bit more terse than other languages. 2K of Clojure is a lot of code. Especially if macros get involved. As for the comparisons to React elsewhere; I wonder how much of that is the result of React being battle tested for a long time and expanded, would this still be so short if Facebook was written in it? I also wouldn’t presume good documentation as a general rule. That’s something that must be…

I‘d still rather read 2k loc in _any_ language, and undocumented, than 350k loc, perfectly documented.
Post reply on HN