Image for post
Image for post

Introducing Type Safety To Your JavaScript Project? Think Again

James Wright
Jun 2, 2016 · 4 min read

Update — 1st February 2017

I’ve heard various counter-arguments regarding type safety in JavaScript since I first published this article, and while I still believe a lot of projects do not require the use of a typed JavaScript superset, I admit that I was too hasty in publishing this article. Some appropriate use cases have subsequently grabbed my attention:

  • Glimmer, the low-level rendering engine behind Ember, is written in TypeScript to promote monomorphic call sites, aiding performance when executed by V8 and potentially other JavaScript engines

I have additionally realised that writing smaller libraries in TypeScript and publishing them with the type definitions generated at build time simultaneously enables their seamless integration with typed and traditional JavaScript projects, thus giving developers a wider technological choice.

Nonetheless, for posterity’s sake, here’s the original article in its entirety.

Today, I encountered an article regarding the launch of JS++, which claims to “fix JavaScript’s lack of type safety.” Funnily enough, we already have TypeScript, ST-JS, and Scala.js, which assist developers in ultimately achieving the same goal.

Before I launch into this tirade, allow me to highlight three important points:

  • I’ve previously written a tutorial on establishing a simple TypeScript project. I see the hypocrisy but my opinions have changed since I published it over a year ago

So why am I generally against static typing in JavaScript?

Predominantly, what makes JavaScript such a powerful language is its weakly-typed nature; it’s trivial to implement branches of logic via type coercion, and it’s so easy to create object instances of an arbitrary type. Furthermore, the lack of compilation (unless one is using a transpiler or build tool such as Babel, for example) makes development incredibly fast, as long the code doesn’t result in any bizarre behaviours. In my opinion, this is what makes it so powerful for frontend and simple backend (e.g. IoT) development.

I personally believe that if one is developing a system so complex that it requires type safety, then one should be using a language that supports it at its core; writing a guidance system, which involves complex mathematical operations, in JavaScript is insane.

My main concern with these JavaScript tools and supersets is that they compile to, well, JavaScript; these programs are consequently running in a dynamic context, thus the same side effects could still occur. TypeScript, for example, may be statically typed (i.e. type information is gathered and analysed at compile-time), but one must have full confidence that the resulting code will still run as expected. Yes, of course even statically-typed languages are usually compiled to a lower-level language, which is then typically interpreted, but these target languages were surely designed with typing as a first-class citizen; as an example, Microsoft’s JIT compiler for .NET still implements runtime type-checking of its intermediate language before compiling to native code.

Furthermore, when undertaking frontend development, I’m still of the mindset that JavaScript should be used to complement HTML and CSS solutions e.g. adding classes to elements, making HTTP calls to backend services etc. While the web has matured in terms of frameworks for authoring larger, UI-based applications (FYI, I have written larger apps with React.js and vanilla JS too; I love both), I prefer to keep my JS as light as possible. I understand that this isn’t always a possibility in reality, but if backend systems serve as the source truth for fundamental business logic, then frontend code becomes lighter and less redundant; in this respect, what benefits will a type system bring?

Following my point of the size of frontend software, my current work entails writing concentrated web applications for each concern of the overarching system; as opposed to one large single-page application for our shop, which contains a product list view, a product details view, and a purchase journey view, we have respective Node.js-backed apps for them. Evidently, this is a best practice in terms of loose coupling and resilience, but from a code point of view, it allows one of focus more easily on the implementation of one area of our frontend.

My final argument is this; is JavaScript really that difficult to learn? As I’ve said before, ECMAScript 5 itself is a flawed language; the different function invocation patterns and how they affect the `this` keyword and lack of block scoping, for example, can make it difficult for beginners. However, with ECMAScript 6, plus the plethora of amazing resources out there, it’s easy to overcome and be aware of these issues. Why not just skip the middle man and learn the language directly?

I’ll close by saying I’m a fan of all typing approaches, but some suit certain scenarios more than others. If JavaScript works best for the majority of frontend software, given its ubiquity within development teams and their projects, then surely it doesn’t need a superset. Additionally, there is a truckload of languages that are inherently type safe, so stop reinventing the wheel!

freeCodeCamp.org

This is no longer updated.

James Wright

Written by

Software engineer, writer, speaker, and open source contributor. Worked at the likes of Sky, Channel 4, YLD, Trainline, and NET-A-PORTER.

freeCodeCamp.org

This is no longer updated. Go to https://freecodecamp.org/news instead

James Wright

Written by

Software engineer, writer, speaker, and open source contributor. Worked at the likes of Sky, Channel 4, YLD, Trainline, and NET-A-PORTER.

freeCodeCamp.org

This is no longer updated. Go to https://freecodecamp.org/news instead

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store