Much of the client-side code is about manipulating the DOM. Such code must assume the DOM-API exists. So such code can not run on the server unless there is some kind of ducky DOM environment there as well. And since client-side relies much on destructively manipulating the DOM, how can such code be tested on the immutable clojure server?
> sizeable parts of the code are cross-compiled to run both on the browser
But not all, right? I think the challenge would be knowing which parts can run on both the client and server, so you can know which parts can be moved between client and server.
But code is typically intended to run on either the server, or the browser. What would be the practical benefit of moving code between those environments?
I have not used Clojure so I'm asking because I have a similar circumstance with Node.js on the server, and DOM-manipulating JavaScript on the browsers, and its not easy to move code between those environments, and secondly, I don't much see the need for doing so. Naturally testing everything on the server would be nice, but I'm not sure how my DOM-manipulating client-code can be tested on the server.
I did a project where we used ClojureScript both on the server and the client. The server ran on Node.js and so most libraries could be used on both the server and client. We used reagent to render our app which made it possible to use reacts render DOM to string functionality.
Essentially the app was developed as an isometric app, and we had some additional stuff in the server part of the application.
While running ClojureScript serverside might not be everyone's cup of tea, it worked well for us.
> Much of the client-side code is about manipulating the DOM. Such code must assume the DOM-API exists. So such code can not run on the server unless there is some kind of ducky DOM environment there as well. And since client-side relies much on destructively manipulating the DOM, how can such code be tested on the immutable clojure server?
The same way as it's done in React. Think of a client app as a loop reacting to user /network events and turning state into html. The same way it's done on server.
That's why the same code can be used on client and server. The simplicity of the process (uses pure functions to turn immutable data structures to html) means that it can be also easily unit tested.
> sizeable parts of the code are cross-compiled to run both on the browser
But not all, right? I think the challenge would be knowing which parts can run on both the client and server, so you can know which parts can be moved between client and server.
But code is typically intended to run on either the server, or the browser. What would be the practical benefit of moving code between those environments?
I have not used Clojure so I'm asking because I have a similar circumstance with Node.js on the server, and DOM-manipulating JavaScript on the browsers, and its not easy to move code between those environments, and secondly, I don't much see the need for doing so. Naturally testing everything on the server would be nice, but I'm not sure how my DOM-manipulating client-code can be tested on the server.