5 ms·
How will TypeScript instead of plain JS help the future me? Unless of-course you meant that as a joke (going by the wink).
by orange8 7y ago
How will TypeScript instead of plain JS help the future me? Unless of-course you meant that as a joke (going by the wink).
- Too 7y agoType safe code improves code readability, and the future you will most likely read the code you are writing today.
- orange8 7y agoIf you were more comfortable/most familiar with strongly typed languages, then yes. But don't assume everyone has your tastes. Java for example is a very strongly typed language, and I find the verbosity makes it harder to parse. Good, future proof code can be written in any language. There's lots of still functioning, well maintained js written 10yrs back out there.
- eropple 7y ago"I didn't have to write a test to know that I am passing a data structure correctly across every module of my application" is not a "taste" thing and comparing TypeScript to nominative typing isn't a reasonable and fair tactic. We have legacy JavaScript dependencies and most of them worry me. I don't stay up at night worrying about the domain and range of TypeScript ones even if their testing is weak. There's a reason for that.cs TypeScript is loose where it should be loose and yet strongly encourages flexible but very clear typing that provides significant resistance to broken contracts and misunderstood semantics. I won't hire a web or Node developer who has a problem with it today because understanding the value of gradual and structural typing is, I strongly think, evidence of baseline competence. "I write worse code, slower" is defensiveness masked as "a taste thing." We've improved the state of the art and it's better here.
- orange8 7y agoIf you write JavaScript with a c# frame of mind, of-course you'll find it akward and hard to test. TypeScript is basically JavaScript written in a c# frame of mind, and there is nothing wrong with that. If it helps some people be more productive, then more power to them. but don't fool yourself that TypeScript is the best way to do JavaScript. If you're finding writing maintainable apps in plain JavaScript hard then you are simply doing it wrong. You can learn how to do it right (hint: its a functional, not a class based language) and add one more tool to your box, or you could stick with Typescript and your comfort zone. I have worked with TypeScript, and I enjoyed it. It reminded me of ActionScript 3, a language I really enjoyed that's more or less dead now. And I also enjoy plain JS, and its just more powerful and expressive. > I won't hire a web or Node developer who has a problem with it today because understanding the value of gradual and structural typing is, I strongly think, evidence of baseline competence. If you think the benefits of "gradual and structural typing" cannot be achieved in JavaScript, you clearly don't understand the language. And that's ok. It is also ok hire people you are comfortable with, rather than those who challenge and disrupt your way. And I wouldnt want to work somewhere where the devs are too rigid or tribal about tools. Am more interested in what I'm building, rather than the tools used.
- eropple 7y agoI don't have a good way to describe this post as anything but not-even-wrong. "Hint, it's a functional language"--types are orthogonal to whatever functional-versus-OO dichotomy you've invented in your head. Gradual and structural typing are components of type systems of either static or inferential basis and JavaScript is neither--so, definitionally, you can't achieve them in JavaScript. And given that TypeScript is a strict superset of JavaScript, it's absolutely bonkers to claim that JavaScript is "more powerful and expressive". Should one need to go outside those gradual type strictures, `any` is right there. I knew JavaScript cold well before I was using TypeScript and I've shipped both mobile and web applications using JavaScript, as well as writing a solid amount of high-performance backend systems. And I ended up writing an eye-gouging number of tests that go away with TypeScript. It is literally, not figuratively, a way to dismiss entire classes of bugs. I may not understand JavaScript, but I'm not the one making factually inaccurate assertions about stuff up in here and that makes me really wonder how solid your conclusions can possibly be. But as a gentle observation: people don't usually go on about "tribal" developers when the facts are on their side.
- Too 7y agoJava is verbose because it is Java, not because it is statically typed. Let's look at some more modern and ergonomic language instead, like Typescript which is much more relevant to the OP. The typing there might add a few extra characters to your function definitions but you gain them back in terms of less need for documenting the argument types in comments. You hardly ever see typing inside of functions in Typescript so it hardly adds any verbosity.
- orange8 7y agoJava was used as an example of strongly typed taken to the extreme. Something YOU can relate to, as a TypeScript user. In terms of verbosity, the difference between Java and TypeScript is like the difference between TypeScript and JavaScript.
- Too 7y agoI do appreciate the comparison and have suffered enough Java in my life to fully understand it. But i have to tell you again, Java is not verbose because it has "taken strong typing to the extreme" (correlation vs causation), it's just a badly designed language. From the same familiy of languages look at C# and Kotlin for example, they are both much stronger than java (minus checked exceptions) but at the same time very less verbose. There are many other examples of this, C++21 is stronger and less verbose than C++98. Rust can also many times be less verbose than C++ or C and at the same time stronger. In many cases typescript can also reduce verbosity because of more modern features and transpiling. For example early versions had foreach long before it was in ES and before Babel was as widespread as today. In fact you don't even need to add type annotations at all to run typescript, you can let it try its best on plain javascript, in those places where it's not obvious from context, just add the extra :string.