Live data from Hacker News

Re-Frame: Build web apps in ClojureScript and React

day8.github.io

31–40 of 57 posts

Re: Re-Frame: Build web apps in ClojureScript and React

#31
post #25
post #6

Earlier quoted context omitted.

Hmm. In my experience, this an unusual opinion (to me, the author). Over the years the re-frame documentation has been the most praised part of the project. Could you point out the area which you found unnecessarily difficult, and I'll happily review it. Could you also include your background, so I know where you are coming from? The docs are a little oriented towards JS developers coming across, but perhaps you are…

> In my experience, this an unusual opinion It can't be too unusual; I've seen this critique shared in forums, to which you've replied, for years. I've seen developers remark how turned off they got by reading stuff like this on its front page, which is frankly just noise and undermines the goals of a serious project: > re-frame is lucky enough to enjoy an unfair advantage...When we use Lisp, we get to leverage 50 ye…

> It can't be too unusual; I've seen this critique shared in forums, to which you've replied, for years.

In this thread, I was responding to someone saying the concepts were simple but explained with too many buzzwords. I certainly have no recollection of someone of someone saying that before.

On the other hand, I have heard some say they'd want more code examples earlier. And, just as soon as I get time I'll be doing that. Unless you want to supply a PR yourself - given your posting frequency you seem very, very invested.

Re: Re-Frame: Build web apps in ClojureScript and React

#32
post #4

Earlier quoted context omitted.

Re-frame really doesn't add much in addition to Reagent, I really don't understand its popularity.

I've run a team with re-frame and a team with reagent (and a convention of a single state atom.) Reagent by itself scaled far better. I use re-frame if it's a company convention, but I'd far rather just ditch it. Plain reagent has no unnecessary function registry; mutations are done with `(swap! my-cursor foo/update-foo bar)` rather than the extra overhead of `(dispatch [::foo/update-foo bar])`. This also helps new p…

Checking: you had a few hundred event handlers in the one namespace? That worries me.

Re: Re-Frame: Build web apps in ClojureScript and React

#33
post #4

Earlier quoted context omitted.

Re-frame really doesn't add much in addition to Reagent, I really don't understand its popularity.

I've run a team with re-frame and a team with reagent (and a convention of a single state atom.) Reagent by itself scaled far better. I use re-frame if it's a company convention, but I'd far rather just ditch it. Plain reagent has no unnecessary function registry; mutations are done with `(swap! my-cursor foo/update-foo bar)` rather than the extra overhead of `(dispatch [::foo/update-foo bar])`. This also helps new p…

Yep, pretty large & business critical app. BTW, while I'm not sold on re-frame personally, it is used in a sizable project that has powered a lot of business for us, so thank you for developing it!

Re: Re-Frame: Build web apps in ClojureScript and React

#34
post #6

Earlier quoted context omitted.

Hmm. In my experience, this an unusual opinion (to me, the author). Over the years the re-frame documentation has been the most praised part of the project. Could you point out the area which you found unnecessarily difficult, and I'll happily review it. Could you also include your background, so I know where you are coming from? The docs are a little oriented towards JS developers coming across, but perhaps you are…

I'm a react developer and I immediately wanted to see code examples. I looked through the docs and couldn't easily find any. I went to the API docs on mobile and was met with layout issues (iphone 11 on Chrome).

If those code examples were in an unfamiliar language (ClojureScript), would they still be useful? I've been under the impression that the concepts would have been a more helpful in that case.

Re: Re-Frame: Build web apps in ClojureScript and React

#35
post #4

Earlier quoted context omitted.

Re-frame really doesn't add much in addition to Reagent, I really don't understand its popularity.

I've run a team with re-frame and a team with reagent (and a convention of a single state atom.) Reagent by itself scaled far better. I use re-frame if it's a company convention, but I'd far rather just ditch it. Plain reagent has no unnecessary function registry; mutations are done with `(swap! my-cursor foo/update-foo bar)` rather than the extra overhead of `(dispatch [::foo/update-foo bar])`. This also helps new p…

Three things that would make re-frame better, if you want them:

- A supported/blessed way to switch out the entire app-db entirely for the purposes of testing

- Use of symbols rather than namespaced keywords for function dispatch

- Docs that give alternate strategies for code organization (fine to have the events.cljs convention, but would be nice to see some viewpoints like having one per child ns similar to angular's code organization model.)

Re: Re-Frame: Build web apps in ClojureScript and React

#36
post #25

Earlier quoted context omitted.

> In my experience, this an unusual opinion It can't be too unusual; I've seen this critique shared in forums, to which you've replied, for years. I've seen developers remark how turned off they got by reading stuff like this on its front page, which is frankly just noise and undermines the goals of a serious project: > re-frame is lucky enough to enjoy an unfair advantage...When we use Lisp, we get to leverage 50 ye…

> I've seen developers remark how turned off they got by reading stuff like this on its front page, which is frankly just noise and undermines the goals of a serious project: This was exactly my experience. Professional clojurescript developer using re-frame, but not typically one to chat on forums. I wouldn't have shared this opinion until prompted to by this forum, but it's an opinion I've held privately for longer…

then maybe the goal isn't to be a serious project in the context upon which you apply that classification.

Re: Re-Frame: Build web apps in ClojureScript and React

#37

Earlier quoted context omitted.

And yet I've also had people tell me the opposite - they say they liked the water cycle analogy, even more than the subsequent dominoes narrative. Hmm. Hard to know what to do about such conflicting feedback.

Very happy re-frame user here - I was pleased to see the 1.0 release recently and I like the sound of the new developments. Personally I do appreciate the amount of conceptual framing (pun intended!) contained in the re-frame docs. It's one thing to know the syntax for, say, declaring a subscription, but it's something else to know what subscriptions are for . For me, Re-frame's value-add is that it provides a bunch…

Docs on builtin effects were added last week.

http://day8.github.io/re-frame/api/

Then click "Builtin effects" in the left Nav.

I'm actually working on the API docs at the moment and wrestling with codox and markdown interaction.

Re: Re-Frame: Build web apps in ClojureScript and React

#38

Earlier quoted context omitted.

I'm a react developer and I immediately wanted to see code examples. I looked through the docs and couldn't easily find any. I went to the API docs on mobile and was met with layout issues (iphone 11 on Chrome).

If those code examples were in an unfamiliar language (ClojureScript), would they still be useful? I've been under the impression that the concepts would have been a more helpful in that case.

Definitely useful. Consider code examples just a missing leg in your table.

Re: Re-Frame: Build web apps in ClojureScript and React

#39
post #28
post #23

Earlier quoted context omitted.

Two main considerations: Does the bundle size matter? CLJS bundles are not terribly huge but if you need a very lightweight bundle you're out of luck. Vs plain JS there is just no comparison. Vs plain JS + just a few libraries CLJS will probably do worse too. But for anything bigger it starts to catch up. Say I'd never use CLJS for a landing page, but for most kinds of apps there shouldn't be a problem. How do you pl…

> Your CLJS library will not be a first class citizen in the JS world. It can be done but it's not a good idea. Why is this? What makes it a bad idea? Does ClojureScript’s new ‘bundle’ compilation target [0] help resolve whatever issues you are referring to? Genuinely curious. [0] https://clojurescript.org/news/2020-04-24-bundle-target

Any CLJS code has to bundle the CLJS runtime. CLJS doesn't compile to idiomatic JS, for example a vector will be a cljs.core/PersistentVector not a JS Array. So code for most CLJS basics has to be bundled with any CLJS code to run.

Let's say you write a tiny library that solves just one problem. I would imagine most people wouldn't want to have to pull in the CLJS runtime for just that.

So let me be clear - there is no problem in using JS libraries, what you linked speaks to using npm libraries which previously was tougher. CLJS is doing very well on that front.

What I'm saying is - if you write a library in CLJS, don't expect plain JavaScripters to use it.

Post reply on HN