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

151–160 of 244 posts

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

#151

Post by sonnyblarney »

ajxs wrote: post #142

At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more robust and comprehensive language. After using Typescript extensively working on a back-end application in a complex problem domain I feel that while it is definitely a fantastic improvement to the core language, it doesn't really escape Javascript's worst is…

" Issues like Promise-fatigue"

Actually, async-await is a nice feature of the JS paradigm that simplifies things and that I miss in the threaded world of Java.

But yes - use TS where you would have used JS, but TS up against other, more classical languages may not be the right choice for a lot of non-web projects.

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

#152

Post by weberc2 »

mixmastamyk wrote: post #39
_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.

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

Why do you imagine types slow velocity? My experience is the opposite. I occasionally prototype in Go and then backport to Python (to integrate with our application) because I can iterate so much more quickly (yes, Python has type annotations, but the ergonomics are poor and the type checker is immature).

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

#153

Post by sonnyblarney »

ravenstine wrote: post #139

The amount of fanboyism in these comments is astounding. TypeScript is a great tool. At the same time, people have written apps with vanilla JavaScript for a very long time now, and it works just fine. If types are really that big a deal that you have a hard time writing an application without a compiler checking your types, you should reevaluate what you're doing. It's not "dangerous" to use plain ol' JavaScript, an…

This is not fanboyism.

" people have written apps with vanilla JavaScript for a very long time now, and it works just fine. "

No, it doesn't, or else TS would not exist.

TS just outclasses JS on almost every front, it's not a religious statement, it's generally true: TS is the standard, it just has too many advantages over JS to allow JS inside the roost.

Though article is only misleading to the point wherein they're talking about TS vs other languages, for solving other problems.

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

#154

Post by sonnyblarney »

mandeepj wrote: post #130
TimTheTinker wrote: post #119

The article mentions object-oriented programming several times as a helpful paradigm (especially for domain-constrained problems where DDD is helpful). I’d also like to point out that functional programming is tremendously helpful for solving these types of problems, especially when combined with use of modules. TypeScript is absolutely capable of modeling, checking, and otherwise handling types in a functional progr…

> TypeScript over C# TypeScript is a transpiler for JS. C# is a server side language. Can you please clarify how former is the replacement for latter?

"C# is a server side language"

Node.js is very popular, making TS/JS available 'on the server side'

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

#155

Post by int_19h »

fourseventy wrote: post #35

Isn't anyone worried that TypeScript will go the way of CoffeeScript?

Given the sheer number of Microsoft's own popular products that have significant amounts of code written in TS - from Office web apps to Visual Studio Code - it's not going away any time soon.

https://www.zdnet.com/article/who-built-microsoft-typescript...

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

#156

Post by weberc2 »

williamdclt wrote: post #76
Retozi wrote: post #72

Earlier quoted context omitted.

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…

I completely agree with you, but the criticism isn't usually with typing number, it's typing complex higher-order functions or this kind of things. Where the time lost isn't in typing out the code, but in understanding what the type should be or (worse) what does this cryptic typing error means

I don’t tend to write or encounter many complex higher order functions in other languages. Are they common in JS?

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

#157

Post by james_s_tayler »

seanmcdirmid wrote: post #109
Retozi wrote: post #72

Earlier quoted context omitted.

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…

What usually slows me down about dynamically typed code is you have some variable returned by a function only denoted by var myVariable = myFunction(); and I'm sitting there staring at thinking... "what are the contents of that variable? what properties do I have access to on that object? what can I do with it?"

And figuring that out becomes a massive time suck when that's a constant across an entire code base. Statically typed stuff means I can very quickly find that out even if it's the first time i'm exploring that particular area of the code.

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

#158

Post by ajxs »

dhab wrote: post #150
ajxs wrote: post #142

At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more robust and comprehensive language. After using Typescript extensively working on a back-end application in a complex problem domain I feel that while it is definitely a fantastic improvement to the core language, it doesn't really escape Javascript's worst is…

I am not sure about other languages, but I have been programming in Java for many years, and Typescript does what Java does (minus performance on a long running VM on CPU bound computations) at a rate that I assume should be sufficient for most (business) apps, without any bloat. Can you elaborate on promise fatigue. In our setup we use async/await and the latest ES (although most of us prefer not using decorators if…

I've had too many terrible experiences having to maintain and work with buggy and poorly designed Node/Typescript packages. I'm especially thinking of the terrible choice of ORMs available for Node, Typescript in particular. TypeORM seems the de-facto standard and my experiences with it have been horrific. It looks like Hibernate but works like a dumpster fire. There isn't anything as robust as ORMs like EF or Hibernate for Node. I feel that the shortcomings of the NPM community have been pointed out one too many times, but on too many occasions I've felt that development of a product was made much harder by the choices of poorly developed frameworks as dependencies.

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

#159

Post by Dylan16807 »

a_wild_dandan wrote: post #8
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.

I see so many HN comments endorsing "build the product to exact specification using the minimum reasonable tool set." When you then ask "what happens when the specification changes?" you get hilarious answers like "just say no to the user", or "just extend the app!" This is why I always over engineer a bit, especially on new projects. I'll happily, for instance, add a framework before it's strictly necessary. I've ne…

Now the non-strawman version: it's a 5 gallon job, vanilla React.js is already a 10 gallon bucket, and typescript comes in buckets up to 100 gallons.

It's often a matter of how much you think the job is likely to expand, how much you should frontload work to make that simple.

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

#160

Post by quickthrower2 »

> I certainly didn't see the benefit... up until I started experiencing some really annoying stuff. Things like builds not failing when they should, buggy code and typos finding their way into production code somehow started to get to me

It's hard for me to understand how anyone can't see the benefit of types at compile time. I mean if you write more than 100 LOC you are bound to make a mistake that a typing system would catch and think "I wonder if there is a way the my build process could catch such as silly error". I can only imagine that such programmers are "write only" in that they add lots of features but rarely need to come back and maintain their code. With an ide with autocomplete it may mitigate some mistakes and give a false sense of security about non-static typing.

Post reply on HN