This week I started working in a new company, my previous working place wasn’t so development focused, while now, at a consulting company, the abundancy of developers around me is no surprise at all.
Academically and professionally my development focus was always .NET, majorly web development, so there was not much space to dig around other technologies due to my personal project’s fields belonging in game development.
This first week was all about training. Training in NodeJS. Training in AngularJS. Training in Knockout. Training.
All of these are JavaScript based technologies. JavaScript by itself is far from being my favorite programming language, but being a web developer for two years and a half it’s no surprise that I had to face this functional, closure infested, dynamically typed beast, which has some significant differences when implementing a solution compared to C#.
In various discussions that I had with other friends and colleagues of mine about these technologies there was never really a major reason that could convince me about changing my preference from ASP.NET MVC or ASP.NET Web API, but that doesn’t mean that instantly called them useless.
So, one week has already passed and now I can express my opinion with a different point of view.
In terms of code size writing a frontend page in NodeJS using AngularJS is way smaller than doing it through ASP.NET MVC views, and I can say the same about code readability, but I still prefer statically typed code, makes avoiding errors way easier and makes IDEs become a more useful tool. It’s true that using JavaScript gives developers more freedom when writing code, this can be both a good and a bad thing, since some people might abuse of this freedom and write real spaghetti code with just a few lines.
Another concern of mine is when doing big code refactoring, breaking a dynamically typed application becomes much more easy than an application that requires to be compiled first allowing some initial errors to be detected in an early stage, I know that unit tests avoid this kind of problems, but in a real life situation it’s difficult to write unit tests for everything and cover all the possible use cases, but who said that a developer’s job was an easy job?
I still haven’t explored the creation of backends using NodeJS, it will come at some point for sure, and I’m quite curious about it.
For sure this was a fun week with a lot of new things learned and some new problems to solve, but the idea that I wanted to communicate with this post is what I always say: there’s no tool or programming language that invalidates others or that is 100% better than the remaining ones, it all comes down to the developers taste and the problem that has to be tackled, and the best way to discover where our preferences are is to try the possibilities and decide by ourselves.
Shared Node 