Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When to Use TypeScript – A Detailed Guide Through Common Scenarios

khalilstemmler.com

Post reply on HN
Print view View original

91–100 of 244 posts

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

#91

Post by reificator »

josteink wrote: post #48
_bxg1 wrote: post #34

It's a default for me now, on every new project. It doesn't slow down development because TypeScript allows you to easily "step down" type constraints as desired, and writing nontrivial code without any kind of type hints is just unimaginable to me now.

> It doesn't slow down development I don’t know about the rest of the world, but I’ve never once been slowed down by a compiler saying “It won’t work like that. Don’t waste your time”.

> > It doesn't slow down development

> I don’t know about the rest of the world, but I’ve never once been slowed down by a compiler saying “It won’t work like that. Don’t waste your time”.

I'm right there with you, I really don't understand this train of thought that catching errors faster somehow makes you slower. I like having the compiler there to catch my errors when I make them rather than some number of minutes/hours/days/months later when everything is on fire and I've forgotten the context of what I was doing.

Maybe learning a statically typed language (nearly) first damages your brain irreparably, and there's no longer any hope for me.

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

#92

Post by danso »

dmit wrote: post #59
oaiey wrote: post #50

Earlier quoted context omitted.

I am not. CoffeeScript was never as popular as Typescript already is. TypeScript is a tool which solves a problem, CoffeScript is a language (IMHO) no one needed.

To be fair to CoffeeScript, it introduced and popularized features that eventually made it to the EcmaScript standard. You could make a case for it being the kick that started the wave of improvements to JS that we've seen in the past decade. As for GP's post, I can only hope that Typescript leaves a similar legacy, even if the language itself ceases to exist.

That kind of historical retrospective is an article I would definitely read. As much as Coffeescript seems like a dying language when compared to where JS is today, its appeal was very strong for it to have become a default include in Rails 3.1, and to have been the primary choice for teams like Dropbox and Github [0].

0: https://en.wikipedia.org/wiki/CoffeeScript#Adoption

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

#93

Post by flabbergast »

> it's actually dangerous for your project to NOT be written using TypeScript today.

Wow! Bye bye Javascript! Such arrogance! In a way it always feels like Typescript developers are way beyond all those poor suckers still coding in Python, Javascript, Ruby, Coffeescript, etc.. Dynamically typed languages are DANGEROUS!!! just as C is DANGEROUS!!! I'm so happy C is still being used and not abandoned in favor of C# or so.

I know I can be way more popular preaching Typescript nowadays, it would make me really cool, smart and up to date. Not going for Typescript proves I'm mediocre at best. This is not cynic, this is real when I talk to fellow web developers.

I believe static type checking should ideally be done by the IDE, we shouldn't need an entire new language for that with all its shortcomings, issues and whatsoever. And we'll see what's left when the hype is over and the next big thing in the Javascript world comes around. At least heaps of Typescript code bases that need to be rewritten.

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

#94

Post by tills13 »

vore wrote: 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.

> greatly outweighs the amount of extra work for adding types

this is such a bad excuse, imo - the "work" required to get your wheels off the ground in a JS -> TS transition is literally just changing the filename. 99% of syntax / TS errors that present themselves after that change are bugs that your code already had.

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

#95

Post by widerporst »

humbleMouse wrote: post #18

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.

Yes, this makes writing Typescript actually faster for me than vanilla JS. The code completion in IntelliJ is really amazing.

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

#96

Post by bytematic »

chmln wrote: 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.

So many of these "do you really need" articles are this, authors who don't understand the idea of scaling

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

#97

Post by FlorianRappl »

Such a guide can be reduced to:

If you only have a single file that has a limited set of responsibilities (e.g., just a small tool) and is not shared / distributed then JS may still be okay, otherwise always go for TypeScript.

Honestly, TypeScript never slows me down. The enhanced completion / IDE knowledge, compile-time type checking, and transpilation supporting newer ES features + React is a huge boost.

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

#99

Post by mixmastamyk »

Normal_gaussian wrote: post #73
mixmastamyk wrote: post #63

Earlier quoted context omitted.

You also have to type, refactor, and test them. I work in multiple languages and the typed are definitely slower at the beginning, but pay off later. The strategy I outlined is the way to get the best out of both.

Also working in both I don't have this issue. I generally find types make refactors faster - I have less bugs from the refactor.

A mature refactor yes, a change in design often not.

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

#100

Post by mixmastamyk »

Retozi wrote: post #72
mixmastamyk wrote: post #39

Earlier quoted context omitted.

> unimaginable I imagine adding types gradually as a design solidifies, rather than slow velocity early on. Best not to be dogmatic on these things.

I have never understood why typed languages make you slower at any point in time (early, late etc.). Because you have to hit more keystrokes to write your program? That doesn't compute. typing is the thing you do the least amount of when programming. In all best practices we are taught to not save keystrokes. Name your variables expressively. write small functions. document code. Write tests. All ""excess"" keystroke…

Yes. Extra typing is not a huge drain, I agree, but it is a minor one. Shorter is better until it impacts readability. Visual noise is a thing.

Code is read much more often of course. You may argue you can read a fifteen-page book as fast as a ten-pager, but it's pretty clear that's not the case.

Of course tools and inference change the balance, but even so I avoid putting code into the the kiln until the design is fully understood and at least satisfactory. And that can take a few revisions.

Post reply on HN