aws / aws-lambda-nodejs-runtime-interface-client

Apache License 2.0
180 stars 56 forks source link

Bet on javascript? #39

Closed jimmywarting closed 1 year ago

jimmywarting commented 2 years ago

This is an unusual request, but how would you consider ditching typescript in favor of vanilla javascript without the need of transpiling?

I don't think there is a reason real benefit to use TypeScript, JSDoc works just as well with typing support. My personal experiences working with TypeScript and ESM-only in some projects is a total nightmare with the extensions .ts, .mts, .cts, .mjs, .cjs and no extension at all. Remote path resolver is a total mess when it comes to TypeScript when it dose not have direct access to the filesystem.

Deno for instance requires explicit path with extension to resolve the path, TypeScript in a NodeJS environment don't support .ts extension in relative imports. They have always relied on striping away TypeScript syntax and expect extension-less path to work in their favor. But this was their downfall. To make a ESM project in NodeJS with TypeScript you basically have to add .js to the end even doe there isn't any file with that .js extension. It's just a total mess at the moment. and doing so you also break Deno's remote path resolver.

TypeScript have never worked in the Browser and it never will. Same for NodeJS All it is is a uncessary JIT compiler that adds a unnecessary extra step that makes it take longer to load

There is many things Typescript gets wrong, it have no understanding of Symbol.toPrimitive and classes that has things like toString() so most often it complains on things like fetch(new URL(...)) which is totally valid to do, but something TS complains about. I don't think typescript fits in a loosed typed language. It's like trying to put a square into a circle.

It's just lagging behind in many areas so it will always stand in the shadow of javascript, when something new comes out then typescript will take for ages to adapt to new changes. one such recent change is having signal in addEventListener

I have written a vanilla javascript project for both Deno and NodeJS with jsdoc and you can get typing/IDE support if you only use JSDoc instead

Typescript just adds complexity to a project, i have worked with it JS in 12 years, two of those years i have activlly used TS back and forth, i don't think it adds any real marginal benefit, you will spend lots of time just making some simple Javascript function compliant to the TypeScript rules. I don't think the bug density is lower just b/c you use TypeScript, you just spend more time upfront. it adds lots of wasteful compile time and unnecessary dependencies. Deno stop using Typescript for a couple of reasons which i can only agree upon.

One day we could have optional static typing, and when that day comes TS will be totally unnecessary and everyone would refactor back to vanilla javascript.


typescript can still be useful for one thing, and that is to generate d.ts files out of jsdoc's

I guess this is a long shot. but how do you feel about setting allowJs to true in tsconfig.js and start migrating the codebase to vanilla javascript without any unnecessary compiling?

krk commented 1 year ago

This is fixed in https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/pull/70.