I really hope that a small plugin to coordinate cljx/cljsbuild will show up in the near future. I found cljsbuild's crossovers much better integrated and easier to use (but still far inferior to cljx).
I agree that a REPL based workflow is much superior, especially with
tools like Om which remove the need to coordinate DOM updates.
Chas Emerick writes:
> This particular trick is a clever one (that I'm afraid I've had some
> hand in propagating, for the benefit of those that like an "auto" +
> browser refresh workflow), but it's never going to be particularly
> efficient. By its very nature, pdo sets up cljx and cljsbuild off and
> running without any coordination; it's equivalent to running the two
> tasks in separate processes.
>
> It's possible that some hooks may become available in cljsbuild so that
> things like cljx can do what they like prior to each compile, but that's
> speculative.
>
> IMO, a REPL-based workflow is far superior to anything involving
> reloading your app's page, insofar as you can (nearly always) apply the
> changes you're working on without blowing away the state of the app. In
> this context, cljx's nREPL middleware excels (but unfortunately cannot
> be used with the stock ClojureScript browser-REPL; check out Austin).
>
> Note that cljx has not been optimized _at all_. It's "fast enough" for
> my purposes (i.e. reasonable when doing a clean rebuild, and snappy when
> doing the small changes typical in a REPL). I'd be happy to merge
> reasonable patches that make the actual cljx transformation faster.
>
> - Chas
>
> On 03/21/2014 01:23 PM, t x wrote:
>> I'm using:
>>
>> "lein pdo cljx auto,cljsbuild auto dev'
>>
>> However, maybe perhaps it's weird timing interaction between cljx and
>> cljsbuild that's making the lag appear more than it actually is.
>>
>> On Fri, Mar 21, 2014 at 8:27 AM, David Nolen <dnolen.li...@gmail.com> wrote:
>>> Unless you're compiling a very large file - with auto :optimizations :none
>>> you should always get sub-second compile times under auto.
>>>
>>> David
>>>
>>>
>>> On Fri, Mar 21, 2014 at 10:55 AM, Timothy Baldridge <tbaldri...@gmail.com>
>>> wrote:
>>>> are you using "lein cljsbuild auto" ? That's what I use, and I get about
>>>> 1-3 sec recompile times for stuff that uses core.async.
>>>>
>>>> Timothy
>>>>
>>>>
>>>> On Fri, Mar 21, 2014 at 12:48 AM, t x <txrev...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> * I'm already using:
>>>>>
>>>>> :incremental true
>>>>> :compiler { :optimizations :none }
>>>>>
>>>>> * I'm also aware of cljs brepl
>>>>>
>>>>>
>>>>> However:
>>>>>
>>>>> 1) the cljs compiler is still too slow for my liking (even though it's
>>>>> not calling closure)
>>>>>
>>>>> 2) I don't like the cljs repl nearly as much as I like the clj repl
>>>>>
>>>>>
>>>>> Now, my dumb/stupid question:
>>>>>
>>>>> Is there any cljs in cljs _slow_ interpreter? I'm perfectly happy
>>>>> with an interpreter that runs 10x slower, if, in exchange, I get to
>>>>> hit "refresh" and my new code starts running.
>>>>>
>>>>> Furthermore, I'm _okay_ with their being a big delay every time I
>>>>> introduce a new macro from clj land.
>>>>>
>>>>>
>>>>> I realize this sounds spoiled -- but -- the cljs compiler delays are
>>>>> really really breaking my flow.
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> 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/d/optout.
>>>>
>>>>
>>>>
>>>> --
>>>> "One of the main causes of the fall of the Roman Empire was that-lacking
>>>> zero-they had no way to indicate successful termination of their C
>>>> programs."
>>>> (Robert Firth)
>>>>
>>>> --
>>>> 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/d/optout.
>>>
>>> --
>>> 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/d/optout.
--
Moritz Ulrich
pgp5NE2maqqks.pgp
Description: PGP signature
