Fork me on GitHub
#clojurescript
<
2015-12-23
>
grav00:12:01

how do I go about turning something that has a javascript Iterator into a cljs collection?

eyelidlessness02:12:52

late-night wondering... js is pervasive, :whatever->js as well as js->:whatever is becoming widely available, focus on performance is huge... and cljs is self-hosting. is there a notion that cljs will become the primary clojure implementation?

dnolen02:12:18

@eyelidlessness: there’s very little value in that direction

dnolen02:12:41

few people that write Clojure for living want to be restricted by the constraints of JavaScript runtimes

eyelidlessness02:12:57

that seems extreme

dnolen02:12:28

@eyelidlessness: extreme, it’s just a matter of fact

dnolen02:12:48

people writing production Clojure tend to write multithreaded code again JVM libraries

eyelidlessness02:12:36

understandably, the JVM implementation is the primary one, and has been around for some time

eyelidlessness02:12:10

but JS as a target and as an intermediary layer has some advantages

dnolen02:12:39

right ClojureScript is there when you cannot reach the JVM

dnolen02:12:51

but there’s few reasons to use it if the JVM is available

eyelidlessness02:12:11

i've worked now on production code against the JVM, and prototypes for cljs, and i can't help noting the cljs environment feels more mature, is advancing faster, and has a much broader reach

eyelidlessness02:12:45

granted i missed a lot of the cljs growing pains

dnolen02:12:05

it may seem like that, but it’s really not the case

eyelidlessness02:12:00

i think the only arguable point on that list is maturity

dnolen02:12:47

basically the thing that newcomers do not really understand

dnolen02:12:58

is that ClojureScript is not a seperate thing from Clojure

dnolen02:12:07

it never was and it never will be

dnolen02:12:17

and all the statistics that are collected reinforce this fact

eyelidlessness02:12:57

well, it's not entirely the same either. they have different capabilities and the libraries available are fragmented in a variety of ways

eyelidlessness02:12:12

but there are strong advantages for both hosts as well

dnolen02:12:22

different capabilities and different libraries don’t really matter

dnolen02:12:32

the critical ones are shared

eyelidlessness02:12:38

they matter to people developing programs with either simple_smile

dnolen02:12:52

and most people build unified systems ClojureScript on the frontend, Clojure on the backend

dnolen03:12:26

even after bootstrapping the interest has been pathetically small as I always predicted

dnolen03:12:42

it is not of interest to non-Clojure programmers in actuality beyond toy experimenting

dnolen03:12:55

all real stakeholders in ClojureScript have already bough into Clojure

dnolen03:12:05

the surveys have consistently reflected this year after year after year

eyelidlessness03:12:25

i would expect no different

eyelidlessness03:12:50

but i do wonder if the JVM is critical to that

dnolen03:12:05

the surveys have consistently reflected this year after year after year

dnolen03:12:13

seriously go read them

eyelidlessness03:12:38

i'm not suggesting, say, abandoning JVM clojure...

dnolen03:12:53

@eyelidlessness: what I’m saying is there no ground for pursuing any other strategy than the one we have pursued

dnolen03:12:07

there exists no evidence that we are not doing precisely what people actual want and what they actually need

eyelidlessness03:12:39

i am also not suggesting otherwise

dnolen03:12:51

ok then I don’t know what you are suggesting simple_smile

eyelidlessness03:12:23

and i am surprised to encounter what seems a defensive response, when i meant in no way to second-guess progress so far

dnolen03:12:48

@eyelidlessness: I’m not being defensive

eyelidlessness03:12:52

i'm just wondering if maybe the winds will change, given the particular momentum i see

dnolen03:12:54

you can interpret things however you want on the internet

dnolen03:12:08

I don’t see any momentum

eyelidlessness03:12:10

and you can assert i'm wrong

dnolen03:12:23

and I’ve been working on this project and interacting with users & the community for 4 years

dnolen03:12:27

so I think I have a lot of information

dnolen03:12:45

and fear not if the winds do change, we will pay attention! simple_smile

dnolen03:12:16

if anything I’ve have a pretty good ear for where the wind is blowing 😉

eyelidlessness03:12:51

well you're right and i'm wrong then. cheers

dnolen03:12:51

@eyelidlessness: ha, not wrong - just more feedback from a potentially growing population that does not show up in any current metrics we track

eyelidlessness03:12:23

you literally started by telling me i'm wrong.

dnolen03:12:51

I didn’t say wrong anywhere

dnolen03:12:17

I said simply stated whatever evidence I have - apologies for any misinterpretations

erichmond03:12:51

Wow. That was weird.

erichmond03:12:11

Anyway, I’m curious, is redux borrowing from Om/Cljs or is Om/Cljs borrowing from redux? Or are both borrowing from something else?

dnolen03:12:53

@erichmond: I think Redux was a bit more influenced by Elm

dnolen03:12:11

however the Redux developer did read my React blogpost which piqued his interest in React

dnolen03:12:30

and I think the single app state idea was reinforced

dnolen03:12:56

in anycase far as I know Redux came nearly a year after Om (which is 2 years old) - it’s a relatively new thing

dnolen03:12:53

Om Next of course is moving beyond the Flux / Redux thing a bit so less influence from that stuff now or FRP or anything else

erichmond03:12:07

Thanks. All this stuff is FASCINATING btw. Kudos on all the work you’ve done. Between what’s happening on the front-end and whats happening with unified logs and things like datomic, it feels like we’re on the cusp of some really major breakthroughs. Most exciting time since Rails came out 10 years ago IMO.

dnolen03:12:28

I’d like to think so, all the client stuff that everybody is doing is very exciting

dnolen03:12:46

it’s now officially hard to follow all the leads simple_smile

dnolen03:12:22

@erichmond: it’s definitely nice to see a good feedback loop between what the ClojureScript community is doing and the React and React influenced JS community

dnolen03:12:27

there’s a good healthy flow of ideas

dnolen03:12:30

and that’s a good sign

erichmond03:12:41

I was writing a ton of backbone 5 years ago, and it was PAINFUL. Can’t wait till I’m working on front-end stuff again to really check it out.

erichmond03:12:50

Yeah, it’s incredible to see

jaju03:12:23

Re: cljs on nodejs - https://github.com/clojure/clojurescript/wiki/Quick-Start states support for 0.12.X at this time - is the wiki outdated or is it to be taken at face value? Just asking before I embark onto some serious trials. simple_smile

dnolen03:12:58

@jaju it works with anything more recent as well

akjetma03:12:17

I’ve been going through some language-agnostic screensharing technical interviews lately using clojurescript and it’s been going really well. I don’t know how much of that success is cljs and how much is me. I feel like I’m cheating or something. Mark of a good thing. :thumbsup:

dnolen03:12:39

@jaju language tweaked

jaju03:12:43

Awesome! Thanks. Gives me confidence to try it out in a tricky situation and clojurescript is the best tool in my toolbox simple_smile

danielgrosse07:12:03

I have a problem with accessing an object property in clojurescript.

(.-challenge extra)
is compiled to
c.rg
with advanced mode. But this returns undefined. How can I tell the compile to generate c.challenge?

danielgrosse07:12:07

Ok, solved it with

(aget extra „challenge“)

Lambda/Sierra13:12:58

@danielgrosse: I think the latest advice on that is to use goog.object.get

glenjamin13:12:15

any idea why that might differ from aget? i’ve been using aget in those scenarios (where I haven’t defined externs)

dnolen13:12:14

@glenjamin: aget works but purely by accident - in Clojure aget is only for arrays

dnolen13:12:33

we may in the future start emitting warnings for incorrect usage

dnolen13:12:50

for dealing with objects just use the goog.object namespace

jaen13:12:36

Out of curiosity - is there any reason to not alias it into the namespaces by default if it's expected to be used?

dnolen13:12:38

@jaen the value is very minimal since it does not correspond to anything in Clojure

dnolen13:12:02

and people should just get comfy with that Closure ns for interop

dnolen13:12:14

in general Closure is underused for no good reason

dnolen13:12:27

another reminder to try master ^

dnolen13:12:41

the dependency changing logic needed a few more tweaks

dnolen13:12:58

you should now be able to change dependencies freely without trashing your builds

jaen14:12:41

Heh, "does not correspond to anything in Clojure" feels like argumentum ad verecundiam to be honest. Clojurescript already departs from Clojure at points if there is sufficient rationale for doing just that. And looking at the rationale document "does not correspond to anything in Clojure" doesn't seem to be a sufficient rationale to not do things differently to Clojure, behaviour of Clojurescript macros being the foremost example. Besides, IIRC in Clojure there are no cases where (.-challenge extra) decides to not work and require something else instead. And since aget works and is readily available, while goog.object.get is not, doing the right thing is less convenient - the language itself seems to discourage the right usage. Having goog.object.get aliased to, say, oget in the core namespace would go a long way in teaching people to use it. As for people underusing Closure library - it's all based on convenience; GClosure lib documentation is basically a Javadoc, probably the worst way do document things ever. You don't get to learn how to use something just from reading API documentation without any example or explanation. For example I've never used Java interop in Clojure for string functions because they couldn't even deal with nil strings. Something like cuerdas is nicer and more Clojury, not exploding on nil not being the only reason. Maybe not using GClosure due to poor documentation (yes, that is certainly subjective) is not a good reason, but it is a reason nonetheless. But then again if you feel accessing object properties being more convenient (as opposed to less) clashes with your vision of Clojurescript I don't feel any need to argue further- after all it's your language, not mine.

dnolen14:12:27

@jaen this discussion has been beaten into the ground and so far no new information is being introduced here simple_smile

dnolen14:12:46

what I’ve said can be more or less considered the official stance and recommendation

dnolen14:12:24

so I don’t have anything more to add and if incorrect usage of aget becomes a warning or error no one should be surprised in the future

glenjamin14:12:55

goog.object.get looks to be null-safe, which is nice

jaen14:12:18

I don't have anything against warnings for aget, this makes sense. I just don't think having to require and alias something each time you need to do basic language functionality makes sense.

jaen14:12:35

But I can live with grating things in a language, I guess.

jaen14:12:41

It's still better than most alternatives.

dnolen14:12:50

@jaen your annoyance is noted - but the official stance is unlikely to change on this one simple_smile use goog.object

dnolen14:12:42

@glenjamin: there’s also a bunch of useful things in there which make no sense for us to replicate that you will inevitably need

dnolen14:12:59

object iteration etc.

glenjamin14:12:10

they said that about JVM string functions, and it makes cljc a bit annoying 😛

darwin14:12:32

just a quick question, is it possible to detect if function passed to me as parameter has particular arity?

glenjamin14:12:35

but in this scenario, there’s no JVM equivalent afaik, so cljc isn’t really relevant

dnolen14:12:47

@glenjamin: right that’s part of the problem

dnolen14:12:01

there’s no platform sharing to be done around JavaScript objects unlike strings

glenjamin14:12:27

it’s a shame they can’t extend the Map protocol, but that wouldn’t really work

dnolen14:12:45

and mucking around with object is a total disaster

dnolen14:12:57

special casing is perf loss

dnolen14:12:27

as I said, this is well trodden territory with an enormous amount of consideration with a simple answer

dnolen14:12:31

use goog.object

darwin14:12:28

I ended up using custom macros: oget, ocall, oapply and oset: https://github.com/binaryage/chromex/blob/master/src/lib/chromex/support.clj#L5-L26 they just wrap goog.object in a more convenient way I would like to see it as a re-usable library some day… ideas for improvement welcome

danielgrosse14:12:57

@dnolen thanks for the explanation. I had my crash course in externs, Javascript interop and gclosure today, as I compiled my script for production for the first time. 😅

dnolen14:12:03

@danielgrosse: cool - yep, when dealing with 3rd party libraries externs are right answer over goog.object

dnolen14:12:16

If anyone here is using Atom it would be nice to get some information here - https://github.com/clojure/clojurescript/wiki/Atom

dnolen14:12:42

Parinfer seems like a no-brainer, but I don’t know enough about Atom to know if there’s a sensible REPL integration story there

jaen14:12:40

@darwin: that looks nice; if only there was some way to have something referred by default into each namespace.

darwin14:12:45

@jaen: yeah, I would love to have some way to refer my logging and similar I use all over the place

darwin14:12:27

poor man’s solution simple_smile

jaen14:12:35

But if it works ; d I guess I could hook something similar into my boot pipeline with some effort.

darwin14:12:32

I ended up not needing it much, just once in a while, when I add a new common function I want to see "everywhere"

darwin14:12:52

usually when starting new namespace I just copy some existing file which has most of it already there

martinklepsch14:12:12

@darwin: may be a stupid question: why are these o* helpers macros and not regular functions?

darwin14:12:12

after deleting file’s code, Cursive then suggests what to delete

darwin14:12:58

@martinklepsch: no strong reason, it is fundamentally code rewriting, normally I would write several nested goog.object.get, this is just an automation for that.

darwin14:12:27

and I don’t want to introduce more function calls than there would be when written directly

martinklepsch14:12:42

so essentially more of a perf thing?

darwin14:12:08

it is just a sugar, the perf profile should stay the same

danielgrosse14:12:19

I looked at the code of the precursor app and noticed that they are using source maps, which are protected to be accessed from anyone. Is there some documentation how to realize this?

darwin14:12:11

@martinklepsch: ideas for improvements welcome, this was just a quick solution to my need to produce a lot of interop code without extern file

darwin14:12:25

nice thing is that it generates code I would write by hand, it is just more flexible (eg. it takes multiple keys, etc.), oset should be probably designed better

martinklepsch14:12:09

@darwin: really just curiosity, no real suggestions right now

dnolen15:12:52

@danielgrosse: what do you mean? it just sounds like their deploy elides source maps

dnolen15:12:18

most people just drop the :source-map compiler option for advanced builds

sander15:12:45

@danielgrosse @dnolen here it seems like the source map is included but the sources are 403 (probably based on source ip)

sander15:12:02

i.e. i can see the tree of .cljs files, i just can't read any of them

sander15:12:15

i guess source maps get loaded only after opening devtools so this shouldn't reduce performance for users, while making it easier for developers to catch bugs while using the deployed version themselves

dnolen15:12:46

see the “Private Source Maps” section

sander15:12:06

actually precursor is using a publicly accessible .map file but private .cljs files. i'd keep the map file private as well, like in the blog post

dnolen15:12:57

@sander yeah though map files are not super useful without the original source

dnolen15:12:17

esp. under advanced compilation

sander15:12:27

i'm still sometimes using wordpress where it's said to be slightly safer to hide your (dependency) version numbers etc simple_smile

sander15:12:53

but yes, this seems not problematic, just fun to be able to see that it's indeed built in cljs and how the files are structured

gardnervickers19:12:15

Hey all, I’m having some issues with :simple and :advanced compilation, getting "$s$$.substring is not a function”. Any tips on where to start diagnosing this? Or do I have to start removing portions of my app to figure it out.

gardnervickers19:12:59

Ahh nevermind, had a println statement

mheld19:12:31

is there a preferred clojure/clojurescript web framework stack nowadays?

jaen19:12:20

Depends on who you ask, I suppose.

jaen19:12:46

If you asked me the answer would look something like this - https://gitlab.com/jaen/clj-cljs-presentation/blob/master/resources/deps.edn

dnolen20:12:49

really kind of stunning when you put all the various things that happened in 2015 into one big review simple_smile

spike20:12:44

@dnolen: it was briefly touched on at euroclojure, but… when… do… you… sleep?! 😄

spike20:12:56

but thank you for everything that you do

spike20:12:32

it lays a strong foundation for the community to build on

dnolen22:12:16

@spike haha I think the point of that post was … when does the ClojureScript community sleep?!

mheld23:12:06

is reagent or om the more prevalent react wrapper for cljs?

dnolen23:12:16

@mheld: they are both pretty popular

eggsyntax23:12:27

@dnolen: that post really made me grin. It sure has been a hell of a year simple_smile