7 ms·

I would welcome this making its way into ECMAScript not because I like TypeScript, but because it's a drag to see TypeScript enthusiasts litter the JavaScript e

I would welcome this making its way into ECMAScript not because I like TypeScript, but because it's a drag to see TypeScript enthusiasts litter the JavaScript ecosystem with all of the piles of bolt-on TypeScript baggage. Forking projects just to add type definitions, or else mega repos like DefinitelyTyped madness; bringing all of the terrible complexity that we love to hate in Webpack/ESBuild/Rollup/etc back over to Node.js with server-side tsc; drive-by PRs to all my open source projects from inspired people trying to add types and me having to disappoint... I would gladly do without all of that. To me, I see the TypeScript tradeoff as coming with only marginal upside, in return for a large downside as described above. But, others passionately disagree and see a huge upside, and that's cool. In the end, I want us all to be happy, and I think this proposal would have hope getting us there. For this to be really spec'd and standardized would be a green light even for skeptics to invest in deeply learning and internalizing. To get to avoid yet another build-time compilation step would be bliss. To have us all back in on the same team would be glorious.

IshKebab 5y ago
You're wrong - the benefits of Typescript are huge, and the size of the hoops people are willing to jump through to get those benefits should indicate how big they are. I do agree it would be nice to simplify some of the tooling though.
ht85 5y ago
Do you write a lot of library code? I'm genuinely wondering in what kind of environment you would get "marginal upside" from having a good type system.
- riskable 5y ago
  I've been coding JavaScript for many, many years. I've never encountered a situation where the lack of typing bit me in the ass. Not even once! Having said that, it might be because when I'm writing JavaScript it's just me. Normally I'm the sole developer. So of course I know my own stuff! I'm not going to experience an error passing the wrong type to a function because I literally wrote all the functions myself. I even have enormous libraries of JS code that I use in my personal and work projects where I wrote everything. This developer is probably in the same sort of situation. Type errors are the kind of thing you run into when you're working with large codebases that were written by lots of different people. It's not the type of thing you experience with your own code. I've also written loads of Python and never experienced an error where the wrong type gets passed to a function (even working in a team). For years I couldn't even fathom how static typing would be a benefit other than maybe it can speed things up by giving a compiler/interpreter the ability to optimize things. Then at work--after nearly 20 years of Python--we finally had an issue where the wrong type was passed (float was inadvertently rounded because the function was made for integers and it wasn't obvious). It was caught before the code was sent to production (and it wouldn't have been a huge deal anyway) and I finally had a real-world situation where type annotations would've prevented an error. It's just not something that happens very often. It's the type of thing that creeps up on you for sure but it's not a common, every day occurrence. Type-related bugs are really super obscure. They're far, far rarer than type-obsessed developers make them out to be.
  - Turing_Machine 5y ago
    I've often speculated that strong typing only seems like a win to the kind of developer who makes a lot of type errors, and a waste of time to those who don't (which doesn't mean they don't make other errors, of course).
    - Aldo_MX 5y ago
      Or to the kind of developer that works in a big team for a big project.
    - markstos 5y ago
      Even developers who "don't make type errors" have to deal with bad and unexpected data, which may be in a different type. If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result. Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster. "Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types. My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript. Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"
    - rattlesnakedave 5y ago
      bringing in tooling to eliminate an entire class of potential errors sounds sounds like an easy decision to me.
      - Turing_Machine 5y ago
        Not if the errors are rare and the "tooling" slows down development.
        5y ago
Waterluvian 5y ago
I used to feel the same way about TypeScript until I really gave it a try one season. I feel like I was crippling myself for years, being an inferior developer wasting so much time with the things that TS guards against, documents, and autocompletes for. I support any formalization of TypeScript that further tidies up the "add-on" nature of it. But to be honest, it's really quite fine already.
- edgyquant 5y ago
  I work at a place that is full stack typescript with a legacy app that is Js/react (the kind of stuff I was writing in 2017-2018.) After using typescript and going back to fix issues on the legacy codebase I now understand why the industry adopted Ts
seniorsassycat 5y ago
Would you use type comments in your projects? Would you like pull requests adding them, or fixing them? What if the typescript checker and another checker have different semantics and you have fans fighting between `number` and `u8`?
keawade 5y ago
I disagree that TypeScript comes with only a marginal upside. In my experience TypeScript projects are much more approachable for contributors. For example, I once was debugging an issue in a JS framework and while I knew what was wrong and where I could fix it I didn’t have any idea what existing tools I had available in that context to fix it. Having type definitions would have made that work much simpler by increasing the accessibility of the code base. It’s experiences like this that have convinced me that if I’m writing code that any one will possibly read or need to modify later (including if it is just me) then I should be writing TypeScript instead of JavaScript. Or, more generally, that it should be typed.
- shadowgovt 5y ago
  You and OP are both right, because it really depends on what you're doing. At the scale I operate, it would be corporate suicide to try and write this code in straight JavaScript without type support. But for smaller teams, more focused teams, and teams that use a heavy testing discipline or enforced naming conventions that supplement the lack of static typing, it's not a problem.
- NoWizards 5y ago
  I couldn't disagree more with you... All i see when working with different levels of experienced contributors is param:any any[]. Even more when you want to interact directly with DOM instead of using an opinionated framework.
  - selfmodruntime 5y ago
    You‘re blaming the active misuse of a tool on the tool itself.
  - david422 5y ago
    This is either just code that is too complicated or devs that aren't doing a good job of type hinting. Everytime there is an any, it means that each developer reading or modifying this code has to find it out for themselves - every single time. Why not just type hint it correctly in the first place.
spion 5y ago
This isn't going to fix those issues. Those issues aren't due to tsc. They're due to an ecosystem which refuses to recognize the realities of compilation and add first class support for it. Its also due to an ecosystem willing to break compatibility (and not just backward compatibility but compatibility to other tools) at the drop of a hat. For example, the main reason I've seen why people began using bundlers for node recently is the fact that a lot of modules transitioned to pure ES6 without CommonJS support. In most projects, this means you have to use a bundler to be able to import those modules, or switch your entire codebase to ES6 (which is non-trivial due to changes in import path semantics). If it weren't for the above, you could just run `tsc` to get a `.js` file in `dist` for every `.ts.` file in `src` and run node on those.
- afavour 5y ago
  > They're due to an ecosystem which refuses to recoginze the realities of compilation and add first class support for it. IMO this is the correct path. Compilation should result in WebAssembly and it seems like the tooling is finally getting there.
  - dmitriid 5y ago
    > Compilation should result in WebAssembly It... It really shouldn't. Especially not if the target is the browser as the bridge between WebAssembly and the rest of the browser is still "just pass these arrays of integers around".
  - jeremyjh 5y ago
    I do not think that is a goal of either project; I’m not even aware of a POC JavaScript to WASM compiler. AssemblyScript couldn’t work without strong typing semantics and doesn’t support many typescript features.
- spion 5y ago
  Of course, using a bundler means you'll face several other unpleasant realities. Like - what about tests, how do they run - source maps support in node being 3rd party and unbearably slow for any medium sized project - edit: this has been fixed somewhat recently https://nodejs.medium.com/source-maps-in-node-js-482872b56116 - only the 3rd party bit, not the slowness bit https://github.com/nodejs/node/issues/41541 - also applicable when not bundling, albiet fewer reprcutions to turning off source maps - poor native (C++) modules support in bundlers - modules with really dynamic `require` statements being supported at varying levels by varying bundlers
afavour 5y ago
For what it’s worth I agree with you: after spending years battling with Babel and all that nonsense it’s been amazing to be able to just write ESM JS and have it run both on Node and in the browser. The real lightbulb moment for me was using JSDoc annotations with TypeScript types in JS files. It definitely isn’t as graceful as JS itself but it’s not that big of a deal, plus it encourages you to add comments. And any TypeScript editor will parse the code as if it’s TS, provide autocomplete, type checking etc etc as required.
simion314 5y ago
Just finished debugging one of those ugly issues where it works fine for the developer but for some other person things are broken. it was a piece of code that assigned an Number to a property that should have been an object(the dev confused the property name). Because the project is complex and there is a lot of network requests and stuff running in different order depending on the user internet the bug did not happened to everybody. You could work aroudn this using setters and doing runtime checks but I have a feeling people that don't like types also don't like getter and setter.
- markstos 5y ago
  Are you saying that if there had been type checking, this issue would have been much easier to detect and prevent?
  - jaywalk 5y ago
    How could it not be? With type checking, you wouldn't be able to set a variable to a number when it's supposed to be an object.
  - simion314 5y ago
    Yes a line like stuff.anAccountTypeField = obj.aNumberValue; Would cause an error in a typed language , something like incompatible type Number and type Account. Maybe you were confused by my commnet about the network requests and different order of running code, this caused the error not to happen most of the time so it never crashed on developer machine.
dlojudice 5y ago
> To me, I see the TypeScript tradeoff as coming with only marginal upside, in return for a large downside as described above. I've coded using static and dynamic types. C#, Java, Ruby, JS, etc. 20 something years doing it, mainly for business applications (opposed to system or embedded). My personal opinion is that types bring an elusive value of control and maintainability. Confronted with legacy / spaghetti code, developers with less experience will bring lint, code style, some layers and ... types, as a way to solve the problem of long term maintainability. But unfortunately it does not bring that much value. Actually it brings costs to readability and unnecessary abstraction (interfaces, generics, etc) aka "fighting the compiler". A better test suite can have exponential more value on maintainability than types. > Static Typing was the most requested language feature in the State of JS survey in both 2020 and 2021. [1] So when I see static types been the most requested feature I wonder how many of them know how to create a good test suit or a good architecture. If its behind this feature request is a different pain to be solved. [1] https://github.com/giltayar/proposal-types-as-comments/#community-usage-and-demand https://github.com/giltayar/proposal-types-as-comments/#comm...
- azangru 5y ago
  > A better test suite can have exponential more value on maintainability than types. A lot of ink has been spilled over this question. The conclusion is: no, tests do not and cannot replace types. Types, in themselves, provide a layer of tests that nobody, typically, would think of writing (what if a function is called with fewer arguments? what if it receives a different type of argument from what it was expecting?) and eliminate a whole class of superfluous tests that are checking for things that are better checked with types. The self-documenting property of types is remarkable. Jsdocs do not hold a candle to a typed codebase. Plus, refactoring. Even with tests I would be scared of large refactorings if I didn't have a type checker to also hold my hand. Of course, maybe I just don't know how to write code properly.
  - kemiller2002 5y ago
    I always say that Types are not there for the truly expert programmer. They are there for the rest of us. It's a lot easier to pick up code and understand it when you at least have an inkling as to what a variable or parameters needs to have to function. Can interfaces be confusing, and generics become difficult to read? Yeah of course, but that's not really the problem of static type system, that's a problem with the code. I've generally found if you're doing something where you're thinking "this is just getting the way", you probably need to rethink your approach. Clear is always better than clever.
kingdomcome50 5y ago
Found the guy who hasn't used Typescript beyond tinkering! I kid... mostly. But in all honesty I have found very few instances of developers who have worked significantly with both languages and have come to the conclusion that TS has a marginal upside (though maybe they will come out in defense here!).
- claytongulick 5y ago
  <raises hand> I've worked extensively with both. I find that ts normally brings a downside, actually. In one project I maintain, a solid 30% of the code is nothing but ts stuff. It makes maintaining the code base excruciating. Small changes between versions of ts or .d.ts files have caused hundreds of errors. A concrete example of this is the change in mongo driver that forced "new ObjectId()" instead of "ObjectId()" though functionally there was no difference. I see massive bizarre and difficult to grok type declarations that grow in excruciatingly byzantine complexity just to satisfy the compiler for non-trivial flexible function definitions. I see painful compilation times, a beefy laptop's CPU getting pegged and the fan whining while trying to do even minor updates. Try to do a build while on a video conference? I see two to three minute build times. I see a series of nonsense stories in sprints that are nothing more than activity over achievement. They don't drive product functionality, they are a bunch of make-work to satisfy the developer asthetic and the compiler. The nightmare of "compiled" NodeJS production support is a dystopian hellscape that I'm forced to endure every day because of NestJS and typescript. And nothing in that has done anything to increase code quality or reduce bugs from the crappy offshore team that wrote it. Clearly, I'm not a fan. That being said, I think type comments in jsdoc are a honking good idea. I use inline /* @type */ declarations and .d.ts files liberally. If we could add to jsdoc the ability to document types and purpose of arbitrary js objects inline, at definition time, instead of an external .d.ts file, I'd be a happy guy. An example of this would be sequelize schema defs, or mongoose schema defs, where I can have all my jsdoc code comments and type definitions in the same place as the code. All that being said, I like the idea of this proposal. Especially if it could solve the schema definition issue above. I think optional typing is a good idea to bake directly into the language. I thought AS3 did a great job of this. I even think it would be great to have an equivalent of "strict" that would enforce typing at the module level to enable straightforward AOT / wasm interop (I know it doesn't solve the GC issue). My beef is mostly with the extra compilation step and needless complexity of ts. If we had simple (no generics) opt-in typing that was natively supported by the engine, I think it would enhance the language overall, like type hints have done for python.
yboris 5y ago
You should try Vite - https://vitejs.dev/ https://vitejs.dev/ - start a TypeScript project in under a minute - no annoying Webpack configuration needed.
fifticon 5y ago
I abandoned my attempts to make larger projects in pure javascript. I happily write larger projects in typescript. Typescript makes javascript feasible, usable for me.

IshKebab 5y ago

You're wrong - the benefits of Typescript are huge, and the size of the hoops people are willing to jump through to get those benefits should indicate how big they are. I do agree it would be nice to simplify some of the tooling though.

ht85 5y ago

Do you write a lot of library code? I'm genuinely wondering in what kind of environment you would get "marginal upside" from having a good type system.

riskable 5y ago
I've been coding JavaScript for many, many years. I've never encountered a situation where the lack of typing bit me in the ass. Not even once! Having said that, it might be because when I'm writing JavaScript it's just me. Normally I'm the sole developer. So of course I know my own stuff! I'm not going to experience an error passing the wrong type to a function because I literally wrote all the functions myself. I even have enormous libraries of JS code that I use in my personal and work projects where I wrote everything. This developer is probably in the same sort of situation. Type errors are the kind of thing you run into when you're working with large codebases that were written by lots of different people. It's not the type of thing you experience with your own code. I've also written loads of Python and never experienced an error where the wrong type gets passed to a function (even working in a team). For years I couldn't even fathom how static typing would be a benefit other than maybe it can speed things up by giving a compiler/interpreter the ability to optimize things. Then at work--after nearly 20 years of Python--we finally had an issue where the wrong type was passed (float was inadvertently rounded because the function was made for integers and it wasn't obvious). It was caught before the code was sent to production (and it wouldn't have been a huge deal anyway) and I finally had a real-world situation where type annotations would've prevented an error. It's just not something that happens very often. It's the type of thing that creeps up on you for sure but it's not a common, every day occurrence. Type-related bugs are really super obscure. They're far, far rarer than type-obsessed developers make them out to be.
- Turing_Machine 5y ago
  I've often speculated that strong typing only seems like a win to the kind of developer who makes a lot of type errors, and a waste of time to those who don't (which doesn't mean they don't make other errors, of course).
  - Aldo_MX 5y ago
    Or to the kind of developer that works in a big team for a big project.
  - markstos 5y ago
    Even developers who "don't make type errors" have to deal with bad and unexpected data, which may be in a different type. If you don't validate that all untrusted data is off the appropriate type, security vulns or "garbage in - garbage out" bugs can result. Then if you do manually validate the types of untrusted data, then you have to wonder of having built-in type support might be faster. "Bad data" doesn't just come from the outside world. As teams start to use shared libraries written by other people, it's also valuable adds guards to ensure that shared functions are being called with the expected types. My own experience is that it doesn't feel like type-related bugs come up often on my team, but when they do the problems they cause can be bad enough to make us wish more of our code had been ported to TypeScript. Classic example: a CSV parser parsed numbers as strings because a particular spreadsheet quoted the number column. Result: "2"+"2" = "22"
  - rattlesnakedave 5y ago
    bringing in tooling to eliminate an entire class of potential errors sounds sounds like an easy decision to me.
    - Turing_Machine 5y ago
      Not if the errors are rare and the "tooling" slows down development.
      - 5y ago

Waterluvian 5y ago

I used to feel the same way about TypeScript until I really gave it a try one season. I feel like I was crippling myself for years, being an inferior developer wasting so much time with the things that TS guards against, documents, and autocompletes for. I support any formalization of TypeScript that further tidies up the "add-on" nature of it. But to be honest, it's really quite fine already.

edgyquant 5y ago
I work at a place that is full stack typescript with a legacy app that is Js/react (the kind of stuff I was writing in 2017-2018.) After using typescript and going back to fix issues on the legacy codebase I now understand why the industry adopted Ts

seniorsassycat 5y ago

Would you use type comments in your projects? Would you like pull requests adding them, or fixing them? What if the typescript checker and another checker have different semantics and you have fans fighting between `number` and `u8`?

keawade 5y ago

I disagree that TypeScript comes with only a marginal upside. In my experience TypeScript projects are much more approachable for contributors. For example, I once was debugging an issue in a JS framework and while I knew what was wrong and where I could fix it I didn’t have any idea what existing tools I had available in that context to fix it. Having type definitions would have made that work much simpler by increasing the accessibility of the code base. It’s experiences like this that have convinced me that if I’m writing code that any one will possibly read or need to modify later (including if it is just me) then I should be writing TypeScript instead of JavaScript. Or, more generally, that it should be typed.

shadowgovt 5y ago
You and OP are both right, because it really depends on what you're doing. At the scale I operate, it would be corporate suicide to try and write this code in straight JavaScript without type support. But for smaller teams, more focused teams, and teams that use a heavy testing discipline or enforced naming conventions that supplement the lack of static typing, it's not a problem.
NoWizards 5y ago
I couldn't disagree more with you... All i see when working with different levels of experienced contributors is param:any any[]. Even more when you want to interact directly with DOM instead of using an opinionated framework.
- selfmodruntime 5y ago
  You‘re blaming the active misuse of a tool on the tool itself.
- david422 5y ago
  This is either just code that is too complicated or devs that aren't doing a good job of type hinting. Everytime there is an any, it means that each developer reading or modifying this code has to find it out for themselves - every single time. Why not just type hint it correctly in the first place.

spion 5y ago

This isn't going to fix those issues. Those issues aren't due to tsc. They're due to an ecosystem which refuses to recognize the realities of compilation and add first class support for it. Its also due to an ecosystem willing to break compatibility (and not just backward compatibility but compatibility to other tools) at the drop of a hat. For example, the main reason I've seen why people began using bundlers for node recently is the fact that a lot of modules transitioned to pure ES6 without CommonJS support. In most projects, this means you have to use a bundler to be able to import those modules, or switch your entire codebase to ES6 (which is non-trivial due to changes in import path semantics). If it weren't for the above, you could just run `tsc` to get a `.js` file in `dist` for every `.ts.` file in `src` and run node on those.

afavour 5y ago
> They're due to an ecosystem which refuses to recoginze the realities of compilation and add first class support for it. IMO this is the correct path. Compilation should result in WebAssembly and it seems like the tooling is finally getting there.
- dmitriid 5y ago
  > Compilation should result in WebAssembly It... It really shouldn't. Especially not if the target is the browser as the bridge between WebAssembly and the rest of the browser is still "just pass these arrays of integers around".
- jeremyjh 5y ago
  I do not think that is a goal of either project; I’m not even aware of a POC JavaScript to WASM compiler. AssemblyScript couldn’t work without strong typing semantics and doesn’t support many typescript features.
spion 5y ago
Of course, using a bundler means you'll face several other unpleasant realities. Like - what about tests, how do they run - source maps support in node being 3rd party and unbearably slow for any medium sized project - edit: this has been fixed somewhat recently https://nodejs.medium.com/source-maps-in-node-js-482872b56116 - only the 3rd party bit, not the slowness bit https://github.com/nodejs/node/issues/41541 - also applicable when not bundling, albiet fewer reprcutions to turning off source maps - poor native (C++) modules support in bundlers - modules with really dynamic `require` statements being supported at varying levels by varying bundlers

afavour 5y ago

For what it’s worth I agree with you: after spending years battling with Babel and all that nonsense it’s been amazing to be able to just write ESM JS and have it run both on Node and in the browser. The real lightbulb moment for me was using JSDoc annotations with TypeScript types in JS files. It definitely isn’t as graceful as JS itself but it’s not that big of a deal, plus it encourages you to add comments. And any TypeScript editor will parse the code as if it’s TS, provide autocomplete, type checking etc etc as required.

simion314 5y ago

Just finished debugging one of those ugly issues where it works fine for the developer but for some other person things are broken. it was a piece of code that assigned an Number to a property that should have been an object(the dev confused the property name). Because the project is complex and there is a lot of network requests and stuff running in different order depending on the user internet the bug did not happened to everybody. You could work aroudn this using setters and doing runtime checks but I have a feeling people that don't like types also don't like getter and setter.

markstos 5y ago
Are you saying that if there had been type checking, this issue would have been much easier to detect and prevent?
- jaywalk 5y ago
  How could it not be? With type checking, you wouldn't be able to set a variable to a number when it's supposed to be an object.
- simion314 5y ago
  Yes a line like stuff.anAccountTypeField = obj.aNumberValue; Would cause an error in a typed language , something like incompatible type Number and type Account. Maybe you were confused by my commnet about the network requests and different order of running code, this caused the error not to happen most of the time so it never crashed on developer machine.

dlojudice 5y ago

> To me, I see the TypeScript tradeoff as coming with only marginal upside, in return for a large downside as described above. I've coded using static and dynamic types. C#, Java, Ruby, JS, etc. 20 something years doing it, mainly for business applications (opposed to system or embedded). My personal opinion is that types bring an elusive value of control and maintainability. Confronted with legacy / spaghetti code, developers with less experience will bring lint, code style, some layers and ... types, as a way to solve the problem of long term maintainability. But unfortunately it does not bring that much value. Actually it brings costs to readability and unnecessary abstraction (interfaces, generics, etc) aka "fighting the compiler". A better test suite can have exponential more value on maintainability than types. > Static Typing was the most requested language feature in the State of JS survey in both 2020 and 2021. [1] So when I see static types been the most requested feature I wonder how many of them know how to create a good test suit or a good architecture. If its behind this feature request is a different pain to be solved. [1] https://github.com/giltayar/proposal-types-as-comments/#community-usage-and-demand https://github.com/giltayar/proposal-types-as-comments/#comm...

azangru 5y ago
> A better test suite can have exponential more value on maintainability than types. A lot of ink has been spilled over this question. The conclusion is: no, tests do not and cannot replace types. Types, in themselves, provide a layer of tests that nobody, typically, would think of writing (what if a function is called with fewer arguments? what if it receives a different type of argument from what it was expecting?) and eliminate a whole class of superfluous tests that are checking for things that are better checked with types. The self-documenting property of types is remarkable. Jsdocs do not hold a candle to a typed codebase. Plus, refactoring. Even with tests I would be scared of large refactorings if I didn't have a type checker to also hold my hand. Of course, maybe I just don't know how to write code properly.
- kemiller2002 5y ago
  I always say that Types are not there for the truly expert programmer. They are there for the rest of us. It's a lot easier to pick up code and understand it when you at least have an inkling as to what a variable or parameters needs to have to function. Can interfaces be confusing, and generics become difficult to read? Yeah of course, but that's not really the problem of static type system, that's a problem with the code. I've generally found if you're doing something where you're thinking "this is just getting the way", you probably need to rethink your approach. Clear is always better than clever.

kingdomcome50 5y ago

Found the guy who hasn't used Typescript beyond tinkering! I kid... mostly. But in all honesty I have found very few instances of developers who have worked significantly with both languages and have come to the conclusion that TS has a marginal upside (though maybe they will come out in defense here!).

claytongulick 5y ago
<raises hand> I've worked extensively with both. I find that ts normally brings a downside, actually. In one project I maintain, a solid 30% of the code is nothing but ts stuff. It makes maintaining the code base excruciating. Small changes between versions of ts or .d.ts files have caused hundreds of errors. A concrete example of this is the change in mongo driver that forced "new ObjectId()" instead of "ObjectId()" though functionally there was no difference. I see massive bizarre and difficult to grok type declarations that grow in excruciatingly byzantine complexity just to satisfy the compiler for non-trivial flexible function definitions. I see painful compilation times, a beefy laptop's CPU getting pegged and the fan whining while trying to do even minor updates. Try to do a build while on a video conference? I see two to three minute build times. I see a series of nonsense stories in sprints that are nothing more than activity over achievement. They don't drive product functionality, they are a bunch of make-work to satisfy the developer asthetic and the compiler. The nightmare of "compiled" NodeJS production support is a dystopian hellscape that I'm forced to endure every day because of NestJS and typescript. And nothing in that has done anything to increase code quality or reduce bugs from the crappy offshore team that wrote it. Clearly, I'm not a fan. That being said, I think type comments in jsdoc are a honking good idea. I use inline /* @type */ declarations and .d.ts files liberally. If we could add to jsdoc the ability to document types and purpose of arbitrary js objects inline, at definition time, instead of an external .d.ts file, I'd be a happy guy. An example of this would be sequelize schema defs, or mongoose schema defs, where I can have all my jsdoc code comments and type definitions in the same place as the code. All that being said, I like the idea of this proposal. Especially if it could solve the schema definition issue above. I think optional typing is a good idea to bake directly into the language. I thought AS3 did a great job of this. I even think it would be great to have an equivalent of "strict" that would enforce typing at the module level to enable straightforward AOT / wasm interop (I know it doesn't solve the GC issue). My beef is mostly with the extra compilation step and needless complexity of ts. If we had simple (no generics) opt-in typing that was natively supported by the engine, I think it would enhance the language overall, like type hints have done for python.

yboris 5y ago

You should try Vite - https://vitejs.dev/ https://vitejs.dev/ - start a TypeScript project in under a minute - no annoying Webpack configuration needed.

fifticon 5y ago

I abandoned my attempts to make larger projects in pure javascript. I happily write larger projects in typescript. Typescript makes javascript feasible, usable for me.