Live data from Hacker News

Reactive Clojure: A web language

hyperfiddle.notion.site

91–100 of 185 posts

Re: Reactive Clojure: A web language

#92
post #75

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…

The problem with this type of system in my experience is that 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 and you go crazy

True With any system

Re: Reactive Clojure: A web language

#93
I like how client and server code is separated, but I do wonder how changes in expressions are evaluated.

I'm thinking about autocomplete that on new user input (needle='ad') filters previous result from server (needle='a') in the client before server returns a new response from new input (needle='ad').

Essentially can inner parts of expression update even when they are somewhat dependent on reactive data from server that comes from their parent expression?

Re: Reactive Clojure: A web language

#95
This is tangential but also a validation.

FoxPro (& dBase) is a realization of the concept: To deal with databases, you need a database language.

Exist a lot of minor things that our apparent "general-purpose" languages lack in the moment you need to deal with certain niches. From very small stuff as not-even available decimals, dates, currencies, units types, to lack of simple way to transform data, to ad-hoc queries, to ad-hoc data validations, to lack of relationship modeling, etc.

Even if you say "linq!, ActiveRecord!, functional!, lisp!, pandas!..." and others all that are a shadow of what the dBase family provides.

How far? I was not in worry about all the stuff everyone worry about today (injection? orms? impedance mismatch? reactivity? So, in short, most languages, even php, python, ruby, ... are not that good for web programming (and worse for database programming!), just that are not that terrible, either.

Re: Reactive Clojure: A web language

#96
Coincidentally, Alephjs (https://github.com/alephjs/aleph.js) added a commit hours ago that also seems to solve this particular problem for React.

So now there's a React hook (useDeno) that takes a callback that is only executed on the server-side, and the returned value is sent back to the client side transparently.

Re: Reactive Clojure: A web language

#97
I think no-code/low-code backend is here to stay. Products like Hasura put authorization/ratelimiting/graphql/api-GW on top of trusted postgres. Now BE and no serialization up and down. Simply generate a client based on the graphql schema and off you go.

Re: Reactive Clojure: A web language

#98
I've thought of doing this several times, and always shied away at the complexity and nuance that goes into it. Kudos to the devs for having the skill and determination needed to actually make this real. Very impressive work, and I hope it works great in practice.

Re: Reactive Clojure: A web language

#99

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…

You need to treat clients as zero-trust. Your db is just a vector for DOS attack if you don't.

Re: Reactive Clojure: A web language

#100
post #80

One thing I admire about the Clojure community is audacious projects like this. While a ton of these seem to run out of steam, they certainly shoot for the stars and tend to come pretty dang close for a while. For those working in Typescript, Blitz.js seems to do a great job at drastically decreasing the plumbing you have to write to shuttle data between Postgres and React. There’s also a ton of goodies like auth bui…

It's a very impressive project, and something I would definitely try in a greenfield app.

I wish there was somewhere to follow updates that wasn't Twitter though.

Post reply on HN