Live data from Hacker News

Reactive Clojure: A web language

hyperfiddle.notion.site

51–60 of 185 posts

Re: Reactive Clojure: A web language

#51

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…

So more like Liveview for Phoenix / Elixir is what this kind of sounds like to me, and less so back-end mainly language like PHP.

Re: Reactive Clojure: A web language

#52
post #39

This reminds me of Meteor.js[0] from back in the day (2014?), which had a very similar approach—you wrote code that ran on both the frontend and the backend, and database updates were propagated automatically. It suffered from a pretty hard reliance on Mongodb and its own package manager (Atmosphere), and it was at odds with the rest of the JS ecosystem which was settling on NPM. This project looks very cool! I like…

Another big problem was that you rarely want exactly the same code on client and server.

Re: Reactive Clojure: A web language

#53

Quite a few comments that are dishonest or didn't focus on what the author focused on, but rather on auxiliary things. There are concrete similarities to PHP, which is effectively what this server/client macro setup gives you at a superficial level. However, from what I'm seeing, this will behave more like a LiveView or Hotwire, with the focus being on optimizing network requests in an automated manner. My big questi…

[deleted]

Re: Reactive Clojure: A web language

#54
post #39

This reminds me of Meteor.js[0] from back in the day (2014?), which had a very similar approach—you wrote code that ran on both the frontend and the backend, and database updates were propagated automatically. It suffered from a pretty hard reliance on Mongodb and its own package manager (Atmosphere), and it was at odds with the rest of the JS ecosystem which was settling on NPM. This project looks very cool! I like…

one that sort of fell by the wayside when Meteor and Ember got popular, was/is Derby.js/ShareDB. https://github.com/derbyjs/derby https://derbyjs.com/ https://github.com/share/sharedb

The LiveView lead resurgence in server side rendering is exciting. Does anyone have any insight as to why ShareDB never really took off?

Re: Reactive Clojure: A web language

#55
post #39

This reminds me of Meteor.js[0] from back in the day (2014?), which had a very similar approach—you wrote code that ran on both the frontend and the backend, and database updates were propagated automatically. It suffered from a pretty hard reliance on Mongodb and its own package manager (Atmosphere), and it was at odds with the rest of the JS ecosystem which was settling on NPM. This project looks very cool! I like…

Yeah Meteor was an interesting example of an amazing project that fell into a hole based on a couple of bad decisions. It's basically fixed those at this point but become something pretty different in the process. It sounds like it may be something I can use now but I haven't tried it.

Re: Reactive Clojure: A web language

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

Re: Reactive Clojure: A web language

#58

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…

> Imagine a programming language runtime whose runtime state (i.e. lexical scope) is partially broadcast over network as it happens, kind of like a remote debugger.

This sounds absolutely terrifying from a security perspective...

What's to stop a malicious client from broadcasting code that deletes my entire database?

Re: Reactive Clojure: A web language

#59
This is beautiful. I used to think about this problem deeply. The best imaginary system I did imagine was:

- A system that starts with our database schema

- a language in the front-end that abstracts away server connection and db access

- this imaginary language should allow defining react-like components but treat the db as a local datastore

- Most clients are UI stricture interpolated with that user’s data queried from the central db. So this imaginary front-end language should allow querying from user-level views from the db

Most of what I read from the post, looks like a realization of this dream.

Re: Reactive Clojure: A web language

#60
If you are trying to allure front end devs, maybe don't use tables in you example.

To my taste, all of that is way too overcomplicated. I don't know why we need to make writing and maintaining web pages more complex with every year that goes by. To my mind, this industry looks completely derailed.

Post reply on HN