[dlbucci]

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.

[vbezhenar]

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.

[olliej]

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.

[skybrian]

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.

[olliej]

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.

[johnny22]

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?

[laurencerowe]

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.

[niedzielski]

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.