Credit: Pixabay (https://pixabay.com/en/node-js-logo-nodejs-javascript-736399/)
I started off in my career fairly close to the hardware. I had learned C and Objective-C to work on the iOS platform. I had a lot of control over the software and I had to learn to manage memory and spend hours or days fixing an issue that was caused by my own negligence and oversight (this was pre-ARC). My career grew with a bias towards iOS and I started learning Java (and more recently Kotlin) to branch to Android.
With Android development, memory management was less of an issue due to a forgiving garbage collector. However, I still had a lot of control over the application lifecycle and I was forced to learn the differences between the two major mobile platforms and from interface to functionality that’s a lot to take in.
I stayed in my comfortable bubble whilst scoffing at JavaScript developers — mocking the terrible performance of web apps. I refused to touch JavaScript for a long time and would always reluctantly attempt a more familiar taste such as TypeScript. It’s still JavaScript but at least I didn’t have to type it. I liked my variables and constants to have an explicit type. Years of memory management had me on edge.
If you own a car, the chances are that you don’t get along with cyclists sharing the road. There is psychology behind this and it’s commonly known as the free-rider problem. It took me a long time to realise that the reason I didn’t like JavaScript developers was because of this psychology. I had put years of effort and pain into learning memory management and application lifecycles. I thought to myself “JavaScript developers get to share my title without paying the price of memory management or understanding of software lifecycles?!”.
Credit: News Corp Australia
As I grew and became less content in my career, I started to have my own ideas. My idea required a web application with a few basic features like access-control and authentication. It needed a few endpoints and resources. I did some research and came across NodeJS. I thought I might as well give it a shot since it looked fairly easy to setup and was well supported. It took me one evening to get this web application up and running. One evening. This is the stack that I threw together.
- NodeJS (Server)
- mLab (Mongo DB)
- PugJS (Template Language)
- Several
npm install --save xxxcalls
A few hours hacking around and I had a functional web application with a functional authentication system and access control. I didn’t care about Redis, Docker, K8s or any of the good stuff yet. My MVP was built. I could test my product. I had a sandbox database with no backups, I had an unscalable product hosted on Digital Ocean. However, I tested this product with real users and realised it wasn’t as magical as I dreamed. Oh well, nothing wasted, just learned.
I started learning more about JavaScript and the unfamiliar package economy it had. Developing on iOS and Android, you are expected to use a few common dependencies like Alamofire and Retrofit. I expected a similar level of dependencies in JavaScript. I was so wrong. I soon realised why it was called the world wide web. It was literally a huge web of dependencies. This was a scary experience for me.
Credit: Pixabay (https://pixabay.com/en/spider-silk-bokeh-rain-arachnid-1287407/)
However, after learning a few rules such as using a transformer with polyfills, the most common dependencies and the general ecosystem — I started to get much more comfortable. I was able to create an MVP of any product in a couple of days. That’s an impressive turn-around and it’s all thanks to NodeJS.
Once an MVP worked out, it was time to invest time elsewhere. I started to branch out and care about scaling for my specific needs. NodeJS is not a silver bullet. NodeJS is great for some uses but like any other language, it’s not to be used just because you’re familiar with it.
As for the language itself, I used to be disgusted with JavaScript. The core reason for this is that I used to use ActionScript 3.0 a while back. Both JS and AS3 were ECMAScript so why was AS3 so much nicer than JavaScript? Compatibility. It took me a while to realise how important browser compatibility was for JS. Once Babel started to be adopted, JavaScript started changing fast. It made some mega improvements. I actually enjoy writing JavaScript now whilst being assured that legacy code is being created under the hood.
This post is primarily targeted at people who scoff at JavaScript. I still don’t like the idea of “native” JS applications. However, I understand just how much flexibility this gives to desktop/mobile apps and it’d be hypocritical of me to be sat here on VSCode whilst slating them. I do like the idea of hybrid applications that have some core components written in a low-level language which is an approach a lot of intensive desktop web-apps are doing.
If you see a developer that hates JavaScript, it’s probably because they perceive you as a cyclist taking over a space they believe they’re entitled to.
If you liked this article, please clap and follow me to read my future content.