DEV Community: Henrique Leite

TypeScript (and JSDoc) vs JavaScript

Henrique Leite — Thu, 24 Oct 2024 19:59:28 +0000

Introduction

Even in 2024, 12 years after the release of TypeScript and 17 years after the release of JSDoc, many people still dont know why to use a static typing tool in their JavaScript project, even after it became a standard in the JavaScript/NodeJs community.

In this article, Ill explain what TypeScript and JSDoc are, and why you should use one of them in your projects.

What they are

TypeScript and JSDoc are tools to allow JavaScript to have static typing. See below for an example of both of them.

As you can see, TypeScript usually is less verbose than JSDoc, but on the other hand, JSDoc doesnt require a build step, it works directly with comments in JavaScript code.

TypeScript

convert-string-to-int.ts (TYPESCRIPT file!)

JSDoc

convert-string-to-int.js (JAVASCRIPT file!)

Pros

Before speaking about the pros, I must say that no matter how many articles you read or how good these articles are, theres no way to describe how much better the developer experience is when you work with static typing.

No one can explain with words or arguments how good it is to work with a codebase that has static typing over an untyped one, not even the best of poets.

I, like many others, will try to translate this feeling into facts and data, but I ensure that it will not be enough to describe the exact feeling.

Avoid errors in production

This, without a doubt, is the biggest advantage of static typing. There are not enough words to describe how helpful it is, both in terms of avoiding reworks and saving money.

To ship things fast, mainly hotfixes, we end up not having the time to write unit tests or test all the possible flows of a solution. If you work with pure JavaScript, theres no way to ensure that:

All the variables that you are using exist
All the variables that you are using are declared
You are using allowed methods for that type (ex: you can use map in a number variable)
If you are comparing equivalent variables (you shouldnt compare an number with an array)

If you do not test your code extremely well, you will have to work on it again to fix a bug, spending precious time on something that you could have coughed before. Bugs caused by these things may sound stupid, but they are the ones that happen the most.

Using static typing, you ensure safer and faster development, decrease absurdly the amount of bugs in production, and allow the developer to focus only on the thing that really delivers value: The business logic.

No unnecessary testing

Most legacy projects and cloud-intensive projects (projects that you many resources exclusive to the cloud) have a difficult process of running the code locally, or even worse, you have to deploy it to be able to execute without mocks.

The process of running things locally can be very time-consuming and exhausting to the developers, and being able to avoid it saves a lot of resources (time, money, patience, cloud resources, etc).

With static typing, the code is very predictable, and you can develop everything knowing what is happening in each part of the code, and track the execution very easily, this makes it so that the only time you need to run the code is after finishing development, to truly test if everything works as expected.

No outdated docs

Most of the time (if not all of them) when we try to write documentation about a function and try to add examples of input/output it becomes outdated in the blink of an eye. Developers never remember to update the docs, and Scrum Masters never want to allocate enough time to do it.

With static typing, the code is a live doc. Itll never become outdated, because when developers update the code, they will be updating the docs.

Avoid problems with CommonJs / ES modules

After the implementation of ES modules in NodeJs, many libraries started to migrate to this new way of writing code, so their new versions (more secure, reliable, performative, and with more features) arent compatible with older versions of JavaScript, which leaves you stuck with unsafe outdated versions.

Guess what is compatible with both CommonJs and ES modules without having to change anything in your code (only a few lines in the configuration)? Exactly, TypeScript (unfortunately, I think that JSDoc doesnt have this advantage).

Autocomplete & avoid miswriting

Instead of having to remember every property and method that something has, let static typing and your favorite IDE do it for you!

This decreases development time because:

You do not have to go back and forward to consult the properties of something
You can type only the first letters of the property/method and press enter (or select the right suggestion, then press enter), and it will be autocompleted

It also avoids the miswriting of words , a thing that causes more bugs in production than it should.

Less loss of knowledge & no time wasted

Its common that in a project, different developers write specific parts of the code, and what may seem very obvious to the person writing it, may not be intuitive to everyone.

If other developers work on a new thing written by another person, they will have to spend some time understanding it before being able to make any changes. Using static typing allows developers to cut A LOT of time understanding the values of the variables and the flow of execution.

If the developer who wrote that code leaves the company/team, it will not have an impact as big as it would have, because all this documentation is directly on the code. Easy to find and easy to understand.

Developers also need to rely less on pair programming to be able to work on a project, if its well-typed and simple enough, they may be able to make improvements/changes without even talking to someone in the project, increasing absurdly their efficiency.

Modern and attractive to developers

TypeScript is one of the most loved languages based on the Stack Overflow Developer Survey, heres the results of 4 consecutive years:

2020:

2021:

2022:

2023:

JSDoc is not present in the survey, so I do not have any kind of data to say that its a good option. The only thing that I can say is that HTMX is using it, but its a very simple library.

On the other hand, we can say that from this survey, developers have preferred TypeScript over JavaScript for most of the recent years.

Flexible

You do not need to type everything. TypeScript and JSDoc can guess the type of most of the things, which makes it a lot easier and less verbose than other languages like Java or C.

For TypeScript, in the worst-case scenario, just use any. any is the joker type, it represents anything, and because of this you should avoid it at all costs , but if you are short on time or dont want to be blocked by the lack of a type, you have this option.

For JSDoc, simply do not comment on anything, its pure JavaScript!

No more unnecessary refactor

Ill explain more about the why of it in the It has a high learning curve section, but Ill give some spoilers here.

Codebases with ununderstandable code need to be refactored, and codebases that dont have proper documentation (that we agree is impossible to maintain if its separate from the code) have a higher amount of sections impossible to understand without a lot of digging and time to analyze.

Refactors should not happen because your code is impossible to understand, but because of performance issues or changes in the business logic. having to do the same thing twice is bad for everyone: the developers, the users, and the investors.

More independence for developers

Its common for long-lived projects to have multiple people working on them, and it always takes some time (both for the newcomer and the more experienced developers) to make newcomers proficient with that codebase.

With static types, we can decrease the necessary time A LOT, because developers can understand at least the basics of the code alone, and need the help of other developers only to understand more complex business logic (if they arent documented in the code, but this is a topic for another article).

It makes it easier to have newcomers in the projects, decreases their learning curve a lot, and allows them to work on the project with less risk of breaking something, increasing the efficiency of your team as a whole.

Cons

More complex build step

The only con that TypeScirpt has is that its build step is more complex (because lets be real, nowadays ALL JavaScript projects have a build step already, so it only makes it a little more complex).

You may need proper plugins or adapters to integrate your build process with TypeScript, but nowadays we have a bunch of mature and ready-for-production libraries, plugins, tools, and whatever you need to make it work.

Im not gonna lie, it may cause you some trouble the first time, like most other tools in the JavaScript ecosystem, but not enough to overtake the pros.

If you choose to use JSDoc instead of TypeScript, this only con that TypeScript has is gone, but a new one appears: JSDoc doesnt work very well with more complex types if you dont use classes to represent them.

Debunking arguments

It has a high learning curve

Static typing requires you to write a few more things, but the learning curve is not related to the extra : string that you have to write, but to how difficult it is to work with that codebase.

Without static typing, you need A LOT more context to understand what is happening in the code, what values a variable has, and what business logic is being applied.

Lets see an example:

function processOrders(orders) {
 // Logic here
}

With only this information, can you determine what values does orders has? You may say Its an array!, but guess what? You are wrong. orders is an object. Which properties does it have? Good luck spending at least a minute looking at the code to figure it out.

Are the properties optional? Do they always exist? They are objects, arrays, or strings? Does another member of your team have this knowledge or the person who wrote this code is long gone?

Static typing by itself reduces the learning curve by a colossal amount.

With pure JavaScript, each person who would work at something related to processorders would have to go through the same process:

Asking themselves what orders is
Spending a lot of time inside the processOrders logic trying to figure it out
If it requires a specific behavior of processOrders, probably asking other team members for more details and spending their time also

Lets put it in numbers, to make it more fun:

A team of 5 people, each one making $ 100k/year
Lets say they must work with processOrders one time every 6 months, time enough to forget about specific details
They spend 5 minutes to figure out EVERYTHING they need (Yes, Im being very, very optimistic here)
A project usually has thousands or at least hundreds of functions, all of them similar to processOrders, but lets consider only a small project here, with only 10 functions.
5 developers * 10 minutes / year * 10 functions = 500 minutes per year

If each developer makes 88 cents per minute, It would cost $440 only to figure out what 10 functions receive and return. This is unproductive time, that doesnt generate any value, in the BEST case of a fictional scenario where your magical project only has 10 functions, and not the real-world where a project has thousands of these.

Now, with TypeScript:

interface Orders {
 ids: Array<number>
 skipTypes?: Array<string> // Skip orders if they have specific types
}

interface ProcessedOrders {
 total: number
 success: number // Amount of orders that were succesfully
 processed skipped: number // Amount of skipped orders based on input filters
}

function processOrders(orders: Orders): Promise<ProcessedOrders> {
  // Logic here
}

I know that this is a terrible unintuitive function, but this happens in the code. It shouldnt , but it does, so its better to at least have it documented.

Contrary to the pure JavaScript version, here you have all the context that you need to understand everything that the function receives and returns, whether its optional or not, and the basic principle of what the function does.

After all this, you can still argue many things, like Its a Clean Code problem, not JavaScripts problem! or Its a Lack of Documentation problem, not JavaScripts problem!, but I ensure you, all of these things are DIFFERENT problems that yes, happen in the code, that I may address in other articles, but arent the focus of this one.

Some libraries dont support TypeScript

This is the magic of TypeScript: You do not need your libraries to support TypeScript.

You can use the library without any typing, and it will work the same, but since it will be harder to work with a pure JavaScript library (because it doesnt have any of the advantages mentioned in this article) you probably should consider using a different one.

Ill have to learn something new

Yes. We as developers have to learn something new every day. its part of our jobs. We are here to create technical solutions for problems, to be a reference, and to figure out how to solve the problems that we face.

Learning something new that has so many benefits is an effort that makes the time worthwhile.

Conclusion

After knowing how much static typing tools help development, without any considerable cons against it, theres no way to deny how beneficial it is for everyone: The developer, the users, and the finances of the company.

I hope that this article helps you to understand it and convince your pairs to improve your development experiences.

Should I do it in the client or the server?

Henrique Leite — Sun, 18 Aug 2024 21:53:07 +0000

When working on interactive websites, we constantly face the challenge of defining if something should be executed on the server or in the client, but how do we decide it? This article will help you know how.

This article does not applies to SPAs.

Different types of web apps

We have two types of web apps: Offline-first and Online-first.

Offline-first apps are the ones where you need an insanely fast response for the user. They are extremely interactive. Good examples are Notion (or any WYSIWYG editors), Google Calendar, Trello, and Google Sheets.

Online-first apps are the most common cases, all apps that don't need to be offline-first should be online-first. They rely on the server's responses to execute things and show the results to the users only after it.

For offline-first apps, you must execute everything on the client BEFORE executing it on the server, this way you don't have to deal with the server's latency, so it's a solved case.

Now, online-first apps, are the real deal. They prompt us with the challenge of deciding where to execute something.

The criteria

To determine if you should execute something in the client or on the server, you need to ask yourself the following questions:

Does the user will lose something if the power goes out?
If they lose something, will it be extremely important?

Now, let's see how to apply these questions.

Our example

Let's have a web app with a sidebar that displays the username of the currently logged user and a page that has a button "edit username button":

When clicking on the "edit username button", a modal shows up:

And after the username is successfully updated, the username on the sidebar changes, and a success toast appears on the top right corner of the page:

This is not a real web app, I created these images using Photopea

State

Notice that we have multiple states here:

The user's username is a state
The open/closed modal is a state
The toast open/closed and the message are states

The client should only manage short-lived, unimportant states, that control mostly visual things.

The server should have no state, but should be able to operate with states:

query string
sessions
cookies

In summary, avoid states as best as you can, but be aware that we rarely can avoid them, so we must learn how to deal with them.

Opposite poles

We have multiple ways of doing it, and I'll tell you the 2 cases: One that does all the changes through the client and the other that does all the changes through the server.

All client

Initial load:

The page loads with all the elements, but the username is empty
Does a request to the server's API to get the username
Changes the HTML using JS with the data returned by the server's API

The user clicks on the "edit username button" button:

It triggers a JS function that opens the modal (removing a hidden class, creating it, and appending it to the HTML, it doesn't matter)

The user inserts his new username and clicks on the "submit" button:

The client makes a request on the server's API and waits for it to succeed
Then update the HTML text of the username with the new username
Closes the modal
Makes the toast appear with the message "username successfully updated!" and disappears after some seconds.

All server

Initial load:

Get username from session / JWT / database / doesn't matter
Returns the page already completed with the username

The user clicks on the "edit username button" button:

Redirects the user to another page, that has the modal open and the input
Because the username still appears on the sidebar, it will have to get the username again

The user inserts his new username and clicks on the "submit" button:

Submits a form that makes a POST request to a route in the server, that changes the username and redirects to another page
The new page has the modal closed, the new username, and a toast rendered

Why do both cases suck

Let's see why none of the cases work very well to create a good user experience:

All client

For the ones that only ever worked with React/SPAs, this seems like the only way to do things, and nothing seems wrong, but let's see the drawbacks that this solution has for the user experience:

The user will see a glitch on their username in the bottom left corner since it has to be loaded after the page loads
It's hard to isolate the things and reproduce the steps to get to the "new username" state (in this case, make the success toast show up)

All server

In this case, I think that it's easier for everyone to see why this approach is bad:

You will need to copy the page with the "update username button", with the addition of a modal on top of it. Increases nonsense code duplication.
As we can't use any client-side interactions, the toast will stay there for as long as the user stays on the page

Uh, but what about the latency?? If you need to worry about latency in 2024, you probably are doing something wrong. Please, reconsider where are you hosting your servers, how you are delivering your content, and what are your routes doing. Read this article from the Yahoo guys, they rule.

Balance

The best approach is neither all server-side nor all client-side, but a mix of both. And we need to balance this properly.

The correct flow

Initial load:

[server] Get username from session / JWT / database / doesn't matter
[server] Returns the page already completed with the username

The user clicks on the "edit username button" button:

[client] It triggers a JS function that opens the modal (removing a hidden class, creating it, and appending it to the HTML, it doesn't matter)

The user inserts his new username and clicks on the "submit" button:

[server] Submits a form that makes a POST request to a route in the server, that changes the username and redirects to the same page, but this time using a query param toastJSON
[server] The route will then check if toastJSON is present in the query params, and in addition to the page, will also return a toast without JS.
[client] The client will have an window.onload event, that searches for toast elements and applies the necessary JS to them.

Now the user never will lose an important toast nor have glitches in the UI.

It's a lot easier to test if the UI is working: all of our state is shortlived and has no impact if it's lost.

States

Let's review our states and see which part of our system is controlling them:

[server] The user's username is a state
[client] The open/closed modal is a state
[server + client] The toast open/closed and the message are states

Conclusion

Mixing client and server actions helps us to develop more stable and testable applications, without having to manage complex unreproducible states.

Thanks for reading.

The current state of GitHub

Henrique Leite — Thu, 15 Aug 2024 18:38:12 +0000

It's not a secret that I dislike all the things that Microsoft owns, and yet, I'm haunted by them every single day. No day passed by without I'm forced to use Microsoft Teams, Azure with their terrible excuse of scrum boards, or GitHub, with their lack of features only being compensated for the free things they offer.

The only exception is VSCode, but they are really trying their best to make it as bloated as possible, so I have high hopes for Zed.

The last straw

Today, I noticed something very special: GitHub is working on lists to organize your stars.

This is the feature that the community is claiming for! We NEED it, and I didn't even know that a few seconds ago. I'm so happy that they know their customers so well.

Who thinks like that? Who has a list of missing features on GitHub where the first item is "list of starred repositories"? This to me is the last straw. They don't know what they are doing with the platform.

GitHub is good enough, but is far from perfect. Let's see a small list of things that it's lacking:

Repository folders, so you can group your repositories
Default reviewers for group of repositories
GUI to change and configure the default reviews
Repository topics on the home page of an organization, like in the repositories page
Organization/account wide configuration for repositories
Organization access tokens, so you don't have to use user personal account key in pipelines
RSS feed for releases
A better home page
GUI for filters (on issues, discussions, etc)
And many, many more

"We are a social platform"

Who uses GitHub to hang out?

Hey, I saw on my GitHub homepage, because I follow your profile btw, that you create a new repository, very nice champ!

If I want to follow you, I'll follow you on Twitter or Daily.Dev, not on GitHub.

GitHub is the platform for open-source (kinda hilarious how the open-source platform isn't open-source, isn't it?), we go there to create public things and interact through issues and discussions, and yet, Microsoft tries its best to force it to be Facebook.

It should be focused on collaboration, on making things easier. Easier to find repositories (folders), easier to organize permissions (access key for organizations), and a lot of things that GitHub has been ignoring for years.

The alternatives

Do we really have alternatives?

I tried to use Bitbucket, but it has SOOOO MANY things that it's hard to configure anything. The interface is extremely polluted, you can't find anything there. The learning curve is immense.

I heard that GitLab has the same problem Bitbucket has, so what more do we have? Amazon CodeCommit? No, thanks.

GitHub was amazing before it was purchased by Microsoft, and on the first few years, the purchase was a great thing: free private repositories and free pipelines, but now they are doing the same thing that they do with every Microsoft product: destroying it.

The good thing is: The same way that the fall of Skype brought the rise of Discord, I see a new git platform for open-source coming in the next few years. One that solves the problems that GitHub have, even if it has a price.

If you know any GitHub alternatives, please leave it in the comments to share with the community, may we can at least give GitHub some fair competition to make them fell the pressure to improve.

Thanks for reading.

Anvil: An attempt of saving time

Henrique Leite — Wed, 14 Aug 2024 20:00:12 +0000

When I'm creating a new project, I always have the same problem: In order to follow best practices and make the code maintainable, the codebase becomes extremely verbose.

It always takes my motivation from me to have to write a bunch of stuff only to make some CRUDs. It's boring, repetitive and takes all my joy off coding.

Why I don't use Template Repositories?

It's a terrible experience to have to keep updating dependencies.
I always forgot to change example values, like the README
The changes that I do on the template aren't applied to the previous projects, so if I want to add a new thing like graceful shutdown, I have to do it one by one, and I have it.
This one doesn't affect it so much, but I don't like to have commits from the template repository on a new repository, and it's an extra thing to have to delete the .git folder

This leads me to think about the things that I hate, and I discovered that I hate many things:

Lack of documentation in a project
Lack o standards between multiple projects
Lack of a way to track where a piece of data is used
Lack o standards between multiple projects
Lack of a way to track the flow of events and communication between services
Lack o standards between multiple projects

Did I mention that I hate Lack o standards between multiple projects? Because I hate it. A lot.

And all these frustrations gave me an idea: What If I tried to create a specification to creating APIs?

Most APIs follow the same pattern, have the same things, and we all agree in a couple of standards and best practices for web development.

And from this, Anvil was born.

Anvil is my attempt to create something that's a mix of three things:

OpenAPI/Swagger specs
No-Code solutions
Frameworks

So, from a schema file (similar to OpenAPI specs), a code generator that can be fully customized by anyone, will generate a repository with all the standards and best practices that you want, without making you dependent on it like a Framework would.

The best part is that it can update your project for you, so it's not used only on the project creation. The schema file will always be the starting point for any feature.

I'm already working on the schema definition, it's hard to make it work with all the features that HTTP has, it ends up being too much flexible (WE NEED MORE STANDARDS!!!!), but nothing that a couple of days to define if a property should be called ResHeaders or ResponseHeader, am I right?

Please, give a look at the repository, the json schema definition and the examples to see what you think about it. I'm open to any suggestions, the more edge cases that we can predict, the less breaking changes we have.

If you have any options that you wanna share, please, leave it in the comments or create an issue in the repository and let's talk about it. Thanks for reading.

Why the upvote system is a pyramid scheme

Henrique Leite — Mon, 12 Aug 2024 16:21:24 +0000

I'm sure I'll get a lot of downvotes on this one, but I have to say it.

In programming, most of the communities like Reddit, Stackoverflow and DailyDev have an upvote/downvote system, and in this article, I'll say why this is a nonsensical pyramid scheme that has the only purpose of inflating ego.

How the votes work

It's very simple:

Someone upvotes your post/comment/answer and your reputation increases
Someone downvotes your post/comment/answer and your reputation decreases

But here's the trick part: It's only valid when it's coming from someone with high reputation.

The problem

By allowing only the people with high reputation to give reputation to others, you segregate your users and build a monopoly of reputation. Only the ones approved, chosen by the gods, are worth to have their voices listen.

This leads to very toxic communities, the best example is StackOverflow, where most of the mods are there only to inflate their egos and not to help. This is a disfavor for all the dev community.

The solution

Rate limiting

These platforms already have a rate limiting system, where you can post / interact just a couple of times a day. By enforcing hate limiting, like "you can only give reputation to someone 1 time a day", this would cut most of the bots.

Behavior analysis

To increase even more the security, what I think that it's always necessary, you could do checks to see if someone is creating fake accounts with very suspicious behavior:

Only giving reputation to a specific set of people
if their account's only purpose is to upvote

Conclusion

Things would be more susceptible to bots? Yes, for sure, but I think that it's better to give voice to the people and moderators to ban the bots than creating a niched club of selected people.

I personally hate how this incentivizes division, superiority of a few and dominance instead of community, collaboration and knowledge share.

These "communities" are more like stages to a few people to have their egos massaged than a place to share knowledge and help each other.

Why companies and teams should be dictatorships

Henrique Leite — Mon, 12 Aug 2024 15:33:14 +0000

Everyone sees the world through a unique lens, shaped by their own experiences and ideas. Recognizing this and being willing to listen to and understand different perspectives is essential for discovery, personal growth, and building better things together. However, sometimes this openness can also lead us down a darker path.

As a leader, you need to be someone your team can rely on, someone they trust and feel comfortable speaking to, whether they have an idea, a problem, or even a solution to your nightmares.

It's always valuable to listen to your team, but that doesn't mean you should always follow their suggestions. Good leadership involves hearing every voice, then making thoughtful decisions based on what's best for the team and the goals at hand.

In this article, we’ll explore the risks of trying to consider everyone’s ideas equally, and share strategies to avoid these challenges while still encouraging collaboration and open dialogue.

The problem

Just as a ship has only one captain, a company or team needs a single leader: someone responsible for making decisions and guiding both the product and the people toward what’s best for the group as a whole.

If you rely too heavily on group opinions or put every decision up for a vote, you risk avoiding your responsibility as a leader. It's your job to understand the bigger picture and how each decision affects it. If things go wrong, it’s your fault, not theirs. That’s why it’s essential to be discerning about how you listen to others.

Let’s be clear: people have their own motivations, their own challenges, and their own areas of focus. Your team isn’t responsible for the big picture — their job is to handle the small details. And it’s precisely those details that keep a company growing and delivering results.

A developer won’t have insight into marketing, just as a salesperson won’t be familiar with the company’s quarterly financials. That’s not their role.

A leader, however, must understand the broader picture: the basics of how each area of the company operates to align everyone toward a common goal. Team members are the engines of the company, and leaders are the gears that connect them to the wheels, making the whole vehicle move forward.

The solution

Listening to others is essential. No one has all the answers, and the wisest thing you can do is stay open, truly open, to other people’s perspectives. That’s how we grow, challenge our assumptions, and become better.

Sometimes, a janitor might share an insight that changes your life. Never judge someone by their role, race, sexual orientation, or any other bias. When you do, you’re not just being unfair, you’re closing the door to valuable experiences and perspectives.

Listening to what others have to say, understanding their context, and having the empathy to put yourself in their shoes, that’s what allows you to truly analyze their perspective. Doing this for each person on your team, one by one, is what will lead you to greatness.

It’s not easy, is it? But no one ever said that being a good leader would be easy.

The example

Let’s look at an example:

Your company has decided to refactor an important microservice. The current codebase is outdated, written in PHP 5.4, and no longer meets modern development standards. Your team is now responsible for rewriting the service, giving it the opportunity to choose a new programming language.

Your team consists of four members: John, Dave, Mike, and Lucas.

John, a junior developer who joined the company a few months ago, suggests using Node.js.
Dave, another junior developer recently hired, agrees with John.
Mike, a mid-level developer with a couple of years at the company, has no strong preference but is open to trying Node.js.
Lucas, a senior developer with many years of experience in the company, suggests sticking with PHP and simply upgrading to the latest stable version.

If you run your team like a democracy, the decision would be to use Node.js: two votes in favor, one neutral (effectively in agreement), and one against.

That sounds good, right? Power to the people. Everyone feels heard, there's no conflict, the team stays happy, and you avoid potential dissatisfaction, heated discussions, or even team turnover. Problem solved, right?

Now let’s analyze the context, because understanding context is your job as a leader:

The company has several teams, and all of them work with PHP.
The entire infrastructure (pipelines, deployment processes, monitoring) is built around PHP.
The most experienced developer on your team has years of professional experience with PHP. The second-most experienced does as well.
The only experience with Node.js comes from two junior developers, both in their first jobs.

So, do you still think choosing Node.js is a great idea?

I don’t. In fact, I believe that any leader who allows a refactor like this to happen in a different language (under these circumstances) shouldn’t be in a leadership position.

Is that because PHP is the best language in the world, suited for every project, everywhere? Absolutely not.

It’s because PHP is the best choice for this specific context.

You could swap PHP or Node.js with any other language: Python, Ruby, Go. The logic still stands: good decisions are made with context, not popularity.

To be even more didactic, let’s weigh the pros and cons of rewriting the project in Node.js in this context.

Pros

Your team members, especially the juniors, are excited and happy.
You might see performance improvements or gain access to certain modern tools or frameworks.

Cons

Your team would be the only one in the company using Node.js, creating an inconsistent pattern across teams.
There would be no one else to turn to for help. You’d be on your own when facing issues. It’s a very important service. Are you sure that you should accept the risk?
If the company uses internal libraries or shared utilities, new versions would need to be written just for your project.
- This duplicates logic.
- Duplicates effort.
- Duplicates cost (By spending more of a developer’s time).
New deployment pipelines and processes would need to be built and maintained separately.
The most “experienced” developers in Node.js would be two juniors, still in their first jobs, with limited real-world understanding of the language and its ecosystem.
And if they leave the company or, as the classic phrase goes, get hit by a bus, what then?

When you look at the full picture, it’s hard to argue that the pros outweigh the cons. For me, it's clear: the cons far outweigh the benefits.

You could argue that "changing versions also could lead to all these problems", and you are right, but what can cause more conflicts, changing versions of the same language, or changing entire ecosystems? Making decisions is not about choosing the option that has no risks, but choosing the one that has the risks that you are willing to take.

The same principle could be applied to anything: Libraries, frameworks, protocols (like GraphQL), and databases.

Note that in this example I used Junior developers to be the ones that bring these changes, but this is not a matter of seniority. Even senior developers can fall into this trap. When you’ve worked with the same technology for a long time, it’s natural to feel bored and eager to try something new. And that’s a good thing—innovation comes from curiosity.

But innovation needs direction.

So instead of experimenting with the company’s core systems (the ones that run the business and keep everyone’s jobs), why not apply that drive for innovation to smaller services or less critical parts of the ecosystem? That way, you encourage growth and experimentation without putting the stability of the entire company at risk.

Sometimes, the pros overcome the cons, and the technical gains that you have with that change would make up for all the trouble that comes with it.

Conclusion

As a leader, it’s your responsibility to evaluate the things your team members may not have the context to see. You must protect your project's integrity within the company so that the product remains functional, valuable, and sustainable. Your job is to make sure the work continues, and that everyone still has a job next month, next year, and so on.

Here’s my final advice:

Don’t let quantity intimidate you. Just because many people are saying something doesn’t mean it’s the right thing. Leadership is about discernment, not popularity.
Think long-term. You or your team members might not be in the company a year from now. That doesn’t mean you should cut corners. Build something that’s maintainable for the people who come after you. That’s how you show real leadership and respect.
You can’t make everyone happy. Sometimes people leave, and that’s okay. It’s the cycle of life and work. Ideally, the hiring process filters out those who aren’t aligned with how the company operates, but when that fails, we have to manage the gap with empathy and maturity.
Always listen. Truly listen. Great ideas can come from anywhere—yes, even junior developers. Your role is to encourage those voices, evaluate them with context, and decide what’s best for the bigger picture.

How to install and configure Golang

Henrique Leite — Thu, 11 Jul 2024 13:44:25 +0000

In this article, you will see how to install Golang and configure it to use the private GitHub repositories of your company.

Right to the point

BE SURE TO REPLACE {VERSION} WITH THE DESIRED VERSION THAT YOU WANT!!!

Download Go

curl -OL https://golang.org/dl/go{VERSION}.linux-amd64.tar.gz

Install Go

sudo tar -C /usr/local -xvf go{VERSION}.linux-amd64.tar.gz

Configure Go

sudo nano ~/.profile
# Or with zsh:
sudo nano ~/.zprofile

Paste this at the end of the file, replacing {YOUR COMPANY ALIAS} with your company alias:

# Golang
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export GOBIN=$GOPATH/bin
export GOPRIVATE=github.com/{YOUR COMPANY ALIAS}/*
export PATH=$PATH:$GOROOT:$GOPATH:$GOBIN
export PATH="$PATH:$(go env GOPATH)/bin"

Run this to update your terminal and apply the changes:

source ~/.profile
# Or with zsh:
source ~/.zprofile

Configure SSH key on GitHub

Run this, and remember to replace {YOUR EMAIL}\ with your email:

Run this and only press enter until the command stop
The ssh key MUST NOT have a password

ssh-keygen -t ed25519 -C "{YOUR EMAIL}"

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/id_ed25519

cat ~/.ssh/id_ed25519.pub

Copy the content displayed on your terminal, including your email. COPY EVERYTHING that the previous command returned.

Go to GitHub and follow this tutorial to add the SSH key.

Configure Git

sudo nano ~/.gitconfig

Paste this at the end of the file:

[url "ssh://git@github.com/"]
    insteadOf = https://github.com/

Done!

Now you can work with Golang and private repositories on GitHub with no problems!

Why HTMX is far superior to React and NextJs

Henrique Leite — Tue, 09 Jul 2024 01:48:21 +0000

On Anuntech we have the challenge to create an ERP, and for the ones that already worked with it, know that ERP can be one of the more complex types of software to create (and use, god have mercy of SAP users).

To avoid the complexity to use, we wanted something similar to PlayStore: You have an infinity of modules to enable, you can choose the ones that you need or choose a "business template" to fit your needs, and with our goal in mid, came or first problem: Choosing the frontend tool.

React

So, to create any website, we need a framework, everyone knows this unquestionable truth. And as any other person, the first framework that came in mid was React, the most used, most loved, most incredible, of the billion JavaScript frameworks out there.

React is nice, it gave us:

The ability to create components and reuse them, keeping a standard and avoiding duplication
The ability to create high-interactive frontends (now our forms can have inline validation to know if your email has an @!)
A way to decrease our server costs (very important for every startup), by running everything on the client

But react itself has lots of problems:

It bundles EVERYTHING together, and for a product like Anuntech, that will have hundreds of different things, the bundle would have the same size as an AAA game.
It's heavy af, uses virtual DOM to create and manipulate things, what is terrible for weak pcs, and guess what? All our clients have weak pcs.

So we had to think a little more: If we can't use React, what is our next choice?

Of course, the natural evolution of React, Next!, React is already perfect, but with Next it's on another level of perfectness! There's no way that it will not work:

Next bundles each page separately, and each page only has the required dependencies, this will keep the bundle at an acceptable size
It still keeps all the good stuff that React has: high-interactive frontends
Has many built-in optimizations for images, videos, etc.

But Next has even more problems than React:

We lose the pro of not spending with servers, now we need a server to run our frontend
It still is heavy af, it uses react to build things, and worst, it builds on the server too
Know that we have client and server, we must keep the user logged on both, and it must be able to do authenticated requests to our APIs both on server and client, which increases the complexity A LOT.

So we began to realize that the problem wasn't the framework, but the whole JavaScript ecosystem.

War against JavaScript

The JavaScript ecosystem has innumerable flaws:

It's extremely complex for someone with 0 experience to work with JavaScript tools. They all require 10 other tools to work, and you MUST learn them all to do even the basics.
- If we keep using Next, to hire a frontend developer, they would be required (or we would be required to invest time and money training they) to know: HTML, CSS, JavaScript, TypeScript, Tailwind, React, NextJs, Hookform (or whatever library they will be using 5 minutes from now), State management with React, Server components, the brand-new awesome way to write react that will change next month, the brand-new way to right next that will change next month, and so on. The list never ends, and all of it to do the basics.
It requires LOTS of dependencies, and each dependency has even more dependencies. The JavaScript ecosystem has a serious problem with wanting to delegate even the smallest problem to someone other than themselves. It brings security risks in a scale never seems before, and they seem to not learn a thing with events like PolyfillJs and Coa.
Builds 1 bundle with your custom code and all the libraries that you use, what makes it impossible to cache the libraries on the client to avoid having to download them again if you change your custom code.
JavaScript is terrible anything else than manipulating the DOM, using it on the server is something that we want to avoid at all costs. Has terrible performance, terrible memory management and terrible long-term life.
The ecosystem is more unstable than the humor of someone with borderline disorder, JavaScript developers can't stand having one ; that they don't like, or they will create their own thing from scratch, and guess what? It will become the new standard, god knows why. Every couple months the way to write React changes, or the way to write Next changes, or the way to manage states changes, or manage forms, or do styling, ALWAYS something is changing and nothing never has the minimum amount of stability nor standard. It forces the developers to always learn the same thing in a different way, and your codebase will be outdated on the moment that you finish writing it.

And for our specific case, we also had more problems:

In our case, as we have microservices for the APIs, with Next/React we have to maintain gRPC (for server-server communication) and REST (for client-server communication), which makes the backend team maintain 2 delivery systems, 2 API documentations (.proto and openapi specs), and make the services available on the internet for the client to hit them directly, what also make us to have to validate the user authentication and authorization on every service.

And because of all the problems that we had on our place, we decided to take the things drastically. Instead of looking in one single solution and try to make it work, changing it a bit to see if we manage to fit a square into a triangle, we choose to turn 180° and look for extreme alternatives, avoiding the root of all these problems: JavaScript.

HTMX

As probably many of the people that knows HTMX, I heard of it firstly from Primeagen. At first, I hated it. My first though was "Nice, coming full circle back to PHP", but after some review on the solution and after learning more about the idea, I saw that HTMX is exactly what we are looking for.

HTMX solves all our problems and gives us even more power:

It is SSR, which solves the bundle-size problem.
It provides interactive for the most important parts (partial page reloading), and allow us to create our own custom basic script for things that it cannot do (like validating form fields).
Allow us to choose the language that we want to run it, we are no longer stuck at JavaScript.
Has 0 dependencies.
It's only 1 file of JavaScript, very easy to understand and well documented. If the maintainers decide to not maintain it anymore, we can maintain it ourselves, as opposite of React / Next, where we are stuck with them and their decision to where to go.

The final solution

So, as we were already writing our backend services in Golang, we choose to write our frontend in Golang + HTMX + Templ, with Tailwind and DaisyUI for styling. Here are the main reasons:

As the backend team is already having to communicate between services, they are already maintaining a library for each service that exposes the "API routes", what makes it a lot easier for the frontend to integrate with the services: Just use the libraries instead of building an integration from the scratch.
The selling point of "JavaScript on the server" also can be used here: Having one language for frontend and backend allows your developers to be full-stack and have less trouble working on both parts of the system (what is a big lie with TypeScript, btw)
The benefits of having one language also affects the DevOps team: With 1 language there's only 1 dev environment to configure (and 1 doc to write about how to configure everything you need), 1 pipeline to maintain, 1 type of machine to configure to run the servers, and so on.
With only SSR, almost zero JavaScript and no state management on the client, the automated tests become a lot easier to write and reliable: Just call the route and check if the text (HTML) returned is right.
Golang is EXTREMELY faster and lightweight than NextJs servers. It allows the devs to have weaker pcs and not lose performance and having to wait 5 minutes to start the server and render a single page, what makes the company able to buy cheaper pcs and save a lot of money.
HTMX allows us to run things in lambdas, something that we don't do at the moment, but hey, it's very nice to have this door open when it was sealed with concrete and 3 inches of steel when working with NextJs.

The challenges that we can see coming:

The good old ID duplication: Too many components can generate components with the same ID, what makes it easily change things that shouldn't be changed. We plan to avoid it, defining a good naming pattern for the IDs.

The conclusion

We are here exploring a new thing: There are not many production apps using HTMX, and probably none of them are as big as we want to become. I'm not sure if we are taking the right decision here, but I'm sure that it's better than using NextJs or dealing with the JavaScript ecosystem.

Which programming language should you choose

Henrique Leite — Sat, 15 Jun 2024 13:15:35 +0000

Each programming language has its own purpose, they all are a tool to solve a specific problem, and you should choose the one that really fits your needs.

The languages

JavaScript

console.log("Hello World!")

JavaScript is a terrible and confusing language (see more here), but unfortunately it's the only option that we have for working with Frontend Web development. You should choose (or is forced to) use it when your goal is to create interactive Frontend Websites.

In any other case, JavaScript MUST be avoided, it's unsafe, underperforming, makes no sense, requires lots of configurations and libraries to do the basics, and it's infested with terrible practices.

"Choose" it if you want to become a Frontend Web developer.

PHP

<?php echo 'Hello, World!'; ?>

PHP still the most used language for the Web, mostly because most of the websites are legacy or build with WordPress, an easy-to-use tool where you can start almost with no knowledge about programming.

You will find a lot of jobs to work with PHP, but it's "for the old people", and the new generation is avoiding it because of the memes, and yeah, they are kinda right, but PHP was very important for the early Backend development.

Choose it if you want to (or have to) work on legacy systems, or systems that are for companies which the focus isn't on their tech, like Stores or Supermarkets.

Python

print "Hello World"

Python is a very simple language, ideal for beginners that want to start in the programming world or for non-programmers that need to automate a task.

It's heavily used for Machine Learning, Neural Networks and similar, usually build by mathematicians.

Pythons has terrible performance, so it should be used in environments where you don't need things to be fast, like training your AI, running things locally to automatically format your CSVs, move your mouse so your companies spyware thinks you are working and similar.

Python should not be used in production, but the result of what is produced by python can.

Choose it if you want to start in programming but find it too hard in any other way, or if you aren't a programmer and don't want to be one, but needs to automate something or create AIs to take someone's job.

Java

class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello World!"); 
    }
}

Java is the good-old trustable language, used for most backend systems that must be reliable, like banking. It's kinda verbose and heavy, but a good language overall, has lots of job positions, good practices, great developers. It's the one that you can't go wrong.

Choose it if you want something guaranteed, even if you don't work directly with Java, the things that you learned for sure will be useful in your career.

Golang

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

Go is a safe, fast and easy programming language, it's growing, but not a lot of companies out there have job positions to work with this.

C++

#include <iostream>

int main() {
    std::cout << "Hello World!";
    return 0;
}

C++ is the language for who wants to develop games. You will probably use Unreal Engine or (very, very rarely) develop your own. Most (maybe all) big games are developed using this language.

Lua

print("Hello World")

Lua is also for gaming, its focus is not to be performative, but to be very easy to learn and modify. If you want to create a game that supports a lot of mods and has a great community, use Lua. Your community will love to make mods and expand your game, it will also help with its growth.

C, Rust and Zig

#include<stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}

fn main() {
    println!("Hello World!");
}

const std = @import("std");

pub fn main() !void {
    std.debug.print("Hello, World!\n", .{});
}

Low level languages, perfect for things that really needs performance, like Databases (creating databases, not using them!) and Operational Systems.

You will probably not get a job with these languages, but may need to develop something using them if you were hired by a medium/big tech company.

All other languages

Don't use it, it's not worth it.

Let's summarize

JavaScript: Frontend Web
PHP: Legacy backend
Python: For non-programmers
Java: Safe in all means, good option overall
Golang: Good but not very used
C++: Very performative gaming, for competitive or immersive games
Lua: For community driven games
C, Rust and Zig: For OSs and Databases.

For the fanboys

This is a meme that represents "You can cry as much as you want, but it will not change a thing".

Conclusion

Hope that it helps mainly the beginners to understand the purpose of each language and avoid people that only want their money, selling courses about "LEARN THIS LANGUAGE AND YOU WILL MAKE 500K A YEAR!!!", please, don't fall for these schemes.

If you have different options (and don't want to cry about how your language is the best language in the world and should be used everywhere, except for C, C is the best), please leave it in the comments and let's talk about it!

Git: How to fix PR conflicts

Henrique Leite — Thu, 13 Jun 2024 11:14:21 +0000

When working with PRs, we may encounter conflicts trying to merge them. In this article, we will learn what conflicts are and how to fix them.

What causes conflicts

In the image above, you can see that we have a main branch called master, and from this branch we created 2 new branches at the same point in time: feat/1 and feat/2.

Obs: point in time is not the same as time. Point in time means that no changes happened in the branch since the last time you checked. On the example above, the master branch keeps on the same point in time until the PR #1 is merged and the state of the branch changes.

After we created both branches (one can be created by you, and another one by your coworker), we start to make changes on them to develop a new feature, fix a bug, or improve the documentation, anything that we want to change.

As things on each branch are different, one of them will probably be faster to develop and will have the PR merged first, and once in a while may happen that 2 branches must change the same file.

As both branches were created at the same point in time, git will not be able to know which one of the changes it must keep, the one of PR #1 or the one of PR #2 (your PR), and it will cause the conflict.

How to fix the conflict

If the git commands below don't work, it may be because you need to configure your git before executing them.

Go back to the master branch (or the source branch for your current branch)
- git checkout master
Get the updated state
- git pull
Go back to your branch
- git checkout feat/2
Rebase with master
- git rebase master
See the files that are causing conflicts
- git status
Go to the files and make the necessary change to the file to include both your changes and the previous changes.
Add the files to be tracked by git
- git add .
Continue the rebase
- git rebase --continue
[May not occur] If a strange text appears, run the commands:
- If you are using vim, press Esc, :wq and Enter
- If you are using Ubuntu's default editor, press Ctrl + O, Enter and Ctrl + X
Push the changes
- git push

Conclusion

And that's it! Solving conflicts is not the end of the world, we can fix them very quickly. Hope that this article helped you in some way, and if you have anything to say or an experience to share, please say it in the comments! 😄

How to handle migrations in Golang

Henrique Leite — Tue, 11 Jun 2024 14:21:04 +0000

Introduction

We always can create and run our migrations manually, but if we want to make it faster, safer, and easier to read and maintain, it's recommended to use a specialized tool for it.

To choose this tool, we need first to analyze what are the requirements for "handling migrations". They are:

Generate UP and DOWN migrations to apply and revert the changes
Keep track of which migrations already were executed and be able to apply only the new migrations
Have a clear, simple and fast way to know the current structure of your database

On the next sections, let's dig up a bit about each one of these features, and at the end let's see some tools that we can use for it.

Generate `UP` and `DOWN` migrations

Generate migrations is not a requirement, but is a great bonus. It saves a lot of time and rarely needs any adjust. To do it, the tool needs to get the current state of the database, the new state that you want to apply and create the necessary SQL queries to synchronize both, in the best way possible and without any bugs.

The current new state that you want to apply can be defined as code or a specific schema file, but I'll talk more about it on the Know the current structure of your database chapter.

Up and Down migrations can be written in 2 ways:

Using raw SQL files
Using .<your-language> files (in this case, .go)

I personally prefer to have raw SQL files, because this way I fell safer that none of the behaviors of the language will affect my migration, and any of the updates in the language will make me update previous migrations.

If the tool doesn't generate the migrations for you, you will have to write them manually.

Keep track of migrations

This is without a doubt the most important part of every migration tool. It's very important to know which migrations already were executed, so the tool can avoid running the same migration twice and causing an error.

For our luck, all the most famous tools for handling migrations do it very well.

Know the current structure of your database

This is the part that improves dev experience and the velocity that you can modify your database to fit your new needs. Have a simple and fast way to know the current state of your database is essential for many things: Have the big picture of your database, be sure how a change would affect it, if it has the best performance that it can have (with all the right indexes and relations), if it has a column that you need and how can you add it if necessary.

Most tools don't have a way to do it, and once you start using this kind of documentation, your life changes, and you never want to work with an undocumented database again.

There are ORMs like gorm that supports some kind of documentation with files, but they mainly focus on converting the database to "things" in the code to be used by the ORM, and not as documentation only/documentation-first.

To solve this problem, DBML was created, but it lacks a lot of features required for migration tools.

Available tools

golang-migrate

A basic Golang specific tool to run migrations.

Pros:

Is the most famous and loved one
Has more than 14k stars in GitHub
Is in development since 2014
Very reliable

Cons:

It can't generate migrations, can only run manually written migrations and ensure to not run already executed migrations.
Has no way to know the current state of your database, depends on external tools like (DBeaver).

goose

Another Golang specific tool to run migrations, with a bit more functionalities.

Pros:

The second most famous and loved one
Has more than 6k stars in GitHub
Has better documentation than golang-migrate
Can handle both SQL and Golang migrations

Cons:

It can't generate migrations, can only run manually written migrations and ensure to not run already executed migrations.
Has no way to know the current state of your database, depends on external tools like (DBeaver).
Is more complex than golang-migrate

Atlas

A language agnostic tool to run migrations.

Pros:

Is language agnostic
Is maintained by a (small) company
Has more than 5k stars on GitHub
Has an extensive and very good documentation
Has a way to know the current state of your database
Can generate migrations
Has a Discord server for close contact with the maintainers
Can convert your schema to other formats, like JSON, DBML, ERD and others

Cons:

Is maintained by a SMALL company, and not really adopted, so if the company goes bankrupt, it may be the end of support
Uses a version of HCL as its schema language

Go Prisma

A wrapper to a JavaScript library that is both an ORM and a migration management tool.

Pros:

Is language agnostic
Has more than 2k stars on GitHub
Has an extensive and very good documentation (on the original library, not the wrapper)
Has a way to know the current state of your database
Can generate migrations
Both the original library and the wrapper have Discord servers for close contact with the maintainers

Cons:

Is maintained by a small group of people
It's a JavaScript library
Is a wrapper for another library, what can cause conflicts
It's a JavaScript library
Not only a migration tool, but an ORM, what means a bunch of unnecessary things come with the library
It's a JavaScript library

What tools do I recommend?

Both golang-migrate and goose can't generate migrations and don't have a way to document your database, so I can exclude them already.

Atlas has a lot of potential, has the core that we need: From a schema file it can generate things. Generate migrations, .dbml files or "things" specific for your code to be used by an ORM if you want to.

The only problem with Atlas is that I personally hate HCL for databases, I think that it's overcomplicating the problem, too many keywords words for something simple. I know that it decreases development complexity for the guys maintaining it, but it's a terrible experience for anyone using it.

If you like HCL, I recommend you to go with Atlas. It may be risk because it's maintained by a small company, but I think that it's the best option that we have in the market.

And last: Go prisma. I use it, not because I think it's a great tool, has the best performance or has extra unseen magical features. I use it because prisma.schema.

The Prisma syntax for writing database specifications is good, not the best, may be a little overdecorated, but works, it's simple, it's understandable and has its own formatter (HCL also has one btw). Go Prisma is a workaround to use Prisma without having to install it using node, and to be honest, at this moment, I'm not even sure if you can run it without having node installed.

I prefer to take the risk and have some other things installed to be able to use the prisma.schema file, since at the moment (and for the next years) it will not affect significantly my project.

Conclusion

Hope that you liked the article, and please feel free to share your options on the comments!

Why JavaScript is a terrible language

Henrique Leite — Tue, 11 Jun 2024 00:46:10 +0000

I could spend a day talking about how JavaScript lacks performance, has terrible memory management, and relies on a thousand libraries to do the basics, but in this article I'll focus on the core: The Original Philosophy. If you want to learn more about how JavaScript works under the hood, I recommend this series of articles, this talk and this video, all of them amazing of explaining the internal behavior of JavaScript.

The creation

The old history that everyone that works with JavaScript already knows: JavaScript was created in the 90s by Brendan Eich with the objective of bringing some interactivity to the web that at the time were composed only by static HTML and CSS.

The best part is not that it was created by 1 person (nothing against Brendan, he truly did something amazing with the resources that he had), or that he had 10 DAYS to develop it, no, the best part is that they needed the language to be adopted, so they put any features into the language that was asked to them, like implicit type conversion.

What can learn with this is: The bases of JavaScript is a language created following the best method of development: GoHorse. No big picture, no defined goal, no planning, no worries about it being good, just about it being on the market.

We developers know more than anyone how good products can be when you follow no process and just code as fast as we can without thinking, right? The best products are made this way, I'm sure that it's the best of the best. No, It isn't.

"It improved over time"

Ok, the creation of it was terrible, but hey, JavaScript has more than 30 years, it had a lot of time to improve and become a better language, right?

No, things move veeery slow on the developer's community, we almost kill each other when trying to get to a consensus, it takes years to decide the best option to do something, or you can simply do what JavaScript does: Go implementing stuff.

JavaScript has more than 30 years and the people that use it still tries to make it fit every scenario, when it almost not fit the original case that it was created to fit. JavaScript keep trying to turn 180° and make it usable on the server, on CLIs, on pipelines, everywhere!

The language was created to execute short-lived simple scripts to manipulate the DOM, not to stay running and execute complex tasks, live web servers, CLIs or pipelines. No matter how much you try to make a workaround to make it fit the scenario that you want, you still will be trying to fit a square into a circle.

The alternatives

Honestly, you have many alternatives that aren't scripting languages that for more to the BackEnd, pipelines or CLIs. Unfortunately, for the Web we are stuck with JavaScript, but it's OK, it doesn't affect us that much (I hope).

For REST APIs, you can use Java, Ruby, Elixir, Golang, even PHP (yes, it's a better option than using JavaScript on the BackEnd). Try to choose something that was created to fit your case, and not adapted to fit your case.

A tool specifically made to solve a problem will always be better than a generic tool that has something kinda can solve that problem.

Conclusion

JavaScript was an amazing innovation back in the day, Brendan Eich did something magical with the resources that he had, and thanks to it, we have the web the way that we have today.

It's also a good start for new developers: It's simple, has a package manager so you can rely on others to do hard things for you (like checking if a number is even or odd) and you can run it directly on the browser to test things.

But overall, any serious company or project should not use JavaScript to power its system. It's a workaround, something glued with gum and spit, if you want your system to have a good amount of reliability you should not use JavaScript.

I know that you may have many arguments, like "Netflix/Google/Facebook/AnyBigCompany.com uses Node on the BackEnd!", and I know it, I just don't understand why, and I would love to have the opinions of the amazing developers that work there about the topic.

Thanks for reading! If you have any comments about the topic, please, share below and let's discuss more about it.