I mean, with all due respect, who are you to decide what Javascript is and is not? There's obviously a huge demand for type safety in Javascript, hence the existence and adoption of Typescript.

I don't know but I've been using JavaScript for a while now. It seems like a lot of the people that want JavaScript to look similar to other languages are coming from different programming fields, and want JavaScript to look more like their language of choice.

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'm on the fence about this one. On the one hand I would love strong typing in JS.

But the reason I never adopted TS is because one time I spent months converting Coffeescript back into JS once it fell out of favor. This was back when a bunch of Ruby developers decided that JS should look like Ruby.

If I'm writing Javascript, I'm writing Javascript, not something that pretends to be something else.

You can convert TS to JS at the drop of a hat. This is part of what’s required to get it to run a browser, which doesn’t understand native TS. It’s different to Coffeescript which was different syntax for JS. TS is additional, type-specific syntax but you are still writing JS.

I ran a team that had to maintain a large Coffee codebase, that we could never get the resources to move off. So I know that pain. TS is different, both in how it works and the level of adoption. Coffeescript was always niche, and some benefits were there but they weren’t game-changing for (eg) writing correct code or maintaining large codebases.

You can generally migrate out of TS very easily if it was the wrong choice. You can mostly use the compiler output as a drop-in replacement for your source code. Depending on compiler options, it's quite readable.

One of the benefits of TypeScript is that it literally is just JavaScript plus some. You can literally run `tsc` and it will spit out JavaScript written the same way as you wrote it but without any of the types. The only things that might look out of place is things like enums or decorators but you can choose not to use them.

The good news is that you can take your time with it, only start using typescript in new files while converting older ones slowly. And even if you never do that, typescript tooling provides hints and autocompletion to vanilla J's files as well.

> but I've been using JavaScript for close to 20 years now

How dare you use JavaScript for anything else than validating forms!!! What is that jQuery thing??? Stop trying to make JavaScript into something it's not!!!

What about the aspect of JavaScript having weak type system relegates it's use to only be used for forms?

Is C only used for forms?

I thought you were there literally 20 years ago when people were complaining about adding DHTML to the browser.

And most of the developments in Java, since 1.8, have been taking ideas from other languages (primarily Scala) to make the language better. Why is it ok for other languages to evolve but not Javascript?

Scala is a perfect example of an overly complex bloated mess with so many foot-guns I can't even begin to count them.

EDIT: I never said JS shouldn't evolve! JavaScript has evolved a ton! From better handling of asynchronous control-flow with promises and then async/await, to destructing, spreads, constant assignments, Map/Set objects, a number of other improvements I can't even begin to list. But none of these changes fundamentally changed JavaScript from being a dynamic weakly typed language.

I actually write a lot of Scala and beg to differ. The chances for bad developers to write bad code in Scala are higher than most other languages but what you might call foot-guns are actually elegant ways at solving complex problems.

A lot of these "problems" (implicits, enums, etc) were solved with Scala 3 too. Another example of a language evolving and becoming better based on community feedback and thoughtful iteration.

I would like to say that I have written js for a long time as well and I love it; but the thing that keeps me around nowadays is typescript. I would need to be paid much more to work on a non-ts js codebase nowadays.

> but they did not change the fundamental characteristics of the language.

FWIW, this proposal does not change the fundamental characteristics of javascript. It just adds a new comment syntax.

There is no way this is where the buck stops... after comment syntax people will look at compiler optimizations. It will change the language.

But didn't he merely express his opinion about this?

I'm questioning their opinion, as we do on this site.

You asked: "who are you to decide?". That's not questioning their opinion but rather their right to voice their opinion.

Compare the lines of code (on Github, say) written in straight Javascript and the lines of code written in Typescript.

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

Every TypeScript project is going to have at least an equivalent amount of JavaScript code sitting in the repo from the output of the TypeScript compiler.

most people don't version control the output of their compiled build though.

This is like saying compare the lines using generators or proxies vs the lines using type annotations.

Just because a feature is not widely adopted it doesn't mean that is not useful to the people using it, especially when the feature is used to mitigate the entire "cannot find property of undefined" type of errors.

In the linked article, the author spends 1 sentence dealing with objections:

> I can understand if JavaScript developers are afraid of TypeScript taking over their language. However, this proposal will be as far as things will go w.r.t. adding TypeScript features to JavaScript

And in the next few sections it includes someone who wants to build on the proposal including using type hints to optimize code. I just think there's literally no way to guarantee that "this will be as far as things will go". Yes languages evolve and add new things all the time. But GP's point is that the language seems to be going toward what people want it to be coming from other languages.

I agree, stop trying to make JS something it's not.

> And in the next few sections it includes someone who wants to build on the proposal including using type hints to optimize code.

This changes literally nothing about the JS language. JS engines already attempt to determine the types of things to optimize the code they generate. Type annotations would just allow them to make more aggressive optimizations.

> This changes literally nothing about the JS language.

Besides adding a bunch of new syntax, of which JS already has far too much.

I'm not sure that's a useful metric.

Did you read the article? All the proposal does is allow the javascript engine to accept typescript-style syntax, while erasing all the annotations at runtime. From the browser's point of view, it would essentially treat the type annotations and type declarations as comments. This combined with native Ecmascript modules means you could theoretically develop a typescript application with no bundler or other build tools. 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. Some newer bundlers like Vite and esbuild greatly reduce the amount of configuration required to set up a typescript project, but being about to develop a project with nothing but an editor and a browser would be a huge win for small projects.

Since the proposal doesn't care about the semantics of the type annotations, it doesn't even necessitate typescript. It would work just as well with Flow typing or even a completely new type checker.

> From the browser's point of view, it would essentially treat the type annotations and type declarations as comments.

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.

Out of curiosity, where do you stand on ES6 classes?

Certainly cleaner than using the old prototypal inheritance syntax.

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

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

Although the new class syntax may obfuscate from what's actually happening in an effort to look more like traditional class-based languages like Java.

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.

The only constant is change! The "don't make JavaScript into something it's not" ship sailed decades ago when AJAX was thrust upon the world.

Besides, adding even more complexity to the JS ecosystem at this point is like pouring a cup of water into the sea.

Do you remember Javascript from 1996? (I do.) Do yo think that all the improvements of ES5 (reflection, strict mode, JSON) changed it into what it was not? Did ES6 (classes, imports) change JS into something it was not, or should not be? Did ES2016 (async) do that?

I get that this is a humble opinion. And I respect that. But for a language that draws so much ire from the programming community, and yet demonstrates such an ability to change and morph over the years. Are you saying you do NOT WANT it to get better? (and I realize "better" is subjective).

The same is true of PHP. People hate it. People complain. PHP takes the criticism and makes updates. People complain more.

Of course I want it to get better. I just don't necessarily agree that a type-system = better, particularly in the way in which it's been suggested. Especially when you aren't talking about changing the internals regarding how JS is executed or how data is represented, you are only talking about adding "comments".

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?

It does feel like we have a problem saying no to language features, and it’s not just in the JS world.

Definitely, ES6 was great and it seems we've ramped up to add as many features as possible, which has produced a lot of churn and unused/hated features. A committee was formed to add new features when needed, and now they... just keep adding and adding even when not needed.

That ship already sailed. If we were just twiddling the DOM I wouldn't even be reading this thread right now but people are writing production back-end code for financial services companies in JS. Bring on the type system.

This argument could be used for literally any improvement to JavaScript.

I think this proposal is trying to keep in that spirit while making everyone happy, by only adding what is effectively another comment syntax to JS, instead of defining a type system for it.

I am mildly confused by your objection. It appears the proposal is to allow type annotations to appear as essentially no-op instructions. It isn’t adding a type system to JS.

partially agreed, I would love to see tools and supports of WASM being put on a higher priority and people improves dev experiences there. JavaScript syntax is already coupled with too many factors being a scripting platform or a compilation target.