4 ms·

TypeScript is a JavaScript best practice at this point. It's a type safety net on top of dynamic types, so you get the best of both worlds. TypeScript has a fl

TypeScript is a JavaScript best practice at this point. It's a type safety net on top of dynamic types, so you get the best of both worlds. TypeScript has a flag that prohibits switch fallthrough, for instance, though that's an easy one to set up a linter to catch. One reason I prefer NativeScript to React Native; they are embracing TypeScript and Angular vs. React. I find Angular 2 to be more flexible, but that I freely admit is a preference.

qwertyuiop924 10y ago
TS over JS isn't best practice yet: Some of us like dynamic typing.
- kuschku 10y ago
  For what purpose is dynamic typing ever useful except "it’s faster to develop"? With a proper type system (see: Haskell, Scala) and parametrized types, you can do everything that’s reasonable in a dynamically typed language, too.
  - evgen 10y ago
    You can do them, as you noted, at a much slower pace. Type systems catch one class of bugs, and if in your experience these are not the bugs you worry about or the bugs that cause you the most pain then slowing down development is a high cost to pay.
    - winter_blue 10y ago
      It goes beyond just catching bugs. Large code bases written in statically typed languages are easier to understand. I've worked on large production codebases in the past, for servers written in both Java (at company [a]), and JavaScript with Node.js (at company [b]). The Java codebase was much easier to read, understand, navigate around, and debug. If a function took an argument "SomeClass foo" I could look up "SomeClass" and know exactly what it was. In the Node codebase, if have argument "foo", you're lost with no easy way to figure out exactly what this "foo" is. You would have to run the code, set a breakpoint, and inspect "foo". In addition, JavaScript encouraged a lot of bad coding practices that almost made me want to cry. In the Java server, we used a JSON library where you would annotate a class, and the library would construct an object for that class. This guaranteed the JSON was well-formed, among other things. In the Node.js codebase, people would pull something out of Mongo, chuck it in a variable "data", and then do "data.foo.bar[1].qux". (Yes, the "[1]" is real.) It was terrible. The company that used Node.js had far less reliable code overall, and their services (written in JavaScript) would crash frequently, most commonly due to type errors. And this is just a tip of the iceberg. There were so many problems that attributable to the choice of JavaScript as the language for a large, complex back-end system, and the failure to use any tool for type checking (like Flow), in addition to bad coding practices. [a] Amplify Education, Inc. https://www.amplify.com/ https://www.amplify.com/ [b] Lifion, a division of ADP. http://www.lifion.com/ http://www.lifion.com/
      - qwertyuiop924 10y ago
        That's an example of bad design. You can do that in Java as well, just in different ways. There are trade-offs that you make, and it means that various languages and type systems make different kinds of screw-ups easier.
    - overgard 10y ago
      Honestly I think the bug catching aspect of static typing is its least useful property. (Useful, but not like, amazing -- you can write assertions on a type in a dynamic language). I think the good thing about static typing is it makes a code-base much easier to navigate and much more self documenting. I spend most my time navigating other peoples code. I know you can get most of the reliability of static typing with extensive test suites etc., but that doesn't help my IDE and it doesn't let me look up parameters at a glance. I used to be firmly in the dynamic camp, but having to maintain other people's javascript definitely made me do a 180.
      - eyelidlessness 10y ago
        > you can write assertions on a type in a dynamic language You can, but you can't get any guarantee that said assertion will never fail.
      - Bahamut 10y ago
        Writing assertions has a runtime cost that isn't present when using something like TypeScript. Granted, that benefit is probably minor, but it is a benefit in TypeScript's favor.
        mbrock 10y ago
        It does have a compile time cost and that's not negligible... although with all the heavy transpilation going on these days, a bit of type checking might drown that out. At a previous job we tried TypeScript but it took around 20 seconds to build our front end. Since then I hear speed has improved.
    - saosebastiao 10y ago
      Maybe the initial write is faster, but any refactoring strongly favors static type systems in the speed department. Even an extremely well tested dynamic code base will have a significant disadvantage for refactoring because the tools can't catch all the small details and you'll have to iterate over and over again until tests pass.
  - wvenable 10y ago
    Unless you are doing Java, I would even take issue with the argument that dynamic typing is faster to develop. It's taken as obvious fact but I don't think we should just take that as face value. Getting as-you-type feedback, intellisense, and simple documentation (methods, parameters, types) is hugely productive. As well as the ability to break things and know you've caught all the breaks. I would say that a very fast edit-run cycle is an advantage of dynamic languages -- especially if you can edit code live without restarting the application -- but that's not always the norm.
    - SomeCallMeTim 10y ago
      I agree, and I consider TypeScript to be twice as fast to develop in as plain JavaScript just because you don't need to: * Look up member names * Look up object hierarchy structures * Run code (or tests) to verify that you've done the above correctly When the compiler knows the types, it can bring your code up to 90% correct. Half the time you don't even need to specify types: TypeScript can guess them from context. You need to specify parameter types and return types; if you're declaring a variable without initializing it, or assigning it an empty array or object, you need to specify its type. Other than that you generally get type inference from TypeScript (at least as of 2.0).
- SomeCallMeTim 10y ago
  TypeScript gives you the benefits of dynamic typing without the drawbacks of a C++/Java restrictive-typing system. It just makes the dynamic typing safer. It absolutely should be considered a best practice; anything that can accelerate development by 100% or more should be.
kowdermeister 10y ago
If you are not building large applications then TS is counter productive. Just consider the extra compilation step, the dependencies and obfuscated source code. While it can be tremendous help, calling it a best practice misses the point.
- SomeCallMeTim 10y ago
  The code output is really clean; I wouldn't call it obfuscated. Especially when source mapping works just about everywhere. And having ES2015 features (+async/await) is very useful: var should be deprecated, arrow functions should be standard, etc. Tiny projects? Sure, do whatever you want. But I've started switching even my one-file, 2-3 screens of code Node servers over to TypeScript, and it's not only useful, it accelerates development by 100% simply because you don't need to run your code to know that you've got the types correct. I stand by "best practice."

qwertyuiop924 10y ago

TS over JS isn't best practice yet: Some of us like dynamic typing.

kuschku 10y ago
For what purpose is dynamic typing ever useful except "it’s faster to develop"? With a proper type system (see: Haskell, Scala) and parametrized types, you can do everything that’s reasonable in a dynamically typed language, too.
- evgen 10y ago
  You can do them, as you noted, at a much slower pace. Type systems catch one class of bugs, and if in your experience these are not the bugs you worry about or the bugs that cause you the most pain then slowing down development is a high cost to pay.
  - winter_blue 10y ago
    It goes beyond just catching bugs. Large code bases written in statically typed languages are easier to understand. I've worked on large production codebases in the past, for servers written in both Java (at company [a]), and JavaScript with Node.js (at company [b]). The Java codebase was much easier to read, understand, navigate around, and debug. If a function took an argument "SomeClass foo" I could look up "SomeClass" and know exactly what it was. In the Node codebase, if have argument "foo", you're lost with no easy way to figure out exactly what this "foo" is. You would have to run the code, set a breakpoint, and inspect "foo". In addition, JavaScript encouraged a lot of bad coding practices that almost made me want to cry. In the Java server, we used a JSON library where you would annotate a class, and the library would construct an object for that class. This guaranteed the JSON was well-formed, among other things. In the Node.js codebase, people would pull something out of Mongo, chuck it in a variable "data", and then do "data.foo.bar[1].qux". (Yes, the "[1]" is real.) It was terrible. The company that used Node.js had far less reliable code overall, and their services (written in JavaScript) would crash frequently, most commonly due to type errors. And this is just a tip of the iceberg. There were so many problems that attributable to the choice of JavaScript as the language for a large, complex back-end system, and the failure to use any tool for type checking (like Flow), in addition to bad coding practices. [a] Amplify Education, Inc. https://www.amplify.com/ https://www.amplify.com/ [b] Lifion, a division of ADP. http://www.lifion.com/ http://www.lifion.com/
    - qwertyuiop924 10y ago
      That's an example of bad design. You can do that in Java as well, just in different ways. There are trade-offs that you make, and it means that various languages and type systems make different kinds of screw-ups easier.
  - overgard 10y ago
    Honestly I think the bug catching aspect of static typing is its least useful property. (Useful, but not like, amazing -- you can write assertions on a type in a dynamic language). I think the good thing about static typing is it makes a code-base much easier to navigate and much more self documenting. I spend most my time navigating other peoples code. I know you can get most of the reliability of static typing with extensive test suites etc., but that doesn't help my IDE and it doesn't let me look up parameters at a glance. I used to be firmly in the dynamic camp, but having to maintain other people's javascript definitely made me do a 180.
    - eyelidlessness 10y ago
      > you can write assertions on a type in a dynamic language You can, but you can't get any guarantee that said assertion will never fail.
    - Bahamut 10y ago
      Writing assertions has a runtime cost that isn't present when using something like TypeScript. Granted, that benefit is probably minor, but it is a benefit in TypeScript's favor.
      - mbrock 10y ago
        It does have a compile time cost and that's not negligible... although with all the heavy transpilation going on these days, a bit of type checking might drown that out. At a previous job we tried TypeScript but it took around 20 seconds to build our front end. Since then I hear speed has improved.
  - saosebastiao 10y ago
    Maybe the initial write is faster, but any refactoring strongly favors static type systems in the speed department. Even an extremely well tested dynamic code base will have a significant disadvantage for refactoring because the tools can't catch all the small details and you'll have to iterate over and over again until tests pass.
- wvenable 10y ago
  Unless you are doing Java, I would even take issue with the argument that dynamic typing is faster to develop. It's taken as obvious fact but I don't think we should just take that as face value. Getting as-you-type feedback, intellisense, and simple documentation (methods, parameters, types) is hugely productive. As well as the ability to break things and know you've caught all the breaks. I would say that a very fast edit-run cycle is an advantage of dynamic languages -- especially if you can edit code live without restarting the application -- but that's not always the norm.
  - SomeCallMeTim 10y ago
    I agree, and I consider TypeScript to be twice as fast to develop in as plain JavaScript just because you don't need to: * Look up member names * Look up object hierarchy structures * Run code (or tests) to verify that you've done the above correctly When the compiler knows the types, it can bring your code up to 90% correct. Half the time you don't even need to specify types: TypeScript can guess them from context. You need to specify parameter types and return types; if you're declaring a variable without initializing it, or assigning it an empty array or object, you need to specify its type. Other than that you generally get type inference from TypeScript (at least as of 2.0).
SomeCallMeTim 10y ago
TypeScript gives you the benefits of dynamic typing without the drawbacks of a C++/Java restrictive-typing system. It just makes the dynamic typing safer. It absolutely should be considered a best practice; anything that can accelerate development by 100% or more should be.

kowdermeister 10y ago

If you are not building large applications then TS is counter productive. Just consider the extra compilation step, the dependencies and obfuscated source code. While it can be tremendous help, calling it a best practice misses the point.

SomeCallMeTim 10y ago
The code output is really clean; I wouldn't call it obfuscated. Especially when source mapping works just about everywhere. And having ES2015 features (+async/await) is very useful: var should be deprecated, arrow functions should be standard, etc. Tiny projects? Sure, do whatever you want. But I've started switching even my one-file, 2-3 screens of code Node servers over to TypeScript, and it's not only useful, it accelerates development by 100% simply because you don't need to run your code to know that you've got the types correct. I stand by "best practice."