Hi everyone! This part of series Idiomatic JavaScript Backend.
Part 1/3
Part 3/3
Important Information
For best experience please clone...
For further actions, you may consider blocking this person and/or reporting abuse
I'm with Theofanis here, your code looks a lot more like the code I wrote back in the days when I developed web services with Java and Spring than any node app I've ever seen. Be far from me to tell you how you should or shouldn't write your code, but I have to ask: what about your code is idiomatic Javascript?
Hey! thanks for your comment. To me, compare my code with Spring is more than a compliment than a bad thing. But I have to point out that this framework is far far simpler. Library core is less than 80 lines, adding the extensions probably 170.
To me idiomatic code is a piece of code that doesn't need any inline comments or explanations to understand whats going on, as long as you've knowledge on the language it self.
This article is part of a series so this development has not concluded yet. But try to do the same app with express (full app) following requirements and then tell me which one is more idiomatic. Deal?
It sounds like we don't share the same definition for idiomatic, then. The way I see it, idiomatic code is not only easy to grasp, but it follows the common conventions and constructs of the language and takes advantage of its expressive (or lack thereof) power. I really like the definition Corey Goldberg gives in this SO question:
I might take on your challenge if I manage to find some free time, but I'm afraid we both would end up preferring our own code for obvious reasons. Anyway, I don't think my own Javascript code is always very idiomatic because I tend to use a lot of functional constructs more common in other languages, so... shrug.
For me, a language should be easy to grasp or understand. That's the most important goal.
Anyways languages tend to evolve and find shortcuts. JavaScript for example has been evolving since its creation that means drop some features to use new ones. Its like you're telling me that a language is something metaphysical rather than a tool that should fit or needs..
Of course each of us will prefer what is best for our experience or knowledge. Thats why languages evolve when new comers use it. Since 2009 JavaScript has changed a lot because of new comers from languages like Java and c# (.NET). People back on the days was comfortable with prototypes and callbacks. That was the:
I don't mind abot the challenge, use what fit best for you. But I don't get the point of this discussion.
I beg your pardon? I never meant anything remotely similar to that. All I said is (a) your code looks more like idiomatic Java than Javascript to me; (b) so what makes your code idiomatic Javascript?; and (c) oh, we define idiomatic differently, that would explain my confusion. I'm sorry if it came as me somehow challenging your code.
However, if we would discuss what idiomatic Javascript (by my definition of idiomatic) is, then we would definitely enter the realm of philosophy and metaphysics and should abandon any hopes of ever reaching a satisfactory conclusion. Mostly because the language has evolved without a unified vision and there are several interested groups trying to stir the evolution of the language in the direction they find most appealing; and there are as many opinions in that regard as developers, and no authority that can be reliably quoted.
But now I digress...
The point of this discussion appears to be that we have different definitions for idiomatic and I wasn't aware of that, therefore I asked. Clarified that point, however, I see no reason for any further discussion either.
Are you sure you are using the right language here? It reminds me of Java ...
Good, Java has annotations (kind of decorators). I don't know if you think if this is good or bad. To me decorators are a powerful tool. Many frameworks make hard use of them.
Yep, I'm using the right language here.
Decorators are harder to use than misuse. Plus they are experimental (stage 2) so expect some debates against them.
Discussion is only on implementation details, they're unlikely to remove any of its features as I see on tc39 threads, even adding more.
Decorators are very easy to use if you know to do that. I think you're a bit influenced by your past experience with Java annotations. I know, that thing was a nightmare.
I do find that the problem was some design failures by framework it self (spring) rather than the idea about use decorators to encapsulate behaviors.