Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ClojureScript from First Principles [video]

youtube.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: ClojureScript from First Principles [video]

#11

Post by diggan »

fud101 wrote: post #9
amadeuspagel wrote: post #8

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.

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.

Re: ClojureScript from First Principles [video]

#12

Post by dustingetz »

fud101 wrote: post #9
amadeuspagel wrote: post #8

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.

Re: ClojureScript from First Principles [video]

#13

Post by diggan »

ethan_smith wrote: post #10
tekacs wrote: post #3

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…

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.

Re: ClojureScript from First Principles [video]

#14

Post by diggan »

dustingetz wrote: post #12
fud101 wrote: post #9

Earlier quoted context omitted.

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 w…

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

Re: ClojureScript from First Principles [video]

#15

Post by dustingetz »

diggan wrote: post #14
dustingetz wrote: post #12

Earlier quoted context omitted.

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 w…

> 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 front…

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.

Re: ClojureScript from First Principles [video]

#16

Post by diggan »

dustingetz wrote: post #15
diggan wrote: post #14

Earlier quoted context omitted.

> 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 front…

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.

Re: ClojureScript from First Principles [video]

#19

Post by kgwxd »

amadeuspagel wrote: post #8

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

Re: ClojureScript from First Principles [video]

#20

Post by refset »

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/

Post reply on HN