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.
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.
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:
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.
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.
My own learning path
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.
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:
- Guido Vilariño (@gvilarino)
- Douglas castilho (@doug001)
- Ignacio López (@TrueNacho)
- Fernando Otero (@fotero)
- Hernan Rajchert (@sherman3ero)
- Gustavo Andres Brey (@italchemist)
- Santiago Gaston Coco (@santiagococo)
- Freddy Vega (@freddier)
- Alejandro Oviedo (@a0viedo)
- sebasjm (@sebasjm)
- Ezequiel Aceto (@eaceto)
- Nicolas Gonzalez (@_nlgonzalez)
- Sebastian Arena