Thanks for the feedback, Bryan! I really appreciate the honesty, and you’ve touched on a very real shift in the JS ecosystem.
Regarding the this and class-based approach: you’re absolutely right that the industry has leaned heavily towards functional patterns and arrow functions recently. The choice to use classes in Rikta is specifically to support Dependency Injection (DI).
In modular backend systems, DI makes it much easier to manage services (like the GreetingService in the example) and, more importantly, makes unit testing significantly simpler because you can easily swap real services for mocks.
As for the decorators (@): I completely understand why they can feel like "magic" or be hard to reason about. In Rikta, we use them to declaratively attach metadata to your code (e.g., "this method should handle GET requests"). It keeps the boilerplate out of your logic, but I realize it requires a bit of a mental shift if you're used to a more literal, functional style.
Don't worry about the "TypeScript competence" part! One of my goals with Rikta is actually to provide enough structure so that you don't have to be a TS wizard to build something solid. The framework handles the "heavy lifting" of the types, leaving you to focus on your business logic.
Elixir and Phoenix are fantastic choices (concurrency there is hard to beat!), but if you do decide to stick with Node for your next project, I’d love to have you try Rikta. Feel free to reach out if you hit any walls—I’m always looking to make the "getting started" experience smoother for everyone, regardless of their TS experience level.
You spend more time explaining context than writing code. Copy-paste your architecture. Paste your design system. Repeat your database schema. The AI generates code. Then forgets everything.
This is vibe coding. And developers waste 3+ hours daily doing it.
Context-aware coding solves this:
• Your AI knows your entire codebase before generating a single line
• No more duplicate code that ignores existing utilities
• No more styling that clashes with your design system
• No more authentication logic that bypasses your user service
• Real-time updates when you add or refactor files
The difference? An orchestrator that indexes your repository and maintains conversation memory across your entire project.