Microsoft proposes type syntax for JavaScript
- Reference: 1647269414
- News link: https://www.theregister.co.uk/2022/03/14/types_in_javascript/
- Source link:
The proposal planned from Microsoft and others, including devs from the Igalia Coding Experience program and Bloomberg, is all about adding "types as comments" to the language.
The theory is that it would become possible to have a syntax for types that could be used by tools that need those hooks (such as Microsoft's own TypeScript) and ignored by those that do not.
[2]
Types are a controversial and, some might say, long overdue innovation for the venerable JavaScript.
JavaScript survey: Most use React but satisfaction low [3]READ MORE
The popularity of tools such as TypeScript and Flow, with built-in type checking, has demonstrated that a demand exists. The most recent [4]State of JavaScript survey highlighted Static Typing as something many were thirsting for.
The thing is, there is wide variation in opinions about what Static Typing actually represents in the world of JavaScript, not to mention a healthy subset that would run a mile from such functionality. The proposal from the group of devs led by Microsoft is a compromise position. At present, in the TypeScript world, one can express types in JSDoc comments, which tend to be a little verbose and, dare we say it, clunky in use.
[5]
[6]
The example given by Microsoft's Daniel Rosenwasser of current TypeScript JSDoc comment practise is: /**
* @param a {number}
* @param b {number}
*/
function add(a, b) {
return a + b;
}
Which could, if the proposal gets accepted, become something like: function add(a: number, b: number) {
return a + b;
}
"The idea of this proposal," said Rosenwasser, "is that JavaScript could carve out a set of syntax for types that engines would entirely ignore, but which tools like TypeScript, Flow, and others could use."
Rosenwasser was quick to emphasize that the proposal is not about sticking TypeScript type-checking into every JavaScript runtime (certainly, one could imagine all kinds of compatibility problems down the line) instead, the plan is that the approach would be picked up by any type checker, not just the likes of TypeScript.
Certainly, if a developer is accustomed to using a type checker, then the approach has much to commend it. However, by carefully making sure everything remains optional there is also the risk it might just complicate things further and simply be ignored.
[7]
Unsurprisingly, debate over the move has rumbled on since its publication last week. [8]Some think the idea is an excellent one while [9]others are a little more negative .
[10]This JavaScript scanner hunts down malware in libraries
[11]30-up: You know what? Those really weren't the days
[12]Next.js 12: Middleware, ECMAScript modules, and lessening use of Node.js
[13]Securing open-source code isn't going to be cheap
Rosenwasser said: "A proposal like this will receive a lot of feedback and appropriate scrutiny."
It is also still only a proposal at the moment, planned for [14]Stage 1 of the ECMA TC39 process . There are therefore many hurdles ahead before the concept (if accepted) makes its way into the form ECMAScript and plenty of opportunity for debate.
However, judging by the responses of just over 16,000 devs that answered questions in the 2021 [15]State of JavaScript survey , there is appetite for some sort of type functionality. The developers' proposal is a first step on the way. ®
Get our [16]Tech Resources
[1] https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Yi90t1eThvG4VcwFb5vjBQAAAIY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.theregister.com/2022/02/22/javascript_survey/
[4] https://www.theregister.com/2022/02/22/javascript_survey/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yi90t1eThvG4VcwFb5vjBQAAAIY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yi90t1eThvG4VcwFb5vjBQAAAIY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yi90t1eThvG4VcwFb5vjBQAAAIY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://twitter.com/Rich_Harris/status/1501638466857283588
[9] https://twitter.com/JessTelford/status/1501720911900454913
[10] https://www.theregister.com/2022/03/01/socket_npm_dependency_scanner/
[11] https://www.theregister.com/2018/09/20/verity_stob_column_september/
[12] https://www.theregister.com/2021/10/27/nextjs_12/
[13] https://www.theregister.com/2022/02/09/secure_open_source_software/
[14] https://tc39.es/process-document/
[15] https://www.theregister.com/2022/02/22/javascript_survey/
[16] https://whitepapers.theregister.com/
Re: Nah
Don't forget the GOTO. No point numbering lines if they don't allow you to crash out of a function without messing up the stack.
would this be...
Would this be the same Microsoft that tried to fob us off with VBScript in Internet Exploiter?
-A.
Copied from Python
Python introduced type hints some time ago with the same syntax, which I personally find extremely distracting and unhelpful. There supposed to be "optional" but the syntax is in your face and some companies are mandating them. Looks like the same thing for JS.
Re: Copied from Python
The syntax may be "in your face" but it can be very useful and it IS optional. Its also easy to ignore.
As for companies mandating them, it depends on why and where. Large bodies of complex code on which static analysis tools are run or small scripts? If people are requiring its use where the tradeoff between the extra code and the benefits of it is bad, that is their fault.
Re: Copied from Python
Commenting from a Python POV - type hinting is great for two reasons - static analysis is cheap and finds bugs, and secondly it allows editors to provide more robust auto-completion.
Well engineered code says what arguments a function takes and what it returns, its a minor concern to add proper type hints to something, and the value gained from adding them increases exponentially as the proportion of type hinted code increases. It's universally a good thing.
Is there a reason why languages from "web people" always favour the types after the variable names in function arguments? I.e
void do_thing(a: int, b: float)
vs
void do_thing(int a, float b)
Go, Rust, Typescript all seem to do it. Surely it isn't simply because these guys are all just used to Adobe's ActionScript 3?
I'm simply more used to the latter and it doesn't really matter, I am just interested in the legacy of where it arose or if there is a technical reason (i.e easier to parse, etc).
Server-side JScript under ASP.Net has done it that way for years
> void do_thing(a: int, b: float)
That appears to be the same (optional) type syntax already used for a long time in server-side JScript (*) under ASP.Net.
That might or might not be why MS have suggested it here.
(*) JScript being MS's version of JavaScript in both client-side flavour (where it's essentially their "version" of regular JavaScript with EEE tweaks) and for server-side ASP and ASP.Net (where it lets you use both JS and Windows/.Net objects).
Short answer, type inference. Its easier to parse let x = 5; and let x: int = 5; if you know let x is going to be first no matter what.
From:
https://softwareengineering.stackexchange.com/questions/316217/why-does-the-type-go-after-the-variable-name-in-modern-programming-languages
So the long and short of that, is that all those "modern" languages aren't strongly typed, and those that are strongly typed (such as C#) allow type inference via the var keyword where applicable.
This is because there is a trend towards non-compiled, or semi-compiled languages, where the runtime has to do the work of figuring out the actual variable type (or using some horrible struct that can store a pointer to a real variable, or an instance of all the types something can be represented as, or, worse still, a string which gets cast to e.g. an integer, when it is treated as such).
Because computers are getting faster, people don't notice that this sort of thing is much more computationally intensive, or wasteful of memory, so they don't understand why their tight loops run slower than something written in C running on older hardware, or why their program keeps stopping for seconds at a time to do a garbage collection.
Personally, I find the abstractions provided by modern languages are useful to allow you to focus on what the program is supposed to do, rather than the implementation detail of how it does it under the hood. However, I don't trust any developer who can't explain what 2's complement is, or can't tell you what bit-shifting a 32-bit unsigned integer three places to the left will do.
Just say node!
Personally, I think JavaScript is an abomination: it's the hate child of BASIC and PL/I. For those who share my view, I can't see the point of these insignificant cosmetic fripperies. For those that don't, they'll likely never use them anyway.
In the browser (the place that complex pieces of arbitrary software least belong), it is at least becoming possible, if you must write code, to use serious programming languages that compile to WASM. Outside the browser there's so much choice it's inconceivable anyone would want to use JavaScript for anything.
It used to be all fields round here, you know.
Re: Pl/1
I used to enjoy Pl/1 so thanks for reminding me.
P.S. Were the fields round your way typecast?
Jusding from a lot of the Typescript I've seen
Brace yourselves for seeing lots of code liberally sprinkled with :any because the developer was too lazy to work out what the type should be, and their compiler warnings* are set such that untyped variables won't be allowed...
*yes I know JS isn't compiled, but that doesn't stop you running it through a linter does it?
Nah
We need line numbers in C++ first, then we'll worry about types in Javascript.