Hi Dylan, Good stuff! Thanks for the kind words about my work and for sharing what you made.
In terms of using whitespace optimizations for Nashorn evaluation, I agree that is is far from ideal. I was very excited to see Mike Thompson's recent experiment on ClojureScript testing without compiling to a single file ( https://github.com/mike-thompson-day8/cljsbuild-none-test-seed). I haven't had a chance to play with it, but it looks like this technique could be employed for Nashorn evaluation as well. In terms of routing, I agree with you that routes should be bidirectional pure functions that map from a URL to a state and back. That's why I wrote and released Silk <https://github.com/DomKM/silk>. My hope is that it fulfills this requirement for both Clojure and ClojureScript. If you try it and find it lacking in any way, please do let me know or open a GH issue. I want to make it production ready as soon as possible. Thanks again for sharing! Dom On Sat, Aug 2, 2014 at 3:12 PM, Dylan Butman <[email protected]> wrote: > I was really excited to see [Dom Kiva-Meyer](https://github.com/DomKM)'s > article on [Isomorphic Clojure[script]]( > http://domkm.com/posts/2014-06-15-isomorphic-clojure-1/) and the > accompanying example project [Omelette](https://github.com/DomKM/omelette). > His server rendering implementation is very elegant, and his thinking about > routing as bidirectional pure functions between state and uri closely > mirror my thinking with [Tao](https://github.com/pleasetrythisathome/tao). > > However, I wanted a minimal test case for server rendering as a way to > wrap my head around exactly what's happening for future use, so here it is! > > [Om Server Rendering Example Project]( > https://github.com/pleasetrythisathome/om-server-rendering) > > The one limitation I found is that the [weasel]( > https://github.com/tomjakubowski/weasel/) repl of which I've grown so > fond is incompatible with Nashorn. clojure.browser.events extends > js/Element which is undefined in Nashorn. I've found some suggestion that > this is also true in ie8 and below, but haven't tested. I logged the issue > [here](https://github.com/tomjakubowski/weasel/issues/20). If anyone else > is inspired to port weasel to [goog.clojure]( > http://docs.closure-library.googlecode.com/git/class_goog_net_WebSocket.html), > let me know and maybe we can collaborate, I don't think it's a huge lift, > but I'm not terribly familiar with repl implementations... > > The project also currently using :optimizations :whitespace to merge all > output code into a single file to simplify Nashorn evaluation. Dom does the > same thing in Omelette, but I'm sure you could add additional eval > statements in order to use :whitespace :none for faster development, which > is especially needed without a repl (I know Austin works, but I've had so > many frustrating days with it, I've given up). Additional, although > wrap-reload reloads the server on file save, the compiled js file is read > on compile when the routes are defined, which means that you have to > redefine the routes to pick up changes for server rendering. Definitely not > an ideal development environment...fixes and/or ideas to streamline the > process are welcome. > > -- > 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. > -- 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.
