I'm not sure what "REPL attachment to production build" would look like in terms of a client-side program like this?

Usually what I do in my ClojureScript programs is saving all the actions the user do into localStorage, offer a "Report Issue" button that shows a form with a description input, and submitting that form also submits the data from localStorage. Sometimes I also include the full app-state in there too, but often isn't even needed if the application is simple enough.

If you're using libraries like re-frame or similar, you basically get that for free, just need to persist the events somehow and associate them with a session/user.

So replicating issues that happened in the production build is a matter of replaying those same actions locally. Don't remember having any issues with this approach, and if you end up in the scenario where the same actions only trigger an error in the production build, then run that build locally but with sourcemaps and you'll be able to track down the issue quickly enough.

Back in 2016 (holy shit, ~ten years ago?!) when Atom was the editor of choice, I built a small extension that let you preview and interact with React components inside of the editor: https://github.com/victorb/atom-react-preview

I don't use Atom or Visual Studio Code today, nor much JavaScript, and my most-used language kind of gives me this for free nowadays (ClojureScript) but I expected there would be entire businesses today offering the functionality I built back in 2016, but as a all-in-one package with even more bells and whistles. There is so much we could do to make the experience better.

It seems to me like "interactive development" is just a thing for some section of programmers. Personally I couldn't live without my repl-connected editor, but judging by the amount of people who live and swear by the "edit -> compile -> view -> repeat" loop they spend all day doing, it seems like not everyone is wired the same.

a problem with a repl-centric approach to crud apps is that the repl is not reactive. It is a good fit for request/response pure function backend programming. But UIs are not pure functions, they have a deeply effectful nature, and being reactive all those effects are highly “situated” if you will (to use Rich Hickey’s word). IMO this is a severe impedance mismatch at the core of Clojure’s design. We simultaneously want to write small functions that can be explored in the REPL and we also want to write in-situ functions with complex dependencies in scope. ClojureScript users are running in circles for a decade trying to turn the latter into the former to make the REPL work again but it’s a mirage, the REPL is just not a fit for a deeply situated problem domain. An example of this impedance surfacing in backend programming is a nontrivial map/reduce pipeline. What is the shape of the document at stage six? How do I manifest one to play at the REPL? Clojure doesn’t have great answers to this.

    (defn inspect
      [coll]
      (doto coll tap>))
    
    (->> coll
         (map this)
         (inspect)
         (filter that))

Vscode already has js debugging

For whoever needs to know: you can get almost the same in vscode/cursor with Calva. Quite a nice piece of work!

ClojureScript still uses both? If so, what is going to replace the Closure library?