Deno (by the creator of Node) is another option, meant to be a more secure runtime env with TypeScript support out of the box. But it’s too early to talk about this alternative.
What’s the big deal about running a one-language show?
The power of having the same programming language for most parts of a system is not to be underestimated, especially if you are interested in the following topics:
Let us discuss further…
Assembling a “dream team” of full-stack engineers is not an easy task, and sometimes it is considered not ideal. There’s a saying that goes “jack of all trades, master of none”. The truth is, BackEnd, FrontEnd and DevOps are very different worlds and it is always helpful to have one Guru for each of these roles.
The presence of a full-stack engineer is good when flexibility is a requirement, which is mostly the case for small teams, like those of a startup. In the corporate world, it is very common to have specific roles with narrow tasks. But startups can’t usually afford this.
At my previous company, we’ve built a team focused around the idea of full-stack engineers, but with a clear focus. Basically, it’s a mixture of the corporate and startup approach. This allows us to have flexibility when required (which is often the case) but also have Gurus of different parts of the system.
In my previous company, we had a microservices architecture managed by multiple full-stack teams that enable us to be flexible but with a clear focus.
Wait…? Did I just repeat myself?
Isn’t that bad…? Don’t repeat yourself or DRY is a very important principle in programming and the JSE is here for you.
We’ve all heard about the benefits of code reusability, but just to remind you of a few: easier code maintenance, fewer unexpected bugs, cleaner and leaner codebases, consistency, easier testing, and more…
These benefits are not to be taken lightly, especially when your team starts to grow along with the codebase. It’s fair to say that this (code reuse) comes almost for free when you are in the JSE, and I say almost because for this to be true, you and your team must think of writing reusable code, at least when possible and needed of course.
It's common practice to have a repository (and sometimes even a monorepo) where you store all the different shared libraries that will be used for both the microservices and front-end applications. This approach facilitates us developers to write code in a reusable way that is maintainable.
Where am I trying to get with this?
Some may include good use of third-party libraries and frameworks, code reuse (DRY principle, which was explained already), code formatting (which in the JS world can be standardized for both BE and FE).
When defining your tech stack you have two options here:
Go with opinionated frameworks that will tell you how to structure your code for the frontend and for the backend.
Design your own architecture and maintain it — we went this route at my previous company because we wanted customizability — and it has worked really well for us.
In the end, a bad codebase is an issue caused by developers. If you don’t believe me, look at Facebook. They’ve built one of the biggest and most popular platforms in the world using PHP, a language that holds a reputation for allowing hideous code (syntactically and logically). But that’s the key point: it allows it. This doesn’t always have to be the case — and Facebook’s achievement is proof.
With the JSE, you have all the tools to create an architecture that will scale, be maintainable, and be readable, we and other companies are doing it already.
Chances are, you’ve already been stuck with some rare issue (or at least you think it’s rare) related to your code or a library/framework you are using. This could have gone multiple ways for you:
A solution was found online without much trouble
You had to post the issue online and wait for a savior
It was fixed with a sketchy workaround
Another benefit of an active community (that some may see as a disadvantage) is a big amount of libraries or frameworks that are being released frequently.
This can bother developers as they have to learn new technologies all the time to stay relevant. Don’t get me wrong, it does bother me sometimes — but once you have enough experience with coding and working with frameworks, picking up a new one is easier each time.
You truly start to appreciate this when searching for a specific library or utility. Take a look at NPM and see what I am talking about. Also, it’s worth noting that API developers know that the JS community is one of the biggest out there — so usually you can find library wrappers for popular APIs.
The idea is simple: if you have one language, you require fewer tools. In the same manner that you can reuse code with JS, you can also reuse tools. This includes:
Text editors and IDEs
This is really nice to have: you can create one configuration file for your linter and use it in every application, helping standardize all the code with the same format. One of the most popular options is ESLint.
Stick to one framework for testing your code; after a while, you can focus on the tests and not on how to use the framework itself. One of the most popular options is Jest or Mocha.
As we will explore right after this section, the community for open source libraries in JS is one of the biggest in the world. And you can use most of these libraries on both ends of your app. There are two main options: yarn or npm.
Wrapping it up