> Dynamic load is simply not possible due to the restrictions of the
browser (all IO is async). A static load could be possible but I'm not
convinced that it would actually change much.
It seems to me this is a static problem that could have a static solution.
Even just a static in-ns (essentially a compiler directive) would, I think,
provide a solution.
The three second compile time is with :compile-dependents false,
:optimizations :none and :parallel-build true. I would love to know if that
is atypical and what I might have set up wrong.
> A more Clojure-esque REPL driven approach via `load-file` can also be a
whole lot faster than automatic file-watch + hot-reload.
`load-file` seems to be just as slow as recompiling, but one thing that is
super fast is send-form-to-repl (I'm using Cursive). The only downside is I
have to remember to do that for every top-level form I change. If I've
jumped around a bit and made a few changes it's much easier to hit save.
> Splitting the code into multiple impl namespaces and only exposing actual
public API selectively seems like a pretty good strategy apart from the
keyword issue?
Yes it's really just the keyword issue making me decide against that route.
The library in question is all about manipulating a bunch of nested maps,
which are full of name spaced keyword keys. I find the pain of the large
namespace preferable to the pain of super long keywords.
Thanks very much for the advice, and also for pointing me to the jira
issue. I've voted for that. Seems like it has a long way to go though -
it's not much more than "this is a problem" right now.
Tom
--
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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
