3 ms·

I'm also in the not-liking typescript camp. I was an early adopter (I think my first version was 1.7 or 1.8) and it put me off forever. What increased my produc

I'm also in the not-liking typescript camp. I was an early adopter (I think my first version was 1.7 or 1.8) and it put me off forever. What increased my productivity the most was not languages, linters, build tools, compilers, transpilers, etc... it was a good IDE. Now I just write plain Javascript with JSdoc and I don't need to update my toolchain every week.

eyelidlessness 4y ago
I maintain several JS+JSDoc projects for work, and several TS personal projects. You can certainly get a very similar IDE experience with plain JSDoc, but the tradeoffs are pretty severe. Certain aspects of the type system have no JSDoc equivalent (assigning a type to a class definition), or worse have conflicting equivalents (eg enum, which I know everyone hates in TS but the JSDoc version is worse), or require cramming TypeScript syntax onto a single line in (eg conditional types). Most plain JS projects use some build tooling even without compiling TS, my work projects are no exception. When I started the job, the build tools (Rollup and Terser) worked just fine and had been in place for years. A short while later I made the case to switch to ESBuild to improve iteration speed, which took a couple hours maybe? It’s been almost totally untouched since. And if I had more time, I’d be able to gradually convert the code to TS without any additional tooling effort. I get that tooling pain in the JS/TS ecosystem is basically a running joke at this point, but no one is forcing you or anyone else to update anything. Plain old tsc still works if you want to keep it simple (and it’s what I recommend to anyone who wants to try out TS and feels confused or intimidated by the whole Tooling Thing). To each their own of course, but living on both sides of the fence… the JSDoc-types side isn’t nearly so green as it can sometimes sound. Here’s hoping the types-as-comments proposal keeps gaining traction. I’ll still use a build tool to strip types out for prod, but I think the no-tooling/JSDoc-types crowd would benefit a lot from a syntax much closer to TypeScript too.

eyelidlessness 4y ago

I maintain several JS+JSDoc projects for work, and several TS personal projects. You can certainly get a very similar IDE experience with plain JSDoc, but the tradeoffs are pretty severe. Certain aspects of the type system have no JSDoc equivalent (assigning a type to a class definition), or worse have conflicting equivalents (eg enum, which I know everyone hates in TS but the JSDoc version is worse), or require cramming TypeScript syntax onto a single line in (eg conditional types). Most plain JS projects use some build tooling even without compiling TS, my work projects are no exception. When I started the job, the build tools (Rollup and Terser) worked just fine and had been in place for years. A short while later I made the case to switch to ESBuild to improve iteration speed, which took a couple hours maybe? It’s been almost totally untouched since. And if I had more time, I’d be able to gradually convert the code to TS without any additional tooling effort. I get that tooling pain in the JS/TS ecosystem is basically a running joke at this point, but no one is forcing you or anyone else to update anything. Plain old tsc still works if you want to keep it simple (and it’s what I recommend to anyone who wants to try out TS and feels confused or intimidated by the whole Tooling Thing). To each their own of course, but living on both sides of the fence… the JSDoc-types side isn’t nearly so green as it can sometimes sound. Here’s hoping the types-as-comments proposal keeps gaining traction. I’ll still use a build tool to strip types out for prod, but I think the no-tooling/JSDoc-types crowd would benefit a lot from a syntax much closer to TypeScript too.