12 ms·

TC39 Proposal: Type Annotations

129 points by rglover 4y ago

padjo 4y ago
Immediate reaction is that this is a bad idea. Seems like it would result in a weird Frankenstein language that is neither fish nor fowl. The lack of prior art for this type of approach is particularly concerning.
- runarberg 4y ago
  Isn’t Python type annotation also ignored during runtime and left for third party tools to check? I would consider that prior art.
  - padjo 4y ago
    From the proposal: > The proposal here differs significantly from Python's types, as the types in this proposal are entirely ignored, not evaluated as expressions or accessible at runtime as metadata. So guess sorta prior art but quite different. Reading the TC39 minutes for this proposal makes me think it’s highly unlikely that the approach as outlined here will go anywhere.
Matheus28 4y ago
Sounds like a bad idea. I get it that not specifying type syntax makes it the most flexible, but also prevents any actual checks and optimizations from being performed by the browser. So it’s just inflating bundle sizes for no reason. Might as well run them through something that checks then removes type annotations… which is what we already have
- lagrange77 4y ago
  > So it’s just inflating bundle sizes for no reason. When using a bundler, it will be trivial to remove the annotations in the build process. Using a TypeScript transpiler in that process is also trivial you might say. But static typing syntax and tooling as part of the language itself is the way to go imo.
  - Matheus28 4y ago
    >But static typing syntax and tooling as part of the language itself is the way to go imo. But if the typing syntax is essentially just comments in very specific places... what advantage does it bring? Sure one can use tools to interpret those comments and check types... but at that point, isn't just using typescript tooling much superior (interface declaration, type declarations, etc. not just a type between : and =)? I will confess that I am guilty of having used JSDoc comments for quick and dirty .js scripts that I didn't want to grab the tsc compiler for, but still wanted vscode to check my types. But even being one of the likely users of this proposal, I feel that it's needlessly bloating the language.
    - lagrange77 4y ago
      > what advantage does it bring? The advantage would be, that static typing is part of the language. Don't you find it odd to use another language just for a missing language feature? For me it feels somewhat hacky and '// temp. solution!!! fix soon!'-worthy.
      - Matheus28 4y ago
        But with this proposal, static typing wouldn't be part of the language. It's just a fancy looking comment. No different than using JSDoc with a nicer syntax
        lagrange77 4y ago
        Ok agreed, i would also like to have the type checker build into the language as well. But in the end, this is a scripting language. Maybe it's not too bad to not enforce it being typed, but provide a baseline to have it being typed optionally, in form of an 'official' annotation syntax. But i'm thinking out loud now.
        Matheus28 4y ago
        I just think it'd overcomplicate implementations. We already have typescript and such, and they work perfectly. It's my personal belief that integrating those things into the language would slow innovation.
- jupp0r 4y ago
  It would be great to be able to have access to types at runtime in order to change behavior based on types. That would make TypeScript so much more useful but it does require javascript support.
  - Matheus28 4y ago
    You should try decorators for that. They're pretty decent
    - jupp0r 4y ago
      Yeah it's a workaround, but not really ergonomical for the library author (for example they can't modify the type being decorated).
  - mixedCase 4y ago
    You can use a runtime type system like io-ts or something like reflect-metadata. Let's not pay the cost when we don't need it.
    - jupp0r 4y ago
      The compiler knows when this is used and can only insert type metadata when needed. io-ts and reflect-metadata are unwieldy crutches compared to a type system that's designed to influence runtime behavior (ie Rust, C++, etc).
      - rektide 4y ago
        https://github.com/tc39/proposal-decorator-metadata https://github.com/tc39/proposal-decorator-metadata is where we'd probably need to begin to store this information. It's still need a transpiler to generate the necessary decorators. Decorators are still in progress (but kind of seemingly shaping up these days).
- cookiengineer 4y ago
  I don't understand what effect it would have on bundle sizes? If you are going to transpile/bundle your assets, you're probably using webasm at some point...or not!? And nobody forces you to have typed minified JS in your bundles?
  - Matheus28 4y ago
    But if you're already transpiling/bundling your assets, why not use typescript? Instead of bloating the language and browsers even more. Not only that, but solidifying an interface there. Once it's done, it'll be very hard to change, as people will rely on all sorts of quirky behaviors.
- hardwaregeek 4y ago
  By that same logic, comments are inflating the bundle size. Both can be stripped out using a minifier or bundler.
- Matheus28 4y ago
  footnote: Looking at my phone's browser history, I read the article at https://tc39.es/proposal-type-annotations https://tc39.es/proposal-type-annotations when making this comment. Not the github repo. I hadn't dove too deep into it, but it does seem that it specifies a syntax for the top level type declaration. I initially believed it was entirely unspecified what the contents between the : and = were. But it does try to specify some rules, but leaving anything inside a {}, [], <> and such completely unspecified. My feelings are still the same in that I don't support the proposal.
asddubs 4y ago
I don't want this. I want real types, that are checked and throw errors, or are at least coerced on being passed into/out of methods (preferably the former) If you don't want to take the performance hit of type checks, you can still check and then remove type annotations during bundling. Having this would just mean that we will never ever ever get actual static typing in javascript, so it's actually worse than doing nothing.
- jmisavage 4y ago
  We almost had it with JavaScript 2/ECMAScript 4, but Microsoft and Google killed it. One because they didn’t want to update their JS engine and the other had just released v8. Adobe implemented it as ActionScript 3 and Firefox had most of it done too. Everything since then has been about incrementally add similar features into the existing code base without fixing the foundation.
  - lstamour 4y ago
    Okay, but also at the same time we had XHTML with strict errors that would crash the webpage. As a result, nobody used it or wanted it in practical, messy, real world code. Since that backtrack, the Internet has always been about displaying something at all times. Adding types to JavaScript and hard failing when they’re incorrect is not a JavaScript anyone wants to publish. We’d rather have the forgiving but messy JavaScript than the one that stops a webpage from working when it gets a different data shape from a JSON endpoint due to runtime checks. Nobody actually wants runtime checks on the web unless you’ve a way to opt in to them. And guess what? You could. There’s nothing stopping you from writing a compiler that adds runtime checks to your code. In fact, that’s pretty much what code generators do for typescript when they create validation functions to make writing or working with APIs a bit easier.
    - asddubs 4y ago
      adding type annotations to your code is opting in. if you don't want it, you can leave them out, or have them be removed during bundling. what's the point of having annotations that do nothing?
ash_gti 4y ago
https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/ https://devblogs.microsoft.com/typescript/a-proposal-for-typ... Has additional context on this proposal and has previously been linked here.
syspec 4y ago
> One can explicitly specify the type arguments of a generic function invocation or generic class instantiation in TypeScript. // TypeScript add<number>(4, 5) new Point<bigint>(4n, 5n) > The above syntax is already valid JavaScript that users may rely on, so we cannot use this syntax as-is. We expect some form of new syntax that could be used to resolve this ambiguity. No specific solution is proposed at this point of time, but one example option is to use a syntactic prefix such as : // Types Annotations - example syntax solution add::<number>(4, 5) new Point::<bigint>(4n, 5n) > These type arguments (::<type>) would be ignored by the JavaScript runtime. It would be reasonable for this non-ambiguous syntax to be adopted in TypeScript as well. ---- Hmm I didn't know this, so I tried it myself in Chrome's console... sure enough it works... new DOMPoint<Number>(4,5) Given that the above works in the browser, what exactly is it doing? I've never seen angle brackets used that way in vanilla JS code
- Matheus28 4y ago
  ((new DOMPoint) < Number) > (4,5) Comma operator makes (4,5) = 5
- methyl 4y ago
  It just evaluates to false, as this is just two comparison operations. It's easier to comprehend if add a parentheses around first operation as such: (new DOMPoint < Number) > (4, 5) (new DOMPoint < Number) evaluates to true and it becomes (true) > (4, 5). Because (foo, bar, baz) syntax always evaluates the last item, we can finally simplify it into (true > 5), which surely enough in Javascript evaluates to false.
- evan_ 4y ago
  It's just less than/greater than: https://astexplorer.net/#/gist/b0dff7bdaf1d8f9024fe18fda70a9a11/084c148af609421337fbfb94977f8352448600a7 https://astexplorer.net/#/gist/b0dff7bdaf1d8f9024fe18fda70a9...
- colejohnson66 4y ago
  IMHO, the "turbofish" syntax (popularized by Rust) is ugly and should not be used. The reasoning of syntax ambiguity is also a lame one because C# manages just fine without it. But to then say that: > The above syntax is already valid JavaScript that users may rely on, so we cannot use this syntax as-is. What users would be using said syntax? Why would one compare a function to a type? If we're making a backwards incompatible change, just say that `func < type` is a syntax error unless immediately followed by the rest of a call. IMO, in any spec committee, if a naysayer says that "someone may be using that syntax", they should be required to prove it. Prove that someone is comparing a function to be less than a type, and why they'd do such a thing. Honestly, I don't see how this can be done in a backwards compatible way short of type annotations in comments. Just rip the bandaid off and have WHATWG say that TypeScript is a valid runtime and allow `<script src="..." type="typescript">`. Deno manages to have a TypeScript runtime just fine.
polskibus 4y ago
Just merge with Typescript already and reduce the complexity of the ecosystem. If someone does not want types they can just ‘any’ everything.
- dymk 4y ago
  Adding (even a simplified version of) the Typescript typesystem to the Javascript spec is probably a bad idea. It's all the weird little complexities of Typescript that make it flexible enough to add types to most JS code. Javascript as an untyped build target is fine. I'm opposed to adding (ignored) type hints to Javascript because they'd just end up rebuilding Typescript, but done poorly.
- frou_dh 4y ago
  TypeScript doesn't have a language specification so there's nothing to merge. If you tell browser vendor X that they need to start supporting TypeScript, what does that mean?
  - neysofu 4y ago
    I wouldn't hold the lack of a natural language specification against Typescript. Canonical open-source implementations work just as well in practice and tend to become de-facto standards: Microsoft's compiler is effectively a human- and computer-readable specification.
  - Existenceblinks 4y ago
    I can't come up with reason why you got downvote. This is a fundamental and basic thing on designing type. I'm afraid to comment "merge what?" (genuine question)
- cyral 4y ago
  Or enable implicit any which makes it just like JS with optional types.
codedokode 4y ago
> The sunsetting of IE11 and the rise of evergreen browsers that implement the latest JavaScript standard means that developers can once again run standard JavaScript code without transpilation. This is a wrong assumption. There are lot of smartphones that do not get updates and have browsers that can be several years old. Therefore transpiling and polyfills are not going away anywhere soon. Of course, supporting different browsers can insignificantly increase development costs. It might be impractical to try to support Internet Explorer 7. A safe and reasonable choice would be to make sure that site looks and works perfectly in any browser released 5 years ago and is usable in a 10-year old browsers. Obviously there are cases when this rule can be amended, for example, if you are making a game requiring a fast GPU and a mouse, then you can ignore smartphones and old browsers. But for a general website, like a corporate website, an online store, a social network, this seems like a sane default choice. You can extend support to 12-15 years old browsers if you feel confident in your skills.
- asddubs 4y ago
  I think it doesn't really matter one way or the other, anyway. Even if it takes 10 years to proliferate, at some point in the future, it'll be 10 years from now, and we'll be able to use it. depending on your usecase, maybe sooner.
- laurencerowe 4y ago
  I still expect most people would bundle and minify the code shipped in production but removing the requirement to setup a transpiler for development would be a huge win for developer ergonomics. For many smaller projects that bundling step may then simply be `deno bundle index.js` or similar.
alexfromapex 4y ago
Calling it now, there will be a flame war over type systems
spion 4y ago
I'm not sure this will help solve any of our problems. Theoretically, there would be no more need for compilation tools after this change is implemented. In practice, lambdas need to be bundled, frontends still need to be bundled and running typescript in node efficiently nowadays should be as easy as `node -r @swc-node/register path/to/file.ts` So this will actually not ease the JavaScript tooling nightmare.
- brundolf 4y ago
  Transpiling and bundling are two separate things. Removing the need for one of those would have benefits even if the other were still there That said, I'm not convinced this would actually remove one of them: - It would mean shipping more code which is a no-no - It probably won't ever cover the whole of typescript's features, so many people will continue to use that, and will still have to transpile I'm sure this will help... somebody, but it's going to be a very narrow set of workflows that benefit
  - klodolph 4y ago
    This makes both irrelevant, since you can already run code without bundling. Obviously it’s not something you’d do in a normal production environment. It’s nice to be able to run code without any compilation steps if you’re working on something small (e.g. some demo on my personal website) or something in a development environment. I’ve done this. Served up JS with “import” statements everywhere. The devserver just served JS straight from the filesystem without modification. When I change the JS, the browser just needs to reload—there’s no build process, no waiting. The production environment ran it all through Closure. Closure also ran in the dev environment, but it ran asynchronously, in the background, telling you what the errors are. No source maps to deal with. No delays. The browser gets exactly what I write.
    - brundolf 4y ago
      Sure, it's just that very few companies are probably going to be doing this outside of very early prototypes/toy examples. Load time is just too important
yakshaving_jgt 4y ago
Looks like programmers wish their favourite language would adopt their new favourite feature right after they've just learned how to use it. Sure, it makes the language you use more sophisticated, but at the cost of raising the bar for everyone else to learn that language. To continuously add features and complexity to JavaScript makes getting started with web development that much more cruel and arduous for our more junior colleagues. If you like types (and personally — as someone who for the past several years has almost exclusively written Haskell and Elm professionally — I do), why not just pick a different language that has the features you want and compile it down to JavaScript? I have a perception (and I'm sure some would argue it's inaccurate) of the web development community that likes to pat itself on the back for being smart enough to use JavaScript's [relatively] new spread operator, but at the same time whinging about Elm because its syntax looks weird.
- frou_dh 4y ago
  > the web development community that likes to pat itself on the back for being smart enough to use JavaScript's [relatively] new spread operator, but at the same time whinging about Elm because its syntax looks weird. It's probably more like that meme image from some TV show: Elm user: I feel bad for you. Enthusiastic JS/TS user: I don't think about you at all.
  - tialaramex 4y ago
    It's from "Mad Men" the TV show about a US advertising agency, initially on Madison Avenue in New York (hence "Mad Men" from both "Mad[ison avenue]" and "Ad[vertising]"). Don Draper the show's main protagonist dismissed the "I feel bad for you" comment by a minor character this way. Because Don is the protagonist the audience knows how they're expected to feel about that.
    - azemetre 4y ago
      In the context of the episode Don Draper spent the entire episode thinking about the minor character constantly. When he says the line in the elevator we know it’s absolutely not true, especially when the character was asking Draper why he hates him; Draper makes the remark to be more hateful because the character has been occupying his mind for days. Always funny to see “memes” evolve outside the original context.
cphoover 4y ago
Nahhhh lets get the immutable data structures (record + tuples) proposal to land, this one is of much more value IMO https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple
- deleted 4y ago
  [deleted]
- andreineculau 4y ago
  This 100!
- rektide 4y ago
  This is zero-sum thinking. I don't think there's huge value in playing "me first!" games.
  - cphoover 4y ago
    I don't think there is value in type hints that don't do anything. Especially because JS is sent over the wire. We already have a compile time type checking system called Typescript. If you want JavaScript to enforce types in the browser that is a larger discussion.
    - rektide 4y ago
      JS build pipelines are an industrialized software shithole, & we're starting to look like the other worst offenders (python). relief is needed. js was, for decades, simple & easy & sparked joy. it can again. this proposal potentially liberates & eases enormous pains. it also means we dont have armies of projects downcompiling to es2015 (unperformant) and/or cjs.
      - cphoover 4y ago
        > js was, for decades, simple & easy & sparked joy. This is total revisionism. Using JS to program anything substantial was a total nightmare in decades past. I've been building websites since the early 2000s, JS is more ergonomic and capable now than ever before IMO.
rektide 4y ago
Trying to ease development burdens & generate more intercompatible ways of doing things, with less lift required to get going, while retaining the same benefits of types for those who want them, is 100% a superb & worthy idea. It's great to see such developer-friendly compatibility & adaptability. Top level comments so far (I have skipped two top level comments): "I don't want this." "I'm not sure this will help solve any of our problems." "Sounds like a bad idea" "Nahhhh lets get the [non-type related foobar] proposal to land" "This is a wrong assumption." "Just merge with Typescript already" "there will be a flame war" Mercy! Be happy!
- asddubs 4y ago
  browsers are very conservative about breaking changes. javascript features that allow for loose and questionable usage is the thing that got us into this mess in the first place. once this is out there, there will be code using it in the most incorrect way it can get away with, and no one will want to break that code later on. that's why it's not just important that we get "something", but we get it right.
  - rektide 4y ago
    > javascript features that allow for loose and questionable usage is the thing that got us into this mess in the first place. And what "mess" is this? Again I think my previous advice is pretty on point: "Be happy!" Everything has only gotten better, from my perspective. That TypeScript exists & has grown up is yet more proof that incremental, ongoing, progressive advancement is amazing. I think if we'd tried to make everything all at once, it would have been a disaster. > once this is out there, there will be code using it in the most incorrect way it can get away with, and no one will want to break that code later on. This is a spec to let various typechecks be applied, but doesn't specify any specific type-system. I have a hard time visualizing whatever scary situation it is you are imagining. This seems low risk.
    - yakshaving_jgt 4y ago
      > Everything has only gotten better, from my perspective. Would you accept the idea that the language has actually gotten worse? What would it take to convince you?
klodolph 4y ago
I love this. Maybe it means that I don’t have to preprocess / compile TypeScript before running it. This is a genuine win for me. The TypeScript compiler can continue doing what it does best—type checking—and then I can just run the code. Running the TypeScript compiler from a cold start takes a surprisingly long amount of time. Currently, I have to figure out how to get a build system that compiles TypeScript once for bundling to the browser and once for running in Node, and the user experience around setting this up is just incredibly bad. It sucks. I make some change to how I build for browser and it turns out to be incompatible with whatever system I am using for Node. This solves part of that problem, and reduces friction. Type annotations can be just part of the JS and stripped out by minification.
- bavell 4y ago
  This is the reason I don't use the typescript compiler and instead use babel to strip the types out completely on compilation. I use vs-code's built-in type checking when coding in dev and then throw out types in prod. Fast dev builds and still get all the type checking I want. Optionally you can run the full blown typescript compiler as part of CI/CD if you want to ensure no errors or warnings hit prod.
  - IshKebab 4y ago
    That "optionally" is going to bite you in the arse as soon as you have more than one person working on the project.
- redox99 4y ago
  I don't see what the issue is. For backend node, you simply edit a couple of lines in the package.json to use ts-node during dev, and run tsc for shipping builds (a bit more performant than ts-node). For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it. And if you do everything manually, considering you still need to setup babel, webpack etc, it makes almost no difference. It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either.
E2EEd 4y ago
This article is on the hn front page but disappears for this account "E2EEd".
- deleted 4y ago
  [deleted]
- pvg 4y ago
  You might have hit 'hide' on it, take a look at https://news.ycombinator.com/hidden https://news.ycombinator.com/hidden when logged in
  - E2EEd 4y ago
    Yes, that is it, thanks.
j3schmidt 4y ago
- pplongway 4y ago
Existenceblinks 4y ago
I think the first thing in design to have sane (sound) type is to separate effects from pure stuff. Browser engine is complex but API shouldn't be, right? It would be great if those compile-to-js lang authors folks also get involved. (those ML based and some others)
- golergka 4y ago
  This proposal doesn't include any actual type-checking. It would make various type checking annotations valid no-ops in JS, nothing more.
  - Existenceblinks 4y ago
    Yeah I also have another comment https://news.ycombinator.com/item?id=31673288 https://news.ycombinator.com/item?id=31673288 about chance to do something different.
steen_hansen 4y ago
Hey I got an idea, let's ignore a better solution like Closure.spec's runtime type checking. Its even like "functional", you can turn it on or off at will, it can even do regular expression tests to validate string parameters. I partially copied it for Javascript, https://www.npmjs.com/package/type-czech https://www.npmjs.com/package/type-czech, it even runs in JsFiddle https://jsfiddle.net/steen_hansen/1Lshcept/?Example-Contents https://jsfiddle.net/steen_hansen/1Lshcept/?Example-Contents
- Existenceblinks 4y ago
  Or make Webassembly text extensible then we could have something like https://github.com/carp-lang/Carp/blob/master/docs/LanguageGuide.md https://github.com/carp-lang/Carp/blob/master/docs/LanguageG...
- Matheus28 4y ago
  That sounds awfully inefficient
rubyfan 4y ago
Am I the only one that thinks annotations are a code smell?
- codedokode 4y ago
  Isn't reverse engineering a code with annotations much easier than without them? And reverse engineering the code often takes significant time in large projects.
- recursive 4y ago
  Probably not, but I've never heard of that before. And nor can I think of an argument for why that might be the case.
- azemetre 4y ago
  Can you expand what you mean? IME self documenting code is a myth.
olliej 4y ago
Oh, we're finally talking about reinstating the syntax that gave us `for(of)`
cphoover 4y ago
Everyone talking about how much this would simplify their workflow from going from development with type-checking to the browser ignores that you can run a single command and remove all type annotations already... I'm not sure what this proposal solves? Perhaps there should be an added item to vscode context menu that is "copy without type annotations". I feel this would be very easy to implement...
- awhitty 4y ago
  Folks who write JavaScript today might not remember a time when it was normal to write JS and ship the same files verbatim to end users. We’ve seen a Cambrian explosion of new syntax, new tools, and new ways to build applications using JavaScript in the last decade. Many of those features are now built into modern browsers, but static typing is one of the last Big New Ideas that hasn’t made it into mainline JavaScript. We’re conditioned to expect there will be a compilation step between our source code and the code that runs in a browser. That forces many decisions about how we structure our projects and the kinds of tools we can use to deliver the software we write. Minimizing or eliminating the reasons why folks might need that build-the-code step between the code they write and the code their users run opens up doors and new ways of writing and delivering software, and that’s exciting! Think, for instance, what would it take to get something like the TypeScript type checker in Chrome’s devtools? A first step would be to adopt the type annotation syntax.
  - deleted 4y ago
    [deleted]
  - 8n4vidtmkvmk 4y ago
    even if we add types to js... minification, dead code elimination, and even precomputing or other performance optimizations will still require a compiler. not sure what typechecking inside chrome would add.... maybe it could be used for faster js execution like how asm.js works
  - cphoover 4y ago
    I dunno I think there is a lot of historical revisionism happening in regards to how joyous coding in JavaScript used to be. I've been doing web-dev since the early 2000's, JavaScript is way more usable today than it's ever been in the past.
leni536 4y ago
Could browsers potentially use the annotations as optimization hints for their JIT compiler?
captainmuon 4y ago
I feel that is unneccessary, because if I want type annotations, then I can just use TypeScript. Although adding them in Python didn't hurt and was a net win I would say. But I'm not sure how feasible it is, because you want backwards compatibility with JS, and if you have to preprocess anyway to remove the annotations, why not use TS proper. But I like it for another reason. The single most frustrating thing for me in JS is the lack of operator overloading. Matrix operations become so ugly if you can't use infix operators. If you do complex graphical calculations it is really important that the calculations remain readable. Custom operators and operator overloading require type-dependent dispatch. The types could be known at compile time in TS. But the developers will not add any such feature, unless JS has it. One of a few prerequisites seems to be that JS gets type annotations! But honestly it seems I would have to wait until JS becomes TS, before we can overload operators. Maybe it is more realistic to add this via babel or so.
MarquesMa 4y ago
I would say it would be great to merge with TypeScript. It would greatly reduce the need of those crazy building tools nowadays. Now we have HTTP2, if only we can write and serve a bunch of TypeScript files directly. Be it browser, Node.js or Deno, you could use the same script file without setting up M*N different webpack.whatever.config.js files. And it will also open up the possibility of optional runtime type checking which JavaScript as a glue language really needs. TypeScript has been very cautious about adding non-JavaScript features, and kept its promise on JavaScript compatible, so I don't see big problems merging them. It's just people will need to figure out a spec to formalize the type system for TypeScript. The only risk is there might be clash of the communities. But it also might get us great results where the whole community working on a great project together.
nikolay 4y ago
Given sufficient time, every language becomes Java, and every format becomes XML.

129 points by rglover 4y ago

Immediate reaction is that this is a bad idea. Seems like it would result in a weird Frankenstein language that is neither fish nor fowl. The lack of prior art for this type of approach is particularly concerning.

runarberg 4y ago
Isn’t Python type annotation also ignored during runtime and left for third party tools to check? I would consider that prior art.
- padjo 4y ago
  From the proposal: > The proposal here differs significantly from Python's types, as the types in this proposal are entirely ignored, not evaluated as expressions or accessible at runtime as metadata. So guess sorta prior art but quite different. Reading the TC39 minutes for this proposal makes me think it’s highly unlikely that the approach as outlined here will go anywhere.

Matheus28 4y ago

Sounds like a bad idea. I get it that not specifying type syntax makes it the most flexible, but also prevents any actual checks and optimizations from being performed by the browser. So it’s just inflating bundle sizes for no reason. Might as well run them through something that checks then removes type annotations… which is what we already have

lagrange77 4y ago
> So it’s just inflating bundle sizes for no reason. When using a bundler, it will be trivial to remove the annotations in the build process. Using a TypeScript transpiler in that process is also trivial you might say. But static typing syntax and tooling as part of the language itself is the way to go imo.
- Matheus28 4y ago
  >But static typing syntax and tooling as part of the language itself is the way to go imo. But if the typing syntax is essentially just comments in very specific places... what advantage does it bring? Sure one can use tools to interpret those comments and check types... but at that point, isn't just using typescript tooling much superior (interface declaration, type declarations, etc. not just a type between : and =)? I will confess that I am guilty of having used JSDoc comments for quick and dirty .js scripts that I didn't want to grab the tsc compiler for, but still wanted vscode to check my types. But even being one of the likely users of this proposal, I feel that it's needlessly bloating the language.
  - lagrange77 4y ago
    > what advantage does it bring? The advantage would be, that static typing is part of the language. Don't you find it odd to use another language just for a missing language feature? For me it feels somewhat hacky and '// temp. solution!!! fix soon!'-worthy.
    - Matheus28 4y ago
      But with this proposal, static typing wouldn't be part of the language. It's just a fancy looking comment. No different than using JSDoc with a nicer syntax
      - lagrange77 4y ago
        Ok agreed, i would also like to have the type checker build into the language as well. But in the end, this is a scripting language. Maybe it's not too bad to not enforce it being typed, but provide a baseline to have it being typed optionally, in form of an 'official' annotation syntax. But i'm thinking out loud now.
        Matheus28 4y ago
        I just think it'd overcomplicate implementations. We already have typescript and such, and they work perfectly. It's my personal belief that integrating those things into the language would slow innovation.
jupp0r 4y ago
It would be great to be able to have access to types at runtime in order to change behavior based on types. That would make TypeScript so much more useful but it does require javascript support.
- Matheus28 4y ago
  You should try decorators for that. They're pretty decent
  - jupp0r 4y ago
    Yeah it's a workaround, but not really ergonomical for the library author (for example they can't modify the type being decorated).
- mixedCase 4y ago
  You can use a runtime type system like io-ts or something like reflect-metadata. Let's not pay the cost when we don't need it.
  - jupp0r 4y ago
    The compiler knows when this is used and can only insert type metadata when needed. io-ts and reflect-metadata are unwieldy crutches compared to a type system that's designed to influence runtime behavior (ie Rust, C++, etc).
    - rektide 4y ago
      https://github.com/tc39/proposal-decorator-metadata https://github.com/tc39/proposal-decorator-metadata is where we'd probably need to begin to store this information. It's still need a transpiler to generate the necessary decorators. Decorators are still in progress (but kind of seemingly shaping up these days).
cookiengineer 4y ago
I don't understand what effect it would have on bundle sizes? If you are going to transpile/bundle your assets, you're probably using webasm at some point...or not!? And nobody forces you to have typed minified JS in your bundles?
- Matheus28 4y ago
  But if you're already transpiling/bundling your assets, why not use typescript? Instead of bloating the language and browsers even more. Not only that, but solidifying an interface there. Once it's done, it'll be very hard to change, as people will rely on all sorts of quirky behaviors.
hardwaregeek 4y ago
By that same logic, comments are inflating the bundle size. Both can be stripped out using a minifier or bundler.
Matheus28 4y ago
footnote: Looking at my phone's browser history, I read the article at https://tc39.es/proposal-type-annotations https://tc39.es/proposal-type-annotations when making this comment. Not the github repo. I hadn't dove too deep into it, but it does seem that it specifies a syntax for the top level type declaration. I initially believed it was entirely unspecified what the contents between the : and = were. But it does try to specify some rules, but leaving anything inside a {}, [], <> and such completely unspecified. My feelings are still the same in that I don't support the proposal.

asddubs 4y ago

I don't want this. I want real types, that are checked and throw errors, or are at least coerced on being passed into/out of methods (preferably the former) If you don't want to take the performance hit of type checks, you can still check and then remove type annotations during bundling. Having this would just mean that we will never ever ever get actual static typing in javascript, so it's actually worse than doing nothing.

jmisavage 4y ago
We almost had it with JavaScript 2/ECMAScript 4, but Microsoft and Google killed it. One because they didn’t want to update their JS engine and the other had just released v8. Adobe implemented it as ActionScript 3 and Firefox had most of it done too. Everything since then has been about incrementally add similar features into the existing code base without fixing the foundation.
- lstamour 4y ago
  Okay, but also at the same time we had XHTML with strict errors that would crash the webpage. As a result, nobody used it or wanted it in practical, messy, real world code. Since that backtrack, the Internet has always been about displaying something at all times. Adding types to JavaScript and hard failing when they’re incorrect is not a JavaScript anyone wants to publish. We’d rather have the forgiving but messy JavaScript than the one that stops a webpage from working when it gets a different data shape from a JSON endpoint due to runtime checks. Nobody actually wants runtime checks on the web unless you’ve a way to opt in to them. And guess what? You could. There’s nothing stopping you from writing a compiler that adds runtime checks to your code. In fact, that’s pretty much what code generators do for typescript when they create validation functions to make writing or working with APIs a bit easier.
  - asddubs 4y ago
    adding type annotations to your code is opting in. if you don't want it, you can leave them out, or have them be removed during bundling. what's the point of having annotations that do nothing?

ash_gti 4y ago

https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/ https://devblogs.microsoft.com/typescript/a-proposal-for-typ... Has additional context on this proposal and has previously been linked here.

syspec 4y ago

> One can explicitly specify the type arguments of a generic function invocation or generic class instantiation in TypeScript. // TypeScript add<number>(4, 5) new Point<bigint>(4n, 5n) > The above syntax is already valid JavaScript that users may rely on, so we cannot use this syntax as-is. We expect some form of new syntax that could be used to resolve this ambiguity. No specific solution is proposed at this point of time, but one example option is to use a syntactic prefix such as : // Types Annotations - example syntax solution add::<number>(4, 5) new Point::<bigint>(4n, 5n) > These type arguments (::<type>) would be ignored by the JavaScript runtime. It would be reasonable for this non-ambiguous syntax to be adopted in TypeScript as well. ---- Hmm I didn't know this, so I tried it myself in Chrome's console... sure enough it works... new DOMPoint<Number>(4,5) Given that the above works in the browser, what exactly is it doing? I've never seen angle brackets used that way in vanilla JS code

Matheus28 4y ago
((new DOMPoint) < Number) > (4,5) Comma operator makes (4,5) = 5
methyl 4y ago
It just evaluates to false, as this is just two comparison operations. It's easier to comprehend if add a parentheses around first operation as such: (new DOMPoint < Number) > (4, 5) (new DOMPoint < Number) evaluates to true and it becomes (true) > (4, 5). Because (foo, bar, baz) syntax always evaluates the last item, we can finally simplify it into (true > 5), which surely enough in Javascript evaluates to false.
evan_ 4y ago
It's just less than/greater than: https://astexplorer.net/#/gist/b0dff7bdaf1d8f9024fe18fda70a9a11/084c148af609421337fbfb94977f8352448600a7 https://astexplorer.net/#/gist/b0dff7bdaf1d8f9024fe18fda70a9...
colejohnson66 4y ago
IMHO, the "turbofish" syntax (popularized by Rust) is ugly and should not be used. The reasoning of syntax ambiguity is also a lame one because C# manages just fine without it. But to then say that: > The above syntax is already valid JavaScript that users may rely on, so we cannot use this syntax as-is. What users would be using said syntax? Why would one compare a function to a type? If we're making a backwards incompatible change, just say that `func < type` is a syntax error unless immediately followed by the rest of a call. IMO, in any spec committee, if a naysayer says that "someone may be using that syntax", they should be required to prove it. Prove that someone is comparing a function to be less than a type, and why they'd do such a thing. Honestly, I don't see how this can be done in a backwards compatible way short of type annotations in comments. Just rip the bandaid off and have WHATWG say that TypeScript is a valid runtime and allow `<script src="..." type="typescript">`. Deno manages to have a TypeScript runtime just fine.

polskibus 4y ago

Just merge with Typescript already and reduce the complexity of the ecosystem. If someone does not want types they can just ‘any’ everything.

dymk 4y ago
Adding (even a simplified version of) the Typescript typesystem to the Javascript spec is probably a bad idea. It's all the weird little complexities of Typescript that make it flexible enough to add types to most JS code. Javascript as an untyped build target is fine. I'm opposed to adding (ignored) type hints to Javascript because they'd just end up rebuilding Typescript, but done poorly.
frou_dh 4y ago
TypeScript doesn't have a language specification so there's nothing to merge. If you tell browser vendor X that they need to start supporting TypeScript, what does that mean?
- neysofu 4y ago
  I wouldn't hold the lack of a natural language specification against Typescript. Canonical open-source implementations work just as well in practice and tend to become de-facto standards: Microsoft's compiler is effectively a human- and computer-readable specification.
- Existenceblinks 4y ago
  I can't come up with reason why you got downvote. This is a fundamental and basic thing on designing type. I'm afraid to comment "merge what?" (genuine question)
cyral 4y ago
Or enable implicit any which makes it just like JS with optional types.

codedokode 4y ago

> The sunsetting of IE11 and the rise of evergreen browsers that implement the latest JavaScript standard means that developers can once again run standard JavaScript code without transpilation. This is a wrong assumption. There are lot of smartphones that do not get updates and have browsers that can be several years old. Therefore transpiling and polyfills are not going away anywhere soon. Of course, supporting different browsers can insignificantly increase development costs. It might be impractical to try to support Internet Explorer 7. A safe and reasonable choice would be to make sure that site looks and works perfectly in any browser released 5 years ago and is usable in a 10-year old browsers. Obviously there are cases when this rule can be amended, for example, if you are making a game requiring a fast GPU and a mouse, then you can ignore smartphones and old browsers. But for a general website, like a corporate website, an online store, a social network, this seems like a sane default choice. You can extend support to 12-15 years old browsers if you feel confident in your skills.

asddubs 4y ago
I think it doesn't really matter one way or the other, anyway. Even if it takes 10 years to proliferate, at some point in the future, it'll be 10 years from now, and we'll be able to use it. depending on your usecase, maybe sooner.
laurencerowe 4y ago
I still expect most people would bundle and minify the code shipped in production but removing the requirement to setup a transpiler for development would be a huge win for developer ergonomics. For many smaller projects that bundling step may then simply be `deno bundle index.js` or similar.

alexfromapex 4y ago

Calling it now, there will be a flame war over type systems

spion 4y ago

I'm not sure this will help solve any of our problems. Theoretically, there would be no more need for compilation tools after this change is implemented. In practice, lambdas need to be bundled, frontends still need to be bundled and running typescript in node efficiently nowadays should be as easy as `node -r @swc-node/register path/to/file.ts` So this will actually not ease the JavaScript tooling nightmare.

brundolf 4y ago
Transpiling and bundling are two separate things. Removing the need for one of those would have benefits even if the other were still there That said, I'm not convinced this would actually remove one of them: - It would mean shipping more code which is a no-no - It probably won't ever cover the whole of typescript's features, so many people will continue to use that, and will still have to transpile I'm sure this will help... somebody, but it's going to be a very narrow set of workflows that benefit
- klodolph 4y ago
  This makes both irrelevant, since you can already run code without bundling. Obviously it’s not something you’d do in a normal production environment. It’s nice to be able to run code without any compilation steps if you’re working on something small (e.g. some demo on my personal website) or something in a development environment. I’ve done this. Served up JS with “import” statements everywhere. The devserver just served JS straight from the filesystem without modification. When I change the JS, the browser just needs to reload—there’s no build process, no waiting. The production environment ran it all through Closure. Closure also ran in the dev environment, but it ran asynchronously, in the background, telling you what the errors are. No source maps to deal with. No delays. The browser gets exactly what I write.
  - brundolf 4y ago
    Sure, it's just that very few companies are probably going to be doing this outside of very early prototypes/toy examples. Load time is just too important

yakshaving_jgt 4y ago

Looks like programmers wish their favourite language would adopt their new favourite feature right after they've just learned how to use it. Sure, it makes the language you use more sophisticated, but at the cost of raising the bar for everyone else to learn that language. To continuously add features and complexity to JavaScript makes getting started with web development that much more cruel and arduous for our more junior colleagues. If you like types (and personally — as someone who for the past several years has almost exclusively written Haskell and Elm professionally — I do), why not just pick a different language that has the features you want and compile it down to JavaScript? I have a perception (and I'm sure some would argue it's inaccurate) of the web development community that likes to pat itself on the back for being smart enough to use JavaScript's [relatively] new spread operator, but at the same time whinging about Elm because its syntax looks weird.

frou_dh 4y ago
> the web development community that likes to pat itself on the back for being smart enough to use JavaScript's [relatively] new spread operator, but at the same time whinging about Elm because its syntax looks weird. It's probably more like that meme image from some TV show: Elm user: I feel bad for you. Enthusiastic JS/TS user: I don't think about you at all.
- tialaramex 4y ago
  It's from "Mad Men" the TV show about a US advertising agency, initially on Madison Avenue in New York (hence "Mad Men" from both "Mad[ison avenue]" and "Ad[vertising]"). Don Draper the show's main protagonist dismissed the "I feel bad for you" comment by a minor character this way. Because Don is the protagonist the audience knows how they're expected to feel about that.
  - azemetre 4y ago
    In the context of the episode Don Draper spent the entire episode thinking about the minor character constantly. When he says the line in the elevator we know it’s absolutely not true, especially when the character was asking Draper why he hates him; Draper makes the remark to be more hateful because the character has been occupying his mind for days. Always funny to see “memes” evolve outside the original context.

cphoover 4y ago

Nahhhh lets get the immutable data structures (record + tuples) proposal to land, this one is of much more value IMO https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple

deleted 4y ago
[deleted]
andreineculau 4y ago
This 100!
rektide 4y ago
This is zero-sum thinking. I don't think there's huge value in playing "me first!" games.
- cphoover 4y ago
  I don't think there is value in type hints that don't do anything. Especially because JS is sent over the wire. We already have a compile time type checking system called Typescript. If you want JavaScript to enforce types in the browser that is a larger discussion.
  - rektide 4y ago
    JS build pipelines are an industrialized software shithole, & we're starting to look like the other worst offenders (python). relief is needed. js was, for decades, simple & easy & sparked joy. it can again. this proposal potentially liberates & eases enormous pains. it also means we dont have armies of projects downcompiling to es2015 (unperformant) and/or cjs.
    - cphoover 4y ago
      > js was, for decades, simple & easy & sparked joy. This is total revisionism. Using JS to program anything substantial was a total nightmare in decades past. I've been building websites since the early 2000s, JS is more ergonomic and capable now than ever before IMO.

rektide 4y ago

Trying to ease development burdens & generate more intercompatible ways of doing things, with less lift required to get going, while retaining the same benefits of types for those who want them, is 100% a superb & worthy idea. It's great to see such developer-friendly compatibility & adaptability. Top level comments so far (I have skipped two top level comments): "I don't want this." "I'm not sure this will help solve any of our problems." "Sounds like a bad idea" "Nahhhh lets get the [non-type related foobar] proposal to land" "This is a wrong assumption." "Just merge with Typescript already" "there will be a flame war" Mercy! Be happy!

asddubs 4y ago
browsers are very conservative about breaking changes. javascript features that allow for loose and questionable usage is the thing that got us into this mess in the first place. once this is out there, there will be code using it in the most incorrect way it can get away with, and no one will want to break that code later on. that's why it's not just important that we get "something", but we get it right.
- rektide 4y ago
  > javascript features that allow for loose and questionable usage is the thing that got us into this mess in the first place. And what "mess" is this? Again I think my previous advice is pretty on point: "Be happy!" Everything has only gotten better, from my perspective. That TypeScript exists & has grown up is yet more proof that incremental, ongoing, progressive advancement is amazing. I think if we'd tried to make everything all at once, it would have been a disaster. > once this is out there, there will be code using it in the most incorrect way it can get away with, and no one will want to break that code later on. This is a spec to let various typechecks be applied, but doesn't specify any specific type-system. I have a hard time visualizing whatever scary situation it is you are imagining. This seems low risk.
  - yakshaving_jgt 4y ago
    > Everything has only gotten better, from my perspective. Would you accept the idea that the language has actually gotten worse? What would it take to convince you?

klodolph 4y ago

I love this. Maybe it means that I don’t have to preprocess / compile TypeScript before running it. This is a genuine win for me. The TypeScript compiler can continue doing what it does best—type checking—and then I can just run the code. Running the TypeScript compiler from a cold start takes a surprisingly long amount of time. Currently, I have to figure out how to get a build system that compiles TypeScript once for bundling to the browser and once for running in Node, and the user experience around setting this up is just incredibly bad. It sucks. I make some change to how I build for browser and it turns out to be incompatible with whatever system I am using for Node. This solves part of that problem, and reduces friction. Type annotations can be just part of the JS and stripped out by minification.

bavell 4y ago
This is the reason I don't use the typescript compiler and instead use babel to strip the types out completely on compilation. I use vs-code's built-in type checking when coding in dev and then throw out types in prod. Fast dev builds and still get all the type checking I want. Optionally you can run the full blown typescript compiler as part of CI/CD if you want to ensure no errors or warnings hit prod.
- IshKebab 4y ago
  That "optionally" is going to bite you in the arse as soon as you have more than one person working on the project.
redox99 4y ago
I don't see what the issue is. For backend node, you simply edit a couple of lines in the package.json to use ts-node during dev, and run tsc for shipping builds (a bit more performant than ts-node). For frontend usually you literally don't configure anything, Next.JS, CRA, or whatever already comes with typescript preconfigured if you select it. And if you do everything manually, considering you still need to setup babel, webpack etc, it makes almost no difference. It seems quite extreme modifying javascript for this considering you still would want to remove types in order to reduce bundle size, and you would still need the actual compiler because you have things such as enums, annotations and more that JS doesn't support either.

E2EEd 4y ago

This article is on the hn front page but disappears for this account "E2EEd".

deleted 4y ago
[deleted]
pvg 4y ago
You might have hit 'hide' on it, take a look at https://news.ycombinator.com/hidden https://news.ycombinator.com/hidden when logged in
- E2EEd 4y ago
  Yes, that is it, thanks.

j3schmidt 4y ago

pplongway 4y ago

Existenceblinks 4y ago

I think the first thing in design to have sane (sound) type is to separate effects from pure stuff. Browser engine is complex but API shouldn't be, right? It would be great if those compile-to-js lang authors folks also get involved. (those ML based and some others)

golergka 4y ago
This proposal doesn't include any actual type-checking. It would make various type checking annotations valid no-ops in JS, nothing more.
- Existenceblinks 4y ago
  Yeah I also have another comment https://news.ycombinator.com/item?id=31673288 https://news.ycombinator.com/item?id=31673288 about chance to do something different.

steen_hansen 4y ago

Hey I got an idea, let's ignore a better solution like Closure.spec's runtime type checking. Its even like "functional", you can turn it on or off at will, it can even do regular expression tests to validate string parameters. I partially copied it for Javascript, https://www.npmjs.com/package/type-czech https://www.npmjs.com/package/type-czech, it even runs in JsFiddle https://jsfiddle.net/steen_hansen/1Lshcept/?Example-Contents https://jsfiddle.net/steen_hansen/1Lshcept/?Example-Contents

Existenceblinks 4y ago
Or make Webassembly text extensible then we could have something like https://github.com/carp-lang/Carp/blob/master/docs/LanguageGuide.md https://github.com/carp-lang/Carp/blob/master/docs/LanguageG...
Matheus28 4y ago
That sounds awfully inefficient

rubyfan 4y ago

Am I the only one that thinks annotations are a code smell?

codedokode 4y ago
Isn't reverse engineering a code with annotations much easier than without them? And reverse engineering the code often takes significant time in large projects.
recursive 4y ago
Probably not, but I've never heard of that before. And nor can I think of an argument for why that might be the case.
azemetre 4y ago
Can you expand what you mean? IME self documenting code is a myth.

olliej 4y ago

Oh, we're finally talking about reinstating the syntax that gave us `for(of)`

cphoover 4y ago

Everyone talking about how much this would simplify their workflow from going from development with type-checking to the browser ignores that you can run a single command and remove all type annotations already... I'm not sure what this proposal solves? Perhaps there should be an added item to vscode context menu that is "copy without type annotations". I feel this would be very easy to implement...

awhitty 4y ago
Folks who write JavaScript today might not remember a time when it was normal to write JS and ship the same files verbatim to end users. We’ve seen a Cambrian explosion of new syntax, new tools, and new ways to build applications using JavaScript in the last decade. Many of those features are now built into modern browsers, but static typing is one of the last Big New Ideas that hasn’t made it into mainline JavaScript. We’re conditioned to expect there will be a compilation step between our source code and the code that runs in a browser. That forces many decisions about how we structure our projects and the kinds of tools we can use to deliver the software we write. Minimizing or eliminating the reasons why folks might need that build-the-code step between the code they write and the code their users run opens up doors and new ways of writing and delivering software, and that’s exciting! Think, for instance, what would it take to get something like the TypeScript type checker in Chrome’s devtools? A first step would be to adopt the type annotation syntax.
- deleted 4y ago
  [deleted]
- 8n4vidtmkvmk 4y ago
  even if we add types to js... minification, dead code elimination, and even precomputing or other performance optimizations will still require a compiler. not sure what typechecking inside chrome would add.... maybe it could be used for faster js execution like how asm.js works
- cphoover 4y ago
  I dunno I think there is a lot of historical revisionism happening in regards to how joyous coding in JavaScript used to be. I've been doing web-dev since the early 2000's, JavaScript is way more usable today than it's ever been in the past.

leni536 4y ago

Could browsers potentially use the annotations as optimization hints for their JIT compiler?

captainmuon 4y ago

I feel that is unneccessary, because if I want type annotations, then I can just use TypeScript. Although adding them in Python didn't hurt and was a net win I would say. But I'm not sure how feasible it is, because you want backwards compatibility with JS, and if you have to preprocess anyway to remove the annotations, why not use TS proper. But I like it for another reason. The single most frustrating thing for me in JS is the lack of operator overloading. Matrix operations become so ugly if you can't use infix operators. If you do complex graphical calculations it is really important that the calculations remain readable. Custom operators and operator overloading require type-dependent dispatch. The types could be known at compile time in TS. But the developers will not add any such feature, unless JS has it. One of a few prerequisites seems to be that JS gets type annotations! But honestly it seems I would have to wait until JS becomes TS, before we can overload operators. Maybe it is more realistic to add this via babel or so.

MarquesMa 4y ago

I would say it would be great to merge with TypeScript. It would greatly reduce the need of those crazy building tools nowadays. Now we have HTTP2, if only we can write and serve a bunch of TypeScript files directly. Be it browser, Node.js or Deno, you could use the same script file without setting up M*N different webpack.whatever.config.js files. And it will also open up the possibility of optional runtime type checking which JavaScript as a glue language really needs. TypeScript has been very cautious about adding non-JavaScript features, and kept its promise on JavaScript compatible, so I don't see big problems merging them. It's just people will need to figure out a spec to formalize the type system for TypeScript. The only risk is there might be clash of the communities. But it also might get us great results where the whole community working on a great project together.

nikolay 4y ago

Given sufficient time, every language becomes Java, and every format becomes XML.