I think it might appeal to devs like me (old guys) who came up on app servers like ColdFusion, .NET, PHP, etc. and prefer the server do the heavy lifting. It doesn't dictate anything about your front end, and instead tries to be as flexible as possible in providing whatever output the client might need, whether it's a single fully-rendered HTML view, partials, JSON, or plain text.
Only 2 direct dependencies for terminal commands (commander) and file watching (chokidar). Built-in functionality includes zero-configuration server-side routing, session management, key/value store (cache rendered views, controller actions, objects, and static files), simple directives for managing cookies, sessions, redirects, and caches, and more.
It's been in continuous use on at least one site that receives hundreds of thousands of page views per month, running months at a time without the process crashing. Fairly stable.
Appreciate any comments/feedback/contributions.
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.
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.