JavaScript Everywhere
How entire companies are being built with mostly one language.
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 in the world wide 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.
Want to read this story later? Save it in Journal.
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 in this list 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 us, JavaScript is at the core of what we are building at Alteos, and this decision has benefited us greatly, as we have grown with our system.
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 corporate world, it is very common to have specific roles with narrow tasks. But startups can’t usually afford this.
At my 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, which is something we’ve been doing progressively at Alteos.
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: expect no shortage of good developers.
Code reusability
At Alteos, we have 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, specially when your team starts to grow along with 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.
We’ve built a repository where we store all the different shared libraries, like the ones mentioned before; we have these libraries as dependencies for our microservices and frontend 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?
Developers are the sole responsibles of 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 standardised 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 to do.
When defining your tech stack you have two options here:
- Go with opinionated frameworks that will tell you how to structure your code like Angular for frontend and NestJS for backend.
- Design your own architecture and maintain it — we went this route at Alteos because we wanted customisability — 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 of 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 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:
- A solution was found online without much trouble
- You had to post the issue online and wait for a saviour
- 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 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 a really nice to have: you can create one configuration file for your linter and use it in every application, helping standardise 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 are Jest and 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 in 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
About me
Born and raised in Costa Rica, currently living in Berlin, Germany working as a Software Engineer for Alteos GmbH, a company that AXA trusts will greatly influence the future of tech insurance.
Follow us for the next ALTEOS Tech stories — there are more voices to be heard!
More from Journal
There are many Black creators doing incredible work in Tech. This collection of resources shines a light on some of us:
