I used to fall into the trap of always wanting to build everything myself, which ironically led to me building a framework so I wouldn't have to do that over and over. So I agree totally.
Every "framework" available when I started with Node seemed to be a collection of loose opinions regarding Node best practices, lightly dusted with syntactic sugar. Functionality I considered table stakes for web apps usually involved choosing from several middleware packages with different maintainers and different syntax. Didn't like it.
Thanks for the compliments. I hope the community sees the value.
In reviewing the Adonis docs, I think the biggest difference between citizen and Adonis is convention over configuration.
citizen expects you to put certain things in certain places so it can handle all the imports, execution, and flow control for you. Adonis requires you to be far more explicit.
For example, in Adonis, you define routes within a router file, whereas in citizen, routes are implied by the existence of controllers and actions/handlers in the appropriate locations.
citizen does have config files (and controller/action config overwrites) for things that require an explicit setting, but I tried to keep that to a minimum.
I don't know what's out there that's similar to citizen, honestly. I didn't set out to create competition for existing frameworks; I just built the stuff I found useful for my own projects and think it's finally at a point where others might find it useful also.
Basically, I wasn't a fan of what was available 10 years ago, so I built what I needed and didn't pay much attention to what others were doing.
One of my fears in sharing it widely was getting a response like, "You're about 5 years late, frameworks X, Y, and Z do all these things already." But based on some of the comments, it seems like citizen offers something that others don't.
What I like about citizen is that it provides enough structure to get started, keep my code organized, and focus on what I'm building as opposed to how, while remaining flexible and hands-on enough for me to feel like I'm actually writing code and not just gluing together everybody else's code.
As you've noted, citizen is clearly written to handle pretty much everything within the application server itself, which stems from my own particular use cases.
I suppose that's my anti-pitch: citizen caters to apps that can run comfortably on a single instance and accommodate storage within that instance, or have a web server in front that can distribute clients across multiple app servers and keep each client on the same instance so as to preserve user sessions across requests.
Now that I consider it feature-rich enough for general use by other devs, I'm thinking about how it could be expanded to accommodate external storage solutions and make the app server stateless.
I opened this months ago and it directly addresses your point:
The same question applies to citizen's built-in caching, but if I uncouple that from the app server, I have to ask why the dev wouldn't just use a third-party caching solution instead.
As for external data, I deliberately left models wide open and un-opinionated. They're modules you can put anything into. For my own apps, I use node-postgres, and my models contain all my SQL queries and interact directly with the database. citizen doesn't interact with the model in any way besides storing the module in the global scope so it can be retrieved without importing it (which I do to support hot module reloading).
Curious to see what you've been working on and your approach.
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.
Looking forward to your feedback.