4 ms·

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? Writi

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.

shay_ker 8y ago
> 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?
- wrestlerman 8y ago
  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.

shay_ker 8y ago

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

wrestlerman 8y ago
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.