4 ms·

Yup, that commenter did exactly what he told others not to do, bashed on something without checking if he's right. Typical bashism. Typescript is from a single

Yup, that commenter did exactly what he told others not to do, bashed on something without checking if he's right. Typical bashism. Typescript is from a single big vendor with all the tooling. React is a different story. By itself it's from a single big vendor, but all the tooling is tons of random packages and scripts...

jongjong 2y ago
The fact that you don't recognize how TypeScript adds a massive number of dependencies into your project is proof of how deeply entrenched the mindset of unnecessary complexity is. Let's not even dive into the question of how `tsc` relies external dependencies written by third-parties outside of Microsoft (it definitely does). Let's not even talk about how many people are working on TypeScript and how big of a target it is for foreign state actors. Let's not discuss how easy it would be to introduce vulnerabilities into `tsc` due to how well it can hide them inside its mangled JS output. An even bigger issue is that TypeScript forces you to add a ton of dependencies into your project. Once you add TypeScript to a project, you are essentially forced to use a bundler on the front end. Also, it forces you to add a lot of special add-ons for whatever front end framework you're using. You need special add-ons for testing, e.g. `ts-jest`, you need additional linting dependencies and you need to import a large amounts of external type definitions. You now need 2 config files instead of 1 (tsconfig.json + package.json)... 2 engines instead of 1 (tsc + node). The code you write is no longer the same as the code that's running in production; you're running a transpiled version with incorrect line numbers... Now you may need a special library to manage client-side errors with source mapping. E.g. you may need to install the `source-map-support` module or other or you might rely on third party services to help figure out the source of production errors. Your trusty older version of `mocha` now may not show the correct line numbers when tests fail; also `mocha` is now too slow for you since TypeScript takes so long to build... So you end up using the far bulkier `Jest` instead (and all of its dependencies). Most devs these days don't even realize that it's possible (in fact, easier) to build fast front ends without a bundler. Browsers can now pre-load scripts easily and it's way more flexible than bundling. With native Web Components, you don't even need a framework these days, you can achieve similar results as reactivity using the `attributeChangedCallback` inside custom Web Components. Many people have been successful with this approach in production environments; it's far more lightweight and less error-prone than React development. It also makes it feasible to share components between different physical web pages and services since you don't need to load the entire React framework to use those components. You can follow DHH (founder of Ruby on Rails) if you need proof that you don't need a bundler.

jongjong 2y ago

The fact that you don't recognize how TypeScript adds a massive number of dependencies into your project is proof of how deeply entrenched the mindset of unnecessary complexity is. Let's not even dive into the question of how `tsc` relies external dependencies written by third-parties outside of Microsoft (it definitely does). Let's not even talk about how many people are working on TypeScript and how big of a target it is for foreign state actors. Let's not discuss how easy it would be to introduce vulnerabilities into `tsc` due to how well it can hide them inside its mangled JS output. An even bigger issue is that TypeScript forces you to add a ton of dependencies into your project. Once you add TypeScript to a project, you are essentially forced to use a bundler on the front end. Also, it forces you to add a lot of special add-ons for whatever front end framework you're using. You need special add-ons for testing, e.g. `ts-jest`, you need additional linting dependencies and you need to import a large amounts of external type definitions. You now need 2 config files instead of 1 (tsconfig.json + package.json)... 2 engines instead of 1 (tsc + node). The code you write is no longer the same as the code that's running in production; you're running a transpiled version with incorrect line numbers... Now you may need a special library to manage client-side errors with source mapping. E.g. you may need to install the `source-map-support` module or other or you might rely on third party services to help figure out the source of production errors. Your trusty older version of `mocha` now may not show the correct line numbers when tests fail; also `mocha` is now too slow for you since TypeScript takes so long to build... So you end up using the far bulkier `Jest` instead (and all of its dependencies). Most devs these days don't even realize that it's possible (in fact, easier) to build fast front ends without a bundler. Browsers can now pre-load scripts easily and it's way more flexible than bundling. With native Web Components, you don't even need a framework these days, you can achieve similar results as reactivity using the `attributeChangedCallback` inside custom Web Components. Many people have been successful with this approach in production environments; it's far more lightweight and less error-prone than React development. It also makes it feasible to share components between different physical web pages and services since you don't need to load the entire React framework to use those components. You can follow DHH (founder of Ruby on Rails) if you need proof that you don't need a bundler.