3 ms·

I think the author would agree. They are bemoaning Typescript which is everything but lightweight and the build chain. JS for me was a very nice change from th

by iSnow 6y ago

I think the author would agree. They are bemoaning Typescript which is everything but lightweight and the build chain. JS for me was a very nice change from the heavyweight OOP languages but now what the usual stack implies is just as bloated and obtuse.

askonomm 6y ago
I do agree indeed! It has its quirks, but all-in-all easy to use and get stuff done. Not to mention no need to set-up a compiler or anything. It just works.
citrons 6y ago
Yeah the setup-project boilerplaye stuff is a mess. Luckily for backend it's super easy to set up typescript as the default are good enough for weekend projects/prototypes: ``` mkdir my-project cd my-project npm init -f npm i -D typescript ts-node @types/node npx tsc init touch index.ts npx ts-node index.ts ```
JoeNr76 6y ago
This was my main reason to switch to mainly front-end: to get away from clunky, badly written C# and Java back-end programming. 2/3 of a code file are just the coder wrangling the OOP typesystem instead of just coding the functionality that is needed. I do like Typescript if you just use it minimally: you can type (I prefer interfaces usually) argument types and rely on the compiler to infer types. But then the OOP fundamentalists got their hands on it and now they want strict type checking and believe that it makes their code bulletproof https://indepth.dev/posts/1402/bulletproof-angular https://indepth.dev/posts/1402/bulletproof-angular
- wizzwizz4 6y ago
  Strict type checking does make your code bulletproof. Unfortunately, TypeScript doesn't provide anything close to that. It's easier to mask errors with TypeScript than auto-detect them. Its strict typing should be considered hints for the programmer.
  - JoeNr76 6y ago
    Real strict type checking (as in, eg, Haskell ) does indeed make your code resistant to a certain type of bug. But the kind of type checking Typescript gives you is mostly useful as autocomplete. (and, if I'm not mistaken, at run time, you can still add or remove properties from an object and re-introduce bugs. Which can happen with 3rd party libraries, for example.)
    - wizzwizz4 6y ago
      At runtime, you can pass primitives to a function that expects a very specific DOM object (say), and it'll just plough on ahead like JavaScript does, until you get an exception that nothing catches because FooFunction doesn't raise any exceptions, and everything breaks. Oh, and did I mention that virtually every browser API these days is potentially optional, with the undefined primitive replacing bits and pieces of them at seemingly random, depending on browser version and configuration, and the presence or absence of certain extensions…? I like the idea of TypeScript, I really do, but don't even try to use it for FFI (where “foreign” is anything outside your TypeScript module).

by iSnow 6y ago

askonomm 6y ago

I do agree indeed! It has its quirks, but all-in-all easy to use and get stuff done. Not to mention no need to set-up a compiler or anything. It just works.

citrons 6y ago

Yeah the setup-project boilerplaye stuff is a mess. Luckily for backend it's super easy to set up typescript as the default are good enough for weekend projects/prototypes: ``` mkdir my-project cd my-project npm init -f npm i -D typescript ts-node @types/node npx tsc init touch index.ts npx ts-node index.ts ```

JoeNr76 6y ago

This was my main reason to switch to mainly front-end: to get away from clunky, badly written C# and Java back-end programming. 2/3 of a code file are just the coder wrangling the OOP typesystem instead of just coding the functionality that is needed. I do like Typescript if you just use it minimally: you can type (I prefer interfaces usually) argument types and rely on the compiler to infer types. But then the OOP fundamentalists got their hands on it and now they want strict type checking and believe that it makes their code bulletproof https://indepth.dev/posts/1402/bulletproof-angular https://indepth.dev/posts/1402/bulletproof-angular

wizzwizz4 6y ago
Strict type checking does make your code bulletproof. Unfortunately, TypeScript doesn't provide anything close to that. It's easier to mask errors with TypeScript than auto-detect them. Its strict typing should be considered hints for the programmer.
- JoeNr76 6y ago
  Real strict type checking (as in, eg, Haskell ) does indeed make your code resistant to a certain type of bug. But the kind of type checking Typescript gives you is mostly useful as autocomplete. (and, if I'm not mistaken, at run time, you can still add or remove properties from an object and re-introduce bugs. Which can happen with 3rd party libraries, for example.)
  - wizzwizz4 6y ago
    At runtime, you can pass primitives to a function that expects a very specific DOM object (say), and it'll just plough on ahead like JavaScript does, until you get an exception that nothing catches because FooFunction doesn't raise any exceptions, and everything breaks. Oh, and did I mention that virtually every browser API these days is potentially optional, with the undefined primitive replacing bits and pieces of them at seemingly random, depending on browser version and configuration, and the presence or absence of certain extensions…? I like the idea of TypeScript, I really do, but don't even try to use it for FFI (where “foreign” is anything outside your TypeScript module).