Fork me on GitHub

What's the datastructure for efficiently getting a subvec of a vector, without holding onto the parent?


I think subvec prevents the parent from being GCd


i'm surprised by that


yeah, I remember there was some custom datastructure ( that allowed you to do subvecs that didn't share the parent


from core.rrb: > The main API entry points are clojure.core.rrb-vector/catvec, performing vector concatenation, and clojure.core.rrb-vector/subvec, which produces a new vector containing the appropriate subrange of the input vector (in contrast to clojure.core/subvec, which returns a view on the input vector


Hmm, with the risk of being what s.o. would call an "opinion based" question...I'll ask anyway: for a small team proficient in clojure but not in clojurescript and with an aim to build large scale, complex SPAs, what would be some of the arguments for/against reagent/re-frame vs om (next)?


I welcome personal opinion, just looking for some possible arguments to get a feel for the lay of the land


In my opinion / experience - reagent doesn't give you everything you need for a complex app, so you'll often end up building more architecture bits yourself, and may end up inventing / reinventing a lot, om next seems very powerful, fast and pioneering and is what I wanted to use but I struggled with how to structure an app well, because when I looked at it there wasn't as much in the way of documentation and community help. Similarly you'll end up inventing a lot unless you use fulcro or something which provides a set of defaults. Re-frame I'm very happy with - combined with a few of the community libraries, like the http-fx and async-flow-fx. It's not perfect but seems to me to occupy a nice space in the middle of being conceptually easy enough to grasp while still allowing complex apps


There's also rum (and scrum/citrus) which I'd consider but have never tried. It looks like Rum has a pretty good server side rendering story.


I've also seen untangled, fulcro, quiescent, etc mentioned. I have to say, coming in cold to this eco system is non-trivial


untangled is the same as fulcro


it got renamed when the writer left the company because the company technically owned the brand name


fulcro is like om next with more batteries included


I think @wilkerlucio has done some work on making om next parsers easier to write, too (pathom library) - again that wasn't around when I was looking into using om next, and I stumbled at my first hurdle of trying to make a placeholder component that was part of the visual tree but not the data/logical tree


I thought rum occupied a "smaller space". As in tried to solve a smaller problem, not get involved in some things like data storage etc...but perhaps that's part of my eco-system-shock of trying to grok the landscape


some more points, as i see it (take my comments about re-frame with a pinch of salt, i have very little experience with it): - om next manages both the client and server interactions, which re-frame (as far as i know) does not - om next is simpler (it is more structured, and aims to keep incidental complexity low), whereas re-frame is easier (it gives you a set of well-defined tools, and then leaves how you fit them together to you, and so does not save you from incidental complexity in that regard) - you can see some other arguments here:, - i also highly recommend reading through


@mbjarland I've seen some big re-frame codebases, they tend to go bad after a while, the major issue I see is that if you not using a graph api, you end up having a huge amount of code dedicated to make REST calls, coordinate those calls, chain those calls (this is the worst, unless you are VERY careful, this can make your code complicated to understand), and adapt those to the database. the load story on Fulcro is much easier, the graph can move all this hard parts to the server, and you communication is the graph, I found this to work much better when you are trying to scale up a complex SPA, in fact we are just doing this transition at work because the re-frame app is very hard to maintain


fulcro/ has a steeper learning curve indeed, but the results pay off big imo


And to add another opinion: I'd choose Rum+Datascript in a heartbeat again. Hands down the best tool IMO. And I did use the other frameworks ( / {fulcro}).


and this is one of the reasons I really like the clojure community...thank you @danieleneal, @sundarj, @wilkerlucio, @rauh for the answers...some of the higher level aspects are really hard to get a feel for without making the mistakes and going through the pain of rewrites etc yourself


I agree. It's a tough time at the beginning of a project. So many decisions


That's after a large SPA of ~25k LOC CLJS and a datascript schema of about 100 attributes.


Thanks from my part as well; I’m at the stage of encountering a new name every hour as I try to understand the ClojureScript ecosystem…


I think I’m done with REST endpoints; even for a CRUD app, the moment I’m asked to have some kind of auditing and version history, everything breaks down. I was attracted to the Clojure platform in the hopes that new solutions would appear that re-think the approaches…


@sundarj The CircleCI blog post is really enlightening, thanks.


I see Om.Next latest release is 1.0.0-beta1 — is that considered stable enough to try out?


i would say so, there are plenty of people using it in prod (such as CircleCI):


(Please point me to another room if there is a more relevant one)


there are #om and #fulcro rooms


as a continuation on my last question: what about react native from clojurescript? I saw Srihari Sriraman's excellent presentation ( and was intrigued. I believe he is using re-frame, but I have a gap in my understanding of how / fulcro / reagent / re-frame would work for building react native apps....


@mbjarland i don't have any experience with this myself, but i think people use


I think the question wouldn't change that much. I use reframe with react native, with almost no modification, but om next is also possible. has slightly nicer interop with plain js classes than reagent. I use expo rather than re-natal ( because it means the whole xcode bit is circumvented, making development easier at the cost of not allowing using native libraries . The main problem with cljs on react native, I find, esp with e.g. figwheel is there are a lot of layers going on (sometimes with hacks and workarounds) and debugging can be difficult.


@danieleneal thanks...and I'll add expo to my growing list of things to look into, looks promising


yeah, kinda how I'm feeling right now...though that stack does not look nearly large enough


we always talk about cognitive limits on modeling and digesting our code base, but we don't do the same much with UI for the mercy of user. If we argue against a monolithic application, why we don't see the same with SPA? For a "complex" system, if we put "everything" as a conceptual whole for user to digest, how useful do you think is the application for the user? I think we've taken SPA too far. As with the argument for microservices, we need micro-SPA on UI as a whole, where each SAP itself is independent of each, sharing same root with the "big atom" with independent "context". The best showcase of a bad SPA is facebook on mobile.


Hi all: I've been experimenting with the module code splitting feature of the cljs compiler, and I can get the basic example outlined in the cljs docs to work: However, when I try to pass (react synthetic) dom events as context to cljs.loader/load callback fn, the properties in the event objects somehow go to nil. I'm trying to figure out if this is a bug, or if I'm missing something conceptually. Here's a small gist with the relevant code: (I have a small demo reagent repo, which I could publish in full if that would be more helpful)


@zalky (.persist ev) just before your call (loader/load ...) should fix it, no?


@rauh: thanks, that was very helpful. It helped me see that even if the event persists, referring to it in the callback is not concurrency safe.


Ran into Clojurescript js/location shadowing again today so decided to write a quick gist:


Would it be a mitigation of this surprising effect to exclude "location", "document" and "window" as names for JS vars to correspond to let bindings? (let [window :...]) would expand to var window_ = ...; or something like that instead.

souenzzo14:10:37 Now that cljs resolve clojure.spec as cljs.spec, this issue will be solved just with clj -> cljc


@pesterhazy ?