4 ms·

I've been saying for years, over and over, that we need to focus on simple architecture and improve our coding standards but I keep getting ignored. People keep

I've been saying for years, over and over, that we need to focus on simple architecture and improve our coding standards but I keep getting ignored. People keep making software and tools more complex... "Just use TypeScript" they say, "Just use React, with Typescript" then they end up with literally thousands of unnecessary dependencies. The bad guys are laughing at our collective ignorance and naivety. Now probably the whole industry is compromised. Maybe our entire political system is compromised because of this. People just had to look for projects with minimal code and dependencies. Precisely the opposite of what they did. These clean projects were starved of attention and opportunities and the overengineered projects were brought to the forefront. Now they are easy targets for bad actors. It's so easy to hide vulnerabilities amongst complexity... And we've chosen complexity.

phendrenad2 2y ago
I suspect that the bad actors aren't merely benefitting from this situation, they're probably actively encouraging it, in GitHub issue discussions, on Reddit, in the comment sections of YouTube videos, here on HN. Maybe I'm paranoid.
- jongjong 2y ago
  I think this is a reasonable assumption for most high exposure projects. There are state actors from all sides who want to inject backdoors into software and they all benefit from complexity. It could indicate that governments are more focused on offense than defense. It seems to be a logical consequence of our short term corporate and political mindset. Offense is the best defense, they say... Ok, but not at scale when your opponents also possess the same weapons as you do; then you both end up worse off.
wiseowise 2y ago
Typescript has zero dependencies.
- whatevaa 2y ago
  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.

phendrenad2 2y ago

I suspect that the bad actors aren't merely benefitting from this situation, they're probably actively encouraging it, in GitHub issue discussions, on Reddit, in the comment sections of YouTube videos, here on HN. Maybe I'm paranoid.

jongjong 2y ago
I think this is a reasonable assumption for most high exposure projects. There are state actors from all sides who want to inject backdoors into software and they all benefit from complexity. It could indicate that governments are more focused on offense than defense. It seems to be a logical consequence of our short term corporate and political mindset. Offense is the best defense, they say... Ok, but not at scale when your opponents also possess the same weapons as you do; then you both end up worse off.

wiseowise 2y ago

Typescript has zero dependencies.

whatevaa 2y ago
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.