I do it and know of other teams also doing it it's the sort of thing that may look ugly from the outside, but once you just try it one sees only a useful, clean pattern that's not even particularly verbose (I'm a fan of implementing protocols via metadata; this also kills some code-reloading issues)

Interestingly, protocols can be considered to reify side-effects (or "side-causes"), yielding a functional (-ish) architecture

Hi. Didn’t quite get this part: protocols can be considered to reify side-effects (or “side-causes”), yielding a functional (-ish) architecture.

under vanilla clojure, if you want to perform a side-effect, you normally just do it, inline: (write-to-db! ...) such calls make a given defn impure. There's no automated way to analyse impure functions, instrument them, etc by having protocols to perform all side-effects, you can get a comprehensive listing all sorts of side-effects/side-causes going on in your codebase. It's easier to determine if a given defn is impure: if it receives an object that implements a protocol as an argument, then it's almost certainly impure there are various other gains as you can imagine: swapping implementations (for making tests faster/deterministic) etc

(let [x (delay
          (Thread/sleep 1000))
      start (System/currentTimeMillis)
      diff! #(- (System/currentTimeMillis)
               start)]
  (prn [:before (realized? x) (diff!)])
  (future
    @x
    (prn [:after-deref (realized? x) (diff!)]))
  (Thread/sleep 100)
  (prn [:after-start-deref (realized? x) (diff!)]))
[:before false 0]
[:after-start-deref true 1001]
[:after-deref true 1001]
=> nil

I think there’s an IPending or something similar that gets involved with this

https://ask.clojure.org/index.php/10004/calling-realized-delay-currently-executing-blocks-caller

in the queue for 1.11

I had a similar case when implementing a web service API where I needed java classes with lots of annotations (and no args constructors, mutable fields with setters,…) to generate the WSDL. In the end I decided to just define the classes as plain Java code, instead of constructing them by gen-class etal.

Have you tried using defrecord? It supports Annotations I believe. Some Java APIs need a default constructor though and in that case gen-class is all I've come up with when I needed it.

I also tried defrecord but could not make it work

I'm not a JAVA guy and I just briefly know what a "POJO" is, but i thikn that these links can help https://github.com/clojure/java.data https://clojure.org/reference/datatypes#_java_annotation_support

Vectors are associative collections, so just (assoc v 17 x).

Oh, sorry, I missed the "every" word. Then just mapv.

Thanks! I tried to understand it but I don't see how that would be done (I'm still a beginner, sorry...) And wouldn't that still require iterating over the entire vector?

A possible way using transients. This multiplies each 3rd element by 10

(let [data [1 2 3 4 5 6 7 8 9 10]
        step 3]
    (persistent!
     (reduce
      (fn [data i]
        (assoc! data i
                (* (get data i) 10)))
      (transient data)
      (range 0 (count data) step))))
  ;; [10 2 3 40 5 6 70 8 9 100]

Ah but if you’re beginner there’s also the more straight-forward way without using transients:

(let [data [1 2 3 4 5 6 7 8 9 10]
        step 3]
    (reduce
     (fn [data i]
       (assoc data i
              (* (get data i) 10)))
     data
     (range 0 (count data) step)))
  ;; [10 2 3 40 5 6 70 8 9 100]

Thank you! Do you know if this offers better performance than the solution Alex gave? I'll paste it here:

(loop [coll v, i 0]
  (if (< i (count v))
    (recur (assoc coll i (inc (nth coll i))) (+ i 10))
    coll))

it should be faster, yes I didn’t see the (+ i 10), it’s pretty much the same written differently

but only marginally so?

The transient version however should be noticeable faster. You could also add transients to Alex solution though

Here’s the official guide if you’re interested in performance: https://clojure.org/reference/transients

mapv uses transients by itself. Don't try to optimize without measuring and at places that aren't bottlenecks.

Fair point, but mapv would still have to loop over every item, which can be very bad depending on how big is the nth

Ahh, right, I see - you have created a transient from the already existing data. Makes sense, and I'm especially blind today for some reason.

Since vector is associative you can use update as well with an index as second argument:

(update [0 0 0 0 0] 2 inc)
;; => [0 0 1 0 0]

Ah I see there’s no transient version update!, that’s why above used assoc

Indeed, for the non-transient version update is better

Bear in mind that by default it shows on-CPU time - if you are interested in wall clock time there’s another option for it

> It doesn't exist yet

you mentioned Ripley, I wrote about that a year ago https://dev.solita.fi/2020/06/01/rethinking-the-frontend.html I took the approach of server side apps that are enhanced with live components… you can probably get even better patch granularity and smaller websocket traffic with full “vdom on the backend”

but I find that sending html fragments is good enough, tho I don’t have any real world benchmarks to give

and of course, I didn’t even try to solve the “no server” scenario

Late to the party, but I've found the two articles linked above very engaging reading, thanks! I'm wondering whether your thoughts, @U11SJ6Q0K and @U050CJFRU, have evolved further? Have you found more downsides? Being unable to work offline (a hard problem either way) notwithstanding, it is the latency that is most worrying me (as somebody looking to build, say, a Notion-like UI): > Some applications require very rich interactions and those will benefit most from executing logic directly on the browser. But given that the average https://humanbenchmark.com/tests/reactiontime is over 200 milliseconds there’s plenty of time for a server round trip in most cases. Perhaps a rich text editor component will need browser side components still but common CRUD applications with tabular listings and forms are no problem. Though: > The average [localhost] latency out of over 10,000 requests was ~0.23ms. That's 4347 updates/second (`1000/0.23 ~ 4347.82`). This 0.23ms is especially negligible when processing and UI are not on the same thread (hi SPAs!). > This will greatly depend on your internet connection. On my phone, a roundtrip took 19ms, on desktop over wifi 12ms. I'm having a hard time reconciling the app being UI-heavy but also having a complex data model (meaning that a lot of the decisions about the state of the UI have to be deferred to the JVM db – so the SPA optimistic update approach can only work sometimes). (@U899JBRPF might be interested in the discussion.)

for the kinds of apps I do, it hasn’t been a problem at all

for example in a query view, an SPA will need to send a query, wait for results, read JSON, involve client side logic to update app db and then render… live components are a good replacement

the photon demos look particularly impressive

Completely agree (Ripley, too!). I can't escape the feeling, though, that for a UI-heavy app one might end up needing a bunch of client-side state and logic, and then the question becomes how does that blend with the 'server-first' model. You are saying, though, that my feeling is wrong for some kinds of apps.

I’ll concede that ripley doesn’t have a good story for how to blend large scale JS parts with the server side rendering, though I have some ideas on it

Something like inertiajs has a sort of middle ground approach, the components are made in SPA style, but server is still mostly in control

@U02E9K53C9L glad you enjoyed the article! The article addresses your concern re: offline use: > A Jive app combines all of the above into an architecture that treats the browser as a dumb view layer while moving all app logic and computation to a preferably local but optionally remote backend. It shouldn’t be hard to convince power users to install a local backend. This could be minimally represented in the OS menu bar (MacOS) with an icon and do little more that imply that it’s running and communicate whether it’s up to date with the remote server. The frontend would default to this backend and otherwise fallback to a remote backend. At this point I’m most excited about #hyperfiddle’s photon because it’s compatible w/ the ideas of JIVE but far more expressive.

I’ve since taken a less ambitious approach in building https://yam.wiki/. There’s no sync’d virtual dom. Components simply issue http requests and store some results in global state. The frontend is overall dumb. UI code is < 1000 LoC. The backend runs queries over datasets that would blow up any frontend in-memory DB and it’s fast.

Thanks for continuing the discussion! I didn't specify what I mean by "working offline", so this might be causing confusion 🙂 I guess I'm thinking of "offline-first". Some thoughts on that: • If you're running just the local backend, how simple exposing it to the Internet (or P2P) is? And still have to deal with unreliable network. (What I meant by "hard problem".) • If you're assuming that there is always local + remote, the users need to handle the remote server? Doable, but might be asking too much from users? (That's assuming the user controls the remote, perhaps you're thinking the company would provide that as a service?) • If local server runs on JVM, it is my understanding this is not really feasible on mobile devices? So, you have to fall back to remote and you're back to dealing with unreliable network. Being able to work offline on desktops/laptops is certainly a very good start for me, though 🙂

> If you’re running just the local backend, how simple exposing it to the Internet (or P2P) is? And still have to deal with unreliable network. (What I meant by “hard problem”.) Sure, every app, native or not has this problem if if needs to talk to the internet. The benefit of the local backend is multiple cores, persistent disk storage, polyglot languages etc. > If you’re assuming that there is always local + remote, the users need to handle the remote server? Doable, but might be asking too much from users? (That’s assuming the user controls the remote, perhaps you’re thinking the company would provide that as a service?) The latter, that a company would provide a sync service. AFAIK logseq is going to ship something like it soon. Obsidian.md also charges for sync last I checked. > If local server runs on JVM, it is my understanding this is not really feasible on mobile devices? So, you have to fall back to remote and you’re back to dealing with unreliable network. Don’t forget about graalVM. there are already a few durable databases (e.g. datalevin) and http servers that can be compiled with graal (and looking at babashka, a good chunk of the mainstream clojure ecosystem). I did some research a while ago and it seems some people packaged graal native executables in mobile apps. a few unknowns there for sure

> I’ve since taken a less ambitious approach in building https://yam.wiki/. There’s no sync’d virtual dom. Components simply issue http requests and store some results in global state. The frontend is overall dumb. UI code is < 1000 LoC @U050CJFRU can you comment on why you've taken this approach?

Sure. After writing the article @U09K620SG (hyperfiddle/photon) reached out. JIVE is a puddle jump compared to the leap of photon. So I decided to make my UI as dumb as possible with the expectation that I can throw all of it away and rewrite using photon

yeah ok. two things: 1) the SCI interpreter is using reflection at runtime to perform interop calls (this can be optimized more, but that's how it works currently) 2) Graal native binaries support reflection configs. This makes it possible to reflect at runtime like you would in the JVM. But if you don't provide a config for class X let's say, and you wanted to call Object.notify on an instance of X, you would reflect on the class X, but find nothing. However, when you visit the superclass, e.g. Object, and you had a reflection config for Object, then you would still find notify and would be able to call it. This is more work than you would normally have to do on the JVM in the clojure.lang.Reflector. Depending on which class you hit, you would hit that path or not, so I would have to do some benchmarking etc to see how bad the overhead is there, but that's where I'm coming from.

Solved part 2

ok, thanks