zlacker

An important feature of TypeScript is identifying problems in your code before the user runs it, i.e. before a browser even comes into play.

>>Vinnl+(OP)
So? If supported natively by the browser the browser could compile it on download.

You'll still get all the strong typing without have to wait for it to run.

For example an error in a little used branch would cause an error before the branch even runs.

>>Vinnl+(OP)
No runtime type safety bites people often and in unexpected ways. It should just be standardized.

>>array_+Ia
Sure, but that's an orthogonal concern. That sounds more like a call to standardise Zod.

>>lelant+o2
So then the user gets a type error in their face instead of the page loading? That doesn't really sound better than the developer getting that error while writing the code, which is what TypeScript currently does.

>>Vinnl+hk
Not to mention the penalty of the browser having to re-execute the type checking every time the files aren't loaded from cache.

>>Vinnl+hk
> So then the user gets a type error in their face instead of the page loading?

The alternative is not "User sees no error", it's "user sees the error at runtime".

In which case, yeah, having the user see the type error is vastly preferable to having the user see a runtime JS error.

>>lelant+kQ
In my mind, the alternative is running TypeScript while writing and at build time. Type checking at runtime is at best redundant, and at worst an excuse to skip type checking and have it blow up in the users' face.

>>Vinnl+Jy4
> In my mind, the alternative is running TypeScript while writing and at build time.

Right now, sure.

But if TS is supported natively in the browser, wouldn't your editor highlight the errors as you type? In which case the chance of deploying a broken TS file to the browser is minimal - you'll have to go out of your way to do so, like writing the TS file in plain notepad.

To go even further, having TS supported in the browser does not mean that you are forced to abandon your build step(s). You are still free to run a build step that either:

1. Does the full compilation to JS, and that's what gets deployed.

or

2. Just lints the file, and has the original TS file deployed.

Nothing in "Native TS in the browser" enforces a no-build-step dev process; it just makes it optional.

There's also the fact that, if JS is no longer the target (either browser-byte-code or native-code will be the target), then type-checking can be improved even further because there will be no requirement to allow things purely due to JS compatibility.

Finally, there's an awfully large number of optimisations that can be done if JS is not the target and native-code is.

I'm not seeing any downside here.

>>lelant+gj8
Yeah that's kinda the point; you get all that, unless you don't run the build-step/in-editor dev process. And the only reason to make that step optional, is to not run it, which is a worse experience.

So I'm not necessarily saying it's a bad thing, it's just that I don't see the point. And given that there's the major downside of having to go through the standards process, both now and in the future, which will likely involve breaking changes and making it harder to update, I don't see it happening. (Edit: I should add that I do think the "types as comments" proposal makes sense. I do see the advantage of being able to run TS code without a build step. It's just the part where we'd throw an error in the user's face that I don't see providing value to anyone.)

I do think TC39 is progressive enough to be OK with changes to JS if those would allow TS to have more effective type checking (as long as they're backwards compatible, of course, which would also be the case if TS got incorporated into JS), so I don't think it's necessary for that.

Performance improvements enabled by optimisations would be nice, but I believe I heard that no major gains would be expected there, especially compared to something like WASM.