ClojureScript from First Principles [video]

https://www.youtube.com/watch?v=An-ImWVppNQ

by puredanger • 1 year ago

124 30 1 year ago

youtube.com

cjohnson318• 1 year ago

Thanks, I was just looking for ClojureScript material!

tekacs• 1 year ago

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...

billfruit• 1 year ago

What do you mean by re-hydrate?

geokon• 1 year ago

https://en.wikipedia.org/wiki/Hydration_(web_development)

ethan_smith• 1 year ago

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.

diggan4• 1 year ago

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.

chamomeal• 1 year ago

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

ingen0s• 1 year ago

Deffinitly cool, I am sold (100 years later...)

amadeuspagel• 1 year ago

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.

fud101• 1 year ago

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.

diggan4• 1 year ago

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.

dustingetz3• 1 year ago

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.

akkad33• 1 year ago

Vscode already has js debugging

kgwxd• 1 year ago

That's IntelliJ with Cursive

ndr• 1 year ago

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

dzonga• 1 year ago

isn't google closure sunset ?

myko• 1 year ago

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

travisennis• 1 year ago

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

mannycalavera42• 1 year ago

yup, correct https://clojurescript.org/news/2024-01-24-release#_google_cl...

refset• 1 year ago

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/

drdunce• 1 year ago

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

yayitswei• 1 year ago

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.

throwaway0123_5• 1 year ago

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).

ClojureScript from First Principles [video]

Related Stories