Live data from Hacker News

When to Use TypeScript – A Detailed Guide Through Common Scenarios

khalilstemmler.com

21–30 of 244 posts

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#21
post #15
post #3

> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.

You don't need to rewrite to add types.

In theory maybe you are right. In practice it never just adding types. E.g. you need to add null checks, rewrite old parts to follow same style (in case there are old parts in the code) and etc.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#22
post #19
post #3

> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.

I couldn't agree more with you on this. I often see good, actually simple solutions get turned down due to people saying "that's too complicated for what we need", only to later hear, after a couple of months in production, that nobody wants to touch the codebase anymore since it's unapproachable and the rewrite will not happen due to high risk since it's critical production code now.

There must be some bias here in what your remembering. Are the projects that didn't need to be extended, simply doing what they need to, sticking out in your memory

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#23
post #10

Regarding TypeScript, the benefit of catching way more errors at compile time greatly outweighs the amount of extra work for adding types. If you're starting a new JavaScript project, you should definitely think long and hard if you pledge not to use TypeScript.

And the best part is that TypeScript is just a superset of JS. If you're new to TS, you can use it like you've been using JS. Just by giving your variables the `any` type, or disabling null checking, and so on, you can write JS like you always have. No pressure.

And, eventually, you'll be lulled into properly typing your variables, because damn it those type annotations are super handy! Oh, and you start defining your own interfaces because it makes your code more readable and easier to reason about. Oh, and...etc etc etc.

If you start by gradually adopting the extra features that TS provides, you'll never want to go back.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#24
post #16
post #4

4 of the most popular language creators here https://www.youtube.com/watch?v=csL8DLXGNlU agree that type systems are useful. I would suggest definitely not using Vanilla JS. There are excellent type systems over JS, TypeScript, Scala.JS, BuckleScript to name a few each with their pros and cons (I don't know what cons BuckleScript has though, maybe relatively smaller lib-ecosystem)

Larry Wall is endorsing strong types? I'll have to watch that now. I guess you can use Perl 6 in a way that approximates it, but it's very optional.

Does anyone have a timestamp for Larry Wall talking about types?

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#26
post #25

Always, unless it's a very short script that uses packages that have no type definitions.

the issue I run into (and maybe there is a quick solution) but when I work on a TS React project and want to add a library that does not have Typings definitions, i get in a world of hurt. trying to quickly add my own typings or fix TS errors w/out disabling major compiler functions.. usually spend an hour or two and give up on the library.. is there a good way to deal with this scenario?

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#27

Typescript is wonderful, especially as someone used to writing a lot of java/groovy. Typescript is like pouring cement around your javascript house of cards. It makes writing front end code painless and predictable. It also has amazing tooling in intelli-j. Code completion, linting, package recognition, all the good stuff.

> It also has amazing tooling in intelli-j. Code completion, linting, package recognition, all the good stuff.

... and in the free Visual Studio Code, also crossplatform like IntelliJ.

(Nothing against IntelliJ, JetBrains is a cool company with amazing products IMO, I just prefer VSCode myself.)

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#28
post #3

> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.

Rewriting vanilla JS to Typescript isn't that big of a deal though. It would be more like building a house on a budget, then adding some fancy paint, furniture and alarm system.

In my experience, if you spend a few weeks in the "exploratory" phase writing ES6, rewriting to TS won't take more than one or two days.

Nowadays I'm a lot better at Typescript and will use it from the get go, but for someone who is less skilled in it, it might much faster to produce working code first and add types later.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#29
post #15
post #3

> will most often write vanilla React.js apps when: the codebase is small This one never ceases to amaze me. Any codebase is small, until it gets big. And once it's big, the effort to rewrite is hard to justify. You don't build a house and add the foundation later.

You don't need to rewrite to add types.

If you want type-safe code you will usually have to rewrite some parts of your app, or most of it if someone butchered the initial implementation.

Re: When to Use TypeScript – A Detailed Guide Through Common Scenarios

#30
post #25

Always, unless it's a very short script that uses packages that have no type definitions.

the issue I run into (and maybe there is a quick solution) but when I work on a TS React project and want to add a library that does not have Typings definitions, i get in a world of hurt. trying to quickly add my own typings or fix TS errors w/out disabling major compiler functions.. usually spend an hour or two and give up on the library.. is there a good way to deal with this scenario?

That is a pain point, but I think of it as spending a few hours to save a few weeks down the road.
Post reply on HN