DEV Community

Typescript: First thoughts

Damien Cosset on June 19, 2019

Introduction Typescript is a typed superset of Javascript. Because it is a superset, any valid Javascript is therefore valid Typescript....
Collapse
 
prahladyeri profile image
Prahlad Yeri • Edited

Its my unpopular opinion that typescript is a flopped product when the full power of ES6 is already available to you. More than 95% browsers of the world already support ES6 and besides, ES6/JavaScript is a standard unlike TS which is a Microsoft product.

Only one high-profile project uses TS and that is Angular2 and there is also a whole lot of mystery about why Google adopted TS in Angular2 despite it being a competitor's product.

Finally, maybe I'm prejudiced because I'm coming from Python/PHP background but I don't like static typing very much. It restricts you in expressiveness especially when it comes to creating complex structures like classes and and interfaces. In fact, a dynamic language like python has no need for interfaces or even classes, modules themselves have the flexibility and modularity to help you build whatever you want.

Collapse
 
chibiblasphem profile image
Debove Christopher

About TS vs ES6. The debate is totally closed when even Babel 7 enhanced the babel compiler to transform typescript annotation to AST

About what you this is flexibility and modularity, I have one simple example where PHP & Python fail with dynamic typing

  • Tomorrow you change the type of the return value of a function which is used like a dozen times across all your project. Typescript fails a built time, if you do not update the use of this function. PHP & Python will fail at runtime, sometimes where you didn't thought about (thanks to alias/renaming etc)

(Hope I have been clear)

Collapse
 
mazentouati profile image
Mazen Touati

PHP & Python will fail at runtime, sometimes where you didn't thought about (thanks to alias/renaming etc).

Only true when you don't have a testing suite. Which is obvious to have when you are doing some serious work.

Thread Thread
 
cubiclebuddha profile image
Cubicle Buddha

With TypeScript it’s possible to write code such that you don’t have to write tests at all to validate certain scenarios. I’ll be writing about that in a future article.

Thread Thread
 
mazentouati profile image
Mazen Touati

Well, I was talking in general about dynamic typed languages. However, even if we consider that all languages have an X technology like typescript. Why would someone decides that all current and future devs should know about that X technology to avoid such scenarios. While they can simply use universal knowledge such as unit testing or acceptance testing, with minimum learning curve, to ensure a functional app.

Anyway, even if you use typescript there's no escape from testing.

Personally, I don't consider the fact that regression is catchable at compile time as a game changer.

Thread Thread
 
gerreth profile image
Gerret Halberstadt

TypeScript will and should not prevent you from writing tests, and it never came to my mind to think about it like that. Also, comparing ES6 vs. TypeScript is misleading. ES6 is simply a new syntax for JavaScript. Since TypeScript is a superset of JavaScript, so of course it is also for ES6.

But let's break down testing. Assuming you have written your test and only considering type errors, it might look like that (though you might automate some steps):

  1. You implement a new feature or are changing an existing one.
  2. You go to your terminal
  3. Start the test
  4. The test runs
  5. Some test indicates failures
  6. You check the failing part of your code



With TypeScript:

  1. You implement a new feature or are changing an existing one and type errors are indicated right away while you are writing



The point is, TypeScript prevents you from making obvious mistakes very early on. Additionally, and I found this to be very useful, you are reminded if variables can be undefined or null. Even if you write tests, you might very well forget to test certain cases. But again, TypeScript should not free you from thinking about all cases that can happen, but it could serve as an additional layer of testing.

Thread Thread
 
mazentouati profile image
Mazen Touati

Indeed, it's super powerful to have something like realtime testing for your code. However, I still think it's a matter of preferences not a must have technology. I don't like the idea of centralized ecosystem around Microsoft products ( I'm not Microsoft hater tho ). I want to use my editor of choice that not necessarily supports typescript realtime checks. I run tests only once at the end to ensure no regression is happened and my logic is right ( which means my types are right too ).

During writing code HMR and linters are supper enough in my opinion.

Thread Thread
 
cubiclebuddha profile image
Cubicle Buddha • Edited

real-time testing for your code

Yes, testing is great. But when I converted my old JS code to TS code, I was able to delete 500 lines of test code that was just checking if functions were passing the correct type. I don’t have to check that anymore because TypeScript checks it for me. Bye bye jest.expect().toHaveBeenCalledWith(expect.any<string>, expect.any<number>)

linters are supper enough in my opinion

TypeScript is a linter. In fact it’s tsc runner uses the same AST parsing that EsLint uses.

I don’t like the idea of a centralized ecosystem around Microsoft products (I’m not Microsoft hater tho)

If you’re not a Microsoft hater, then why mention it at all? Microsoft has really doubled down on open source technology with TypeScript, VSCode, and .NET Core (which typically runs on Linux which is amazing for a company that used to revolve around their operating system sales).

Thread Thread
 
mazentouati profile image
Mazen Touati • Edited

You got rid of 500 lines of test but you sacrificed flexibility. What if a new JavaScript developer ( who is not familiar with typescript ) joins your team? or your company should be exclusive for typescript developers?

Keeping JS or migrating to TS it's a decision that has pros and cons on both situations. It's up to you or to your company to decide what suits you the best and what to sacrifice.

TypeScript is a linter.

Typically, a linter does not enforce you to use a specific syntax neither the ability to transpile. TypeScript is a superset so technically it's a programming language itself.

If you’re not a Microsoft hater, then why mention it at all?

I mentioned it just to make it clear that my opinion is not biased by hatred toward Microsoft still you confused me with a Microsoft's hater.

Personally, I'm very comfortable with many of Microsoft products, I'm writing this from Win10 and I use VSCode occasionally but this does not mean I'll automatically praise any product Microsoft launch.
Though, I'm super happy with the recent contributions Microsoft has made for the open-source community.

Thread Thread
 
cubiclebuddha profile image
Cubicle Buddha • Edited

What if a new JavaScript developer ( who is not familiar with typescript ) joins your team?

I would be really excited to pair-program with them until they feel comfortable with TypeScript. I'd be really excited to mentor them and to show the value of clearly communicating yourself in code. It's one of the reasons why I'm so passionate about this series I'm writing on TypeScript's emotional/conversational value: dev.to/cubiclebuddha/communicating...

or your company should be exclusive for typescript developers?

I would never dictate the technology for an entire company. The best companies are polyglot and supportive of each team's needs. Now as far as the teams that I lead, I make sure that my teams can develop new features very quickly without having to spend a lot of time fixing old bugs that crop up. So my team members have really gotten used to TypeScript and some have learned to love it.

Thread Thread
 
mazentouati profile image
Mazen Touati

until they feel comfortable with TypeScript.

This is the issue that made me enter the conversation in the first place. Why would you decide that they should use TypeScript. It's okay if that's what your team is comfortable with but this will narrow down your options in term of hiring new talented JavaScript developers ( who are not necessarily interested in TypeScript ).

I would never dictate the technology for an entire company.

Of course, I meant is it okay for your company to use both JavaScript and TypeScript for its projects ?

Thread Thread
 
cubiclebuddha profile image
Cubicle Buddha

Yes, a company should be free to have teams that use whatever language that makes them the most productive.

Thread Thread
 
chibiblasphem profile image
Debove Christopher

You got rid of 500 lines of test but you sacrificed flexibility.

I really can't see how using TS sacrifice flexibility... On the contrary I've gained a lot more...

Thread Thread
 
mazentouati profile image
Mazen Touati • Edited

I meant flexibility in term of expanding the team or sharing the code as not all JS developers required to know TS.
Despite that, I'm really interested to know more about TS and what flexibility it gave you ?

Collapse
 
ganderzz profile image
Dylan Paulus • Edited

I used to be one of those anti-static typing people; after using Typescript in enterprise projects I'm totally on the other side of the fence now.

The power in Typescript comes mostly from the tooling around it. VS Code can autocomplete, or tell you the structure of what functions arguments are expected. The IDE automatically yells if we get types wrong without having to switch back and forth between a browser. This is all huge when working in dev teams. Small or large!

Luckily Typescript is a lot less strict than most statically typed languages due to duck typing. This a long with the any type makes it pretty cool we can switch the lever between dynamically to statically typed at any time.

Obviously, this is highly dependent on the developer's efforts. 
You can write proper garbage with Typescript or elegant readable poetry with vanilla Javascript.

^^^ You summed it up nicely πŸ‘

Collapse
 
emptyother profile image
emptyother

I disliked js.I never liked writing frontend code until typescript came along.

Too much time spent on silly typos. Too much time writing null/undefined/0/[] checks. Or spent time protecting method arguments from messing up string and number addition. I can code faster, with less errors, without having to re-reference the documentation constantly. I can rename a variable and be sure it gets updated everywhere. Whats not to like? Well, writing good type definition files for imported js libs can be a chore, but thats only done once.

Collapse
 
pmkroeker profile image
Peter

We switched from Vanilla JS to TS a few months ago which corresponded to starting with Preact. I would now never go back. Code is easier to follow, and it has caught more potential bugs than I can count.

Slowly incremented the strictness settings, and now am running with the full strict set. It takes some time to get used to the slightly different workflow, but IMO it really feels nice once you are used to it. I'm at the point were I look at all my programming through what types variables will be (re Python [3.7 does have some TS like syntax for speccing types]).

It has for sure improved my code quality.

Collapse
 
stojakovic99 profile image
Nikola StojakoviΔ‡ • Edited

On my initiative we chose to use TypeScript on our new Node.js project - I would never go back to writing plain JavaScript. Being the strong advocate of static typing, I almost instantly liked the whole idea of TypeScript (even though it's not statically but gradual typing) and the ability it gives me to write huge JavaScript applications in a sane way. Even though I sometimes spend more time thinking how I should structure the code, I feel much much better knowing I won't make some stupid mistakes which you will eventually make using JavaScript no matter how good you are. TypeScript + class-validator and you can sleep well at night. And of course, I'm always using full strictness :)

Collapse
 
kelerchian profile image
Alan

I'm a static-types-or-its-wrong zealot cause it has saved me lots of times. ;)

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

Alan, you've gained an automatic follower. I'm also a static type zealot haha. I like it so much that I started a series of articles to try and explain the emotional advantages of TypeScript to non-TS people:
dev.to/cubiclebuddha/communicating...

 
karataev profile image
Eugene Karataev

Processing media files and js files is very different for a browser in terms of performance.
Most of web frameworks are trying to reduce their bundle size with every major release. Svelte was born because of this need.
I'm just curious how many KB Kotlin adds to a js bundle, because I really don't know. This information might help me to consider Kotlin as the main language for my next project.

 
kelerchian profile image
Alan

Hours of unnecessary development time wasted to manually fix untyped mess, undefined is not a function kind of bug, for starter.

Had the pleasure to dive and fix that kind of issue, hope it never happen again.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha • Edited
  • If you’re in the UI? Maybe use TypeScript.
  • If it’s a NodeJS backend? The only kind thing to do is to use TypeScript
Collapse
 
kelerchian profile image
Alan • Edited

At the beginning transitioning was hard because of the paradigm shift. It was worth it. Keep doing it.

Better quality in the code? Yes.

Typescript change the culture of the devs actually. Making them more careful and at the same time more relaxed on writing code and not worrying to find some undefined is not a function kind of bug.

I did notice using Typescript in a big project. Changes to a module that is a dependency to a lot of other codes doesn't seem as hard as when doing it in JS. Of course changes are mostly evil. It's better reduce changes with the right code architecture.

One thing that you might want to care about when you're using typescript, it doesn't help with your javascript code runtime. I found that using io-ts helps a lot (github.com/gcanti/io-ts). It sort of introduce a decoder to your javascript code so that it can decode unknown or any type to an exact type on runtime. Put decoder on network calls and storage accesses and your app would be resilient af.

Happy coding

Collapse
 
skyrpex profile image

How was your experience transitioning from vanilla Javascript?

  • It was rather easy to me. I guess it's because I have C++ background, and also played a little bit with Flow (from Facebook).

Did you notice better quality in the code?

  • Nope, and I think it's because code quality equals to developer quality. What I've seen is that the code is easier to understand because you don't have to guess the types of the variables, thus speeding everything A LOT. Guessing values is a hell in dynamic languages...

  • How did Typescript change the development type?

Not sure what you mean by development type, but as I said: a Typescript codebase is multiple times easier to adopt than a vanilla JS codebase IMO.

  • Do you notice a difference between using Typescript in small teams and bigger teams?

I've never worked with Typescript in a big team, but I can extrapolate and say that it would be immensely beneficial.

Collapse
 
karataev profile image
Eugene Karataev

If I had a need for a modern typed javascript variant I would use Kotlin.

Kotlin requires to include the helper .js file in order to process a project's code in runtime. What is kotlin.js filesize nowdays?

Collapse
 
andrewbrown profile image
Andrew Brown πŸ‡¨πŸ‡¦

So for my open-source video game Swap'N'Pop I changed it from CoffeeScript to TypeScript in hopes that it would improve collaboration and lead to fewer mistakes and I believe this conversion was successful.

I do prefer dynamic and implicit languages though having everyone be able to infer what they should do or find how to do something paired with their skill level created too much friction and this is where Typescript excelled.

When we used TypeScript I relaxed the strictness because it was too much for some to adhere to.

So I am also conflicted with TypeScript.

Collapse
 
cubiclebuddha profile image
Cubicle Buddha

A lot of the new built-in types that TypeScript has added in newer versions make it easier to get more dynamic without sacrificing code quality. Generics also help a lot.

Collapse
 
mattferrin profile image
Insight Lighthouse

Because of strict TypeScript, my QA coworker wasn't able to find many bugs. They were more able to focus on automation. I have become comfortable sharing my code with QA sooner. All positives in my opinion.

Collapse
 
degesis profile image
PovilasB

I hated TS at first but after trying to refactor app that uses TS just once i fell in love with the language immediately.

 
karataev profile image
Eugene Karataev

You keep saying that you can eliminate extra KB in js by compressing media assets. But JS is the most expensive part of a website to process by the browser and 200KB of JS !== 200KB of JPG.
200KB

Kotlin default package is 838KB. Is it correct that by introducing Kotlin to a project, I add almost 1MB of JS to my bundle? If it's the case, I'm not surprised that there are no popular websites made with Kotlin.

 
cubiclebuddha profile image
Cubicle Buddha

On the frontend the choice is usually made for you

What do you mean? React, Angular, and Vue all support TypeScript.

Thread Thread
 
kelerchian profile image
Alan

Everything has its place, the challenge is knowing the best tool for the job.

The Neil I'm know.
Love your blog btw.
Cheers.