This won't give you any of the things you're hoping for. This will not remove the build step, which exists for 100 other reasons besides type checking. JSX anyone?
You show an example of "what types will look like". I'm sorry, but I don't think you've understood much of what's being proposed. No type syntax is proposed. This proposal only carves out a space for possible type syntax.
"Goodbye Typescript"? Most likely this headline is click bait. If you think this changes the status of Typescript at all, you don't understand what this feature is about.
The whole thing is pointless. Who is this for? Types are a developer feature - they should not be deployed. For developers, we already have tools you can set up in minutes. For end users, why would they want to spend time downloading and parsing dead code?
If you wanted to run Typescript in the browser, practically every sandbox/playground tool already does that - with type checking. If you want to actually write Typescript, you'll still need a compiler.
So what problem does this solve? For whom?
The proposal in its current form doesn't even allow all of Typescript. Just certain features. Which will make things even more inconsistent.
The only thing this feature will accomplish, is adding still more confusion and fragmentation to an already heavily encumbered platform.
This is another bad idea in a long, sad history of bad ideas. You won't get any of the things you think you will get, you will just get more problems. I wish you would all snap out of it.
This is what I don't understand about what's being proposed...as you say, types are for developers... so what are browsers going to do with this type information? How does baking in more for the browser to parse help anything?
Seems like we'd still require a build step to remove all the native typing in order to optimise things, much like how we use build steps to minify code, remove comments, etc. - which raises another point, a lot of comments are happy about no build step, but how exactly do they go about optimising their code for things such as minifiying or browser feature support? oh that's right... with a build step.
Seems the only benefit to having native types is you could technically develop without a build step (but you'll still need one for production) which is nice as long as you get a 1:1 output.
Even then, you couldn't develop without a build step - you would still need access to NPM packages, and most serious front-end work involves JSX. Practically every real world project uses loaders of some sort, for SASS, or CSS modules, etc. - almost no one writes vanilla CSS these days.
So no, there is literally no real world use case - not even for learning purposes, as that would raise the same problems this proposal claims to resolve. Not that anybody would open their DevTools console in the first place and expect to learn programming there - if you're a complete beginner, you're most likely starting out with CodeSandbox or StackBlitz etc. where you'd have full IDE and TypeScript support, with access to production grade development tools and features, loaders etc., with no effort and zero setup.
This idea isn't solving any real problem, for anyone.
I was working on a WebGPU, browser based engine for running Quake .map files and reading through the .pak data files. Not the compiled Quake maps, but the raw map editor files, without compilation. Now that real-time lighting is trivial, it would be nice to have near real-time feedback in CSG-based game editors.
It's temporarily shelved while I do some meat-space debugging... but it's a passion project.
I would love to be able to write TS that is just straight TypeScript, with no TSC compile step (because everyone has live language servers in their IDEs, these days), and use simple, straightforward, ESM to list dependencies... which solves a problem that most bundlers have, regarding splitting code between Workers.
At the moment, using Snowpack or Parcel to give me TS means wading through hell for being able to write Workers which import the same ESM libs as dependencies.
So it's either no TS and then don't need a bundler and everything but types works...
...or use Parcel, but then go through hell supporting ESM Workers which are supposed to load the same source files as dependencies, but not share the same instance of the module code...
...or hand-configure individual TS builds for each Worker entrypoint, and run all of those dev builds, or write a daemon to watch all of those sources and then rebuild all of them...
I have done dev, lead, architecture, dev-ops, etc, for really a lot of sites / apps for a lot of different clients with a lot of different needs. Yes, your case is true, there is no reason that production code should be shipped with comments or type annotations... but my case is also true. And while it is a long way from the typical React / React Native / Angular / Vue / Swift / Kotlin / etc, case, it's nonetheless still valid.
Not only that, but I would suggest that it would open the doors to easier support for more visual-based editors, closer to what the game industry gets to use, without the need to run multiple heavy build commands... that said, esbuild and the like have made strides to reduce those times, but all of the different types of packaging needs are still a headache, unless I have missed something in the past couple of years.
Even worst, I think this proposal just adds confusion (like you said) and delays the real debate about how to make JavaScript evolve so that it could actually support real runtime types, which should also be optional to preserve backward compatibility.
Yes, that is one of the big reasons this should be rejected. If this gets accepted, that essentially means JS can never have runtime types - because that would be a breaking change. 😣
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This won't give you any of the things you're hoping for. This will not remove the build step, which exists for 100 other reasons besides type checking. JSX anyone?
You show an example of "what types will look like". I'm sorry, but I don't think you've understood much of what's being proposed. No type syntax is proposed. This proposal only carves out a space for possible type syntax.
"Goodbye Typescript"? Most likely this headline is click bait. If you think this changes the status of Typescript at all, you don't understand what this feature is about.
The whole thing is pointless. Who is this for? Types are a developer feature - they should not be deployed. For developers, we already have tools you can set up in minutes. For end users, why would they want to spend time downloading and parsing dead code?
If you wanted to run Typescript in the browser, practically every sandbox/playground tool already does that - with type checking. If you want to actually write Typescript, you'll still need a compiler.
So what problem does this solve? For whom?
The proposal in its current form doesn't even allow all of Typescript. Just certain features. Which will make things even more inconsistent.
The only thing this feature will accomplish, is adding still more confusion and fragmentation to an already heavily encumbered platform.
This is another bad idea in a long, sad history of bad ideas. You won't get any of the things you think you will get, you will just get more problems. I wish you would all snap out of it.
This is what I don't understand about what's being proposed...as you say, types are for developers... so what are browsers going to do with this type information? How does baking in more for the browser to parse help anything?
Seems like we'd still require a build step to remove all the native typing in order to optimise things, much like how we use build steps to minify code, remove comments, etc. - which raises another point, a lot of comments are happy about no build step, but how exactly do they go about optimising their code for things such as minifiying or browser feature support? oh that's right... with a build step.
Seems the only benefit to having native types is you could technically develop without a build step (but you'll still need one for production) which is nice as long as you get a 1:1 output.
Even then, you couldn't develop without a build step - you would still need access to NPM packages, and most serious front-end work involves JSX. Practically every real world project uses loaders of some sort, for SASS, or CSS modules, etc. - almost no one writes vanilla CSS these days.
So no, there is literally no real world use case - not even for learning purposes, as that would raise the same problems this proposal claims to resolve. Not that anybody would open their DevTools console in the first place and expect to learn programming there - if you're a complete beginner, you're most likely starting out with CodeSandbox or StackBlitz etc. where you'd have full IDE and TypeScript support, with access to production grade development tools and features, loaders etc., with no effort and zero setup.
This idea isn't solving any real problem, for anyone.
It has no merit.
None.
I was working on a WebGPU, browser based engine for running Quake .map files and reading through the .pak data files. Not the compiled Quake maps, but the raw map editor files, without compilation. Now that real-time lighting is trivial, it would be nice to have near real-time feedback in CSG-based game editors.
It's temporarily shelved while I do some meat-space debugging... but it's a passion project.
I would love to be able to write TS that is just straight TypeScript, with no TSC compile step (because everyone has live language servers in their IDEs, these days), and use simple, straightforward, ESM to list dependencies... which solves a problem that most bundlers have, regarding splitting code between Workers.
At the moment, using Snowpack or Parcel to give me TS means wading through hell for being able to write Workers which import the same ESM libs as dependencies.
So it's either no TS and then don't need a bundler and everything but types works...
...or use Parcel, but then go through hell supporting ESM Workers which are supposed to load the same source files as dependencies, but not share the same instance of the module code...
...or hand-configure individual TS builds for each Worker entrypoint, and run all of those dev builds, or write a daemon to watch all of those sources and then rebuild all of them...
I have done dev, lead, architecture, dev-ops, etc, for really a lot of sites / apps for a lot of different clients with a lot of different needs. Yes, your case is true, there is no reason that production code should be shipped with comments or type annotations... but my case is also true. And while it is a long way from the typical React / React Native / Angular / Vue / Swift / Kotlin / etc, case, it's nonetheless still valid.
Not only that, but I would suggest that it would open the doors to easier support for more visual-based editors, closer to what the game industry gets to use, without the need to run multiple heavy build commands... that said, esbuild and the like have made strides to reduce those times, but all of the different types of packaging needs are still a headache, unless I have missed something in the past couple of years.
Even worst, I think this proposal just adds confusion (like you said) and delays the real debate about how to make JavaScript evolve so that it could actually support real runtime types, which should also be optional to preserve backward compatibility.
Yes, that is one of the big reasons this should be rejected. If this gets accepted, that essentially means JS can never have runtime types - because that would be a breaking change. 😣