This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-08
Channels
- # admin-announcements (3)
- # bangalore-clj (3)
- # beginners (21)
- # boot (32)
- # cider (14)
- # clara (2)
- # cljs-dev (19)
- # cljsjs (8)
- # cljsrn (1)
- # clojars (1)
- # clojure (147)
- # clojure-australia (6)
- # clojure-brasil (8)
- # clojure-canada (2)
- # clojure-gamedev (3)
- # clojure-greece (2)
- # clojure-hk (5)
- # clojure-italy (10)
- # clojure-japan (8)
- # clojure-korea (4)
- # clojure-russia (25)
- # clojure-sg (2)
- # clojure-spec (36)
- # clojure-uk (34)
- # clojurescript (88)
- # cursive (157)
- # datomic (6)
- # devcards (1)
- # dirac (1)
- # editors-rus (3)
- # events (2)
- # funcool (1)
- # hoplon (57)
- # jobs (9)
- # lein-figwheel (2)
- # luminus (1)
- # om (156)
- # onyx (93)
- # perun (11)
- # rdf (65)
- # re-frame (36)
- # reagent (17)
- # ring-swagger (3)
- # specter (19)
- # untangled (33)
@dnolen @mfikes - Everyone is really excited about ClojureScript freeing itself from the JVM in the wake of the JavaScript closure compiler. But I was wondering about how ClojureScript would handle one of the more elementary things the JVM gives you, which is IO. I posted my thoughts about this on this little reddit thread, but I was wondering about your take - https://www.reddit.com/r/Clojure/comments/51g31l/google_developers_blog_closure_compiler_in/d7e2vqa
Any possibility of something like a
name space emerging, which might encapsulate the chaos of the world of CLI JavaScript runtime IO interfaces? I recognize that it'd be pretty ugly...
From the compiler codebase perspective, this ticket might lead to at least some hope of using the existing I/O calls that the compiler makes http://dev.clojure.org/jira/browse/CLJS-901 (but then there would still be the need of satisfying I/O requests in something like Node). I’ve been working on CLJS-901 with the mindset of being within the JVM (thus potentially providing sufficient hooks to solve an interesting WebDAV problem with Ambly), but perhaps if a bit more general approach is taken, then any I/O backend could work, even if the compiler is self-hosted and running in Node or some arbitrary JavaScript engine. Interesting.
I’ve just scratched the surface in beginning to think about CLJS-901 and am essentially in experimentation stage with https://github.com/mfikes/clojurescript/commit/fc794202483345f32ff177362a894bc114426f33
Interesting. A long time ago I wrote this in-memory Java compiler in clojure - https://github.com/Codewars/codewars-runner-cli/blob/master/jvm-runner/src/clojure/codewars/runners/java.clj
Anyway, it would also be nice if localStorage
or a cookie file could be used for IO, because sometimes that's all you've got. Food for thought. I'll leave you all alone now...
@xcthulhu i have been working on this : https://github.com/pkpkpk/cljs-node-io
I'd prefer if the competing teams here formed a tiny committee and agreed on an API for
and then I didn't have to worry about which horse to back
What about supporting cljs compilation in the browser?
Then we could have a full cljs IDE (inc. compilation) inside the brower
People could work on their github cljs project, without leaving the browser!
@viebel I so like that! and now that Google Closure compiler is JS only...well why not dreaming 🙂