The whole principle of isomorphic web apps is that views are shared (reused as is) in both the client and server. What remains is data fetching, routing and logic. When you use the same language for your server and client, you have the way of sharing them too. It’s very true in the JavaScript world where many npm modules can be used in both sides, taking care of environment differences for you transparently. It’s also true for Clojure since we have .cljc. In our case, data fetching and routing is different delibaratley, but logic is the same (.cljc). As we’re moving to SPA, we’ll share most of our routing logic too. We do do data fetching differently on purpose because for some cases it make sense to have the data only client side when the user starts interacting with the page.
Maybe when using the likes of Om.next/Fulcro you can reuse the same code for data fetching, not sure about that.
I am curious about whether you are using a framework for your implementation, or if you are composing libraries yourselves? In both cases, which have you chosen?
Rum for the UI (it’s isomorphic on the JVM) complemented by citrus for UI model (isomorphic state management for rum). The rest is a classical web app, we’re using pedestal and other stuff.
Thanks for bringing rum and citrus to my attention; somehow I have missed them previously. Your approach sounds interesting. When Rum renders on the server with citrus, is the result a complete HTML document that does not depend on any Javascript to populate data? When reading the citrus docs that is my impression.
Exactly. It’s also the case with rum only BTW.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.