Skip to main content

Mutable Ideas

Should a backend developer learn Javascript?

I’ve been working with static-typed languages for several years now, C# / Java / Scala developer and I like the safety and guarantees of having type checking, also the whole JVM ecosystem aged well with great building tools, libraries and lots of experience from the community. But I cannot ignore all the buzz around Javascript and I don’t want to be prejudiced about something I didn’t work directly for several years.

This is a very overdue blog post that I had on draft for almost an year, but I believe it is still very relevant yet.

So I asked on Twitter “How a #Java / #Scala developer can learn modern #javascript? Does it make sense? Where should I begin? Thanks for pieces of advice”, the thread lasted for 2 days with several responses, I learned a lot and thought it could be useful to others:

# Popularity

A constant argument in favor of Javascript is it has a huge community, so it is easy to find professionals - although it is probably true, I see JS as an entry point for a lot of people, which of course is good, but I feel you try to find experienced professionals, there is the same shortage as any other mainstream programming language. In the other hand, I found out a lot of people is avid to learn more and defend their loved language - it is good to have a lot of people to have a conversation, and learn with. The only downside of this huge community is to be able to buy a ticket for JS events, they sold out faster than any Rock concert 🤟😎.

# A single language for Backend and Frontend

I’ve mixed feelings about this one, I certainly understand the appeal of having the same stack Frontend/Backend - Every major language in some point in history tried to come up with a translation mechanism so you keep writing in your preferred environment. I could mention Scala.js and many more. I’m convinced leaning different languages and abstraction help you become a better professional, it is not about proficiency in every single language, but understanding why it was designed this way and which advantages it brings to the table. This comparison experience will most likely improve your understanding and skills on your preferred language (JS or not). Learning Scala/Functional paradigms definitely sharpened my Java skills.

# No static-types, no schema, nothing is enforced

Maybe this is the most controversial point, I don’t believe total freedom in programming is a good thing, having a structure, rules and constraints aren’t inherently bad - they give us a sense of how things have to be done and you can start from there, only when you’re proficient enough you understand when/how it is ok to break the rules, not the other way around.

This talk 0-60 WITH TYPESCRIPT AND NODE JS - YouTube from Bowden Kelly is very enlightening on how code becomes unmanageable on big projects without a type system.

Some developers may argue there are templates, design patterns and best practices which help you to create a more structured project, but AFIK they are suggestions, not constraints, which means you may not even realize you’re parting from the best practice you’d like to follow and nothing will stop you.

I’m definitely not a fan of schema-less and 360 degrees of freedom: “There is no schema” is one of the biggest modern lies - you “gain” the responsibility to enforce a schema on your code. Not a pleasant task 😞… https://t.co/5xXWo4lPjC"

## => Implicit Schema = Bad Idea

Martin Fowler wrote about this issue:

Schemaless Data Structures Schemaless Data Structures

# Javascript changed a lot in the last years

If I had to reduce to only one phrase why Javascript got my attention, I remember a conversation with Guido Vilariño (@gvilarino) when he told me “Javascript changed a lot in the last years, it is not what you were used to …” - it got me thinking and now I’m, trying to make sense of all this stuff :)

You probably already watched WAT talk and laugh a little, but besides laughs, it rooted a sense of a poorly designed language and with unexpected results all over the place - not good branding. With kept me away from revisiting it.

And indeed a lot of things seems more structured, better documented and with more community and examples.

It is refreshing to see the creator of something as massive as NodeJs give a talk about “what I did wrong” and of course propose a new path - I think it is not a small feat and definitely help the community to grow and improve.

10 Things I Regret About Node.js - Ryan Dahl - JSConf EU 2018 10 Things I Regret About Node.js - Ryan Dahl

# You can quickly create something

This is another argument that came up often and it is very true, just throw a few lines and run node and you have an API - it has an incredible appeal for rapid prototyping and you can see things working. My concern here is more about maintenance than just release something, yes MVP, product fit, shrink the release cycle are all things everyone is used to, BUT when you find your market fit your company will start to grow very quickly, as your code base, and you just don’t want loose time understanding language quirks, you just want to ship your product.

# Serverless

Although Serverless doesn’t restrict you to Javascript, when you pay for milliseconds to execute your functions, Javascript and Node.js excel when compared with JVM for example. I didn’t have the time yet, but I’m very intrigued if I can make it launch faster using Scala Native or GraalVM.

## My own learning path

Eloquent JavaScript, 2nd Edition

[Eloquent JavaScript, 2nd Edition Book](https://www.safaribooksonline.com/library/view/eloquent-javascript-2nd/9781457189821/)

Reactive Programming with RxJS 5

[Reactive Programming with RxJS 5 Book](https://www.safaribooksonline.com/library/view/reactive-programming-with/9781680505528/)

Get Programming with JavaScript Next

[Get Programming with JavaScript Next: New features of ECMAScript 2015, 2016, and beyond Book](https://www.safaribooksonline.com/library/view/get-programming-with/9781617294204/)

## My Take-Aways

I still have a long way to learn, it’s clear that anything UI related Javascript is a winner, even when companies drop Javascript in favor of native an integral solution_language and toolset is a winner for most companies to reduce development_operational complexity.

For the backend (ie: transactional systems) the lack of a type-system will make maintenance of large systems very difficult, once this kind of error seems to be the most prolific in projects, perhaps #typescript will fill this gap.

I have a long way learning, as of today I would not choose Javascript for a backend system, although it is very refreshing to see this language growing and maturing, definitely it is not the same language it was years ago.

## Should a backend developer learn Javascript? YES

Based on my short experience and the signals I see from community, I highly recommend backend engineers to start learing Javascript, even if you won’t be using it as your primary language.

I was impressed when listened to Martin Fowler discussing the new edition of his book Refactoring: Improving the Design of Existing Code where all examples have been updated from Java to Javascript! Check the podcast

## Thanks & Acknowledgement

Lots of people took the time to get into the conversation, shared their point of view, material and expertise, for that I’m very grateful, it is a big list full of people I deeply respect and admire: