Ask HN: Why use TypeScript?
31 comments
Do you code in a team? Let’s say you see this function written by a colleague Jon in 2013:
processLedgers(ledgers)
What do you pass in? An array? An object? What are the keys?
Without types you are relying on comments (notorious for being out of date) or reading the implementation.
Often the implementation will palm off the work to othe functions and objects and maybe event send it to an api or bits of it. To get a true picture of what ledgers needs to look like you need to either read a tonne of code or copy and paste some other code you hope is right.
With types you define in the type what is acceptable. Many times you don’t need to look at the function definition or the code it calls or the code it calls calls etc.
So types save you time, reduce bugs, and make you happy!
processLedgers(ledgers)
What do you pass in? An array? An object? What are the keys?
Without types you are relying on comments (notorious for being out of date) or reading the implementation.
Often the implementation will palm off the work to othe functions and objects and maybe event send it to an api or bits of it. To get a true picture of what ledgers needs to look like you need to either read a tonne of code or copy and paste some other code you hope is right.
With types you define in the type what is acceptable. Many times you don’t need to look at the function definition or the code it calls or the code it calls calls etc.
So types save you time, reduce bugs, and make you happy!
I'm well acquainted with the merits of types in general (I've worked in Java & Scala for years).
I'm curious why it's so special on the frontend. I can't tell if it's just part of the Javascript hype-train, or if there's legitimately something different about the frontend.
I'm curious why it's so special on the frontend. I can't tell if it's just part of the Javascript hype-train, or if there's legitimately something different about the frontend.
> I'm well acquainted with the merits of types in general (I've worked in Java & Scala for years).
That's your answer - same merits for the front end.
That's your answer - same merits for the front end.
Hm... I feel like that's not quite the full picture. On the backend, for instance, there are options - if you like typed languages, use them! And if not, use something else!
But there appears to be a particularly strong movement towards TypeScript. I just can't tell if it's just yet another JS hypetrain, or if there is something else besides types that's a big win.
But there appears to be a particularly strong movement towards TypeScript. I just can't tell if it's just yet another JS hypetrain, or if there is something else besides types that's a big win.
It's Microsoft paid.
Before you had React - FB paid and before Angular - Google paid. For example Angular 1 was also promoted like - it's made by Google, so it makes sense. It didn't - Angular 2 is incompatible with 1 and rejects most of initial ideas.
All these giants supported also by governments can change trends however they want. You call it a hypetrain.
Before you had React - FB paid and before Angular - Google paid. For example Angular 1 was also promoted like - it's made by Google, so it makes sense. It didn't - Angular 2 is incompatible with 1 and rejects most of initial ideas.
All these giants supported also by governments can change trends however they want. You call it a hypetrain.
Because JavaScript is (still) a cluster fuck, where there is no formal, or even informal, shared code style and it often turns into a giant mess.
Typescript makes it a little less likely you muck up, plus you can use new stuff like string interpolation without ever having to think about browser compatibility.
Typescript makes it a little less likely you muck up, plus you can use new stuff like string interpolation without ever having to think about browser compatibility.
Once you go Typescript you never go JavaScript. You just get all those typing juices and you start getting fewer and fewer errors on your code.
I am also a Ruby dev. Haven't used TypeScript in a big project yet, just played with it, but I'd say it's gonna be a standard for frontend dev soon.
Why? Writing types isn't that time-consuming... Types will tell you very easily what is expected to be passed to function. Why does it matter so much? Imo in Ruby it's not that common that service calls are deeply nested. In frontend it's opposite. Components are very nested and with all that prop passing sometimes you have search lots of files to understand what's being passed. There are proptypes yup, but if you write proptypes, why not types?
Also data on frontend mostly comes from backend, so many times there is no really good docs for data that is brought from backend. In backend you mostly access 3rd party APIs with docs or your DB, which you can easily access to see what it delivers: )
And I am not even going to mention editor plugins that show you docs with expected types. Much fewer mistakes and easier coding with external packages.
Why? Writing types isn't that time-consuming... Types will tell you very easily what is expected to be passed to function. Why does it matter so much? Imo in Ruby it's not that common that service calls are deeply nested. In frontend it's opposite. Components are very nested and with all that prop passing sometimes you have search lots of files to understand what's being passed. There are proptypes yup, but if you write proptypes, why not types?
Also data on frontend mostly comes from backend, so many times there is no really good docs for data that is brought from backend. In backend you mostly access 3rd party APIs with docs or your DB, which you can easily access to see what it delivers: )
And I am not even going to mention editor plugins that show you docs with expected types. Much fewer mistakes and easier coding with external packages.
> Imo in Ruby it's not that common that service calls are deeply nested. In frontend it's opposite. Components are very nested
This feels like the answer that makes the most-ish sense, although I've worked with a ton of nested Ruby code as well.
My suspicion on why people use Typscript is that it's is more about the tooling than types. In Ruby or Python, I can drop into a REPL anywhere in the code and be in context of what I'm trying to do, but that seems way less common in Javascript. Perhaps because of the async nature?
This feels like the answer that makes the most-ish sense, although I've worked with a ton of nested Ruby code as well.
My suspicion on why people use Typscript is that it's is more about the tooling than types. In Ruby or Python, I can drop into a REPL anywhere in the code and be in context of what I'm trying to do, but that seems way less common in Javascript. Perhaps because of the async nature?
Tooling, that means? I haven't had an opportunity to work on a big/very-big JS project yet. But from experience based on working on small-medium size JS project, I guess console.log() and refresh is just enough.
After thinking about it, I guess readability is a huge part of it, there are lots, lots of JS packages. And it makes sense for them to be readable, so they could be easily updated by new contributors to remain valid.
Personally, I have really hard time contributing to gems, because of so much metaprogramming in them, I don't feel like spending a week to understand what is connected with what and if my changes can break it.
After thinking about it, I guess readability is a huge part of it, there are lots, lots of JS packages. And it makes sense for them to be readable, so they could be easily updated by new contributors to remain valid.
Personally, I have really hard time contributing to gems, because of so much metaprogramming in them, I don't feel like spending a week to understand what is connected with what and if my changes can break it.
Here are two relevant recent threads on the topic of typescript
https://news.ycombinator.com/item?id=18961916
https://news.ycombinator.com/item?id=18942260
https://news.ycombinator.com/item?id=18942260
This comment was enlightening, even if it appears fairly critical:
https://news.ycombinator.com/item?id=18946296
https://news.ycombinator.com/item?id=18946296
Not really, it's more of an anti-typed languages and anti-build steps comment.
Also, you have to question the programming skill of anyone who writes this:
Compiler warnings make it hard to test code quickly using console.log(...); I'm more reliant on clunky debuggers which slows me down a lot and breaks my train of thought.
In my experience, inexperienced or bad programmers litter their code with log statements because they can't understand error messages or are incapable of 'running' the code in their head.
Also, you have to question the programming skill of anyone who writes this:
Compiler warnings make it hard to test code quickly using console.log(...); I'm more reliant on clunky debuggers which slows me down a lot and breaks my train of thought.
In my experience, inexperienced or bad programmers litter their code with log statements because they can't understand error messages or are incapable of 'running' the code in their head.
Just types? Let me shed light on the other side before I become engulfed the flamewar. I come from Java/c#/c++ background and tackled Ruby and JavaScript. How the hell can someone do serious work in a language without types is beyond me. "Just types" means that TypeScript transforms JavaScript to a usable sane language.
I am a recent arrival to the JavaScript country and I was taken aback by the prevalent practice that one has to use other languages like TypeScript to develop JavaScript applications because the later is inadequate. I personally don't like having to learn yet another language and all the tooling around that. Aren't we already swamped enough? I am also amazed how JS standards won't address the core issues that make people need to use other languages.
So I created an experimental framework for myself, called JEEP. Its an OOP framework that enhances JavaScript by bringing features from C++. I shared with the community here by posting a Show but unfortunately it didn't succeed in capturing people's interest. I have more to say on this but defer it to later when the time is appropriate. I know and hope once I release a remarkable product created with JEEP, it will automatically garner attention. It was anyway intended to serve only me, which it is doing, and anything greater was always a bonus, so I am cool with whatever happens.
So I created an experimental framework for myself, called JEEP. Its an OOP framework that enhances JavaScript by bringing features from C++. I shared with the community here by posting a Show but unfortunately it didn't succeed in capturing people's interest. I have more to say on this but defer it to later when the time is appropriate. I know and hope once I release a remarkable product created with JEEP, it will automatically garner attention. It was anyway intended to serve only me, which it is doing, and anything greater was always a bonus, so I am cool with whatever happens.
What is remarkable project in TypeScript? It's just Microsoft money and brainwashing on conferences and in articles. It doesn't work reasonable way. I wish you good luck though.
You misunderstood me. I am completely against TS. I was talking about creating a remarkable product with my framework.
I understood you correctly. I'm just saying, even if you will build remarkable product you will loose with some corporation technology like TypeScript. They don't need to be remarkable.
Sorry for being so pessimistic. I wish it be other way. I keep my fingers crossed for your project.
Prettier is a code formatter, not really comparable to TypeScript
You're not missing anything and you will not receive any reasonable explanation for using TS. It's a step back 20y in programming. Easy to recognise when you were programming 20y ago also.
A step back 20 years in programming is quite a statement to make. What is your backing for saying that? What is Typescript doing that other languages 20 years ago discovered was bad?
I was programming all these languages and 20y I do web technologies. Dynamic typed languages with a neat syntax was a huge step forward, developer became powerful with a single line of code. The biggest discovery was - you need all that tooling, because your language is overcomplicated. I also participate many conferences back and frontend each year (sometimes each month) watching this weird and artificially made transition backwards in concepts not only on frontend.
So yes ~20y ago was that point where developers discovered they are more powerful with dynamic typed languages and a boom for web applications started.
So yes ~20y ago was that point where developers discovered they are more powerful with dynamic typed languages and a boom for web applications started.
What about the lost productivity from debugging really simple errors that would have been caught by type checks?
You stop doing really simple errors if you allow yourself to train in this direction. Really simple errors are really easy to fix. After all boilerplate and effort you make in this kind of typed languages is not worth it. I'm not saying now about inventions like Crystal, where there is no effort + there is performance benefit. But TypeScipt adds complexity, boilerplate, and it still compiles to JS so no performance benefit.
https://news.ycombinator.com/item?id=18978404
None so far...
None so far...
Because vanilla javascript sucks
Are types uniquely suited for frontend programming? Can't you get the same by using prettier? I feel like I"m missing something.