yeah, exactly. So I wonder if ultimately they want to have the browser handle transpiling things like typescript? And I definitely think there are other concerns (such as linting) that you want to happen as part of your development pipeline.
There is an ES39 proposal to allow type annotations in Javascript, that would allow the browser to handle TS/Flow files without needing a compile step:
(That's only to allow the type annotations to be there, not to have static checking in the browser)
IMO: I would love to see this implemented. Linting and typechecking should be ran before committing code or deploying, but I want to be able to stop transpiling/bundling in all cases.
that sounds needlessly wasteful. You can trivially strip TS out of JS before sending off to the client. You're still going to need to check TS in the build/CI step (i.e. the time consuming part) before doing anything so you've gained exactly nothing.
"You can trivially strip TS out of JS before sending off to the client"
To quote you, that sounds needlessly wasteful to me. Also I prefer not needing to deal with SourceMaps or different source when debugging. So it's quite the contrary: I gain a lot. Different strokes for different folks.
I understand your reasoning but it seems to be focused more around developer time rather than bundle size and user experience if I am not mistaken.
The ratio between built code size and source size can easily reach orders of magnitude in TypeScript projects with exhaustive types.
Sending all that code to the user is wasteful, and this wastefulness is multiplied by X end users, as opposed to the development process which is centralized.
From a money perspective the picture is different of course.
I would still love to be able to execute TS directly in the browser, but this is purely a DX thing.
I feel like this is what everyone actually wants. Typescript in the browser (at least for me personally) would be awesome, and if they made TS into a separate language with its own runtime, that would be like the holy grail.
