Live data from Hacker News

When to Use TypeScript – A Detailed Guide Through Common Scenarios

khalilstemmler.com

161–170 of 244 posts

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

#161
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'm just jumping into TypeScript after a decent break from production coding. Prior to this break it was Rails, well before that Java.

In my own Hades moment -- Microsoft know how to build great developer tools. The developer ergonomics of TypeScript and Visual Studio Code are excellent. It's really quite surprising to see how far the JavaScript world has come.

Similarly, the DevOps world is becoming much (much) more JavaScript friendly. Serverless, Netlify, and things like AWS Amplify -- all with their foibles, but pushing JavaScript in meaningful ways. I don't think this is the case for many other languages/ecosystems.

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

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

Other than Ruby and PHP, I've only really worked with JS/TS on the backend. Which strongly-typed programming language would you recommend on the backend?

Depending on what it is you're doing, I feel that .net and Java are far superior choices. Obviously these are pretty heavy languages, so obviously decide for yourself whether the size of your app justifies using a language like this. My thoughts run along the lines of: "If people are justifying using Typescript because their projects are large and critical, they're probably large and critical enough to use a language designed for enterprise-scale development." I personally haven't used Go, but I've heard good things about its use in this domain too.

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

#163
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'm just jumping into TypeScript after a decent break from production coding. Prior to this break it was Rails, well before that Java. In my own Hades moment -- Microsoft know how to build great developer tools. The developer ergonomics of TypeScript and Visual Studio Code are excellent. It's really quite surprising to see how far the JavaScript world has come. Similarly, the DevOps world is becoming much (much) more…

I would actually agree with your statement about Typescript and vscode. Working with TS has actually been quite pleasant as far as getting up and running goes. I only ever had to consult the docs a handful of times, and each time my questions were easily answered.

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

#164

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…

People have written apps in C for a very long time now, and they work just fine, but it's not exactly the first language of choice for new projects these days outside of some very specific niches.

Maybe I'm failing to get my point across. I'm not saying that JS is the end-all-be-all of frontend languages, but that some people are speaking as if TS is the messiah and that any JS compiled without it is flimsy garbage. That tells me that people either have limited experience with TypeScript or they were poorly educated when they first began using JavaScript. TypeScript is probably a good tool for them to use. TypeScript is becoming more popular, perhaps with good reason, but the negative attitude TS fans have towards JavaScript is often very immature.

As you say, there are still niches where C is good, and C is going to be around for a very long time because it's used for so many things. To claim that someone can't write a well-built application that is maintainable and scalable is asinine. I myself probably wouldn't choose to write an application in C, but that doesn't mean I'm going to thumb my nose at anyone who decides to write applications with C. C is perfectly fine, and if someone is frustrated with it, then maybe it's just not the right programming language for them.

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

#165

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…

It's like making your swords out of bronze when steel is just sitting there.

I'm sure there are users of Dart who feel the same way about TypeScript.

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

#166

Earlier quoted context omitted.

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

I agree, in a type inferred language or a language where annotations can be supressed, this is just another matter of IDE affordable.

Some dynamically typed languages support type annotations that are only enforced dynamically; Julia is the primary example of such a language ATM.

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

#167
post #150
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…

> performance on a long running VM on CPU bound computations

I'm interested in learning more about this, any other keywords I should throw in if I start Googling about it?

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

#168

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…

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

Think about what you just wrote there.

It's also entirely possible that a given tool can work fine, but other people can build on top of it without irrationally claiming that said tool doesn't work. Elixir and Kotlin are examples of tools that improve upon other runtimes(Erlang and Java), but I've yet to hear anyone from either language community act so dismissive to anyone who chooses to write applications in Erlang or Java as some TypeScript users are towards vanilla JavaScript users.

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

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

Other than Ruby and PHP, I've only really worked with JS/TS on the backend. Which strongly-typed programming language would you recommend on the backend?

TypeScript is very easy to use with Node. You can also use the debugger in WebStorm with it just fine, and you'll be stepping through your TS code instead of your generated JS code.

The problem is really the Node ecosystem, which is a mess and a circus of security issues. Deno[1] may fix most of JS/Node's problems eventually.

For now, if you want a type system that's comparable to TS with a great ecosystem, the best you can get is either F# or Kotlin. If you're not a fan of ML, then you might want to start with Kotlin.

1. https://github.com/denoland/deno

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

#170

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…

>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. Implying that everyone has exceptional short term memory, and reading old code has virtually no cost.

I never said that TypeScript wasn't helpful. The picture painted by some people that frontend applications without compile-time type-checking are ready to fall apart at the seams and have knobs and springs go flying everywhere, like something from a Looney Tunes cartoon, is patently absurd.
Post reply on HN