Was performance the primary reason to choose JS vs. TypeScript? #102
-
I was curious why JavaScript, instead of TypeScript, was chosen as the language for implementation. As the project grows and will scale to more developers, will not having type-safety through TypeScript become an issue? I assume JS was chosen for startup performance reasons? Or was there something else about TypeScript in Deno that was not a good idea? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
I have been asked about TypeScript a lot of times! The reason is just a matter of taste. I'm not a fan of TypeScript because it's too verbose and harder to debug. I know the benefits of working with types (I'd love that javascript had native support for that) but to me, typescript is just another layer that needs to be compiled and maintained to make it work. I remember when Deno developers decided to move all internal TS code to JS: denoland/deno#6793 Anyway, I know that a Deno project not written in Typescript is weird to the community, and I have planned to implement Typescript, so other developers can extend Lume with other plugings easily. The version v1.0.0 will be 100% Typescript. |
Beta Was this translation helpful? Give feedback.
I have been asked about TypeScript a lot of times! The reason is just a matter of taste. I'm not a fan of TypeScript because it's too verbose and harder to debug. I know the benefits of working with types (I'd love that javascript had native support for that) but to me, typescript is just another layer that needs to be compiled and maintained to make it work. I remember when Deno developers decided to move all internal TS code to JS: denoland/deno#6793
Anyway, I know that a Deno project not written in Typescript is weird to the community, and I have planned to implement Typescript, so other developers can extend Lume with other plugings easily. The version v1.0.0 will be 100% Typescript.