3 ms·

You choose the tool chain to fit the anticipated team. If that team is just you, then who cares? Pick the easiest thing for you. But if you’re an expert in the

You choose the tool chain to fit the anticipated team. If that team is just you, then who cares? Pick the easiest thing for you. But if you’re an expert in the tool chain and you anticipate new people hopping on, then the on-boarding process should definitely be one of your considerations. The argument for simpler tool chains for simpler projects is that the time it takes to on-board should not outweigh the time saved by the toolchain’s amenities. So the argument for TypeScript despite its complexities is that you believe its approach to type decorations on top of JS strikes the right balance for ease of on-boarding (IMO fairly straightforward) and supporting code maintainability (IMO a big improvement in 99% of the cases) despite the extra complexity of lengthening the toolchain (IMO it has some counterintuitive parts but you can mostly just forget about it once you find a working setup.) I won’t use TypeScript if I’m whipping something up quickly, but if I anticipate open sourcing, adding unit tests and CI, etc., then TypeScript feels like a useful addition.

gavinray 6y ago
I used to make the same argument, about not using TS for prototyping, but the tooling is so good that at this point, I generally just change the file extension to ".ts" and write no manual types for the mistakes and type-hints + intellisense the compiler and language server provide.
markus_zhang 6y ago
Yeah exactly, and we can also pick the features we need in a language. E.g. C++ is super complex after C++/11, but we can still just pick a small subset to make it easier.
- MaxBarraclough 6y ago
  > we can still just pick a small subset Unless you have to work with legacy code or libraries.
  - munchbunny 6y ago
    Then some poor soul gets to wrap the old patterns into the new patterns! But seriously, if modern C++ has one thing going for it, it has a great backwards compatibility and forward refactoring story. I'm not a huge fan of the "evolved" syntax, and I rarely use C++ anymore, but I like modern C++ substantially more than C++03, which was where I first cut my teeth as a programmer.
    - ruke 6y ago
      C++ is approaching Javascript and other modern languages with Moduless!!
    - MaxBarraclough 6y ago
      > Then some poor soul gets to wrap the old patterns into the new patterns! This isn't always an option. Google's C++ guidelines generally forbid using exceptions, but concede that you might have to if you're dealing with existing code, particularly on Windows. https://google.github.io/styleguide/cppguide.html#Windows_Code https://google.github.io/styleguide/cppguide.html#Windows_Co...

gavinray 6y ago

I used to make the same argument, about not using TS for prototyping, but the tooling is so good that at this point, I generally just change the file extension to ".ts" and write no manual types for the mistakes and type-hints + intellisense the compiler and language server provide.

markus_zhang 6y ago

Yeah exactly, and we can also pick the features we need in a language. E.g. C++ is super complex after C++/11, but we can still just pick a small subset to make it easier.

MaxBarraclough 6y ago
> we can still just pick a small subset Unless you have to work with legacy code or libraries.
- munchbunny 6y ago
  Then some poor soul gets to wrap the old patterns into the new patterns! But seriously, if modern C++ has one thing going for it, it has a great backwards compatibility and forward refactoring story. I'm not a huge fan of the "evolved" syntax, and I rarely use C++ anymore, but I like modern C++ substantially more than C++03, which was where I first cut my teeth as a programmer.
  - ruke 6y ago
    C++ is approaching Javascript and other modern languages with Moduless!!
  - MaxBarraclough 6y ago
    > Then some poor soul gets to wrap the old patterns into the new patterns! This isn't always an option. Google's C++ guidelines generally forbid using exceptions, but concede that you might have to if you're dealing with existing code, particularly on Windows. https://google.github.io/styleguide/cppguide.html#Windows_Code https://google.github.io/styleguide/cppguide.html#Windows_Co...