3 ms·

The value of TypeScript is a function of the codebase size, size of team, and length of time for maintaining this codebase. If you're an individual, putting to

The value of TypeScript is a function of the codebase size, size of team, and length of time for maintaining this codebase. If you're an individual, putting together dinky little web sites that you don't need to maintain for years - the value of TypeScript over JavaScript isn't as pronounced. If you have a web application that counts hundreds of thousands of lines of code, maintained by team of developers over many years - JavaScript does not cut it ... at all.

cryptica 6y ago
This is incorrect. This is just repeating popular rhetoric. Well designed projects are broken up into manageable, individually testable modules... So codebase size is an anti-pattern to begin with. As for time, you think waiting 15 additional seconds each time you want to test something doesn't add up and waste time? What about having to type up all these extra type definitions? You could have spent that time writing more test cases.
- macspoofing 6y ago
  >Well designed projects are broken up into manageable, individually testable modules And JavaScript does not make it easy to do that. It also makes it very easy to do it incorrectly and in a way that is an unmaintainable mess. Every programming language can be used to write clean code if you try really hard, but not every programming language will have the syntax, semantics and conventions that will make it harder to do the wrong thing. If you do try modularize JavaScript, you're going to need a compilation chain to package it all together - so you're not getting away from that. >So codebase size is an anti-pattern to begin with. No it's not. What are you talking about? A large application will have a large code-base. You can't get away from that. >As for time, you think waiting 15 additional seconds each time you want to test something doesn't add up and waste time? Sure it adds up, but it's a tradeoff. If you're writing a dinky little web app for your grandma, maybe that trade-off isn't worth it. If your codebase numbers in hundreds of thousands of lines of code then you take the hit with compilation so that you can save time in other places. For example, tracking runtime bugs that a compiler would catch, is very expensive, and gets more expensive as the application grows. >What about having to type up all these extra type definitions? Heh. That's not a real issue. Programming isn't about speed typing and measuring 'words per minute'. You're not losing time if you need to write 'int i' vs 'var i'. Again, we're not talking about writing quick scripts or throwaway code. We're talking about code that may need to be maintained for years by many different people.
  - cryptica 6y ago
    >> If you do try modularize JavaScript, you're going to need a compilation chain to package it all together - so you're not getting away from that. That's not always the case on the front end (it's still possible to code on the front end without a bundler). And it's certainly not the case on the backend (I.e. Node.js). >> Sure it adds up, but it's a tradeoff. If you're writing a dinky little web app for your grandma, maybe that trade-off isn't worth it. This could not be further from my own experience having gone back and forth between JavaScript and TypeScript multiple times both professionally and as part of my open source work for over a decade. I've built highly complex scalable distributed pub/sub systems, P2P systems, blockchains and a decentralized exchange using plain JavaScript in record time with no bugs found for over a year.

cryptica 6y ago

This is incorrect. This is just repeating popular rhetoric. Well designed projects are broken up into manageable, individually testable modules... So codebase size is an anti-pattern to begin with. As for time, you think waiting 15 additional seconds each time you want to test something doesn't add up and waste time? What about having to type up all these extra type definitions? You could have spent that time writing more test cases.

macspoofing 6y ago
>Well designed projects are broken up into manageable, individually testable modules And JavaScript does not make it easy to do that. It also makes it very easy to do it incorrectly and in a way that is an unmaintainable mess. Every programming language can be used to write clean code if you try really hard, but not every programming language will have the syntax, semantics and conventions that will make it harder to do the wrong thing. If you do try modularize JavaScript, you're going to need a compilation chain to package it all together - so you're not getting away from that. >So codebase size is an anti-pattern to begin with. No it's not. What are you talking about? A large application will have a large code-base. You can't get away from that. >As for time, you think waiting 15 additional seconds each time you want to test something doesn't add up and waste time? Sure it adds up, but it's a tradeoff. If you're writing a dinky little web app for your grandma, maybe that trade-off isn't worth it. If your codebase numbers in hundreds of thousands of lines of code then you take the hit with compilation so that you can save time in other places. For example, tracking runtime bugs that a compiler would catch, is very expensive, and gets more expensive as the application grows. >What about having to type up all these extra type definitions? Heh. That's not a real issue. Programming isn't about speed typing and measuring 'words per minute'. You're not losing time if you need to write 'int i' vs 'var i'. Again, we're not talking about writing quick scripts or throwaway code. We're talking about code that may need to be maintained for years by many different people.
- cryptica 6y ago
  >> If you do try modularize JavaScript, you're going to need a compilation chain to package it all together - so you're not getting away from that. That's not always the case on the front end (it's still possible to code on the front end without a bundler). And it's certainly not the case on the backend (I.e. Node.js). >> Sure it adds up, but it's a tradeoff. If you're writing a dinky little web app for your grandma, maybe that trade-off isn't worth it. This could not be further from my own experience having gone back and forth between JavaScript and TypeScript multiple times both professionally and as part of my open source work for over a decade. I've built highly complex scalable distributed pub/sub systems, P2P systems, blockchains and a decentralized exchange using plain JavaScript in record time with no bugs found for over a year.