[usbsea]

What does "server do the heavy lifting" mean here - and is this much different to a Rails or Django type of thing? I know in Node-land there are less kitchen-sink options like this though.

The storage and k/v looks interesting. Django is pretty pluggable in that regard. Choose sqlite and a local redis and I think you probably have the same thing. But you do need to make choices and read docs to get there.

[jaysylvester]

It mostly means keeping routing/rendering/etc. on the server rather than client. My preference has always been to let the server render the initial request in full (feed the client an entire HTML document) and then update on the client side as necessary (which could be data via JSON or chunks of HTML, whichever makes sense) with progressive enhancement and minimal JS as the goal.

You can of course build an API with citizen that only returns JSON responses and do all the rendering on the client if you like. It's meant to be flexible that way. Basically, the client-side stuff is completely up to you. I've toyed with the idea of building a client-side companion library that wires everything up so server citizen and client citizen talk to each other and do what I described in the previous paragraph automagically.

I started citizen a decade ago, so many options available today were either non-existent or in their infancy then. I haven't performed a competitive analysis to compare features with other frameworks. You nailed it though on the lack of kitchen-sink-type frameworks in Node (especially 10 years ago), which is why I built citizen. And I didn't like the idea of depending on so many third-party packages.