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.
> And the only reason to make that step optional, is to not run it, which is a worse experience.
Yeah, but it's an optional "worse" experience.
IOW, for those people who think it's a better experience (because there is no build step), they can opt into it. For those who think it's a worse experience, they can continue using a build-step.
Nothing changes for those who want a build-step.
(I agree about the standards process thing)
> 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.
If TS is compiled in the browser, then it can be compiled to WASM, not to JS.
It's only when TS is compiled on the server that it has to be compiled to JS.
If the browser support TS natively, the compilation target would not be JS (which is what makes the resulting code slow), but either WASM, or naive code.
> a better experience (because there is no build step)
I feel like the way to make both of us happy is to just strip type annotations, rather than doing full type checking in the browser. Which, luckily, is already making its way through the standards track: https://tc39.es/proposal-type-annotations/
> If the browser support TS natively, the compilation target would not be JS (which is what makes the resulting code slow), but either WASM, or naive code.
I was not talking about compiling it to JS; I seem to recall that native support wouldn't necessarily result in big performance improvements. (Consider that JS is also not being compiled to JS.)
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.