This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-22
Channels
- # beginners (10)
- # boot (134)
- # cider (29)
- # clara (2)
- # cljs-dev (10)
- # cljsjs (2)
- # cljsrn (13)
- # clojure (76)
- # clojure-india (4)
- # clojure-ireland (1)
- # clojure-russia (20)
- # clojure-spec (11)
- # clojure-uk (7)
- # clojurescript (88)
- # core-async (5)
- # core-logic (3)
- # cursive (17)
- # datascript (5)
- # datomic (123)
- # hoplon (8)
- # klipse (6)
- # lambdaisland (2)
- # leiningen (4)
- # luminus (2)
- # off-topic (23)
- # om (23)
- # om-next (1)
- # onyx (20)
- # pedestal (2)
- # perun (2)
- # re-frame (11)
- # ring-swagger (3)
- # untangled (12)
Any numbers to see how many people actually using ClojureScript? I saw questions in the comments on HN on "most-used".
what do you use to inspect data structures in clojurescript? (like console.dir() for JS or dir() for Python)
@ejelome https://github.com/binaryage/cljs-devtools and just console.log
Hi. What's the fastest way to obtain AST for a single *.cljs
file?
https://github.com/clojure/tools.reader ? https://github.com/rundis/rewrite-cljs has a more detailed AST ime.
thanks @dominicm !
however clojure/tools.reader
is telling me ExceptionInfo No reader function for tag js clojure.core/ex-info (core.clj:4617)
@jiyinyiyong I’m not aware of any hard numbers, but if you estimate the number of Clojure users, the yearly surveys consistently show that > 60% use ClojureScript as well
And it turns e.g. "(ns foo)"
into '(ns foo)
IIRC it's possible to see another form, consistng of a lot of maps, sth. like {:type :ns, :name 'foo}
(or probably {:type :symbol, :name "foo", :namespace nil}
)
@jiyinyiyong I don’t think the claim is really that far off the mark - ClojureScript is the most mature compile to JS FP solution I’m aware of
@andrewboltachev rewrite-cljs has something like that.
@dominicm thanks, will check it out
Hey, what would be an easy way to check investigate CLJS compiler to see the output before Google Closure and after ?
@zilvinasu if you don’t strictly require an easy way, I think you can patch this line and spit the files somewhere: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1261
@darwin kinda wondering, basically taking compiler jar feeding it some source with optimizations one, isn’t that the actual result of ClojureScript compiler since there were no optimizations set by Google Closure ?
@zilvinasu :none
is almost what’s generated before Closure sees it
@zilvinasu however we generate slightly different code for :advanced
@zilvinasu so just use :none
with those additional options
I'm working on creating a host agnostic I/O library for ClojureScript, and the two current major approaches I'm thinking about involve using either dynamically bound fn vars, like with *print-fn*
in cljs.core
, and/or to use protocols with defined methods.
Ideally I'd like the heavy lifting to be managed by the host environments, as files/sockets/etc are all host dependent. I'm curious if anyone else has attempted something like this, or has advice on gotchas or previous work.
To clarify that, it seems like it would make the most sense to have the host systems implement the actual logic to, say, read and write a file, and have a way to read from and write to that file without the library knowing anything about the specifics for each host.
@futuro yes it’s been discussed before, the primary problem is that JS means the I/O interface has to be async
I wrote https://github.com/pkpkpk/cljs-node-io and landed on prefixing async fns, ie 'aslurp', and returning a channel, and leaving streams separate
On nodejs, many calls to libuv are called after js/process.nextTick() to allow event cb setup. So things like syscalls to create fd streams are fundamentally asynchronous. In contrast on the JVM fd's can be opened and streamed synchronously. You can mimic this on node with readFileSync but it consumes memory & does not use a pipe'able stream, so it has different semantics
I think @mfikes has work cooking with this, but I do not know if planck has async calls yet
@dnolen My current goal is to abstract over the various host implementations for IO with self-hosted CLJS, but async/sync is a useful lens to think of host agnostic IO through.
@futuro I just meant that because of the philosophical divide I just don’t know how useful it would be to many people
@dnolen Specifically a JVM/JSVM agnostic IO library, or even an IO library that's agnostic over the various JS hosts?
I’m starting to play with cljs using chestnut. I have 2 (probably stupid) questions so far: 1) Should adding [cljsjs/react-bootstrap “0.30.7-0”] to my project.clj dependencies handle adding CSS to my index.html? It seems like it doesn’t or I’m doing something wrong. 2) After adding the dependency I require it in my main file, but get a compilation error from Figwheel. It is only solved after restarting the REPL. Is this expected behavior or is there a command to refresh dependencies from the REPL? If this channel is not appropriate for these questions, please let me know. Otherwise, thanks in advance!
@rparra 1) no 2) leiningen grabs missing deps at jvm startup, so if you add a dep you must restart the process
@futuro if your idea is more narrow like - common stuff just between Node.js / JVM then that sounds useful
It's actually really focused on abstracting over JS VM I/O so creating a self-hosted compatible nREPL is simpler, but I wanted to start with the widest gaze on project goals. Realistically I would avoid thinking about the JVM, as there's already libraries for that.
it turns out that how Node.js and the browsers have evolved ES6 support makes the outcome even better than I could have imagined
at the same time when you go to advanced compilation - Closure can lower ES6 to ES3 and apply all the fancy stuff like DCE
it also means you can decide to write an ES6 module for open source reasons but with the expectation that you will consume from ClojureScript and reap all the benefits w/ fewer downsides
for example Transit.js was done this way - but it’s unidiomatic for most JS devs (Google Closure namespaces)
also provides a potentially interesting story for onboarding people to ClojureScript - we’ll see if that pans out
@dnolen with this and the hints for externs, do you think cljsjs
packaging will be needed less and less often?
Oh that's great, I consider this a very good thing
it is not of course about cljsjs
per se, but about generating externs mainly, that master seems to make waaay more easier
@lockdown yes, you will just be able to supply your .node_modules
directory to ClojureScript and it will just work
and now you have warnings about stuff that isn’t going to work - instead of futzing with :pseudo-names
the warnings features + return type propagation also makes writing externs way more fun
@lockdownz AMD, CommonJS, ES6, and Closure require/provide