Some love it, some hate it, everybody uses it — JavaScript is present in almost every single website you’ve ever visited. And if you don’t believe me, try surfing the web after disabling JavaScript in your browser — good luck with that, truly.

Nobody can deny the strong influence JavaScript has had on the worldwide web, as all major browsers can execute JS, which developers use to add interactivity to web pages and enhance our experience.

But how are things looking for JavaScript, beyond our browsers?

JavaScript beyond our browsers

JavaScript is no longer being used solely on the client-side, but this is not news. Most likely you’ve heard of Node already, which is a run time environment that allows you to run JavaScript outside of a browser.

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.

JavaScript is powering the frontend and parts of the backend (thanks to Node) of some of the most used services in the world. To name a few, we can include the likes of Netflix, Paypal, Linkedin, Uber, eBay, Walmart, and even some projects at NASA.

It is hard to resist the temptation of working mostly with just one language. For my previous company, JavaScript is the core language, and I believe that this decision benefited us greatly, as the company has grown along with its platform.

What’s the big deal about running a one-language show?

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:

• Flexible teams

• Code reusability

• Code quality

• Active community

• Coding tools

More benefits can be achieved when you join the JavaScript Ecosystem (JSE). But from my experience, the points mentioned above are the most noticeable when working with a team.

Let us discuss further…

Flexible teams

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.

Having one language allows companies to develop their frontend and backend developers to be full-stack engineers. It’s also worth noticing that good teams can be assembled more easily since JavaScript is one of the most popular programming languages out there: you can expect no shortage of good developers.

Code reusability

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.

Using JavaScript in the backend and on the frontend has allowed us to reuse a lot of code, such as dictionaries, interfaces, utility functions, payload validation libraries, and many more…

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.

Code quality

I know what you might be thinking… this sounds controversial as JavaScript is often accused of promoting the infamous spaghetti code.

As we have been discussing, JavaScript is a very powerful language. And as we all know, with great power comes great responsibility…

Where am I trying to get with this?

The Developers are the ones responsible for producing a quality codebase. To do so, some good coding practices have to be followed and luckily for us, JavaScript facilitates many of these practices.

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).

As for structuring your code, it is true that JavaScript is more liberal than other languages and doesn’t force any specific architecture to be used. Even more, you can choose to have types or not, which I highly encourage you to do.

When defining your tech stack you have two options here:

1. Go with opinionated frameworks that will tell you how to structure your code for the frontend and for the backend.

2. 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.

Active community

Leveraging the active and ever-growing community of JavaScript is not to be taken for granted, hear me out…

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:

1. A solution was found online without much trouble

2. You had to post the issue online and wait for a savior

3. It was fixed with a sketchy workaround

The likelihood in the JS world is that you are not the first one encountering this issue, and more than likely there is a solution out there for you just waiting to be read. And if not… the community for JavaScript is big enough that you can rest assured your issue or question will be answered.

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.

Coding tools

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

  There are two big players here: VSCode and WebStorm, they both are excellent for JavaScript and NodeJS applications. Not to mention if you like JetBrains products, you only need licenses for WebStorm and this will cover both FE and BE.

• Linters

  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.

• Testing frameworks

  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.

• Package managers

  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

JavaScript is a great programming language that is still evolving with every new ECMAScript specification. It sure has flaws just like every single language out there, but the one thing that sets JavaScript apart from any other language is that you can run it everywhere. This while running on the client’s browser, on a server, and even to build mobile or desktop apps.

The amount of libraries, frameworks, support, and money invested in the language by many of the top tech companies in the world has made it clear: in the upcoming decades, JavaScript is here to stay.

“Keep betting on JavaScript” — Kyle Simpson