> Hello, to play the devils advocate: why does JavaScript need static typing? Your proposal doesn't really answer that. Sure, it mentions tooling and IDEs that can provide you with type hints and complain on mistakes
I actually did. It keeps unwanted type mutations and bad values away. For example,
This:
```js
let a = 10
a += ‘1’ // ‘101’
// or
a += undefined // NaN
```
VS this:
```js
let a: number = 10
a += ‘1’ // Error, cannot convert type string to type number.
// or
a += undefined // Error, number doesn’t have nullable mark.
```
This can help developer itself, in runtime, not only at development time. “But IDE wouldn’t allow that.” But what if property in required json(node js), is undefined? Some IDEs don’t have JSON intellisense, so this is where it can get annoying.
> but things like Flow and Typescript do this today already. 
Yes, but they are compile-time only. Meaning, that in runtime, type mutation and unwanted values can happen.
> What's your goal, to have JS engines run Typescript(-like) code natively without transpiling?
First of, this is compiling. TypeScript is higher level than JS, so it’s compiling. Second, TypeScript code is completely compile-time only. Classes(And other ES8+ code), imports, exports and probably namespaces are the only things which are at runtime also.
> What's the point of building this feature into engines? It just provides additional complexity.
I said reasons above. Also as I said, they are optional. Meaning, new comers can still learn old js code without static types. Besides, doesn’t async, await, classes and other new stuff add complexity to new people to JS?
> Where (when) do you expect types to be checked? Should the engine throw early errors (during parsing)?
Languages normally check types during compile-time. I expect JS to throw errors in runtime, meaning that if you make code which would throw type error and it’s untouched, then it doesn’t throw an error.
> What does "static typing" even mean to you in a dynamic scripting language?
Same thing as in real statically typed languages. Type checking.
> and what happens when you introduce new types with `eval` or by loading another script?
Since as I said, they are runtime only type checking.

> However I would be curious to know if anybody has a usage for them at run time
They have. `eval` can make type mutation(and if it checks the string, you can still overcome them(inputs or array joining)).

Also, if transpiling and compiling is better, why not leave JS dead? I mean, compilers can do job instead of JS. It’s just basically useless, compilers can do awesome stuff, so “no need for new features in JS”(and then if we did, wasm would take over in web development, or browsers would overcome ES and use something else instead). 


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190325/3f53309e/attachment.html>

> Hello, to play the devils advocate: why does JavaScript need static typing? Your proposal doesn't really answer that. Sure, it mentions tooling and IDEs that can provide you with type hints and complain on mistakes

I actually did. It keeps unwanted type mutations and bad values away. For example,
This:
```js
let a = 10
a += '1' // ‘101’
// or
a += undefined // NaN
```
VS this:
```js
let a: number = 10
a += '1' // Error, cannot convert type string to type number.
// or
a += undefined // Error, a doesn’t have nullable mark.
```
This can help developer itself, in runtime, not only at development time. “But IDE wouldn’t allow that.” But what if property in required json(node js), is undefined? Some IDEs don’t have JSON intellisense, so this is where it can get annoying.
> but things like Flow and Typescript do this today already. 

Yes, but they are compile-time only. Meaning, that in runtime, type mutation and unwanted values can happen.
> What's your goal, to have JS engines run Typescript(-like) code natively without transpiling?

TypeScript code is completely compile-time only. Classes(And other ES8+ code), imports, exports and probably namespaces are the only things which are at runtime also.
> What's the point of building this feature into engines? It just provides additional complexity.

I said reasons above. Also as I said, they are optional. Meaning, new comers can still learn old js code without static types. Besides, doesn’t async, await, classes and other new stuff add complexity to new people to JS?
> Where (when) do you expect types to be checked? Should the engine throw early errors (during parsing)?

Languages normally check types during compile-time. I expect JS to throw errors in runtime, meaning that if you make code which would throw type error and it’s untouched, then it doesn’t throw an error.
> What does "static typing" even mean to you in a dynamic scripting language?

Type checking(Not like strongly-typed type checking, but no type mutation).
> and what happens when you introduce new types with `eval` or by loading another script?

Since as I said, they are runtime only type checking. Meaning, it would check type after eval code is executed.

> However I would be curious to know if anybody has a usage for them at run time

They have. `eval` can make type mutation(and if it checks the string, you can still overcome them(inputs or array joining)). Let's say we are importing TypeScript module through compiled TypeScript code(or other way around)(assuming we have thing which let's us import TypeScript files), then all of the enums, interfaces, etc. are completly gone, like they never existed. That's because they are compile-time only.

Also, if transpiling and compiling is better, why not leave JS dead? I mean, compilers can do job instead of JS. It’s just basically useless, compilers can do awesome stuff, so “no need for new features in JS”(and then if we did, wasm would take over in web development, or browsers would overcome ES and use something else instead). 

> Hello, to play the devils advocate: why does JavaScript need static typing? Your proposal doesn't really answer that. Sure, it mentions tooling and IDEs that can provide you with type hints and complain on mistakes

I actually did. It keeps unwanted type mutations and bad values away. For example,
This:
```js
let a = 10
a += '1' // ‘101’
// or
a += undefined // NaN
```
VS this:
```js
let a: number = 10
a += '1' // Error, cannot convert type string to type number.
// or
a += undefined // Error, a doesn’t have nullable mark.
```
This can help developer itself, in runtime, not only at development time. “But IDE wouldn’t allow that.” But what if property in required json(node js), is undefined? Some IDEs don’t have JSON intellisense, so this is where it can get annoying.
> but things like Flow and Typescript do this today already. 

Yes, but they are compile-time only. Meaning, that in runtime, type mutation and unwanted values can happen.
> What's your goal, to have JS engines run Typescript(-like) code natively without transpiling?

TypeScript code is completely compile-time only. Classes(And other ES8+ code), imports, exports and probably namespaces are the only things which are at runtime also.
> What's the point of building this feature into engines? It just provides additional complexity.

I said reasons above. Also as I said, they are optional. Meaning, new comers can still learn old js code without static types. Besides, doesn’t async, await, classes and other new stuff add complexity to new people to JS?
> Where (when) do you expect types to be checked? Should the engine throw early errors (during parsing)?

Languages normally check types during compile-time. I expect JS to throw errors in runtime, meaning that if you make code which would throw type error and it’s untouched, then it doesn’t throw an error.
> What does "static typing" even mean to you in a dynamic scripting language?

Type checking(Not like strongly-typed type checking, but no type mutation).
> and what happens when you introduce new types with `eval` or by loading another script?

Since as I said, they are runtime only type checking. Meaning, it would check type after eval code is executed.

> However I would be curious to know if anybody has a usage for them at run time

They have. `eval` can make type mutation(and if it checks the string, you can still overcome them(inputs or array joining)).

Also, if transpiling and compiling is better, why not leave JS dead? I mean, compilers can do job instead of JS. It’s just basically useless, compilers can do awesome stuff, so “no need for new features in JS”(and then if we did, wasm would take over in web development, or browsers would overcome ES and use something else instead). 

> Hello, to play the devils advocate: why does JavaScript need static typing? Your proposal doesn't really answer that. Sure, it mentions tooling and IDEs that can provide you with type hints and complain on mistakes

I actually did. It keeps unwanted type mutations and bad values away. For example,
This:
```js
let a = 10
a += '1' // ‘101’
// or
a += undefined // NaN
```
VS this:
```js
let a: number = 10
a += '1' // Error, cannot convert type string to type number.
// or
a += undefined // Error, a doesn’t have nullable mark.
```
This can help developer itself, in runtime, not only at development time. “But IDE wouldn’t allow that.” But what if property in required json(node js), is undefined? Some IDEs don’t have JSON intellisense, so this is where it can get annoying.
> but things like Flow and Typescript do this today already. 

Yes, but they are compile-time only. Meaning, that in runtime, type mutation and unwanted values can happen.
> What's your goal, to have JS engines run Typescript(-like) code natively without transpiling?

TypeScript code is completely compile-time only. Classes(And other ES8+ code), imports, exports and probably namespaces are the only things which are at runtime also.
> What's the point of building this feature into engines? It just provides additional complexity.

I said reasons above. Also as I said, they are optional. Meaning, new comers can still learn old js code without static types. Besides, doesn’t async, await, classes and other new stuff add complexity to new people to JS?
> Where (when) do you expect types to be checked? Should the engine throw early errors (during parsing)?

Languages normally check types during compile-time. I expect JS to throw errors in runtime, meaning that if you make code which would throw type error and it’s untouched, then it doesn’t throw an error.
> What does "static typing" even mean to you in a dynamic scripting language?

Same thing as in real statically typed languages. Type checking.
> and what happens when you introduce new types with `eval` or by loading another script?

Since as I said, they are runtime only type checking. Meaning, it would check type after eval code is executed.

> However I would be curious to know if anybody has a usage for them at run time

They have. `eval` can make type mutation(and if it checks the string, you can still overcome them(inputs or array joining)).

Also, if transpiling and compiling is better, why not leave JS dead? I mean, compilers can do job instead of JS. It’s just basically useless, compilers can do awesome stuff, so “no need for new features in JS”(and then if we did, wasm would take over in web development, or browsers would overcome ES and use something else instead).