Fork me on GitHub
#clojurescript
<
2018-06-12
>
richiardiandrea00:06:19

The problem I am hitting has been captured here, but I will try with the vanilla compiler as well: https://github.com/thheller/shadow-cljs/issues/304

dnolen00:06:52

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

richiardiandrea00:06:57

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

dnolen00:06:54

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

dnolen00:06:05

and independently somehow

dnolen00:06:14

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

dnolen00:06:23

this is nothing specific to ClojureScript btw

lilactown00:06:35

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.

lilactown00:06:48

(def js-interop-test
  ^:js
  (fn
    [props]
    (js/console.log props)
    "blahblah"))

lilactown00:06:58

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

br01:06:51

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

br01:06:28

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

br01:06:25

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

br01:06:57

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

br01:06:39

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.

lilactown01:06:06

it’s kind of an apples & oranges question

dnolen01:06:15

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

br01:06:30

That's my view, David.

dnolen01:06:45

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

br01:06:50

"but Angular comes with a router built-in"

dnolen01:06:02

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

dnolen01:06:16

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

br01:06:34

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

dnolen01:06:48

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

lilactown01:06:59

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

br01:06:43

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

dnolen01:06:21

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

br01:06:29

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

dnolen01:06:32

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

br01:06:56

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

lilactown01:06:12

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

lilactown01:06:47

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

br01:06:49

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

lilactown01:06:42

so really, it’s not Angular vs CLJS.

lilactown01:06:57

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

br01:06:15

CLJS + Reagent + Reframe, for me

lilactown01:06:06

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

br01:06:15

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

br01:06:27

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

br01:06:38

the false economy of nearness vs simplicity, to be frank

lilactown01:06:45

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

lilactown01:06:11

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

br01:06:44

There is no fundamental opposition to React in our team.

br01:06:00

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

dnolen01:06:22

except bidi just works, it doesn’t need updates

br01:06:31

pretty much

lilactown01:06:36

those conversations are easy to work through

dnolen01:06:45

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

br01:06:48

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

dnolen01:06:12

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

br01:06:38

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

br01:06:56

We all despise JS framework churn

br01:06:37

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

justinlee01:06:46

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

lilactown01:06:12

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

br01:06:13

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

justinlee01:06:33

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

✔️ 4
💯 12
br01:06:35

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

lloydshark01:06:22

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.

br01:06:34

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

dnolen01:06:47

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

👆 12
dnolen01:06:58

you need some psychological buy-in

br01:06:35

@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

br01:06:44

@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

br01:06:15

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

lilactown01:06:20

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

br01:06:00

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

lilactown01:06:23

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

lilactown01:06:36

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

br01:06:42

Yes that would be my argument, also.

lilactown01:06:26

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

br01:06:35

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

br01:06:43

Clojure good choice for all the "middleware"

br01:06:23

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

br01:06:00

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.

br01:06:56

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

lilactown01:06:20

react is the gateway drug to CLJS IMO 😛

👍 4
lilactown01:06:54

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

lilactown01:06:01

I’ve heard good things about Fulcro

dpsutton01:06:25

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

dpsutton01:06:47

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

br01:06:41

@dpsutton They'll use Atom + ProtoREPL + shadowcljs

br01:06:04

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

richiardiandrea01:06:14

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

richiardiandrea02:06:13

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

richiardiandrea02:06:15

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

richiardiandrea02:06:55

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

br02:06:25

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

br02:06:41

Time to look for another gig, maybe.

br02:06:20

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

br02:06:38

Thanks again for your help. Sorry for derailing channel.

dpsutton02:06:49

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

henrik05:06:52

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.

henrik05:06:06

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.

henrik05:06:41

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

henrik05:06:07

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.

henrik05:06:15

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.

henrik05:06:09

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.

henrik05:06:07

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
kurt-o-sys07:06:16

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: :week.data/from 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].

kurt-o-sys07:06:35

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"}}}'

dnolen17:06:55

open a ticket, thanks!

Marcin20:06:53

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

thheller20:06:58

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

thheller20:06:35

or are they using npm scripts?

Marcin20:06:46

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

johanatan22:06:46

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

johanatan22:06:09

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

johanatan22:06:27

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

lilactown23:06:06

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

lilactown23:06:14

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

justinlee23:06:25

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.