Hi Colin, you may find a description of our stack and experiences with it useful as one data point.
Note that we were supporting IE8 up until fairly recently, when we determined that our client base didn't require it any longer, and since it's such a pain to maintain we ditched it--but our stack could still probably support IE8 just fine. Otherwise we support IE9, IE10, Chrome, FF and Safari. The issues we run into for cross-browser support are generally unrelated to anything in the Clojure/ClojureScript ecosystem. Anyways, a quick summary of our stack: - Om on the CLJS side - SASS and Compass for CSS (that is, wholly Clojure-ecosystem un-aware) - clojure.test for all of our testing infrastructure, pretty much - browserchannel for providing a persistent client-server connection (we are the current maintainers of clj-browserchannel, having taken it over from Gijs not too long ago: https://github.com/diligenceengine/clj-browserchannel) - our own custom lib (https://github.com/diligenceengine/views, sorry docs still nonexistent) for database connectivity, wrapping HoneySQL and c.j.j - minimal integration with 3rd-party JS libs, only where absolutely necessary--for example, we rely on plupload for supporting multi-file upload in some browsers, but it is a major pain. - a bit of basic scaffolding on the server-side in enlive to get things up and running, load up our one-page-app front end, etc. - compojure and the usual suspects on the server-side for serving things. We use a pretty simple build script to get all our assets in order. It works for us, but I could easily see people making solid arguments for other solutions. You won't be able to support IE8/IE9 without browserchannel unless you do some sort of polling...use browserchannel. Om has been a life-saver, and we were looking for something like it right before it came out. I can't speak to other solutions, Reagent seems like it could be great for the right use-case too, but Om has fit our needs really well. Om + browserchannel + our views library is like magic. As mentioned above in general integrating 3rd-party JS libs is a pain. I've learned to stay away from it and go full-on React/Om as much as possible, even when it comes to Google Closure widgets--it's just not worth it. Our code size balloons everytime we have to do something using a Google Closure widget. And just say no to jQuery--there is no reason, if you are using Om or Reagent, to be relying heavily on a DOM manipulation lib. If you need to use one, I would choose dommy ( https://github.com/Prismatic/dommy) out of all the contenders. As far as testing--I've used midje on some other projects and as of six months ago, found it more complex than I needed--I like the simplicity of clojure.test. I'd like to be using QuickCheck (er, test.check) more actually. We unfortunately have almost entirely eliminated the CLJS repl from our workflow. The flakiness <-> usefulness value ratio is just too heavily leaning in the direction of flaky, in our experience, and lein-cljsbuild compile times are pretty fast in auto mode. YMMV. Recently we have been trying to integrate Prismatic's schema ( https://github.com/Prismatic/schema) wherever we can, and if there is anything I regret it's that we didn't do so sooner. I think core.typed is probably a good choice too. I think type-checking of some flavor is a must (as a project grows in size, especially). Happy to answer any further questions you may have--hope this helps. DD 2014-10-20 4:29 GMT+09:00 Colin Yates <[email protected]>: > Any advice for a newbie about to embark on a new non-trivial SPA using > cljs, om and (om-)bootstrap. > > I am not a newbie in terms of CSS, JS (coffeescript for the win!) or > Clojure (despite the evidence :)). > > The app itself will live on an internal LAN with a small number of > clients, heavyish logic but low load. It will be heavily influenced by CQRS > and event sourcing, with the server transmitting "domain events since you > last checked in" to the client. > > In particular, what do you wish you had done differently, specifically in > regard to: > - using JS from cljs (which unfortunately still makes my eyes bleed :)) > - integrating 3rd party components (e.g. jquery ui) with om > - unit testing (previously used midge work but I think I will stick with > core.test with the humane plugin) > - cross browser javascript (I assume the google closure library helps > here) > - hooking up a browser to the REPL (IE8 unfortunately!) > - web sockets/polling (again IE8) > > I am close to finalising on (but counter-arguments welcome!): > - Cursive clojure (falling back to emacs if necessary - so far it isn't) > - lein-cljsbuild > - garden for CSS (but happy to hear stories around asset management) > - core.typed > - core.test or midje > - transmit for encoding data > > (I have had a look at luminus and it seems great. However, I "get" om > architecturally more than reagent and I have already settled on a number of > other libraries. I have also looked at pedestal but it needs to be deployed > on Windows which they don't support.) > > Anything you wish somebody had told you before you started? > > Thanks a bunch! > > -- > 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.
