On Thursday, November 27, 2014 10:14:05 PM UTC-2, Mike Thompson wrote: > On Friday, November 28, 2014 3:21:09 AM UTC+11, Kyle Cordes wrote: > > On Thu, Nov 27, 2014 at 7:08 AM, Colin Yates <[email protected]> wrote: > > > Mike, that's brilliant. Downloading it now. > > > > It is a great thing to have handy, and it is also points to another > > example of the problem I was complaining about, which is that there > > are N different optimization settings, of which different tools > > support different subsets. Quoting the page linked, "At the time of > > writing, cemerick/clojurescript.test doesn't work with :optimizations > > :none". > > > > This is a not a great situation. We have this wonderful programming > > language, whose many great characteristics include a broad toolbox of > > mostly composable tools. But up here at the tooling level, lots of > > CLJS tools are not composable. > > > > > Yes, tooling is definitely a problem. Compiler messages are poor and > initially off putting. Docs are threadbare compared to other languages I've > used. Debugging is a bit too hard. All these things are true. All these > things stop wider adoption. > > I'd expect with the current trajectory that things will be much better in > about 12 months. There are greenshoots: > https://github.com/oakmac/cljsbuild-ui > https://github.com/adzerk/boot-cljs > > To me, a crucial step for CLJS is to have a compiler that is liberated from > Java. I've looked and it seems a number have tried to make it happen, but > without official support each attempt seems to have withered. What we appear > to need is a thin, official clojure I/O library over the top of Java, and all > tools written in terms of that I/O library, which can then be implemented for > different platforms. Then tools would be portable away from Java. > > The trouble is that Java is portable in its own right, correct? Sorta. So > there doesn't seem to be offical momentum to make clojurescript portable off > Java itself. > > On other matters, vote now: > https://github.com/cemerick/clojurescript.test/issues/75 > > > -- > Mike
Making CLJS compiler completely independent from Java seems infeasible, since Google Closure is written in Java itself, and Closure is one of the main advantages IMO over other languages that sit on top of Javascript. I like the idea of IO abstraction. As I understand, internally the cljsc works as a two step process: first it emits the javascript, and after that kicks the closure compiler to do the dirt work. Maybe we could really split it into two separate "components", where the first one could be run without Java if desired. This component alone will not be able to do any optimizations other than :none, but this could be enough. And there is a big gotcha: currently macros run on JVM, and I don't know if there is a way to decouple that. []'s Andrew -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
