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

That's your answer - same merits for the front end.

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.

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.

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.

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.

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?

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.

https://news.ycombinator.com/item?id=18942260

https://news.ycombinator.com/item?id=18946296

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.

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.

None so far...