3 Reasons Why Every Java Developer Should Learn TypeScript in 2019

Estimated reading time: 6 minutes

1260 words

New technologies and frameworks seem to be popping up every day.

But one of them in particular seems to be sticking around for a lot longer, and in fact, growing in popularity.

That technology is JavaScript.

In fact, the 2018 Stack Overflow Developer Survey shows that the most popular language was JavaScript.

Here's the thing:

When I think of the terms "backend developer", I think of Java, C#, and Go. Most certainly not JavaScript.

But as developers, we're playing in an ever-changing and fast-paced environment.

Learning new technologies is a must — otherwise some up and coming kid out of a coding bootcamp might come and eat your lunch. You don't want to be left behind do you?

At the same time, you can't be plagued by shiny object syndrome, because not all technologies stick around and capture market share.

In today's post I'm going to share why it might be time to bite the bullet, swallow your disbelief, and think about using TypeScript.

Plus:

You might be surprised at the similarities between Java and TypeScript.

Obviously…types

It's called TypeScript for a reason. Because it has types. Moving on…

Okay, okay, let me explain why that's actually a good thing.

There's two reasons here.

The first:

1) But…does it scale?

There's no hand waving or guessing around, "does this object have this attribute or method?". From a developer's perspective, that means that she has to now check the entire flow from when the object was created to where it's now being used.

Not really a great use of time, but you kind of have to do it to prevent bugs.

Now, multiply this across an organization. Engineers are adding features, refactoring, and fixing bugs, and they're checking and double checking each time they make a change [1].

A trivial check they would get for free with a statically typed language.

Let's face it. This is no way to sustainably scale your codebase with engineers tripping over themselves.

With TypeScript, you don't have this issue. Just inspect into the class, et voilà, you'll have your answer.

That brings me to my second reason:

2) It seamlessly fits into your developer toolchain

Because it's a typed language, even a text editor like Visual Studio Code starts to feel more like an IDE.

Honestly:

As Java developers, we're spoiled by Intellij IDEA's fancy features.

Code completion, quick definition lookup, and one-click refactoring isn't something you normally get from a text editor.

And those features are really hard to live without.

But with Visual Studio Code and TypeScript you'll feel right at home. You'll be jumping into files, refactoring code, and the only thing you'll notice other than the different keymap is the cleaner look [2].

Yep I said it. And grab yourself this theme while you're at it. You deserve it.

3) Move As Fast (Or Slow) As You Want

Want to know why all the kids are picking up JavaScript instead of an old crusty language like COBOL — er Java?

I won't tell you why. I'll show you why.

Look at the docs for Spring Boot: arguably the fastest way to set up a Java Web Application.

To the uninitiated, what does this mean?

@SpringBootApplication is a convenience annotation that adds all of the following:

  • @Configuration tags the class as a source of bean definitions for the application context.
  • @EnableAutoConfiguration tells Spring Boot to start adding beans based on classpath settings, other beans, and various property settings.
  • Normally you would add @EnableWebMvc for a Spring MVC app, but Spring Boot adds it automatically when it sees spring-webmvc on the classpath. This flags the application as a web application and activates key behaviors such as setting up a DispatcherServlet.
  • @ComponentScan tells Spring to look for other components, configurations, and services in the hello package, allowing it to find the controllers.

Beans? Classpath? DispatcherServlet? Huh? What year is it again?

Look at the starter code Github repository. build.gradle? pom.xml? Here are some potential questions:

  1. Why do I have to learn Gradle for a trivial "hello world" guide?
  2. Wait — Maven? Do I learn Maven or Gradle?
  3. Oh no…do I need to learn both?
  4. Is that XML? I didn't know that was still a thing

Meanwhile, look at the expressjs docs.

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => res.send('Hello World!'))

app.listen(port, () => console.log(`Example app listening on port ${port}!`))

One self-contained example. 5 lines of code.

And they even give you a runkit notebook right on the page for instantaneous feedback!

We all get it.

Not only is it really easy to get started, but JavaScript is incredibly expressive. You can move mountains with just a few lines of code.

It gets even better.

With TypeScript, you get all that expressiveness with the productivity of your developer tooling that you've come to expect from Intellij IDEA.

You're literally flying along at lightspeed while the Spring Boot docs are still mumbling incoherently about "traditional WAR file deployments" and "bean configuration".

Bonus Reason

As Java guys we know and love the power of working with a statically typed language.

But did you know that statically typed languages also leads to a lower incidence of bugs?

A 2017 study [3] between Microsoft and University College London surveyed public JavaScript projects on Github to see if Microsoft's TypeScript or Facebook's Flow could have prevented bugs from being committed.

They looked at public bug reports and concluded that 15% could have been prevented!

The results are encouraging; we found that using Flow or TypeScript could have prevented 15% of the public bugs for public projects on GitHub.

It gets even better:

AirBnb recently gave a talk at JSConfHI and found that according to a postmortem analysis, 38% of bugs were TypeScript-preventable [4].

That's All Folks

You know, I wasn't too sure about TypeScript either.

But I took the plunge, came out on the other side and I'm really liking it.

It has types, fits into your existing workflow, and it's way more expressive than Java.

But don't take my word for it. Try it yourself and I'll see you guys in the next post!


[1] I always found this terribly ironic. Why is it that we proclaim bold innovations by dynamically typed languages in their freedom and expressiveness, only to circle back around and add type checking a few months later?

It seems like a new type checker for Python comes up every month:

And of course JavaScript has Flow and TypeScript.

What does this mean for you and me? Dynamically typed languages are a safe bet for hobby and small projects. But it's a nightmare when you have multiple teams working on the same code base without type checking.

[2] DX is critical to velocity and your IDE/text editor plays a key role. If you're working in a language where you can't cmd + click into a declaration, you're wasting brain cycles.

Because now you have to global search. And what happens when you do that? Unnecessary context switching to parse through search results.

Your search comes back with 3-4 results. So you context switch a few times before finally finding what you wanted.

Add this up over the course of a day, and multiply it across your organization.

Yikes. That's a lot of wasted cycles.

[3] http://ttendency.cs.ucl.ac.uk/projects/type_study/documents/type_study.pdf

[4] JSConfHI

back