ECMAScript Proposal: Types as Comments | Hacker News Reader

ECMAScript Proposal: Types as Comments

github.com

65 points0xedb36 comments

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.

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.

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.

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.

Browsers won't enforce the types (which seems to be a non-goal) but build systems and package managers could. Debuggers could warn about type errors when you're using them, maybe?

The types aren't for end users.

Why would you add a type system to the language and then not use it?

You just advocated for developers using tool to validate the types, but that already exists in the form of typescript.

Warnings also don’t matter, as live sites don’t report debugger warning to the host servers (and even if they did they’re unlikely to be fixed).

The only reason to add the type syntax to js is if that type system is going to be enforced.

We don’t want another series of wat presentations about the bizarre JS type system, and we don’t want to add things to the language if there isn’t value in doing so.

The types are for end users insofar as they help ensure that the site operates correctly. Them not being enforced means that you also can’t be notified (through window.on error or whatever it is) that your site has a type bug in it.

Any type syntax added to the JS language must be able to pay for itself, and making it so you can paste some subset of typescript into the JS console is nowhere near justification.

Wasn't this approach the one taken by Python? I don't actually know, since I don't really keep up with Python.

If it was though, how well or poor is it working there?

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.

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)

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.

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.

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.

> they don't care if

Bold to speak for the group of devs likely to have the most variety. Personally I hate twiddling with build systems and will happily write worse code to avoid it so what I do know.

On my solo projects, I never care about JavaScript build infrastructure, it is all pure vanilaJS.

It feels so liberating not having to deal with the usual mess of JavaScript toolchains.

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.

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.

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.

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

If only the ECMAScript/JavaScript community were this sensible.

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

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.

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).

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

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...

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?

> 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.

Why would more people adopt TS because it's native in browsers, which won't enforce specifying type annotations anyway?

No compiling process = easier?

But how does the end-user care about static type analysis and why is it being done on their client? What exactly does this UX look like for them?

If you push TS source that you didn't bother tsc'ing on your machine because hey it runs on the client, does it simply fail to run for the user even though the program would have worked? I don't see how pushing TS source is better than pushing compiled JS.

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...

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.

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

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.

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

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

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.

Reply on news.ycombinator.com