Fork me on GitHub
#clojurescript
<
2016-10-03
>
rnandan27301:10:55

@dnolen the gzip size of final app.js is coming to 380K. Is this an expected number?

dnolen01:10:02

@rnandan273 it doesn’t seem problematic, you appear to have a lot of dependencies. You haven’t said how much code you have or anything like that.

pesterhazy09:10:30

@rnandan273: that seems like a relatively normal size

pesterhazy09:10:11

Try advanced compilation and eliding asserts

tengstrand09:10:36

I’m looking for a very simple tutorial for Reagent and re-frame. I have found a game, but I’m looking for something even simpler like a page with a button and an input field to start with. I found this: http://lambdax.io/blog/posts/2016-01-19-snake-game-part-1.html

Niclas11:10:53

What's the best practice way of handling namespaced keys when transforming with clj->js and js->clj, as the namespace part of keys are dropped? For example

(js->clj (clj->js {:post/id 1 :post/title “Breakfast"})) => {“id" 1 “title" "Breakfast"}

Niclas11:10:43

Is there a way to keep symmetry between these two transformations, without losing the namespace part?

dnolen12:10:00

@looveh there conversion is loss-y

dnolen12:10:23

I thought you could provide a custom keyword fn to accomplish that specific goal

dnolen12:10:50

@teng might want to ask in the #reagent channel?

tengstrand12:10:25

@dnolen Good ide, will add that channel!

Niclas13:10:27

@dnolen Okay, thanks. Do you know the reasoning behind using a destructive transformation? It seems to me that this is quite a large problem, especially when the adoption of clojure.spec and the best practice of namespacing keywords is increasing

dnolen13:10:34

@looveh the whole transformation process is loss-y

dnolen13:10:39

it’s already destructive

dnolen13:10:03

clj->js is js->clj are also helpers for beginners and were added with great regret to the API

dnolen13:10:26

if you’re doing interop you’re better off just using #js, js-obj, and goog.object

dnolen13:10:12

also if you’re doing interop with JS apis, namespaced keys aren't useful - since that’s not idiomatic for JS

dnolen13:10:48

clojure.spec is unrelated to the purpose of these helpers

dnolen16:10:52

@gerred thanks for sharing that! though it more or less reinforces my long standing beilef that JavaScript users either don’t know or care about compile to JS solutions which are not JS->JS or very close (TypeScript)

gerred16:10:03

of course! it was very interesting to read as someone on the other side - I waxed on it a bit in the reagent room, but I’m coming back over from Elm to ClojureScript.

gerred16:10:34

the numbers on “tried it, wouldn’t use it again” on clojurescript are interesting. not quite coffeescript, but its a higher number.

dominicm16:10:47

@dnolen Coming from js, it took me a long time to realise that cljs wasn't JS->JS. It confused me until I learned Clojure.

gerred16:10:50

i wonder how that breaks down on length of time using it, what version they used it, etc.

dnolen16:10:20

@gerred yes but we’re a rounding error in that survey - so those numbers don’t mean anything

dnolen16:10:27

2% & 1% ???

gerred16:10:46

oh, oops, I mixed up my colors.

gerred16:10:47

you’re right.

gerred16:10:01

I thought 22% had tried and wouldn’t use again, nevermind!

dnolen16:10:12

heh - now that would be a problem 🙂

dnolen16:10:40

@gerred I am curious to hear experience reports from someone coming back from Elm - they’re doing a great job these days attracting users

dnolen16:10:04

but typical Elm users aren’t typical ClojureScript users - ClojureScript users are generally just Clojure users doing full stack

gerred16:10:45

yeah. I’m not doing Clojure at all, if I were it’d be via clojurescript + node, but I use Elixir or Go these days. that said, I’m interested in checking out luminus now.

dnolen16:10:21

@gerred that’s cool, but that’s not typical based on our own surveys

dnolen16:10:32

> 65% of Clojure users use ClojureScript

dnolen16:10:43

that should be greater than

gerred16:10:49

so re: Elm and coming back, I think we’re just in this static typing swing that makes ML attractive. in a large app, though, I feel like I was breaking flow constantly (as opposed to using figwheel). its still an edit -> compile -> debug -> run -> parse type errors -> edit cycle.

dnolen16:10:12

I don’t personally like that either

gerred16:10:43

clojurescript feels much more like prose that I can flow and change and enjoy programming with. ML-like languages are nice, sure, since you have to design all the types up front, but now you just get notifications when something breaks.

gerred16:10:08

when you do a refactor, for example, and for me it breaks anything I’m doing to sit and parse out type systems.

gerred16:10:13

so ultimately for me its preference.

gerred16:10:37

much faster for me to run -> something breaks -> read error -> fix -> push in small isolated changes rather than compiling and clenching.

loganmhb16:10:56

@dnolen for that 65% number, I wonder how many clojure users do frontend work but don’t use clojurescript, vs how many just don’t do frontend work at all

dnolen16:10:26

@loganmhb I think web is like 80% of use cases?

dnolen16:10:31

so you can extrapolate from that

dzannotti16:10:00

@gerred i think it's a matter of confidence. Elm types give you a high confidence that if it compiles, it'll work as intended, and that during a refactor you covered all cases

gerred16:10:14

^ I agree with that.

gerred16:10:00

it also just didn’t grow for me. i built a fairly large app and whereas I had a lot of refactoring confidence, it was all a lot slower for me.

dnolen16:10:04

I tend to disagree it matters much for UI work though - correct is all about state transitions

dnolen16:10:15

you could encode all that into types - but good luck with that

gerred16:10:26

oh, sure, hadn’t thought of it like that. you can’t do that with Elm though. doThing : User -> User doesn’t encode much unfortunately, and ML types don’t create type safe state transitions, that’s where the hard bugs lie.

gerred16:10:34

i think you need something like Idris to even start getting at that.

dnolen16:10:42

right and good luck convincing people to use that

dzannotti16:10:08

@dnolen i sorta agree, but if someone goes and changes an om-next key your app breaks and you wouldn't know better

dzannotti16:10:34

(i think that types do make sense in a elm alike architecture, and much less sense in a om-next alike architecture btw)

gerred16:10:37

so I really like the whole premise of using spec and contracts to create runtime checks.

dnolen16:10:44

@dzannotti yes if you don’t have tests, or devcards, or any other thing to catch stuff like that

dnolen16:10:55

if you’re writing Elm apps without these things then you will also have problems

dnolen16:10:33

but I’m not arguing that types aren’t great for catchings lots of simple mistakes

dnolen16:10:41

and we make simple mistakes all the time

gerred16:10:51

its one thing I’ve always really liked about erlang/elixir is the opt-in type system, and I started hearing about it more with clojure/spec and discovered racket contracts.

gerred16:10:12

so I can start to solidify and harden my older, more stable code with types.

gerred16:10:19

but experiment fast on top of that.

gerred16:10:45

i don’t fully understand spec/contracts yet as opposed to dialyzer types, so I’m not sure what the limits are there.

dnolen16:10:06

I for one find that I care less about capturing mistakes at compile time if you have a fast feedback loop

dnolen16:10:14

Figwheel immediately shows me the error

dnolen16:10:20

what I don’t like w/o types is lack of documentation

dzannotti16:10:23

I think types are great or an massive hinderance, depends on the system architecture

dnolen16:10:29

"what does this fn take ?????"

dnolen16:10:39

and clojure.spec addresses that gap nicely

gerred16:10:21

so beginner question. will clojure.spec replace core.typed? or rather, what’s core.typed place vs. spec’s place?

dnolen16:10:41

just orthogonal concerns

dnolen16:10:52

neither is going to replace the other

dnolen16:10:13

and Ambrose has been working on some neat integration research - so synergy likely

gerred16:10:20

oh cool! ok.

gerred16:10:33

i also think the industry is in a static typing swing at the moment as a reaction to fatigue in other places.

dnolen16:10:48

I don’t know about that - see JavaScript

dnolen16:10:56

none of the various type system things are very popular there

gerred16:10:42

the growth of typescript (flow to some extent as well) is pretty huge. maybe this is more survivorship bias to large web apps since I work on those.

dnolen16:10:20

TypeScript can claim significant niche

gerred16:10:24

then again, this is all tiny niches

dnolen16:10:32

Flow is a rounding error like ClojureScript

gerred16:10:45

as compared to everything else. hell, I think a lot of people are using Go, but when you look at the whole industry that’s not true.

dnolen16:10:00

yes - people are happy with Java

dnolen16:10:09

irrespective of what you read on Reddit or HackerNews

gerred16:10:13

i mean I guess this is why its still a secret alien advantage. 😉

gerred16:10:21

(not java, what we’re doing)

dzannotti16:10:24

I wonder if they are, because they don't know any better/are not interested to know better

dnolen16:10:50

it’s what you learn at school, it’s what people hire for, it’s what all the books cover

gerred16:10:00

i once upon a time worked at Rally (a datomic customer) before they got acquired. we were able to sneak in Clojure because it ran on the JVM. Go was a much harder sell beyond the platform team.

dnolen16:10:16

it’s also why TypeScript can succeed reasonably well but Elm probably won’t

dnolen16:10:22

C#/Java familiar - ML not so much

dnolen16:10:56

in the end that’s why I think Clojure(Script) strategy is the only sustainable one for a Lisp in the modern world

dnolen16:10:08

you have to run on the JVM and compile to JS if you want any reach at all

gerred16:10:10

i’ll be interested here in 5 years to see the links between the C++, Rust, and ML-like communities. i predict that’ll be a heavy area of cross-pollination.

gerred16:10:50

i like Racket and various CLs a lot but I wouldn’t put them in any place that I worked.

gerred16:10:01

whereas Clojure I can absolutely walk in and dump somewhere, probably a lot easier than Go in a lot of places.

gerred16:10:13

* this will probably lead me to doing more Clojure (not just clojurescript)

dzannotti16:10:44

probably it's because i'm not a clojure god - but i often struggle to understand other people's clojure, while i know perfectly well mines and i wouldn't trade it with Java/JS for the world (i wonder if that's a contributing factor for others)

dnolen16:10:19

@dzannotti you can get carried away with brevity with Clojure - the downside to its FP roots

jrheard16:10:30

hopefully having spec included in the language will help with readability/maintainability 🙂

dnolen16:10:19

@jrheard probably won’t prevent code-golfing - but at least you know what the inputs and outputs should be - and that’s great

jrheard16:10:46

yeah, if i know that k is a ::foo/bar and i can see the definition of that somewhere, i’m happier than i was before

joshfrench17:10:49

is it possible to instantiate a record without knowing its type ahead of time, like so? (defn new-record [Type] (Type.)) i’ve played around with various syntax quotings with no luck.

joshfrench17:10:09

(not sure if this is specifically a cljs Q but that’s what I’m working with.)

anmonteiro17:10:18

@joshfrench

cljs.user=> (defrecord Foo [])
cljs.user/Foo
cljs.user=> (defn instantiate-x [x] (new x))
#'cljs.user/instantiate-x
cljs.user=> (instantiate-x Foo)
#cljs.user.Foo{}

dnolen17:10:18

@joshfrench it’s not, long outstanding bug actually

dnolen17:10:42

@anmonteiro technically I think that may not be allowed 🙂

dnolen17:10:52

we should just fix it

anmonteiro17:10:56

I had no idea, I think I’ve used it before 🙂

dnolen17:10:06

Clojure doesn’t allow using a local with new

dnolen17:10:18

but there’s no reason to have this restriction with ClojureScript

anmonteiro17:10:36

right, so what are you saying we should fix?

dnolen17:10:50

it doesn’t work consistently, I would look at JIRA for the case

anmonteiro17:10:03

IMO platform quirks like this should be allowed. just like specify! exists and can’t in Clojure

dnolen17:10:15

it actually used to work (years ago)

dnolen17:10:18

and I think I messed it up

anmonteiro17:10:15

so it seems that the problem is that it works

anmonteiro17:10:25

but we should restrict it for some cases?

anmonteiro17:10:43

maybe worth taking this to #cljs-dev

dnolen17:10:47

@anmonteiro sorry that ticket is just wrong - it should always work 🙂

dnolen17:10:57

instead of half not

anmonteiro17:10:41

sorry I still don’t understand. isn’t it explicit by the ticket that it all works?

anmonteiro17:10:46

what is the half that doesn’t?

dnolen17:10:09

I’m pretty sure it doesn’t though

dnolen17:10:32

(def x SomeCtor) (new x)

joshfrench17:10:53

(new x) sems to work for my admittedly trivial use case, fwiw. i’ll keep in mind that it may not in other circumstances. thanks!

dnolen17:10:14

@anmonteiro I would look in JIRA a bit more - there may be some cases I closed around this

anmonteiro17:10:38

@dnolen I’ll keep looking, but these work in Planck & noderepljs:

cljs.user=> (defrecord Foo [])
cljs.user/Foo
cljs.user=> (def x Foo)
#'cljs.user/x
cljs.user=> (new x)
#cljs.user.Foo{}
cljs.user=> (let [x Foo] (x.))
#cljs.user.Foo{}

dnolen17:10:14

I remember

dnolen17:10:19

it has to be a symbol

dnolen17:10:27

it should just be any expression

dnolen17:10:48

sorry I needed to look at the code for a second

anmonteiro17:10:04

nothing to apologize for, thanks for digging

anmonteiro17:10:49

oh I get it:

cljs.user=> (defrecord Foo [])
cljs.user/Foo
cljs.user=> (def x {:foo Foo})
#'cljs.user/x
cljs.user=> (:foo x)
cljs.user/Foo
cljs.user=> (new (:foo x))
            ⬆
First arg to new must be a symbol at line 1

anmonteiro17:10:07

is there an actual ticket for this ^ though?

anmonteiro17:10:36

CLJS-693 should probably be closed or change its description, right?

dnolen17:10:12

fine to close and create a new ticket yes

stbgz19:10:17

hey all I spent sometime this weekend putting together a clojurescript library to retrieve maven dependencies ala Aether + Pomergranate https://github.com/eginez/huckleberry

stbgz19:10:06

at some point @shaunlebron and I talked about creating less jvm-centric tools

stbgz19:10:27

open to sugestions, ideas, etc

dnolen19:10:22

@stbgz looks interesting!

stbgz19:10:05

Thanks @dnolen still experimenting with a few things hopefully the comunity finds this useful in some way