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

101–110 of 244 posts

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

#101

Post by scotty79 »

marcosdumay wrote: post #55
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.

Well, imagine type-first programming, where you design your system first just by writing the types, look how it works, and only when satisfied go bother with implementation. I'm not sure TypeScript is good enough for doing that (I don't know TypeScript that well), but it's simply much better than starting with code.

> design your system first just by writing the types,

Fine.

> look how it works,

Beutiful except it doesn't work yet because it's just types that make some shape. You could literally draw the thing with pen and paper.

> go bother with implementation.

And only then discover that something you have thought of as implementation detail is one of the main problems with your solution.

No problem. I'll just refactor some type. It's easy. Less beautiful but at least it'll work. Except it doesn't. Butchering your elegant design for hours you come to hard earned realisation that the shape you imagined that you wrote and carefully named all your types to represent actually has nothing to do with the one you need.

If you are a bad person you ship your mangled typed monstrosity that you just barely made to work with traces of your struggle fossilised for any future maintainers.

If you are a good person you toss everything to into trash (save for few hard earned implementations) and start fresh with knowledge and humility wishing you worked with TypeScript where you can start with implementation and only after you figured out the hard parts, add types that reflect your solution (finding few additional bugs in the process and getting more confident about the thing you wrote).

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

#102

Post by pvorb »

hahamrfunnyguy wrote: post #82
connor4312 wrote: post #69

Earlier quoted context omitted.

> I also feel unit-level tests are less necessary with TypeScript. Especially with strict compiler settings, including strict null checks, and the good type conventions they encourage. To give a small example, if you have a value that can either contain an error or a successful result, you can model it as the union of a success and error state. This prevents you from accessing the value until you check the result is…

With C#, I am pretty sure you can get some of what you mentioned by using stricter compiler settings.

This doesn't come as a surprise to me, since Anders Heijlsberg, wo created TypeScript, was the technical lead of the team that developed C#.

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

#103

Post by cheerlessbog »

flabbergast wrote: post #93

> 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…

> static type checking should ideally be done by the IDE, we shouldn't need an entire new language

I am not sure what you are trying to say here. Javascript is barely typed, so presumably you do need a new language to perform type checking.

Unless you mean that your IDE should be able to infer types, which is unlikely because typing defines intent, and we've all read plenty of code where we can't figure out what the code author intended.

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

#104

Post by marcosdumay »

scotty79 wrote: post #101
marcosdumay wrote: post #55

Earlier quoted context omitted.

Well, imagine type-first programming, where you design your system first just by writing the types, look how it works, and only when satisfied go bother with implementation. I'm not sure TypeScript is good enough for doing that (I don't know TypeScript that well), but it's simply much better than starting with code.

> design your system first just by writing the types, Fine. > look how it works, Beutiful except it doesn't work yet because it's just types that make some shape. You could literally draw the thing with pen and paper. > go bother with implementation. And only then discover that something you have thought of as implementation detail is one of the main problems with your solution. No problem. I'll just refactor some ty…

> You could literally draw the thing with pen and paper.

Paper does not tell you when something you draw is wrong.

> And only then discover that something you have thought of as implementation detail is one of the main problems with your solution.

What is no different from learning that something you implemented is wrong, except in that you spent less time to get the problem. Or do you expect some magical designing tool that will lead you to the right solution before you understand your problem?

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

#105

Post by vp8989 »

sideshowb wrote: post #74
_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.

Wait, type checking is good again? Suits me. Welcome to 1985 folks :-)

Also apparently SQL is #good now. But only because all the people who just spent the last 6 years doing Node said so.

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

#106

Post by smt88 »

flabbergast wrote: post #93

> 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…

Your comment seems to be a result of ignorance of what TypeScript is and how it works.

The main point you're missing is that TypeScript is gradual. It's a superset of JavaScript, meaning that you can use TypeScript when you want it or ignore it when you don't want it.

Any valid JavaScript file is also a valid TypeScript file.

> Dynamically typed languages are DANGEROUS!!!

See above. TypeScript is dynamically typed by default. It just also has a static type checker that you can opt into.

A good practice in both JavaScript and TypeScript is to use "const" instead of "var" or "let" anyway.

> I believe static type checking should ideally be done by the IDE

JavaScript doesn't have enough explicit information for this to be possible. The IDE can do a lot, but it can't do nearly as much if the developer's intentions are implicit. In TypeScript, the developer has the option (again, not the requirement) to make her intentions explicit.

> we shouldn't need an entire new language for that with all its shortcomings

Again, see above. TypeScript is a superset of JavaScript, not an entirely new language.

> At least heaps of Typescript code bases that need to be rewritten.

No, they won't. TypeScript compilers will still be available, even if they're not actively developed. They produce JavaScript, so worst-case scenario, you'll just have a JavaScript code base.

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

#107

Post by Jare »

danso wrote: post #92
dmit wrote: post #59

Earlier quoted context omitted.

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

Its syntax and design was very appealing to Ruby developers. I was more surprised when Fog Creek chose it for Trello in '12, but yeah back then the raw Javascript experience was fairly poor, and Typescript would still take a couple of years to be ready for production.

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

#108

Post by danmaz74 »

marcosdumay wrote: post #55
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.

Well, imagine type-first programming, where you design your system first just by writing the types, look how it works, and only when satisfied go bother with implementation. I'm not sure TypeScript is good enough for doing that (I don't know TypeScript that well), but it's simply much better than starting with code.

What you described is the waterfall approach, which brings so many problems in most real world software development scenarios.

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

#109

Post by seanmcdirmid »

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…

Though you have a point, writing down type annotations can seriously slow you down when you are doing exploratory (prototyping) programming. It can also make your code less readable as the annotations can get in the way of the logic you really care about (easily fixed in an IDE, but people want to still use notepad to edit/read code). Then there is figuring out what the annotation should be in the first place, again easily enough automated in an IDE but the notepad problem remains.

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

#110

Post by Jare »

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”.

I find that the first 50 lines are faster / more immediate without types. By 500 lines it's largely even. By 5000 you will have to pry types off my cold dead hands.

I wish I could be convinced by the likes of Rich Hickey that types don't actually help, because he's so smart and charming and eloquent, but my experience screams the opposite.

Post reply on HN