ghost
commented
2 years ago The API is already fully typesafe and if your editor has IDE support it has full on-hover documentation + intellisense + type errors because I made a jsconfig and annotated my own functions with jsdoc types (using typescript notation).
Frontend is another story... it's bundled the old school way right now. Due to using global variables there is no intellisense or on-hover type documentation. In order to get to a typesafe state on the frontend we'd have to move away from eleventy (the vanilla JS static site generator I picked) to a static site generator that uses a bundler like webpack so we can move away from global variables and use modules instead which provide in-editor intellisense. TS support is optional but preferred (you can JSDoc your way to type safety but it's not as ergonomic as just using TypeScript and you don't have all features)
Transitioning would take significant work
dustinvtran
Seems like a strictly superior version of Javascript due to its strong type checking. I'm a huge fan of types as it's one of the best avenues for self-documenting code. I find this particularly helpful for JS because JS has an annoying tendency to use struct inputs like
f(prop). Not only do you not know the types of your input, you don't even know what the inputs are! (all the attributes inside prop)I haven't researched typescript enough to know what the drawbacks are though. For example, is it incompatible with parts of the node js ecosystem? Certain tooling that's common but not usable within typescript?