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.<p>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.<p>That said, if the runtime actually used the types for safety or performance, I could maybe see some value added there.
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)
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.
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.
Is this the same bad idea from MS earlier this week, or is it a completely different spec of the same bad idea?<p>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.