DEV Community

Cover image for Is 2019 the year of TypeScript?

Is 2019 the year of TypeScript?

Nick Taylor on January 16, 2019

This comment in the Jest repository, https://github.com/facebook/jest/pull/7554#issuecomment-454358729, has been floating around on the Twittervers...
Collapse
 
ferdaber profile image
Ferdy Budhidharma

I'm one of the maintainers for React's types, and I'm writing a post series on how TypeScript works with JSX. Hopefully this'll clear up some of the magic smoke behind how JSX typing works :)
dev.to/ferdaber/typescript-and-jsx...

Collapse
 
ben profile image
Ben Halpern

Cool!

Collapse
 
sebbdk profile image
Sebastian Vargr

I really hope not..

Typescript, has its usecases, but without native support it is almost pointless to me.
Too much setup.

The easier debugging is nice however.

My main gripe is problably that it tends to promote large corp style OOP with bajillions of pointless interfaces and classes.

Which in my experience leads to state soup and lack of code-mutability.

Collapse
 
nickytonline profile image
Nick Taylor

For sure it can promote large corp style OOP. Perhaps, and I have no data for this, just my musings, is that Angular promoted this once they adopted TypeScript. DI, classes, decorators etc...

I've been using TypeScript in React and browser extensions and almost never use OOP. The only time I've really used classes in React was for components that required state. Aside from that rarely, and now that hooks are stable and able, function components would be the way to go for new work.

Having said that, OOP is not a bad thing. Just like anything, people can do bad things 😉

Collapse
 
sebbdk profile image
Sebastian Vargr

I am mostly against OOP, for a number of reasons that would longwinded and off topic. :)

I my world, the TS gains do not outweigh the layers of complexity added to all parts of the developing process from developer skills to the libraries and build systems we use today.

It is unnecessary for most things, so why bother with it?

Thread Thread
 
seangwright profile image
Sean G. Wright

I don't think Typescript does anything more OOP than JavaScript (ES2015+) does, besides Interfaces (which also appear in functional languages).

Typescript supports all the same functional concepts that JavaScript does, including being able to type higher-order functions. It also includes other functional concepts that aren't in JavaScript, like union types, or even better, discriminated unions.

Thread Thread
 
sebbdk profile image
Sebastian Vargr

I am talking about complexity, and the way I see the language generally used in practice.

TS has more features, that is the entire point of the language.

Exampletime,
Just yesterday I was debugging a TS npm library, all I wanted was add to poke the source with a few console logs.

But because it was a TS library it came in 5 different ES versions, had a slew of typings I had to see through, and the actual source was not included because npm is for JS.

This would have forced me to get the source code, hook it up to my npm dependencies and then build it with my few debug changes.

Is there a better way to debug, problably yes, I could have explored the map in the browser and addd breakpoints, or use some other tool.

Had this been a JS library I would have spend a few minutes looking over the source.

Now, imagine a junior wanting to do this.

Complexity comes at cost, it is the entire point of functional programming, but centered around the problem of state management.

Toting TS as a good tool for functional programming is like saying eating children is a good way to prevent hunger.

It overlooks the actual problem.

Thread Thread
 
seangwright profile image
Sean G. Wright • Edited

Yeah, that all makes sense. It's definitely a different workflow.

I'm used to other languages that don't ship source code in packages, so this is nothing new to me.

Npm package authors could include source if they wanted - so the lack of it seems more like a personal choice on the part of the author.

Also, the issues you noted about all the transpiled variations of JavaScript for that Typescript authored lib ... those appear with JavaScript libraries too!

If a js lib author uses Babel to support older versions of Node or browsers, they will include transpiled versions of their js code.

This seems to be more an issue of the JavaScript tooling ecosystem still needing to mature.

In .NET/C# I can make a package that has compiled code only, but includes a hash to a git commit. When I'm debugging, my IDE pulls the repo code down to my machine and lets me debug into it live. It's a great developer experience.

I think the JavaScript community will come up with similar creative solutions.

Thread Thread
 
sebbdk profile image
Sebastian Vargr

Lack of tools is not really the problem, quite the opposite the way I see it.

Tools should make us more productive, not be a nessesary thing to be productive at all.

The fact that we are even talking about solving the problem with more IDE tools suggests a flaw in the system.

We need something that will reduce complexity at this point. Otherwise the frontend community will end up fragmenting into completely unessesary domains of knowledge based on frameworks and what kind of transpilation we do.

More so than it already has.

Thread Thread
 
nickytonline profile image
Nick Taylor

Came across this today. I rarely use classes myself, but I thought this was pertinent to the convo.

Thread Thread
 
seangwright profile image
Sean G. Wright

And I love the new VueJs 3 functional component API RFC.

Functional + Types = 💗.

Collapse
 
blindfish3 profile image
Ben Calder

I tend to agree. I have to use it at work and I understand the arguments in favour; but to me it still feels like a ball-and-chain compared to vanilla JS. I do understand some of the benefits; but there are also some downsides:

  • junior devs coming from type-safe languages can get a false sense of security: e.g. not doing proper type-checking on data coming from a back-end
  • assuming that private really means private
  • not getting a proper understanding of JS. ((synctatic) sugar is bad for you)

But yes - mainly my problem is that it can encourage a classic OOP approach to coding when IMO one of the big strengths of JS is that it facilitates some really effective functional approaches.

Collapse
 
ben profile image
Ben Halpern

Might as well call it hypescript at this point. It seems like it’s all the rage.

Probably a good sign that an all-the-rage thing in JavaScript is a tool that should fundamentally help write more sound software across the board, and one that’s been around long enough to become pretty stable I’d imagine.

Collapse
 
chiangs profile image
Stephen Chiang

Hmmm HypeScript could have some fun typings in that language...

const newVariable: ohYeahStrings!;
const anotherVariable: awesomeNumber![];
const thirdVariable: bestObjectEver!{};

export everyoneIsInterestedInThisClass someClassName {};
export mostInterfaceableInterface IinterfaceName {};
Enter fullscreen mode Exit fullscreen mode

I dig it!

Collapse
 
sduduzog profile image
Sdu

I like HypeScript already 🙆 TAKE ALL MY MONEY!!

Collapse
 
mrtnrst profile image
Martin Arista

I do believe it's all the rage right now but there are times when I see the value in a JS implementation. I still think there is not enough support for certain types and you are left either writing your own adding any to describe something. And in converse, when working on a large codebase or teams the comfort of types is very helpful.

And naturally a shameless plug for a react-native expo starter I made to solve that problem for RN.
github.com/mrtnrst/expo-typescript...

Collapse
 
chiangs profile image
Stephen Chiang

I'm curious as to what types you're missing as well.

I have not encountered that yet. An interesting quirk is that if you only need Type checking then you should make an interface. Interfaces are thrown out at compile time which leaves your code lighter. Classes are kept and should only be used if you actually need to instantiate an instance of that type during runtime.

Collapse
 
totiiimon profile image
Totiimon

Which are some types you think are not supported? I was interested in jumping in this TS-hype-train and things like this are good to know before :)

Collapse
 
seangwright profile image
Sean G. Wright

I get the feeling Martin meant 3rd party libraries that don't have typings defined (if written in JavaScript) or are written in Typescript but don't provide their own robust types for APIs.

This can definitely happen, though it's a lot less common (and painful) than it was 3-4 years ago.

I recently used an Angular-specific 3rd party library for authentication. They didn't include types for some of their underlying JavaScript code.

I had the option of either using :any as the type (or leaving the type off, as it will default to :any) or writing my own types to describe their JavaScript APIs.

I wrote out some type definitions that covered the part of their APIs that I was using and the definitions took about 15 minutes after looking at the JavaScript code in the package under /node_modules.

If you decide to use :any (or, again, leave off any type annotations, which works fine) you are where you would be with plain JavaScript - so nothing lost.

If you add type annotations, you gain all the benefits of types - my favorite being discoverability of APIs.

Thread Thread
 
totiiimon profile image
Totiimon

Right, It made more sense after reading more about it. I think the discoverability in general is such a nice thing you get by going with static types that is almost worth it by that alone haha

Thread Thread
 
seangwright profile image
Sean G. Wright

Another nice thing about Typescript is how the types "flow" through the application.

Often I only need to annotate a couple of parameters, variables, methods.

Then when using those things the rest of my code is able to infer the results of operations.

For example:

function getName() {
  return 'lalo';
}

const name = getName();

Notice, there are 0 type annotations here...

But, Typescript knows that name is a string and anywhere I use name, either as a parameter or in an assignment or expression, Typescript will flow that string type to the next place I'm working with name.

A lot of developers when first using Typescript will add a ton of annotations to their code, only to realize later that Typescript is great at inferring type information and doesn't need us to be so explicit.

Collapse
 
vignesh0025 profile image
Vignesh D

Typescript seems to be really gathering attention nowadays. I remember avoiding Angular, as I had to learn another language.. Typescript. But its that same typescript that made me take Angular as well as trying all Possibilities to use wherever I use javascript from React to Electron Js. High quality intellisense and type enforcement makes Typescript 1st class.

Collapse
 
nickytonline profile image
Nick Taylor

If you're in Reactland, it couldn't be easier to get started with TypeScript these days since support landed in Babel 7 and they implemented support in Create React App.

npx create-react-app your-project-name --typescript
Collapse
 
samuraiseoul profile image
Sophie The Lionhart

To be fair having to learn Typescript AND Angular at the same time makes learning both significantly more difficult.

Collapse
 
wolfhoundjesse profile image
Jesse M. Holmes

That was my exact course, and I believe that is why I am so biased toward TypeScript. I avoided so much JavaScript pain.

I definitely took courses on fundamental JS later on, because as wonderful as TS is, at some point you will break your face if you don’t understand the underlying language.

Thread Thread
 
samuraiseoul profile image
Sophie The Lionhart

Oh yeah I LOVE TS, I just was overwhelmed with it at my first shot(I come from static typed languages but was very familiar with JS by this point), and it was annoying not knowing if my problems were TS or Angular when I tried learning both at the same time.

Thread Thread
 
vignesh0025 profile image
Vignesh D

Been There. Done that. 👍

Collapse
 
vignesh0025 profile image
Vignesh D

Nope. I stayed with React and Typescript. Angular's strategy felt too heavy for simple applications.

Thread Thread
 
samuraiseoul profile image
Sophie The Lionhart

I wasn't defending angular, I don't use it either. I was saying that learning both at the same time makes both hard to learn.

Collapse
 
sebbdk profile image
Sebastian Vargr

JavaScript is supported with no setup for almost all libraries, and run native in the browser.

Anything that adds complexity to that situation i would deem as a bad solution.

With TS, we are just shifting the work to someplace else and adding new problems for people to learn rather than solving the original issues.

Collapse
 
justinctlam profile image
Justin Lam

Not exactly sure what it means that 2019 is the year of TypeScript. I worked on large projects at Microsoft and they used TypeScript exclusively on large scale systems for years. And there is a good reason it was used over vanilla JavaScript. I can't imagine not having type safety beyond 1 developer.

Collapse
 
nickytonline profile image
Nick Taylor

All I mean is, maybe this is the year that its adoption really skyrockets. I've been using it since 2015 and it's 🔥.

Collapse
 
dance2die profile image
Sung M. Kim • Edited

I've just started dabbling with TypeScript and..
A simple change helped me to reduce the file size today 😉
probably because I wasn't doing Babel right 😅

But it wasn't so bad so more reason to like/move/try to use TypeScript 👍

js to ts

Collapse
 
nickytonline profile image
Nick Taylor • Edited

I know a lot of people came to TypeScript from Angular 2 and on, but for me it was a different path.

We adopted TypeScript in 2015 where I was working at the time and used it with a custom front-end library. After that, I jumped into the world of FinTech with React and TypeScript. And since then all my professional React experience has been pretty much all in TypeScript. And aside from React, I've used it in node as well. Works really well there too.

It plays really well with React. You know the TS team cares about Reactland, because they added the fragment syntax fairly quickly. And it plays well with Preact too. It was a minor fix, but I had a PR go into Preact for a types issue just over a year ago. Felt pretty good about that.

Collapse
 
seangwright profile image
Sean G. Wright • Edited

I think one of the wonderful things about Typescript is that it's an opt-in type system.

You can take the following JavaScript file (app.js):

const names = ['lawrence', 'kim', 'koala'];

const shortNames = names.filter(n => n.length <= 4);

And copy it into a Typescript file (app.ts):

const names = ['lawrence', 'kim', 'koala'];

const shortNames = names.filter(n => n.length <= 4);

And then compiled it with the Typescript compiler:

tsc app.ts

No changes were need to my JavaScript!

If I wanted to I could add just 1 type:

const names = ['lawrence', 'kim', 'koala'];

const shortNames: string[] = names.filter(n => n.length <= 4);

And everything still works!


Sure, Typescript code that you might see in an Angular application can have types everywhere and a bunch of strict compiler flags - but this is one side of the spectrum.

Typescript is happy and helpful anywhere along that spectrum.

Use :any (or don't add an annotation at all - it's the same thing), leave the compiler options loose, and ease yourself into it.

Then as the project grows in complexity, start flipping on compiler flags, add more types and see where your expectations of your code don't match reality.


If you just prefer no type information in your code, cool! Don't use Typescript :)

(JavaScript still has types, it's just weakly typed and doesn't require you to specify them)

But it's not an all or nothing thing - approach Typescript on your own terms and I think you'll find it enjoyable and interesting.

Collapse
 
simoroshka profile image
Anna Simoroshka

2019 is going to be a year of typescript for me for sure. It was a growing interest throughout 2018 (along with testing) and I finally might get a proper project in TS. My hopes are for higher code quality and predictability, and for the benefits of code editor suggestions :)

Collapse
 
ky1e_s profile image
Kyle Stephens

If you're an Angular developer you'll be pretty familiar with it already ;)

Collapse
 
aviaryan profile image
Avi Aryan

TS is something I have been looking to learn for months/years but haven't really started with. I am sure it is same w/ many other people. They are hitting the tipping point now. Can't wait to give it a try. 😁

Collapse
 
buphmin profile image
buphmin

Or is 2019 really the year js falls out of the top ten...because typescript bum bum buuum

Collapse
 
vitalcog profile image
Chad Windham

well, turns out, if you don't know javascript, your typescript will suck too. oh yeah, and all your doing is writing a superset of JS that literally transpiles back to JS in the first place, so it would be REALLY weird for typescript to displace JS, as ultimately that is what you are actually making with typescript...

Collapse
 
cal_woolgar profile image
Cal

I've recently started to write in TypeScript while creating my first Angular application and I love it. Being able to use types, classes, interfaces etc makes everything so much easier!

 
sebbdk profile image
Sebastian Vargr • Edited

Nah, people just need to start making it a factor. ;)

I am sorry, but i don't see how adding complexity to a situation resolves things, and i think that is perfectly valid reasoning.

For now TS is just yet another tool in a long line of stuff i need to setup before i can press the go' button.

For the record, strongly typed OOP languages like C#, Java, and C++ are the exact reasons i do not like TS/js-class to begin with.

My code has always done' stuff, it never is' stuff on it's own.
So why bother with that?

You write very subjectively, throw some ideas at me.
Otherwise i wont have much of a take-away from this. :)

 
sebbdk profile image
Sebastian Vargr • Edited

Oh yes i write about my subjective ideas' and i hope to get other ideas back.

I would love to hear yours, but it seems you are all out.

I will call it a day, because we can agree on one thing at least.

This is boring and uninformative.

 
sebbdk profile image
Sebastian Vargr

It is entirely possible to avoid most common down the line problems by keeping your codebase mutable, contrary to popular belief.

TS takes that mutability away by tying you to a language subset that requires extra tooling.

Collapse
 
jvanbruegge profile image
Jan van Brügge

The main problem with typescript is that it is becoming a hack upon another hack. The types get very long and the compiler has problems with them (I was able to let the type checker run into an infinite loop aka a stack overflow).

Typescript the idea is great, but the execution is lacking
Still worlds better than untyped js though

Collapse
 
seangwright profile image
Sean G. Wright • Edited

I've worked with Typescript for 4 years now on large and small projects, creating my own custom types and using typed and untyped libraries.

I've never run into a case where I had an infinite loop that caused a stack overflow of the Typescript language service or compiler.

I'm not saying it can't happen, but, based on my personal experience, I can't see this as being a "con" for the language.

I can make any compiler blow up with specially crafted code - that's just programming.

If your types are getting very long (I'm assuming because of complex generics), then you can use type aliases to rename them to something shorter...

Or maybe your system complexity is showing itself in the type annotations.

Collapse
 
jonrandy profile image
Jon Randy 🎖️

God, I hope not #killitwithfire

Collapse
 
vitalcog profile image
Chad Windham

This was literally my first thought when I read the title of this article 🤣🤣🤣🤣🤣

Collapse
 
vitalcog profile image
Chad Windham

That was literally my first thought when I read the title 🤣🤣🤣🤣

Collapse
 
chiangs profile image
Stephen Chiang

TypeScript is what makes Angular 2+ enjoyable for me. I'm seeing it added to everything lately. A good sign indeed.

Collapse
 
lysofdev profile image
Esteban Hernández

Big fan of TS. Been using it for years maintaining Angular apps and have even picked up the habit of using it for larger-than-small JS projects.

Didn't get around to trying Flow.

Collapse
 
ozzyogkush profile image
Derek Rosenzweig

We're gearing up to adopt it where I work, so very possibly yes.

Collapse
 
qm3ster profile image
Mihail Malo

If only TypeScript finally had newtypes.
At least in the form of flow's Opaque type aliases.

Collapse
 
stealthmusic profile image
Jan Wedel

TypeScript is the one reason that made me start writing Frontend code as a Backend developer.

Collapse
 
valentinogagliardi profile image
Valentino Gagliardi

Just published a TypeScript tutorial for beginners. Enjoy!

Collapse
 
nickytonline profile image
Nick Taylor

From Pete Hunt

Collapse
 
nickytonline profile image
Nick Taylor

It looks like even yarn is migrating to TypeScript.

Collapse
 
nickytonline profile image
Nick Taylor

@swyx 😉

 
sebbdk profile image
Sebastian Vargr

You can use all of those, what I am trying to say is don’t build your entire application around them.

You might want to change it later.

Collapse
 
begueradj profile image
Billal BEGUERADJ

This is like a TV advertisement, not a tech article.

Collapse
 
krishna444 profile image
Krishna

TypeScript strict syntax makes it scalable. So, big projects in TypeScript reduces a lot of pain in the ass.