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

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?

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

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

that seems extreme

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

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

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

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

right ClojureScript is there when you cannot reach the JVM

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

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

granted i missed a lot of the cljs growing pains

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

i think the only arguable point on that list is maturity

basically the thing that newcomers do not really understand

is that ClojureScript is not a seperate thing from Clojure

it never was and it never will be

and all the statistics that are collected reinforce this fact

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

but there are strong advantages for both hosts as well

different capabilities and different libraries don’t really matter

the critical ones are shared

they matter to people developing programs with either

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

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

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

all real stakeholders in ClojureScript have already bough into Clojure

the surveys have consistently reflected this year after year after year

i would expect no different

but i do wonder if the JVM is critical to that

it is

the surveys have consistently reflected this year after year after year

seriously go read them

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

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

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

i am also not suggesting otherwise

ok then I don’t know what you are suggesting

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

@eyelidlessness: I’m not being defensive

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

you can interpret things however you want on the internet

I don’t see any momentum

and you can assert i'm wrong

fine

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

so I think I have a lot of information

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

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

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

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

you literally started by telling me i'm wrong.

I didn’t say wrong anywhere

alright.

again, cheers

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

Wow. That was weird.

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

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

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

and I think the single app state idea was reinforced

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

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

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.

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

it’s now officially hard to follow all the leads

@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

there’s a good healthy flow of ideas

and that’s a good sign

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.

Yeah, it’s incredible to see

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.

@jaju it works with anything more recent as well

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:

@jaju language tweaked

@akjetma: cool!

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

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

(.-challenge extra)

c.rg

Ok, solved it with

(aget extra „challenge“)

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

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

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

we may in the future start emitting warnings for incorrect usage

for dealing with objects just use the goog.object namespace

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

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

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

in general Closure is underused for no good reason

https://github.com/clojure/clojurescript/commit/8d72633e693e8b887494288e4ff49539d43f39c5

another reminder to try master ^

the dependency changing logic needed a few more tweaks

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

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.

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

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

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

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

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.

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

It's still better than most alternatives.

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

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

object iteration etc.

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

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

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

@glenjamin: right that’s part of the problem

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

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

and mucking around with object is a total disaster

special casing is perf loss

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

use goog.object

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

@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. 😅

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

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

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

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

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

@jaen: ended up writing a small script, which is rewriting my files: https://github.com/darwin/plastic/blob/master/script/rewrite-macro-requires.sh

poor man’s solution

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

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

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

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

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

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

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

so essentially more of a perf thing?

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

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?

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

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

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

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

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

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

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

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

ah, right - http://blog.getsentry.com/2015/10/29/debuggable-javascript-with-source-maps.html

see the “Private Source Maps” section

@danielgrosse: ^

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

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

esp. under advanced compilation

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

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

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.

Ahh nevermind, had a println statement

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

Depends on who you ask, I suppose.

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

It’s been a while since I did a post http://swannodette.github.io/2015/12/23/year-in-review/

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

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

but thank you for everything that you do

it lays a strong foundation for the community to build on

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

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

@mheld: they are both pretty popular

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