Fork me on GitHub

The problem I am hitting has been captured here, but I will try with the vanilla compiler as well:


in general there’s probably no way for that to work


Yeah I feared that and thanks for confirming. For some moment I thought that it would be idempotent to require core twice.


the error seems to indicate that you’re loading core twice


and independently somehow


if that’s true the data structures won’t work


this is nothing specific to ClojureScript btw


so I’m trying to hand React a fn that I added meta-data to, and it’s throwing an Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.


(def js-interop-test
    (js/console.log props)


removing the ^:js renders “blah blah” just fine


Okay Clojurians... I need some real-world advice to make an argument to colleagues as to why we should use Clojure(Script) instead of Angular (6) for our big, non-traditional web app


Basically the closest analogy I can give is that our web app is like skype for business


and we are in greenfield territory on front and back end. Nothing legacy, we have officially stopped development on our current product (only support and very major bug fixes).


It has to be a PWA, that's the only hard requirement.


It's not a question of "can I do it in CLJS", we know we can. It's just that my colleague who is the senior FE dev (and truly, is more experienced and competent in that area) doesn't want to take the risk, and doesn't see the point. Fortunately our boss is more open-minded, but I still think it is correct to defer to the senior FE dev who will shoulder the responsibility and major work load. We are a small team, and I think Angular is logically Java, only worse because it's in framework-ese. I despise JS frameworks because they are neither imperative nor functional programming, hard to reason about, the opposite of simplicity.


it’s kind of an apples & oranges question


well I don’t know if there’s much real risk, people ship stuff with ClojureScript all the time


That's my view, David.


however, that’s different from getting buy-in from your FE engineer


"but Angular comes with a router built-in"


it’s probably best to spike something small and see if you like it


Figwheel + Reagent is a pretty good way to see what you/they think


Oh I already have and do. For me it's a no-brainer. Only sensible way to do FE work


well but I mean you need to get your FE person to give it try too 🙂


how many people on your team are already familiar with TypeScript, vs. Clojure?


We all have extensive typed language and dynamic language background. None worked with TS, nor Clojure either.


a lot of people are also sold on shadow-cljs these days because of the Node ecosystem integration


From my perspective, you get what you pay for. Steeper learning curve for Clojure, but much bigger wins.


it also does Figwheel style stuff, I haven’t tried it myself


I have tried shadow-cljs, I think it's very easy to set up.


I think that the value proposition of Angular vs. ClojureScript is very different. one is an application framework, the other is a language


choosing Angular makes decisions for you right out of the gate. there is lots of value in that


But the Angular is also a language, too, because you must use TS (and their way of using it)


so really, it’s not Angular vs CLJS.


it’s TS + Angular vs. CLJS + ???


CLJS + Reagent + Reframe, for me


why did your team consider Angular rather than React + Redux?


(we can always change to Om.Next in the future 😉 just reagent is a lot easy to grok)


Because it's a "bundle". It's the convenience argument


the false economy of nearness vs simplicity, to be frank


Reagent + Re-frame is conceptually very similar to Redux, and has a lot of the same value propositions


so you’re going to run into the same conversation of reagent + re-frame as you would suggesting React + Redux. but you’re also suggesting a new language


There is no fundamental opposition to React in our team.


The complaint my colleague has is "oh, the repo for this router (bidi) hasn't been updated in 4 years" or such-and-such tool


except bidi just works, it doesn’t need updates


pretty much


those conversations are easy to work through


just like transit-js/cljs works, I’ve had a handful of commits over the last 4 years


Not if the other person isn't actually open-minded


the JS mindset of no commits means project is dead is ugh


Our boss sees all the value of using ClojureScript, but we all agree that forcing our colleague won't work, either.


We all despise JS framework churn


Hence why we also prefer the stability of ClojureScript as a host language


another plus to cljs that is underestimated: it’s fun. developer engagement is hard to maintain and incredibly valuable.


it seems like your senior FE is advocating for adopting a framework/platform to get off the ground fast, whereas CLJS + reagent + re-frame is going to require a lot more of your devtime spent on many things Angular already has answers for. you trade speed for opening up your possible architectures


yes but my colleague is just looking for reasons to poo-poo it and we need him.


(side note: i DO wish clojure people would just bump their major version #s to 1.x if the thing is stable)

✔️ 4
💯 12

@lilactown You got it, Will. That's it exactly.


My suggestion would be to look for really concrete examples in your existing Angular codebase(s) that could be done "simpler" in clojurescript. I think its very hard to give someone a solution when they don't think they even have a problem.


It's a shame because we actually have time to do the learning necessary to adopt CLJS.


@benisrood I think it’s important to remember that in the end rational arguments alone will only get you so far

👆 12

you need some psychological buy-in


@lloydshark Unfortunately that's not possible. Our legacy FE is in very ancient Ember.JS and it's terrible. Plus, we need to do things entirely differently


@dnolen I agree. I spent the last few months getting collective agreement to our "core values" of how we want to work and what is important, precisely so we could assess tools/tech from the right standpoint


unfortunately some people don't speak up at the right time, like a man, they just keep quiet and promptly ignore that work.


is this project purely FE or are you also doing new service development?


Everything. Whole product redesign from scratch. Think Bobby's talk from the Conj in 2016 on CQRS + Event Sourcing


one of the biggest things that helped sway my team towards adopting clojure was that we could more easily share resources between FE and server-side development


whether it was developers, libraries, business logic, etc.


Yes that would be my argument, also.


also they were old crufty Java devs and there’s already a lot of material for converting those kinds of folks to Clojure 😉


Erlang a more appropriate choice for our bottom-level (think masses of call switching and tracking) and problem domain.


Clojure good choice for all the "middleware"


To me, that's really the true value proposition. A true full-stack language that doesn't suck, has correct concurrency model, is data-oriented, referential transparency, functional, etc etc


I don't care whether we use React or not. Don't give a shit. I care more about the deeper principles and developer experience.


I guess that's really the salient argument. Go with clojure in the front and middle.


react is the gateway drug to CLJS IMO 😛

👍 4

I would maybe look at some of the more fully-featured frameworks for CLJS and try and create a comparison with Angular


I’ve heard good things about Fulcro


One suggestion would be to figure out tooling and workflow. Are you going to use figwheel? The figwheel main rewrite or the older version? Lein or deps.edn. If deps how will you deploy. Will they need cursive and intellij or are you going to get them setup with emacs. Have a couple sample components made and show them how readable it can be


Indecision on which react wrapper to use could be off putting at the beginning if they are considering it


@dpsutton They'll use Atom + ProtoREPL + shadowcljs


Me personally, I can use any of the above. Don't care.


That's a great conversation, I agree rationality does not win colleagues, having the same problems here. There are a lot of things at stake, problem #1 is that the person will feel not productive for a bit, which many peopl do not like


Also tooling, while better now, still cannot, and will ever, compete to JS big projects


open-mind devs would not care of course as long as productivity is not hindered


(side note - tooling is better for browser than for node as many more folks are targeting browser)


Thanks, guys. Sadly does not want to think about anything beyond convenience as "pragmatism".


Time to look for another gig, maybe.


I don't want to program like that. It's not programming, to me. It's being an API assemblage donkey.


Thanks again for your help. Sorry for derailing channel.


one thing: maybe try to get an internal tool written in cljs. you're pushing for a homerun. but getting a base hit might open up the field for the future


I learned CLJ some years ago after accidentally coming across Simple Made Easy. Watching it, I noticed that in the abstract/philosophical, the points made in the video were more or less universally aligned with good practices in my own domain (service design). Therefore it seemed like I might learn more about my own craft if I learned the same principles in this other craft. Which turned out to be true.


I’ve been advocating CLJ/CLJS at my current job for a while, giving a few presentations and so on. Of course, how the product is being built doesn’t affect me directly. But indirectly, the technical choices made invariably comes back as impacts on the service delivery and end user experience.


It’s really, really hard to argue the logical chain between (for example) mutability and user experience and service quality.


At one point, the dev team was running out of time leading up to a release, so they decided they would have to drop a particular capability for the release. This particular thing was considered important to stakeholders, but on the other hand, the rest of the stuff in the pipeline was hygiene/basics, so it couldn’t be dropped without having no release at all.


I figured I might try my hand at some dev work, so I sat myself down and wrote the thing as a micro service in plain old Clojure. It worked fine, and made the release.


Still, no interest in Clojure. Actually, little interest in exploring new/alternative venues at all. My theory is that is fatigue from dealing with the JS ecosystem, which is constantly and perpetually new in itself.


Also, I’m the wrong person to offer the advice, probably. A designer poking their nose in dev?

Hendrik Poernama06:06:40

I personally find people who gets nervous/scared instead of curious when they first see the lisp syntax. My theory is, this pulls them a bit far from their comfort zone and most people just got scared? Also, where I live, I find many who advertise themselves as developer do relatively little original work. So, introducing something with not as many example codes online (as opposed to js) is quite challenging.

👍 4

cross posted from #clojure-spec : I'm using cljs-spec but I have issues with #objects...:

Call to #'... did not conform to spec:
In: [0 :data :from] val: #object[b 2018-06-11T00:00:00.000+02:00] fails spec: at: [:args :arg-0 :data :from] predicate: vector?
:cljs.spec.alpha/spec  #object[cljs.spec.alpha.t_cljs$spec$alpha40486]
:cljs.spec.alpha/value  ({:data {:from #object[b 2018-06-11T00:00:00.000+02:00]}})
:cljs.spec.alpha/args  ({:data {:from #object[b 2018-06-11T00:00:00.000+02:00]}})
:cljs.spec.alpha/failure  :instrument
so, what I try to spec is #object[b 2018-06-11T00:00:00.000+02:00].


how to spec that from-field (`#object [b ...]`)?

Garrett Hopper16:06:43

What does this mean exactly?

-co, --compile-opts edn     Options to configure the build, can be an EDN
                              string or system-dependent path-separated list of
                              EDN files / classpath resources. Options will be
                              merged left to right.
How do I use multiple -co edn files?

Alex Miller (Clojure team)16:06:45

“system-dependent path-separated list” typically means ;-delimited on windows and :-delimited on *nix

Alex Miller (Clojure team)16:06:11

so -co foo/bar:be/bop is what I would expect

Garrett Hopper16:06:22

I think I may have found a bug. Trying to run a cljs.main repl with :modules results in brepl_deps.js being clojure.lang.LazySeq. clj -A:cljs -co '{:modules {:cljs-base {:output-to "out/base.js"}}}'


open a ticket, thanks!


Hey, does anyone know how to deploy shadow-cljs app on heroku? It’s giving me hard time with java not found errors. I’m wondering if there’s a simpler path to it than switching to lein-ish project.clj…?


are you using :target :node-script? if so you specify :output-to "thing.js" and then probably just need to add "main":"path/to/thing.js" in your package.json


or are they using npm scripts?


Thank you @thheller, I’ll figure it out with :target :node-script first and then we’ll see


does anybody have an :exclusions example for excluding core.async so that andare (bootstrapped core.async) can be used in deps.edn?


i.e., I'm trying to use cljs-http and it pulls in the wrong core.async (need to replace it w/ andare)


cljs-http {:mvn/version "0.1.45"
             :exclusions [org.clojure/core.async]}
^^ seems to have done the trick


does anyone know the initial reason that Om/Reagent/etc. implemented async rendering?


like I get that it makes some things quite nice, but am wondering if it’s a fundamental requirement to use other things like CLJS like core.async


with the reagent observer pattern, it is easy to create churn when you do a lot of state alterations, but I don’t know if that was the reasoning behind batching.