ECMAScript Proposal: Types as Comments

https://github.com/giltayar/proposal-types-as-comments

by 0xedb • 4 years ago

65 36 4 years ago

github.com

sergiomattei• 4 years ago

Dumb question incoming… Why not formalize TypeScript into the ECMAScript spec?

nick_• 4 years ago

If only the ECMAScript/JavaScript community were this sensible.

dham• 4 years ago

Why does Javascript have to have all of Typescript brought into it? The browser has supported multiple scripting languages before. Not unprecedented.

krapp• 4 years ago

Unfortunately, the HTML5 spec dropped the language option for the script tag, so browsers will only ever natively support javascript now and in the future. We're not going to get multiple languages back until something like runtime embedding through WASM becomes commonplace.

ByteJockey• 4 years ago

Google controls JS to the point of being able to ignore the spec (e.g. that time they left TCO behind an experimental flag and it just went away despite being in the spec).

As long as node and chrome are so dominant, we're probably not going to see big shake-ups in JS that aren't driven by Google themselves.

JS is flexible, you can cover up a lot with polyfills, but not completely different syntax. Doing that without Google's buy in would create a rift in the internet that would either end with browser specific web pages, or with the complete loss of power for the committee that sets the ECMAScript spec as JS officially goes from being a language that is defined by a spec to a language defined by a canonical implementation (in this case V8).

LudwigNagasena• 4 years ago

Yeah, isn't TypeScript without enums and decorators already kind of "types as comments"?

city41• 4 years ago

TypeScript does support JSDoc type annotations and will use them to validate types in a JS project.

https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

hombre_fatal2• 4 years ago

Some FAQ items address this:

https://github.com/giltayar/proposal-types-as-comments#why-n...

Various good reasons, like how it would hinder TS evolution and you'd end up having to compile TS to whatever older version of TS the slowest implementors support anyways.

But one interesting point is that type analysis is for the developer's benefit. What is the imagined benefit and behavior of pushing type analysis over the wire with the code to be run on the end-user's machine?

mekster3• 4 years ago

What is the imagined benefit and behavior of pushing type analysis over the wire with the code to be run on the end-user's machine?

Is that even a question?

If more people adopt TS because it's native in browsers, producing less bugs means more user satisfaction.

throw_m2393392• 4 years ago

This actually isn't dumb question.

Nothing precludes Typescript from becoming another ECMA spec. It's just not going to be ECMAScript.

Nothing precludes Microsoft from allowing Typescript to run directly in the browser either. Nothing. Just that nothing forces any other browser to support Typescript as well.

Nobody has to follow standards if they don't want to, in practice...

TazeTSchnitzel• 4 years ago

Ignoring the type declarations gives some freedom to type checkers to decide what meaning they have, but it also makes them useless to the runtime. I think that's a shame. Could JavaScript engines not benefit from the type information? PHP does.

olliej4• 4 years ago

JS engines would not benefit significantly from the annotations (there may be some slight wins in code density through coalesced checks, but there would be increases in other data structures). Explicit types in this case are primarily a tool to make writing large scale software easier.

But ignoring the types is actually worse than “not being helpful”, as it both locks in the current syntax (unlike claims it does provide space for experimentation), and it means that engines cannot in future start enforcing the types specified with this syntax.

mattlondon• 4 years ago

Why go to the effort of doing all of this, but not use typescript? I don't see the point - they mention ignoring the build step, but it's not like that is particularly annoying at the moment, at least not in the largish-projects I've worked on (enterprise angular apps staffed by approx 50-60 frontend engineers, so fairly chunky codebase)

zapt02• 4 years ago

Most apps are not staffed by 50-60 frontend engineers, so simplifying for solo devs (which is by definition the majority of developers) is worthwhile.

vinnymac• 4 years ago

Most applications are certainly not staffed by large teams, but the advantages would be best seen in large codebases. Most solo developers are working on much smaller TypeScript codebases, and won't experience many issues with the build system.

TypeScript is the main language that I program in every day, and I don't see the advantages of this proposal outweighing the disadvantages.

mekster3• 4 years ago

I would think the opposite. Solo devs are in the most flexible state and they don't care if they need to go through a bit of inconvenience for a slight boon to code quality but say you got several average devs who can only be taught on how to do these things, it gets annoying to set it all up and make sure nothing breaks or you'll be wasting time babysitting their environment.

pwdisswordfish9• 4 years ago

Indeed. In fact, I wouldn’t mind if the build step were made mandatory, with the form of the code that browsers interpret decoupled from the one that programmers write, so that the former may evolve at a much slower rate without constraining developers too much.

Of course, that would defeat the whole purpose of the ever-continuing TC39 standardization process, so it’s not going to happen.

dlbucci• 4 years ago

This topic came up earlier this week, and I just don't see what the big win is. I guess people want to be able to skip setting up a build system for TypeScript, but if you do that, you'll be sending a bunch of extra junk to browsers that will just be ignored. So you'll need to setup a minifier to strip it all out, which means you have to setup a build system anyway.

Is there some other advantage? Easier debugging on the client, I guess, but proper source maps do that pretty well already. I dunno, this just seems to be making a complex language more complex for not much gain.

That said, if the runtime actually used the types for safety or performance, I could maybe see some value added there.

niedzielski• 4 years ago

I wondered about this as well but speculated that basic compression, either gzip or Brotli, would account for it and, in the case that someone doesn't care about bundling their code, they probably don't care if it has comments (types) in it. If they do care about bundling, even if that is just `cat`, then I think the code is "built" to some extent already.

I would enjoy the flexibility to ship types but personally don't have any need for it. Seems like "boiling the frog" for type-checking in the browsers to me but I personally like the idea of encouraging more typing in native JavaScript.

vbezhenar• 4 years ago

Browser could build optional type support (for example with warnings), so you can leverage it and skip all packaging stuff.

And sending few percent of JavaScript is not an issue. It's gzipped well and it's not what will slow down the website.

For example I really love that I can just write modern JavaScript and just send it to the browser and it works.

Serious websites of course will use minifiers and stuff, but for some small sites it's unnecessary burden.

olliej4• 4 years ago

No they can’t.

The effect of unenforced type annotations is that sites will end up writing code that is incorrect but works.

Any future attempt to enforce the types will break that content, and so cannot reuse the : syntax for type annotations, but browsers will continue to have to support it.

Mode switches are also not the solution: strict mode is responsible for a huge amount of complexity in the ES spec, and many annoying edge cases in JS implementations. The only reason I was ok with strict mode is the removal of |this| coercion, which could only be done via a mode switch. No other changes in strict mode would have warranted the mode switch.

Adding type annotations to JS would not require a mode switch as it is a purely additive feature (as let and for(of) were), but adding the burden of the syntax without actually adding the semantics makes absolutely no sense - it burns the prefer type annotations syntax, it adds complexity to the language, complexity to the engines, and provides no actual improvements to the ergonomics of the language.

laurencerowe• 4 years ago

Not needing to set up a build system for development is a huge reduction in complexity for smaller projects.

Bundling then becomes an optional step that can be implemented for a production build. If it's only JavaScript then a simple `deno bundle index.ts` without any configuration should suffice.

orangepanda• 4 years ago

This proposal doesnt support the full typescript syntax, you'll need a build step anyway. What problem does it solve?

w3news• 4 years ago

No, you don't need a build system, but most developers cannot work anymore without a build system. And what about node.js, it's a lot better to skip a build step.

I think typescript is a temp hype just like jQuery, useful for many, but a few people can just do the vanilla JavaScript way.

throw_m2393392• 4 years ago

It solves absolutely nothing for the people who do not use Typescript.

montroser• 4 years ago

Previous discussion: https://news.ycombinator.com/item?id=30626458

olliej4• 4 years ago

Is this the same bad idea from MS earlier this week, or is it a completely different spec of the same bad idea?

There are many reasons this concept of “unenforced type syntax” is flawed, and from the threads for the MS proposal there are already JS consoles/CLIs that support TS.

0xCAP• 4 years ago

This feels completely unneeded and a huge step backwards. Sure, TypeScript's language server is slow af, and making it better is no easy task, but TypeScript's syntax and overall language mechanics are the best I've ever used and I'm not trading them for whatever DX improvement this stuff promises to bring.

ECMAScript Proposal: Types as Comments

Related Stories