Thanks a lot colin for your insights. I will definitely take the time to investigate all that, and also stick to a more standard dual compilation approach as suggested by David.
Some comments: - ok, schema looks cool! But then it makes me think why would I want to use a dynamically typed language like clojure if I can have a real type system with ghcjs... - yes, I also do enforce separation of biz logic from presentation stuff, unit testing the logic part. However the real point of UI component is that the DOM they produce depends on some state/interaction and this is that part I need to test, not biz logic - I don't use clojure for backend Cheers (and Happy new year) -- Arnaud Bailly twitter: abailly skype: arnaud-bailly linkedin: http://fr.linkedin.com/in/arnaudbailly/ On Mon, Jan 5, 2015 at 3:19 PM, Colin Yates <[email protected]> wrote: > Hi Arnaud, > > Are you using lein cljsbuild auto? If so then :none should be sub-second? > Things that significantly improved my cljs workflow (with om): > > - figwheel (chestnut template is a great starting point) pushes > javascript changes to the browser (and css as well) > - defonce the atom so state persists figwheel pushes > - pristmatic's schema (or core.typed) > - pristmatic's schema (or core.typed) > - pristmatic's schema (or core.typed) > - pristmatic's schema (or core.typed) > - (yeah, realy, schema is that useful) > - pristmatic's schema (or core.typed) > - (I mean it :)) > - https://github.com/cemerick/clojurescript.test (haven't tried David's > shiny new clojure.test port). > - ruthlessly separating out logic from components. If I need to unit test > a component I first see if I can split the interesting logic into a > separate method which I can test without a browser. If I can't then I go > get some coffee and try again. > - in a previous life (CoffeeScript and ExtJS) I had great times with > Jasmine. > - Cursive Clojure (https://cursiveclojure.com/). To be honest you might > want to stick with LightTable if it isn't clj backend. > - https://github.com/noprompt/lein-garden (but I suspect you might be > using a non-clojure CSS generator?) > - https://github.com/gdeer81/lein-marginalia for documentation ( > https://github.com/zcaudate/lein-midje-doc also looks awesome but I > haven't used it). > > And did I mention schema? :). > > For general programming I highly recommend https://github.com/jonase/kibit > and https://github.com/jonase/eastwood. > > Hope this helps. > > On Friday, 19 December 2014 15:18:30 UTC, Arnaud Bailly wrote: > > Hello, > > I have been developing with Om and clojurescript for a few months now, > and I do feel I am missing something to get as productive as I am when > working with Haskell (or java for that matter). > > > > > > I would appreciate some advices or pointers resources from more > experienced people on how to get to the point where I can develop > confidently, easily and with decent speed in clojurescript. > > > > > > Here are my main concerns and some experiences I can share to give more > context: > > - compiler is slow: I have setup cljsbuild profile to use advanced > optimisation which heavily slows down compiler. Even simple optimisation is > rather slow. No optimisation is rather fast, but not that fast (several > seconds...). Note that I "often" have to remove generated compiled file and > target/ dir to get usable result when doing advanced optimisation, > otherwise I got seemingly unrelated runtime errors in the UI > > - compiler is not very helpful in catching errors: Error messages are > ok, at least better than default clojure and its sometimes huge stack trace > (or is it something from cljsbuild?), but of course not having types means > fewer errors got caught... This is not an issue when one has the fast > feedback of the REPL but large compilation time makes it really unwieldy. > > This is particularly annoying in Om because it requires state to be > stored in an atom which in some contexts can be manipulated directly and in > some others need to be dereferenced... And it is very easy, at least for > me, to forget/add an @ > > - unit tests are hard: code is mostly Om/react DOM building and ajax > requests, so pure unit testing is not really useful or would need too much > mocking. There seems to be a testing framework for React but I could not > really figure how to use it given react is actually encapsulated under > Om... I tried to write unit tests manipulating DOM elements but got stuck > on how to simulate a change event. My JS-fu is probably lacking here but > although I was able to synthesize a click, it was not possible for a > change. > > - I resorted to selenium tests, but of course those are fragile and > slow and I would like to avoid having to fire a server for testing part of > client application > > - I tried to LightTable, but not being able to use repl/instarepl means > I am left with a text editor less powerful than emacs. I user LightTable > with clojure code and found it really nice so I would like to be able to > use for clojurescript too. > > > > > > As I said, I have been coding for a living mostly in statically (or not > so statically) typed languages (Java, Haskell), but I have been using > clojure for side projects in the last few years and I really enjoy coding > in clojure. So when I discovered Om I was really enthusiastic about its > capabilities and the way it expanded my horizon to make programming in the > browser a more pleasing experience. > > > > > > But my coding flow is not satisfying, it takes a long time to iterate so > I tend to do larger steps which creates bigger mistakes which take a long > time to track... And I positively hate using a debugged, especially with > optimised clojurescript compiled code :-) > > > > > > So this post is really not a rant at all, I just got the feeling I am > not doing things the right way and would like to be enlightened by people > more knowledgeable than me. > > > > > > Thanks in advance, > > > > > > > > > > > > > > > > > > -- > > Arnaud Bailly > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to a topic in the > Google Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/7o7tX7ktOvM/unsubscribe. > To unsubscribe from this group and all its topics, 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.
