Cool: With the new :module-type :commonjs feature for :foreign-libs, you don't need to specify a :requires vector—the dependencies are derived during CommonJS processing!

@mfikes right as they are proper Closure modules

I'm looking for a guide which tells me how to do prerendering with a clojure/clojurescript/reagent application + how to combine the server side + client side routing story

I guess the term for this would be isomorphic, so I'm looking for a ready to go example of an isomorphic cljs+react project

@borkdude: I’ve kinda done this with clojure/hiccup, om/sablono and a couple of macros. The code lives at my previous employer, so unfortunately can’t share it.

The macros weren’t much though.

@andrewmcveigh: do you end up duplicating routes on the client and the server, or do you only define one compojure route "/" and pre-render from there?

@borkdude: I used bidi for routing, using a EDN-only route specification, for both client/server

The routing essentially lived as part of a “config” namespace

This might be a bit more of a question for the #C053AK3F9 channel but what are pros & cons for Reagent vs Om?

@agile_geek: Reagent is easy to understand for already experienced Clojure(script) developers, since it re-uses the concept of atoms. Om forces you more or less to use one atom for the whole application that you can access by using cursors + API built around that.

I've tried out the demo app in this isomorphic clojurescript blog post: https://www.paren.com/posts/isomorphic-clojure-part-1

it seems promising, although very slow

@borkdude: Thanks for that. So are there use cases that favour the use of one over the other?

@agile_geek: I think it's largely personal preference. I favor Reagent because I like the simple approach.

@agile_geek: also Om is in a transition towards Om.next and they may not be compatible, so it may be worth waiting for that if you're choosing Om. Don't know the details. Ask @dnolen

not worth waiting

the current Om model isn’t going away

and Om Next is likely to be under dev for months

they will also coexist, and there will be some kind of bridge

there are far too many massive Om applications to introduce breakage at this point

@agile_geek: Maybe if you want to be able to recover your entire app from one state value, that is where Om really shines, because it (almost) forces you to work that way

@borkdude @dnolen: cool. I’ve looked briefly at Om but not at all at Reagent. Always hard when Clojure is not my day job. I think I’ll get some more OM under my belt then take a look at Reagent.

@agile_geek: you'll read through the Reagent documentation in under 15 minutes

@borkdude: I read fast but assimilate very, very slowly.

@agile_geek: either will probably get the job done.

@agile_geek: there's not so much too assimilate, trust me on that one

@agile_geek: I prefer to see the "app state" as more of a database

@borkdude: Isn’t much Clojure syntax but it’s taken me 19 months so far and I’m still not there 😉

@agile_geek: things take longer when it's not your day job, I feel with you on that one

i don't think it's accurate to characterize reagent as "the simple approach". om and reagent make a different set of tradeoffs. om's documentation is not substantially less approachable in comparison, and i don't consider it to be complex overall, nor complex in any specific area where it could possibly achieve the same with a simpler approach.

@borkdude and takes longer as u get older!

@jackjames: Yeah, simple is not the right word for it. My personal experience has been that Reagent has a less steep learning curve than Om. There are also less concepts to understand.

Maybe other people have different experiences. There's no absolute way of saying which approach is better, easier, etc. It is about tradeoffs, correct. Both are excellent libraries. Rum is also worth checking out, but I don't have any experience in it.

@borkdude: yep, when you put it like that, i agree completely

@jackjames: simple is an overloaded word in clojure, I should avoid it completely

In all approaches it may be best to first do the React tutorial so you know what happens inside, sort of.

OK, Thanks for the help @borkdude @dnolen @markstang @jackjames. Food for thought. As usual, I seem to have picked the one with, arguably, the steeper learning curve to learn first!

@agile_geek: to make your choice even harder, there's also http://hoplon.io/, which is not React-based.

@borkdude: Given I’m using this on hobby projects I think I’ll stick to React based libraries for now as both Reagent and Om seem to have some traction in the community and I can ask nice people like you and @dnolen for help

@agile_geek: Both Om and Reagent also have cookbooks (just google) and mailing lists

about pre-rendering: actually it would be enough if I could just fool google with some pages that contain relevant content, without any css

it may be less work

Would it be sane for SEO if I would render a page using certain keywords at /item/1 with a meta refresh to #/item/1 ?

probably the #! way is better

https://scotch.io/tutorials/angularjs-seo-with-prerender-io

sorry for rubber ducking this channel

nothing working quite yet but can now point the ClojureScript compiler at cljs.analyzer and generate JavaScript https://github.com/clojure/clojurescript/commit/20d120731aa3063dc7ccf43dcd7f0ccd81e9acac

@dnolen: awesome!

@dnolen: What’s left to do now then? Can’t be too much.

@andrewmcveigh: actually there’s quite a lot to do for it to be usable. However for the minimal viable thing, i.e. read forms and generate JavaScript - just need to port cljs.compiler, make macros work, fix the bugs.

One small step for analyzer... :)

@dnolen: should there be a public API for cljs.repl, like everything else in the quick start? i.e. cljs.repl.api/repl, cljs.repl.api/node-env, cljs.repl.api/nashorn-env, etc

the generated compiler API reference was omitting the important cljs.repl stuff. I suppose I can add an exception, but it just brought up the question of whether it should be in a public api or not