My 2 cents: Why JavaScript developers and organizations are leaving TypeScript?
Is TypeScript evil?
In this issue:
Is TypeScript necessary for JavaScript?
Is this mass opinionation and migration the first of its kind?
My personal opinion on TypeScript.
The downsides of TypeScript: let’s be honest.
In short, they were never really TypeScript users; they were using TypeScript to overcome the shortcomings and problems with older versions of JavaScript. As soon as they were resolved, they moved forward. What’s wrong with that? I believe every developer has a right to make a choice for their favorite language1 and be able to use it.
Before we jump to the debate, think about it from the perspective of databases and database languages. Engineers have been using SQL2 to script the programs and databases. You write an SQL program, and it just works on all the databases. The following line of code, for example:
SELECT * FROM users;If you run the following code on SQL Server, SQLite, or PostgreSQL, the code will work as it is. SQL code, when written with proper indentation, is one of the most beautiful codes3 that you would ever read; if you can read it, of course. Here is the thing. Quite quickly, SQL becomes a nightmare. You bring in the concepts of grouping, joining, and database internals, such as indexes, which index to use, and you have a new engineer pulling their hair out. Or worse, writing the SQL that “executes” but does more damage. With that, now your database is always above 80% CPU, uses a lot of resources, the queries are no longer single-digit read, and you cannot make sense of the data that gets stored or how to delete the dependent data as soon as the parent data is removed from the database.
We do have object-relational mappers, or ORMs4, that allow non-database engineers to write programs that communicate efficiently with database engines and get the job done. The ORMs enable the developer to map out what the program needs and then do its magic to:
generate the schema on the database
create the data and store it in the database
query the data from the database and provide it to the programs
update and delete the data
ORMs go further, creating primary keys, normalizing the data, and defining indexes to speed up data queries.
While this simplifies the process of creating the software, it does add an extra layer of translating the non-SQL code into SQL code that gets executed on the database engine. What do you get?
Your non-SQL code can be unit-tested and statically analyzed for code quality.
The ORM code uses the same tooling and frameworks and minimizes the brain context switching from the SQL language to another language.
Your ORM can apply best practices such as SQL Injection prevention.
Note that while ORMs do take away your freedom and control over the database engine. They do prevent you from making severe, grave mistakes, such as using unsanitized inputs in raw SQL. A junior SQL engineer might make these mistakes and, if not detected earlier, can cause a lot of damage. Don’t think this is real? C’mon.
Read this thread on Hacker News: Accidentally destroyed production database on first day of a job.
So, why the SQL and this talk about ORM? What does it have to do with JavaScript and TypeScript?
This is the same conversation that is happening with JavaScript and TypeScript. TypeScript is not a replacement for JavaScript, just like an ORM is not a replacement for SQL scripts. You have to understand JavaScript is the language of the web. Every web browser speaks JavaScript. In order to run a script on any web browser, you need to write a simple JavaScript program, and voila, every user of your application is able to execute that program with no problems.
Now, coming back to the question: why are people leaving?
TypeScript does not make sense for them—individually or as a team—and they’re making a decision to move to JavaScript. With this, they’re making a decision to use simpler tools. Simplifying their development process and, in their own way, improving the developer experience. Remember, developer experience is relative. All the reasoning for complex build structure, learning curve, non-standard language, and scarcity of features—that are missing in modern JavaScript—are valid in their own contexts.
It is also important to note that the teams are moving away from TypeScript for themselves. They’re not recommending others to migrate away from TypeScript. It is evident as Rich Harris made an announcement on Hacker News that TypeScript support is going to stay in the project, and developers are welcome to use TypeScript for their own projects. Also, even if a project does not actively support TypeScript. You, as a developer, are always allowed to use TypeScript for your projects. Rich’s statement in the post supports this whole point:
If you're rabidly anti-TypeScript and think that us doing this vindicates your position, I'm about to disappoint you. If you're rabidly pro-TypeScript and think we're a bunch of luddite numpties, I'm about to disappoint you as well.
TypeScript is not bad. It’s just like a tea or coffee situation.
Using C++ in place of C was also questioned
More than a decade ago, C++ was in the same situation as TypeScript is today. It was offered to be used for the Linux kernel. Linus was very straight to the point and closed the topic once and for all.
Read:
TypeScript vs JavaScript is just another iteration of other similar problems that we have seen in the past. These problems are not contributing to the overall ecosystem of software engineering. They’re too rigid, too verbose, and too unethical. While I believe TypeScript is going to be my default language of choice, I still find JavaScript a fascinating language, and it depends on the context when to use it.
The difference between C and C++ discussion gives an interesting view of the situation. The statement by Linus:
In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.
This makes sense. And if we apply similar concepts here with TypeScript. For example, if we were to say that we are using JavaScript because we don’t want to bring in “type gymnastics”5 to beat around the bush, it would be one thing. And it would be totally different to say that TypeScript adds build time, so we have to move away.
This behavior raises some concerns and dilemmas.
When we are building software, do we really have to be strict and opinionated about the language and keep on using it with closed eyes?
Does our preference for a style of programming have an influence over our fondness for a particular language?
Do people leaving a community mean that the community is dying?
For the first part: the software evolves. And so should the technology. Luckily, the programming languages and the frameworks also evolve. So, mostly, we don’t need to update the tech stack.
The second point requires some elaboration. It is a common experience that people who like to write scripts are not fans of statically typed languages.
Lastly, for as long as I’ve been writing software. I’ve always heard people saying, “Technology X is dead/obsolete. Move to Y.” Just this year, we got ChatGPT, and I wonder how that would work out.
My first look at and experience with TypeScript
I started my Node.js experience with JavaScript. It made sense, and everything was working like a charm. I was skeptical about TypeScript. For one very simple reason. You do something with JavaScript, and it just works as soon as you execute the command. With TypeScript, you now have a middleware that “transpiles” the TypeScript code to JavaScript, and then you run that JavaScript code. For those who know me, I like to keep things simple. TypeScript did not make any sense to me. Why should I add another layer to write a basic Node.js application or build a simple frontend application with React.js?
It was not until I had burnt myself with very plain-simple-by-design JavaScript problems such as “cannot read property of undefined” and not knowing what is the correct structure of the object. Or if the object is an object at all.
I do have experience working with TypeScript in frontend applications using React and with backend applications with Node.js. I will touch upon the backend experiences for TypeScript development of Node.js applications.
While the Node.js development is very simple and straightforward. You write a program, copy it to the production, and run “node app.js”, it works. The procedure with TypeScript is a little different.
The additional step makes it challenging because the compiler does not support the migration of the resources. There are frameworks that support this. For example, the TS.ed framework is a complete web development framework that completely supports TypeScript. With TS.ed, you can write the applications in TypeScript and use the best features that are provided by TypeScript but don’t have to worry about the build pipeline—as long as you use the procedures supported by the platform itself.
I loved the fact that I could get feedback about my programs as soon as I ran the application. The quick feedback loop helps debugging in the dynamically typed languages. A common JavaScript developer could debug their apps in two ways:
Use the console to log the current state of the application.
Attach the debugger and then run the program line-by-line.
You will only find the bugs caused by the type system when you hit the line. If your application structure is complex and it takes a few method calls before your buggy line is hit, you would be running code multiple times.
A side note: in the applications that follow a flow of requests, each request builds on the previous request. Your debugging session would need to run the sequence of requests each time you have to debug the program to ensure that you follow all the code branches. TypeScript does not need to run all the code branches. During the transpilation phase, TypeScript reads all the code branches, and with each line, it checks if the JavaScript is likely to break at that line. This is the point that the diagram shares above. This quick feedback for the type system enables developers to identify the bugs that are caused by typos. Of course, TypeScript does not find logical bugs. For that, you’re on your own.
Downsides of TypeScript
First and foremost: TypeScript is just a compiler. Or a transpiler.
It does one thing only. It transpiles the TypeScript code to JavaScript code. An ORM has context and an understanding of what the objects are and how they are linked in the broader scope of the application. TypeScript has no idea about other resources. It only reads the .ts6 files. When it reads the .ts files, it processes them and generates the corresponding JavaScript code in the output directory.
I figured this out when I built an entire application using TypeScript. It worked perfectly as it was just an API layer, so I did not have any resources. A few versions later, I decided to put a simple HTML frontend indicating to the visitors that this web application is just an API, if you would like to use the service consider visiting another page, etc. But, there was no HTML output. The output directory only contains the JavaScript code.
This is by design, and TypeScript folks are not planning on adding the support. See this thread on GitHub; the response is:
This is out-of-scope of the TS compiler; I would recommend using a build orchestration tool like gulp or broccoli to do this.
Use a build orchestration tool. That is the first line of frustration. It is indeed very frustrating. You write an amazing application, and you are able to express yourself in a wonderful manner, but you cannot bring in resources such as HTML, CSS, or other static files because your tsc CLI is not built that way. Or, you now have to bring in an extra layer of a build orchestrator to copy your resources.
The second problem with TypeScript. It has a big learning curve. Modern JavaScript has “almost” all the features that you need to write smart, asynchronous, and testable code. There are contracts, modules, and our loved Promise APIs. The ECMAScript is continuously evolving and enabling developers to make use of the best-of-the-class features right out of the box. Then, each web browser (and Node.js, etc.) implements those features; you—as a developer—don’t need to care about it. With that, it makes little sense to have to learn TypeScript to write safe programs.
Just as was mentioned for C++, TypeScript offers the benefits at a great cost. The Linux kernel is very simple and beautiful; for that, C language was enough.
TypeScript’s curse: any type
In the end, I believe that TypeScript is only beneficial if you go all the way in.
It is the same experience with an ORM. ORMs do allow you to open latches and write raw SQL queries to execute the code that is too complex for the ORM to generate. Or when the ORM generates incorrect SQL. If you do that very rarely, like a pinch of salt, that’s okay, and it’s normal in a big enterprise application to write raw SQL to push the business features. But, if you need to write the raw SQL queries in most of your method calls, then ORM is a luxury that you’re using.
Don’t do ORMs just because the cool kids on the block are doing it.
TypeScript allows developers to add the type system to programs and helps them understand and stay on top of all of the program's aspects. The strict configuration of the TypeScript compiler offers checks that detect if you are opening any latches that expose your app to bugs.
Key takeaway
The whole debate about TypeScript vs JavaScript is about the taste. The programs you write in JavaScript have the same benefits and performance as the programs you write in TypeScript. I am not even going to add a footnote here explaining how a few milliseconds on the front end are going to cost the users. Period.
TypeScript can add a type system to your apps that is stripped during the transpilation. During the development, the type system can give you a very nice overview of what to expect. If you are a solo-indie-developer, that’s okay. You know how you name the variables and fields. But if you are a team of developers. TypeScript can be valuable in that it can help you see when you are making a typo. Plus, it can also offer support and find the methods where you expect to return something but forget to return a value from a branch, and so on and so forth.
All that I am saying is that finding the bugs in production is expensive. Do you really want your team to find the bugs with no given contract to skip having to add a safety layer in your JavaScript-based applications?
If you said “yes,” then you’re one hardcore programmer. Let’s have a chat over this. Connect with me on Twitter / X @afzaalvirgoboy, and we can take this further.
With languages, I, of course, mean programming, scripting, markup, and every other dialect of languages. That’s totally fine. If someone wants to write HTML all day long or wants to use Perl to automate their tasks, that’s all fine. It’s just like coffee or juice; everyone has their own taste and right to select the one they prefer. But that does not mean that someone who has never had a cup of tea in their life starts to shout at tea lovers about how good their coffee is.
The structured query language, or SQL, is a set of commands used to script programs that work with databases or the database itself. You can read more about it at: https://en.wikipedia.org/wiki/SQL. SQL itself is a standard, but different database engines have a subset (or superset, how you look at it) of the SQL available to the database engineers to write the programs on top of the database engine.
Check out this blog: https://towardsdatascience.com/10-best-practices-to-write-readable-and-maintainable-sql-code-427f6bb98208, and this style guide on GitHub.
If you would like to read more about this, search for Entity Framework Core for the .NET framework and sequelize for the JavaScript/TypeScript ecosystem; sequelize is my favorite non-.NET framework ORM.
I do not like this concept of gymnastics. I think this is the wrong word and the wrong message. Usage of TypeScript does not mean that the developer wants to showcase their command over object-oriented static-typed languages. The developer wants to be sure, secure, and safe with their source code.
This can be configured, and you can tell the TypeScript compiler to process any file, but it will only touch the TypeScript code.