How does the reactivity work with Datomic? Is it polling those queries? Or I’d it listening to the log of transactions and figuring out when relevant parts have changed?
Reactive Clojure: A web language
141–150 of 185 posts
Re: Reactive Clojure: A web language
#142One 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…
Sadly the running out of steam effect hits the tooling for the community too. It's really hard to find good, stable clojure tools on the level of those available for Java.
I had another coworker compare Clojure and Java tooling recently. I just don't think it's fair to compare one of the most used languages on the planet to one that is written in the other one. Clojure tooling isn't the best out of some ecosystems I've used, but you can leverage a whole bunch of the Java tools and I certainly have, like stack dump analyzers or profilers, or Maven, etc. Are they perfect for use with Clojure, not always, but things are pretty good IMHO. Cursive is an excellent IDE too, a joy to use with very many bells and whistles and there is also excellent Vim and Emacs support. There are at least 3 build tools that are Clojure-specific (Leiningen, Boot, and deps.edn), or you can integrate with older or other JVM tools pretty easily like Maven. There are multiple testing frameworks, multiple test formatters, and multiple test runners. I could go on, but what specifically do you think is missing or could be better?
Re: Reactive Clojure: A web language
#143Earlier quoted context omitted.
> 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?
> runtime state > code Some overlap, but these are essentially two different things. > What's to stop a malicious client from broadcasting code that deletes my entire database? Your backend.
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 distinguishing untrusted inputs from trusted ones, or else it's a recipe for disaster.
Re: Reactive Clojure: A web language
#144This 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
That's true with any system you haven't sufficiently studied.
Re: Reactive Clojure: A web language
#145Earlier 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.
Note that react has a monorepo with a lot of tangentially related packages, such as devtools and alternative renders.
Re: Reactive Clojure: A web language
#146Earlier quoted context omitted.
In this sense it's same as what microsoft is trying to do with Blazor - except they are skipping whole javascript crap and compile to wasm.
Which sounds great until you experience the loading times. Last time I tried it out, the loading times for all the DLLs that a typical application requires was pretty bad. But once it loaded, things were snappy.
I just tried this Blazor demo and its really slow on mobile, even after the noticeable load screen https://www.blazorfluentui.net/calendarPage
Clicking on multiple dates takes time to transition between the two.
Re: Reactive Clojure: A web language
#147Interesting 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?
Re: Reactive Clojure: A web language
#148This is exactly what I've been thinking of lately. I started web development in 1998 and in 2000 I got searching for some way to store data. At first I tried Macromedia Coldfusion, later acquired by Adobe. Now that I checked on it, it seems to be going strong, to my surprise. It was too hard for me. And it was closed software. There was no way for me to learn it without spending money on it. And it wasn't what I was…
Clojure (and Lisps in general) really aren't hard to learn. It just takes those of us that come from C-influenced languages like PHP a little longer to be able to read them at a glance because the syntax is slightly different and usually simpler. Once that lightbulb of the power of a Lisp goes off, there's no turning back. As Eric S. Raymond said, "Lisp is worth learning for the profound enlightenment experience you…
The best tip I ever got for reading Clojure was to ignore the parens and look at the indentation.
Re: Reactive Clojure: A web language
#149"Photon will likely be technical alpha for all of 2022 or longer". Wake me up in a couple of years then.
Re: Reactive Clojure: A web language
#150Earlier quoted context omitted.
> runtime state > code Some overlap, but these are essentially two different things. > What's to stop a malicious client from broadcasting code that deletes my entire database? Your backend.
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))))))
It's the same system you'd use in normal server/client architecture, just inlined.