TypeScript vs. JavaScript

There is no simple answer to the decision on the debate of Typescript vs. JavaScript. The answer relies very much on your organization’s needs and the personal preference and expertise of the developers/technicians who work directly for you.

When considering Typescript vs. JavaScript, start by looking at your specific organization and use-cases and not some generic comparison table on the web, recommended Adam Abrams, Optimove director of architecture. “For example, we use JavaScript heavily on the frontend and backend, but our backend systems also leverage other technology stacks, mainly .NET and Java. Also, we develop microservices in medium-sized teams (around six developers) and need the ability to maintain the same code by different people on a sprint-by-sprint basis.

Optimove developers are used to typing languages, with a testing methodology that relies on basics such as null references and uninitialized variables, to be handled by the compiler, not by hand by developers, Abrams explained. “That’s why we standardized on Typescript across most of our services. Smaller or one-off services are still developed in JavaScript for speed of doing a POC, or testing a hypothesis. We have already later made the code migration to TypeScript in a gradual fashion for some of those. It’s a painless process (that usually improves the code and uncovers a few hidden bugs.)”

READ RELATED: TypeScript and the Power of a Statically-Typed Language

Abrams added, “The more business logic you put into your code (versus just I/O), the better off you’ll be using TypeScript for self-documenting your code with proper types. In JavaScript, it is easy to mix up units/types and get nonsensical results without notice. We noticed it also enforces good discipline on the developers to use the good parts of JavaScript in the actual code and leave the idiosyncratic parts out.”

Challenges with Typescript and JavaScript

Andrew Pierno, Veritone’s director of engineering, sees challenges with either answer in the TypeScript vs. JavaScript debate.

JavaScript is confusing, frustrating, seemingly easy to get started with, and impossible to master, Pierno explained. It is so flexible it’s easy to tie yourself in a knot. There are a million ways to do things, new tools coming out every day, and for as long as it’s been around has been the ugly stepchild of programming languages.

According to Pierno, a JavaScript advantage is that it is readily available for uses from web apps to desktop apps and even for blockchain-related uses. TypeScript solves the issue of JavaScript having “weird” types.

“But in my experience, that’s not an actual problem,” Pierno said. “Not once have I had a production system go down because of a TypeScript problem. TypeScript is two times the work to solve a problem I’ve never seen nor had. TypeScript offers the comfort of a strongly typed language for people coming from other programming languages. You can bolt it on to most applications and introduce it piece-meal in the most critical parts of the application.”

Typescript adds additional protection for large teams by introducing bugs that a compiler would normally catch in other languages but wouldn’t be caught without TypeScript in vanilla JavaScript, according to Pierno.

Minor Differences between TypeScript and JavaScript

“If you’re already using application frameworks or components or working with existing code based on JavaScript, converting to TypeScript will likely involve a major lift, particularly if your developers and support people have expertise in JavaScript and not TypeScript,” according to Jacob Ansari, Schellman security advocate, and emerging cyber trends analyst. With no compelling winner in the Typescript vs. JavaScript discussion, any situational benefits you might accrue from switching languages will likely come with a big cost in terms of testing functionality and retraining people.

“My suspicion is that making a move like that on an existing codebase for security reasons is rarely worth it, unless you suddenly get a new development team who has a lot of expertise in the new language and hates the old,” Ansari added. “Most organizations are better off fully understanding the security tradeoffs their languages, toolsets, and technologies provide and make design and implementation decisions based on those factors. better for its needs (and why)?”

The Case for TypeScript

Despite Ansari’s case for staying with whatever you are using now, Carl Saunders, co-founder and full stack developer for Raven Code Limited, argues that TypeScript is the clear winner in this debate.

“TypeScript is the only one you should use, as it transcompiles down to JavaScript,” Saunder said. “You don’t even have to write TypeScript in most cases — modern editors such as Visual Studio Code and WebStorm will infer the types (integrate with TypeScript) out of the box. This comes with huge benefits, as IntelliSense support will autocomplete the code and even highlight when a developer is doing something wrong (type checking). This alone will stop most errors being committed to the codebase before a review of the code is carried out.”

With TypeScript, a developer can easily write clean and maintainable code, allowing them to concentrate on writing the feature, Saunders said. Another benefit of TypeScript is a developer can adopt early ECMAScript specification proposals before they are publicly available, and behind the scenes, TypeScript will polyfill those features.

“TypeScript can also be used as a command line interface (CLI),” Saunders added. “This means a developer can run it as part of the developer workflow and within a background task. More importantly, it can be executed as part of the continuous integration (CI) build pipeline. This allows errors to be caught even before the code is ever deployed to users.”

Which One Should You Use?

It’s clear the choice for Typescript vs. JavaScript will come down to if you are already using one or the other and are comfortable with it. If so, look through the discussion above to see if there is any compelling reason to switch.

If starting from scratch, you’ll want to read through the discussion above, experiment a little, and see which appears to be a better fit for your organization.