[Nihilartikel]

So, I've only used react indirectly via Clojurescript and https://github.com/tonsky/rum for a personal project... I don't spend much time in the front-end otherwise, but every time I read something about using React from JS as one would regularly it feels much, much more complicated. I.e. I just write functions that return hiccup-html lists, and @decorate a cursor into my immutable state structure for reactive updates, and that's pretty much all there is to it, apart from a few event handlers and decorations to do special DOM pre/post wrangling for odd cases.

Could someone having experience with Rum or other Clojurescript React bindings, but a better understanding of React coming from more JS like languages chime in with their experience?

[maga_2020]

I do not have experience with clojurescript or Om. However, I very frequently switch between React-Native-Web, React-Native & Android SDKs.

In my view, React team actually -- discovered a paradigm that's really good and workable.

In comparasing Android SDK UI work -- feels like it was 'invented' rather than discovered.

Too much difficult to follow indirections and wrong abstraction.

When I program direct Android, I find myself introducing React concepts. Most of my Presenters and Views now have CMyState class and its one instance.

I have setState_XYZ, and clear_State associated with that state. I cary in that state backend pagination hints, etc (as an example).

And I use RxJava (in Android) to emulate eventing model of Clicks/Mounts/Dismounts (eg when android screen rotates).

All in all, again, it does seem that React developers (not sure who the credit should go to, Peter Hunt, many others ?) -- discovered an a abstraction that was always there, but was not easily crystalized through other frameworks.

And now it is. I would be happy if others would just emulate it and make it working across UI programming platforms. It supersedes in my mind anything else that I had seen in last 25 years, in this space.

[scns]

I think the credit should go to Jordan Walke who first wrote React in Standard ML

[drcode]

Certainly, clojurescript makes it possible to do productive React development without having to resort to JSX for syntactic sugar- This comes from the "create your own language" nature of lisp languages, which is leveraged by the many different frameworks to easily generate DOM elements in a natural way. (This also makes it easy to implement graph query languages BTW that are more elegant IMHO than graphQL.)

Another big payoff with clojurescript IMHO is the use of async channels and go blocks in lieu of promises to handle asynchronous operations- It's nice to have what is essentially a form of cooperative multithreading right inside your client javascript code, without the need for web workers.

[e12e]

I'm just getting my feet wet with react - but my impression from various blog posts and a bit of coding - is that in the beginning there was reasonml (ocaml dialect - mostly (but not only) targeting compilation to js target) - and react sort of "fell out" as a set of patterns/framework from doing functional programming of dom/gui/state.

And react for js, ("react") is those patterns + patterns for js to make everything (sort of) work without as solid a language to steer one away from various cliffs.

Which is one reason why I don't quite understand why there are class based components at all.

At any rate - my current goal is to try some reasonml+react - and I think it'll feel better. And I'm not surprised cs+react feels more sane than js+react.

[larzang]

> Which is one reason why I don't quite understand why there are class based components at all.

Classes in js are just syntax sugar, so even if you're writing classes you're still actually writing function prototypes. As such there's little reason not to support them, and they're very welcome when you have a team of developers that are adapting to modern js development almost exclusively from traditional OO languages.

[e12e]

Hm. I might have to have another look at the implementation of classes in js. I still don't see the benefit of the syntax - but if it really amounts to just convoluted closures over variables, I guess I'll view them with a little less grumpiness :)

[acemarke]

ReasonML is a very new language variant, and wasn't part of React's original implementation.

There's a really good history at https://stackshare.io/posts/the-react-story .

[e12e]

Thank you (and @scns). I had a hunch it was (an) ml > more programmers > new programmers unfamiliar with syntax > js version and reasonml.

I didn't realize they didn't start with ocaml, but sml.

[e12e]

It's an interesting podcast, but wanders a bit, and there's no transcript. But does mention Jordan Walke who wrote the first prototype of react for Facebook ads. Jordan is currently working on reasonml:

https://github.com/jordwalke

And Pete Hunt is:

https://github.com/petehunt

I should've remembered the bit about sml - it's mentioned here after all! :

https://reasonml.github.io/docs/en/what-and-why.html

I do wonder if it'd be easier to port sml syntax to ocaml rather than make reasonml - I guess not. But it might give similar benefits: a pleasant syntax dialect for ocaml, a mature compiler for js and native, and bringing in th js and ocaml library ecosystems. [ed: but not, perhaps, 90% overlap with js syntax.]

As I mentioned - I haven't really played with reasonml/reason-react - I think maybe some of the impressions alluded to in my first comment came in part from this:

https://medium.com/@Imaginary_Cloud/reasonml-react-as-first-...

In particular sentiments like:

"When using ReasonML, we don’t need Redux anymore. ReactReason stateless components already come with the concept of a build in reducer, which is meant to take care of the problems Redux used to address."

Discussed here: https://news.ycombinator.com/item?id=17143494

As well as the introduction here:

https://github.com/reasonml-community/reductive/blob/master/...

"Reductive

A reimplementation of redux in Reason.

Word of Caution

You might not need this library, especially so in a language which provides good enough construction blocks out of the box. ReasonReact already comes with reducers!"

Also somewhat related (re: state) :

https://reasonml.github.io/reason-react/docs/en/state-action...

[scns]

React was first written in Standard ML

[always_good]

For example, you can an approximation of some ClojureScript abstractions with Javascript's MobX: a datastructure that you access as normal and it reconciles render()'s for you.

Clojure's simplicity tends to package things up nicer than most other languages, especially a readme, but it's not particularly different from what people are already doing.