3 ms·

Obviously any observation I make is limited by my experience, but my experience of the last few years is that hardly anyone uses 'this' anymore in JavaScript be

Obviously any observation I make is limited by my experience, but my experience of the last few years is that hardly anyone uses 'this' anymore in JavaScript because everyone uses arrow function, generally mandated by leadership. This observation is of course just limited to the places I've worked. So the @Get('/') index() { return { message: this.greetingService.getGreeting() }; } example was weird for me to see, although not unwelcome. I am however not that great at Typescript, which again my experience of work is that most of the developers I encounter aren't, and just use it as a lightweight structuring tool for JavaScript. The @ decorator is thus always hard for me to reason about what is actually going on. On the other hand I might be using this in the new year [despite my relative incompetence in Typescript], if I decide to build my next project on Node (I am considering Elixir to use Phoenix, hence having to say "might"), all of which is a long-winded way of saying looks pretty interesting and nice work.

bryanrasmussen 10mo ago
when I say "not unwelcome", I generally have not been overly traumatized by 'this' usage as some people have, its tricky nature being somehow enjoyable to my mind.
riktar 10mo ago
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. Thanks again for the kind words!

bryanrasmussen 10mo ago

when I say "not unwelcome", I generally have not been overly traumatized by 'this' usage as some people have, its tricky nature being somehow enjoyable to my mind.

riktar 10mo ago

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. Thanks again for the kind words!