JavaScript Types Proposal == ActionScript

programming web dev
1

A little tongue-in-cheek comparison of what is being proposed as an improvement for JavaScript and how close it looks to ActionScript:

image
image1360×596 43 KB

I wouldn’t mind types coming to JavaScript btw! All we would next is onEnterFrame and a handful of other popular AS things :cake:

What is being proposed looks a lot like ActionScript, which is not a bad thing haha :stuck_out_tongue:

1 Like
2

You can also vote in this poll, thought I kinda already gave the answer:

https://twitter.com/kirupa/status/1502537960322863108

3

I think its great… this will make it easier to debug…

What I’d really like to see is object destructuring fallback values with types e.g.

{ name: string = "name not provided", age: int = 0, sex: string = "non binary" }

So if a value is not the correct type OR undefined/ null the fallback is used.

Maybe even an error() object could be a valid fallback so function error handling could kick in.

I really should test that out… :smile: maybe the fallback can currently be new Error() (I’ve never tried)

4

Is there a chance that we could get that sponsored with TC39…@kirupa :wink:

Now that you work for Google… :smile:

1 Like
5

Something to keep in mind - and this can be seen in the proposal name, “ECMAScript proposal: Types as Comments” - is that this isn’t adding types to JavaScript. It’s adding comments to JavaScript that is using the same syntax used by type checkers to specify data types. At runtime these types are ignored. So you could say

let x:number = "Hello, world!"

and still have valid JavaScript.

This means what you’re asking for @steve.mills would not be possible because at runtime, there is no type information to check. (You’d have better luck getting that behavior with a decorator extension.)

This also means that runtime types like this could never be added to JavaScript because doing so could “break the web” once anyone anywhere deployed code with an invalid type like the example above. The only way this could be made possible is if they added a new mode along the lines of “use strict” that enabled types providing an opt in (though the committees current attitude is “no new modes, ever”).

But that could be a good thing. Some languages are untyped. JavaScript is one of them, and it’s probably ok that it stays that way.

So, then, why do this at all? You can already use comments to add type annotations using JSDoc comments. And the proposal here is only for a subset of TS features to be added so it’s not like people can switch over from using TS to JS overnight. TS will continue to be TS and require a build step to transpile. All this is really doing is complicating the JS syntax making it harder to parse.

2 Likes
6

TBH I’m not really getting why it’s not possible.

If I understand correctly this
let {name = 'not given'} = obj
under the hood in will be:

if(obj.name === undefined) let name = 'not given'
else let name = obj.name

Considering that the colon : ‘operator’ in JS can be used as:

  • object intialiser {key: 'value'}
  • label loop1: for(let if of arr){}
  • ternary OR name ? name : undefined
    and now proposed as
  • type comment let x:number = "Hello, world!"

the context for which the colon was used would change the effect…

So why couldn’t let {name: string = 'not given'} = obj not be

if(obj.name === undefined || typeof(name)!== 'string') let name = 'not given'
else let name = obj.name

I understand that when you declare and store variables in Javascript as proposed let x:number = "Hello, world!" its not evaluated (or type evaluated) in any way and its not practical of performant to do that…

But with let {name = 'not given'} = obj… obj.name is being evaluated and another variable assigned as a pointer…

7

That’s just it, the colon doesn’t change anything. Its a comment. Its text completely ignored by JavaScript. It would have no effect on the behavior at runtime.

Could JavaScript be wired up to do something like this? Sure, but not with this proposal, and not with the prevailing idea that JavaScript remain untyped. This proposal sticks to that ideal (no types) by making these “types” comments only.

Going with the decorator approach, you could get exactly what you’re after with a slightly different syntax.

function asString(value) {
  return typeof value === 'string' ? value : undefined
}
let obj = { name: 42 }
let { @asString name = 'not given' } = obj
console.log(name) // 'not given'
1 Like
8

You’re right, the decorator proposal is pretty powerful. :slightly_smiling_face:

9

To be clear, that particular use is an “extension” :wink: and not something the current proposal would support out of the box. Given how long its been taking the current proposal to get off the ground (just for decorating classes and class members) who knows how long something like that would make it into the language, if at all. :sad2:

10

Wohoo, ship it!

3 Likes