Ok, It not longer seems possible to do "incremental" compiles, by which I mean compile all files once, change one file, then compile again. The constants table will then be incomplete. But since I'm using my own build-tool that might just be my fault, would be good if someone else could double check.
One other gotcha: I do hiccup-like DOM construction in the client which needs to extend a protocol to keywords, since keywords were strings before it required extending strings and then checking if we have a keyword. See https://github.com/thheller/shadow/blob/master/src/shadow/dom.cljs#L182 , easy fix but someone else might run into this. Another thing which probably only affects me is that the constants_table.js contains ALL keywords in the whole project. I however split the generated js into multiple modules (via closure modules) so I can keep the initial js file size down and only load additional js when I need it. This resulted in a 215kb/90kb/45kb/166kb split, since the initial file now contains all constants the split is 264k/65k/27k/94k. Not a deal breaker, but a 121kb constants_table.js that cannot be split does not exactly help to "keep javascript files small". Will have to look at other optimizations I guess, although overall its less. Apart from that everything seems to work so far, although I don't have many tests for all my dom code. But a quick click through every page works. ;) Regards, /thomas On Thursday, August 29, 2013 10:51:56 AM UTC+2, Thomas Heller wrote: > > Hey, > > this sounds interesting. I just tried it on my project but it seems to be > missing several keywords in the constants_table.js. > > Dumb example: the code tries to use cljs.core.constant$keyword$1064 , > which does not exist. > > Will try to investigate, just a heads up. > > /thomas > > On Wednesday, August 28, 2013 3:29:26 PM UTC+2, David Nolen wrote: >> >> ClojureScript has long represented symbols and keywords as JavaScript >> Strings as a performance optimization around hash maps. However modern >> JavaScript engines have shown that following Clojure JVM's design more >> closely consistently delivers better performance. >> >> Also the representation of keywords as strings has had an unfortunate >> consequence, we modify the String prototype to allow keywords to be called >> as functions - this is a serious interop liability. >> >> Sean Grove has done some excellent work that I have further extended in a >> branch. In this branch keywords are represented with a deftype. In order to >> deliver performance, under advanced optimizations we emit keywords >> constants to avoid allocation overheads. >> >> The breaking change is that keywords in ClojureScript cannot support the >> identical? property guaranteed by Clojure on the JVM. There is a new >> equality check called keyword-identical? that can be used to efficiently >> check for keyword equality. defrecords and hash maps have been updated to >> use this predicate. >> >> Please try your projects with this branch so we can address any further >> issues because of this breaking change. >> >> http://github.com/clojure/clojurescript/compare/keywords >> >> Thanks, >> David >> > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
