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.
To me, writing an article titled "potatoes are rounded" and somebody replies to it asking "why you think potatoes are rounded" which was previously being showed (as my opinion) is either trying to discredit or challenging my point or view, which for me is fair but I think is beyond scope.
First being compared to spring (I get it as a bad thing, that's what it seems to me) and being asked "what about your code you find idiomatic" well.. even if we have different opinions about what means idiomatic: we can disagree about sky's color (sunny day), but we cannot disagree on that being similar to the sea. As a matter of fact I beg you to compare building the same app features on top another library or framework you choose.
I prefer to discuss about concrete things. Even if we disagree it would be enlighten to the community.
This article, as part of series, aren't fully concluded, this is not the full picture. If you're interested on more in deep information about the library then, please go check it github.com/k1r0s/ritley
The whole point of the article:
I think my code here, on this tutorial is easy/simple to grasp, follow, understand, etc
As I said, to me idiomatic code is code that follows the design principles of the language and the common patterns and constructs native to the language that the community has identified as most useful to write succinct and expressive code. You seem to define idiomatic code as just good code. The way I see it, idiomatic code should result in good code most of the time, but it doesn't always, and good code isn't necessarily idiomatic.
Thus, when I read a title saying idiomatic Javascript, I understand that you are saying this code is a good example of how Javascript should generally be written because it uses the patterns native to the language that have been tested and deemed most useful to write expressive code across many applications.
From this point of view, claiming that anything is idiomatic Javascript is a rather bold statement, because Javascript is a chimera that has evolved in the recent years to please everyone without a unified vision of how the language should look like or be used, and there is no central authority that either of us can quote to support what we consider idiomatic, like we would have in Python, for instance.
At this point, I think discussing any further is pointless because it's clear that we don't think about idiomatic code in the same way and you've stated that you're not interested in such philosophical discussions. However, if you must know, here's why I'm surprised that you define your code as idiomatic:
It makes heavy usage of decorators. Apparently, most of your framework is based on adding behaviour to classes through decorators. Decorators are not part of the Javascript standard yet, and I don't think you can claim any code that heavily uses a construct that is not in the language, and needs to be transpiled to even be valid runtime code, to be idiomatic. It can be good code, it can be a nice approach, but it is definitely not idiomatic.
As a result of your heavy usage of decorators, almost everything that interacts with your framework is a class, because decorators can't be used outside classes. No object literals, no encapsulation via closures and partial application, no functional mixins... Javascript offers much more than classes and your code doesn't take advantage of it because it's heavily based on a feature that's not even in the language yet.
To reiterate, I'm not saying that your code is not good, I'm not saying that you should write it in a different way, and you have written your own web framework, which I haven't, so kudos for that. But I have trouble seeing it as idiomatic Javascript.
Thanks for the info tho!
btw, the previous version of the same library was written without any ES6 classes or decorators: github.com/k1r0s/ritley-alpha
to me, it seems more to angularjs, what do you think?
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.