I was in the audience, asking the question at the end of the video!
I didn't quite get the question across and got an answer to a different question, so to re-state my actual question (that I asked David later), I was curious how heavy a lift it would be to preserve enough information in production ClojureScript compilation to allow re-hydrating. The aim being to re-hydrate enough in production that e.g. in the event of issues or errors, you might attach a REPL to that production build and poke at it.
The answer (which I mostly knew/expected) is... quite a heavy lift. I can imagine some possible solutions, but I'm mostly-Rust nowadays, so no solution from me soon. :)
I also really recommend the other [1] talks [2] from this event!
[2]: https://youtu.be/fcSJAuUGVs8 (Ben, on a core.async error handling strategy that I had totally missed and totally changes the ergonomics of using c.a!)
Shadow-cljs offers partial solutions to this with its runtime code reloading capabilities and source-maps in production, though true REPL attachment to production builds remains challenging due to the optimization/debug information tradeoff.
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.
The thing that tipped me over the edge into learning ClojureScript was the news almost exactly a decade ago about achieving self-hosted compilation with eval [0] (kudos David!). In the end that specific capability was not quite practical enough for what I needed, but it proved a level of sophistication and maturity in the stack that has only increased since.
Today we also have sci/scittle/cherry for anyone who's seeking that runtime Clojure->JS eval vision. And now with Jank (LLVM Clojure) on the horizon this year it's never been a better time to try Clojure, regardless of which hosted runtime you're enthusiastic to use - Basilisp on Python, ClojureCLR, ClojureDart etc.
It's rare I have to do anything client side, but I'm so grateful for Clojurescript when I do. I used to dread native Javascript and the crazy tooling, but Clojurescript makes building client side functionality an absolute joy. It's just a shame it's not all that popular
The way he shows off his REPL in VS code that controls the browser just reminds me how absurd this workflow of constantly switching between the browser and the IDE is, and it's even more absurd since VS code is an electron app, so you're really switching between chrome and chrome.
Right? I'm waiting for that vscode with a browser built in to making crud apps a bit easier. Not yet another stochastic parrot which adds nothing to the heap.
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.
> 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).
Oh, but we do this in ClojureScript the whole time.
You can express events and actions in pure functions as data and then take care of the effects outside of the core of your application.
A great example of how to do this is the "re-frame" framework [1] [2]. The documentation is also a joy to read.
> 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?
There's many ways to find that out in Clojure/Script. There's the built-in `tap>` function [3] which can be used for debugging. You can use that to visualize complex data with Portal. [4]
Most of us (developers using ClojureScript) are using React or similar "view-as-a-function" libraries, where the UI is essentially built from pure(-ish) functions.
I'm using the REPL as effectively with ClojureScript + Reagent as I would with any Clojure program. The only thing that matters is how you structure your application, and it's certainly possible to iteratively develop frontend applications with ClojureScript just like what we do with Clojure.
UI is not just DOM it is also network connections, events from the user, and local state. React only datafies the DOM orchestration. The UI=f(state) composition model fails at all of these points, most vividly at the network boundary, but does not include answers for the other domains I listed as well.
Right, but when actually working on UIs, do you need to replay the actual side-effects of those things, or just whatever happened before/after of that?
Personally I split those things up into two parts, and only iterate on the UI with "static data" that either exists before, during or after. So testing/iterating on things like "Click button, loading animation plays while network request is in flight, show success/failure" is essentially 4-5 "static" states, and you don't really have to care about what happens in-between much except for corner-cases.
in my opinion it is the events and state transitions that are where everything interesting and challenging happens, like server IO in mount/unmount/didUpdate lifecycle methods or event callbacks. For example, a typeahead component. You focus the input and start typing. The picklist unfolds and loads records from the server, we need to stream subsequent keystrokes to the server into the query for server filtering, we need to maintain the DOM gracefully as the query changes stream in, we need virtual scroll if the collection is large, the user then uses the arrow keys to select an item in the picklist and presses enter to submit, closing the picklist and returning the selection to the caller. It is a living, reactive process. Now "use the REPL" to get, like, any value at all?
A one way to address that is via tooling (e.g. to visualize state across time) but maybe there’s something more fundamental to be solved here? Or is it more about current tooling capabilities?
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.
This is such a good intro to clojurescript in general. I’ve dabbled in clojure for a few months, and CLJS seems really cool but also really confusing to get into. It’s got a whole ecosystem to itself.
Now I’m SUPER excited to try cljs!! It’s crazy how modern it is despite being kinda old in webdev terms
Early cljs/react adopter here. Found "the next react" in Hyperfiddle's Electric Clojure — it eliminates the client/server boundary entirely. Write one function that spans both sites, compiler handles the network automatically. The amount of plumbing code that just disappears is staggering.
As someone who rarely does front-end but occasionally needs to hack something together, ClojureScript is a godsend. I get to hijack the react ecosystem for nice UI components while also getting to use a pleasant language and avoiding JSX (I hate anything XML-y).
We forked Google Closure Library. This is mostly a good thing as GCL started introducing frustrating breaking changes around 2018/2019. We've backed everything out and now ClojureScript libraries from 14 years ago work again.
I was in the audience, asking the question at the end of the video!
I didn't quite get the question across and got an answer to a different question, so to re-state my actual question (that I asked David later), I was curious how heavy a lift it would be to preserve enough information in production ClojureScript compilation to allow re-hydrating. The aim being to re-hydrate enough in production that e.g. in the event of issues or errors, you might attach a REPL to that production build and poke at it.
The answer (which I mostly knew/expected) is... quite a heavy lift. I can imagine some possible solutions, but I'm mostly-Rust nowadays, so no solution from me soon. :)
I also really recommend the other [1] talks [2] from this event!
[1]: https://youtu.be/8K4IdE89IRA (Aaron, on using lenses, this sorta stuff [3])
[2]: https://youtu.be/fcSJAuUGVs8 (Ben, on a core.async error handling strategy that I had totally missed and totally changes the ergonomics of using c.a!)
[3]: https://github.com/tekacs/factor/blob/master/src/factor/lens...
Shadow-cljs offers partial solutions to this with its runtime code reloading capabilities and source-maps in production, though true REPL attachment to production builds remains challenging due to the optimization/debug information tradeoff.
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.
What do you mean by re-hydrate?
https://en.wikipedia.org/wiki/Hydration_(web_development)
The thing that tipped me over the edge into learning ClojureScript was the news almost exactly a decade ago about achieving self-hosted compilation with eval [0] (kudos David!). In the end that specific capability was not quite practical enough for what I needed, but it proved a level of sophistication and maturity in the stack that has only increased since.
Today we also have sci/scittle/cherry for anyone who's seeking that runtime Clojure->JS eval vision. And now with Jank (LLVM Clojure) on the horizon this year it's never been a better time to try Clojure, regardless of which hosted runtime you're enthusiastic to use - Basilisp on Python, ClojureCLR, ClojureDart etc.
[0] https://swannodette.github.io/2015/07/29/clojurescript-17/
It's rare I have to do anything client side, but I'm so grateful for Clojurescript when I do. I used to dread native Javascript and the crazy tooling, but Clojurescript makes building client side functionality an absolute joy. It's just a shame it's not all that popular
The way he shows off his REPL in VS code that controls the browser just reminds me how absurd this workflow of constantly switching between the browser and the IDE is, and it's even more absurd since VS code is an electron app, so you're really switching between chrome and chrome.
That's IntelliJ with Cursive
For whoever needs to know: you can get almost the same in vscode/cursor with Calva. Quite a nice piece of work!
Right? I'm waiting for that vscode with a browser built in to making crud apps a bit easier. Not yet another stochastic parrot which adds nothing to the heap.
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.
> 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).
Oh, but we do this in ClojureScript the whole time.
You can express events and actions in pure functions as data and then take care of the effects outside of the core of your application.
A great example of how to do this is the "re-frame" framework [1] [2]. The documentation is also a joy to read.
> 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?
There's many ways to find that out in Clojure/Script. There's the built-in `tap>` function [3] which can be used for debugging. You can use that to visualize complex data with Portal. [4]
[1] The framework: https://github.com/day8/re-frame[2] A library with HTTP-Effects for your re-frame applications: https://github.com/Day8/re-frame-http-fx
[3] https://clojuredocs.org/clojure.core/tap%3E
[4] https://github.com/djblue/portal
> But UIs are not pure functions
Most of us (developers using ClojureScript) are using React or similar "view-as-a-function" libraries, where the UI is essentially built from pure(-ish) functions.
I'm using the REPL as effectively with ClojureScript + Reagent as I would with any Clojure program. The only thing that matters is how you structure your application, and it's certainly possible to iteratively develop frontend applications with ClojureScript just like what we do with Clojure.
UI is not just DOM it is also network connections, events from the user, and local state. React only datafies the DOM orchestration. The UI=f(state) composition model fails at all of these points, most vividly at the network boundary, but does not include answers for the other domains I listed as well.
Right, but when actually working on UIs, do you need to replay the actual side-effects of those things, or just whatever happened before/after of that?
Personally I split those things up into two parts, and only iterate on the UI with "static data" that either exists before, during or after. So testing/iterating on things like "Click button, loading animation plays while network request is in flight, show success/failure" is essentially 4-5 "static" states, and you don't really have to care about what happens in-between much except for corner-cases.
in my opinion it is the events and state transitions that are where everything interesting and challenging happens, like server IO in mount/unmount/didUpdate lifecycle methods or event callbacks. For example, a typeahead component. You focus the input and start typing. The picklist unfolds and loads records from the server, we need to stream subsequent keystrokes to the server into the query for server filtering, we need to maintain the DOM gracefully as the query changes stream in, we need virtual scroll if the collection is large, the user then uses the arrow keys to select an item in the picklist and presses enter to submit, closing the picklist and returning the selection to the caller. It is a living, reactive process. Now "use the REPL" to get, like, any value at all?
what great answers could look like here?
A one way to address that is via tooling (e.g. to visualize state across time) but maybe there’s something more fundamental to be solved here? Or is it more about current tooling capabilities?
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.
Vscode already has js debugging
This is such a good intro to clojurescript in general. I’ve dabbled in clojure for a few months, and CLJS seems really cool but also really confusing to get into. It’s got a whole ecosystem to itself.
Now I’m SUPER excited to try cljs!! It’s crazy how modern it is despite being kinda old in webdev terms
Early cljs/react adopter here. Found "the next react" in Hyperfiddle's Electric Clojure — it eliminates the client/server boundary entirely. Write one function that spans both sites, compiler handles the network automatically. The amount of plumbing code that just disappears is staggering.
As someone who rarely does front-end but occasionally needs to hack something together, ClojureScript is a godsend. I get to hijack the react ecosystem for nice UI components while also getting to use a pleasant language and avoiding JSX (I hate anything XML-y).
Thanks, I was just looking for ClojureScript material!
Deffinitly cool, I am sold (100 years later...)
isn't google closure sunset ?
The [Closure Compiler](https://github.com/google/closure-compiler) is still active.
The [Closure Library](https://github.com/google/closure-library) is done.
Very confusing, I know
ClojureScript still uses both? If so, what is going to replace the Closure library?
We forked Google Closure Library. This is mostly a good thing as GCL started introducing frustrating breaking changes around 2018/2019. We've backed everything out and now ClojureScript libraries from 14 years ago work again.
yup, correct https://clojurescript.org/news/2024-01-24-release#_google_cl...