3 ms·
They've historically done a lot of things on their own for JS. So perhaps VS Code + TS language server isn't quite on par with their JS tooling (which works a l
by ygra 5y ago
They've historically done a lot of things on their own for JS. So perhaps VS Code + TS language server isn't quite on par with their JS tooling (which works a lot better with TypeScript type definitions, though, so perhaps it's just mostly the same as well).
However, what I personally hated was that there's so many squiggly underlined things ... in red, yellow, green and what other colors, each of which (regardless of color) could be either ignored or an actual error. Granted, that's how easy it is to properly check JS code for whether it does something sensible, but I didn't really find it helpful, especially because issue categorization and accuracy was so random.
- jatone 5y ago> Granted, that's how easy it is to properly check JS code for whether it does something sensible > especially because issue categorization and accuracy was so random Stockholm syndrome is strong with this one. =) the reason you didn't find the IDE suggestions helpful is exactly because of how difficult it is to reason about dynamic language code. the tooling is basically just guessing and expecting you to deal with the noise on the off chance it found something.
- ygra 5y agoI've ended up deciding for myself to never write JS and instead using TypeScript. So far it's working well. I just couldn't really see all that random guessing by the IDE as an advantage. If the only way to figure out whether the code is broken is to run it, then it's pointless to guess potential problems on every single expression because dealing with those takes more time than just testing the code – or results in the developer completely ignoring all diagnostics.