hey nils. there are two main design differences

first, play-clj had a very restrictive built-in way of handling state. each screen had a way to store entities and other bits of state, which ended up being inflexible for many people. play-cljs has no mechanism for handling state; you can use a global atom, or whatever else you like.

second, play-clj represented entities as a flat list of records, each storing a special java object inside, and had a ton of macros to make it easier to make all the java interop calls. play-cljs represents entities as hiccup-style data, which means it can be manipulated like any clojure data and also can represent complex hierarchical scenes.

i made the first change because the restrictiveness of play-clj's state system was probably the number 1 complaint i got. i made the second change because i had such a great experience with generating html using hiccup/reagent and figured a data-oriented approach would work for games as well