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.

So while you technically are disagreeing with the parent, it's on the smallest of points, and completely disregarding the main one the parent offered (which, fair enough, but wanted to point that out)

IMO this is the correct path. Compilation should result in WebAssembly and it seems like the tooling is finally getting there.

  - 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

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.

> But unfortunately it does not bring that much value.

If you mean adding these things post-hoc, yes the value is limited. If you start with types, and you embrace them as a design and testing tool, they can literally change the kind of code you write in the first place.

People talk about how convoluted TS types are, but the reality is that’s because they’re describing convoluted JS. TS-first code tends to be a great deal more straightforward, because you define the interface before implementing it.

In other words, if you start out with static types and think about them first, you’ve likely already got a good architecture and test suite.

I've been using Elm for the last 2 years and it's not that I don't fight the compiler, but I constantly use it to guide me while refactoring. Elm code is extremely readable and types (including Maybe, Result, etc.) just give so much confidence and control to the programmer. While working with an Elm code base, refactoring is a constant, joyful, safe act.

It is true that in many cases good tests help. However often when I work with Python (using type hints), I need to write a unit test just to ensure a contract that I could explicity state using types in Elm. It doesn't feel right.

In general dynamic types incentivize the status quo and promote codebase ossification, and somewhat ironically make rapid prototyping harder.

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.

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.

Most of the changes to JS in the last 20 years, have been serious improvements, but they did not change the fundamental characteristics of the language.

Believe it or not there are a lot of people that like JavaScript!

I do not think the demand is quite as huge as you think it is.

V8 still has to updater its parser. Other tools that handle JavaScript parsing need to do that as well.

> You'd be able able to use typescript autocomplete and linting in your editor, and just serve the files to your browser with a static http server.

Nope, it's not using TypeScript directly, but just another language very similar to TypeScript.

    // Dog Class
    function Dog(_name){
       // call the parent constructor
       Animal.apply(this,arguments);
    }

    // extends the Animal prototype chain
    Dog.prototype = new Animal();

However I'm the type of person that will only use React function components in my codebase. I don't think the object-oriented style has added much too my programming, except the temptation to reach for an unnecessary abstraction.

JavaScript has evolved as an untyped language, it has type-coercion and a single way to represent (most) objects in memory. So regardless of what kind of syntax you add on top... it will still be a untyped dynamic language internally. Are we talking about changing this truth? Or just adding additional syntax for developers?

The fact that they by design have no impact on the runtime isn't really even a positive. That could be a large tactile benefit of this RFC; that suddenly JS is capable of communicating to its runtime what types different primitives are, such that the runtime can optimize their storage and usage. But, by design, they don't want this. Maybe that could change in the future, but I suspect it won't because the proposers have taken the stance that everyone minifies anyway so the syntax doesn't matter anymore.

    let user = new User();
    let user: User = new User();