I'd be very surprised if this has never been floated before, so I'm slightly trying to invoke Cunningham's law by presenting this as an "idea":
What if ecmascript could run typescript directly?
This would simplify a huge number of build setups. Type checking could still be done by tsc/the typescript library, but for runtimes that supported it, there'd be no need for: source maps or call stack modification, complex dependency tracking in monorepos just to be able to build things, declaration maps, worrying about destination directories differing from source at runtime, etc. etc.
Similarly to how babel is now able to parse typescript without validating the types, could the js engine be taught to parse the type annotations and just throw them out, then run the code without them? tsc would effectively become a lint task.
I'm not really expecting anyone to say "cool, good idea, we'll do that next week" but I'd be interested to find out if it's already been considered. It seems like it's not that much of a stretch beyond all the es modules syntax, as long as the actual type checking is out of scope. The annotations could be thought of in the same way as comments. The syntax is valid/interpretable, but has no effect at runtime.
Yeah, I guess I phrased it wrong. I'm curious if there's any interest on this side. If, hypothetically, typescript had a full formal spec, would this team be open to incorporating a subset of it? Specifically, to make things easier, the subset of just the syntax - type annotations, generics, type/infer/extends/keyof/as/is/asserts keywords etc. without any of the type checking requirements.
I've just looked at the latest typescript spec and it's apparently archived. The hypothetical still stands though - and maybe it could be a motivator for the ts team to unarchive and start maintaining the spec, since that'd be a prerequisite.
An existing, officially supported, way for projects to benefit from TypeScript without requiring a build step is to write JavaScript and add the type-information using a mix of '.d.ts' files and the JSDoc syntax that TS supports
I've used this on a few (small) projects and really liked the experience.
This stage 0 proposal might be of interest. It is pretty close to what you're describing: an approved syntax for type annotations, treated like comments by the engine.
I see this introduces interface as a declaration syntax, enabling parsing and ignoring it. How would this work for structures with a more complicated transpilation story like enum, which have runtime representations and lead to the creation of values? What about other "pluggable type systems" that require more of these, e.g. a trait {}?
While static type checking is a nice draw, one benefit of having typed JavaScript which surprising to me does not often seem to be brought up is the potential for near-native performance. AssemblyScript allows compilation of TypeScript into WebAssembly but it should be awfully nice to have a standard syntax which JavaScript engines from Node to the browser themselves could interpret out of the box (and hopefully without the current browser WebAssembly limitation of requiring loading by regular JavaScript).
While it would still require a good deal of specification, and some might not like it since it wouldn't be as likely to be as terse as TypeScript, one alternative path to bringing types to JavaScript (for the sake of static type checking and near-native performance), and one which perhaps standardizers could more easily stomach, would be through formalizing JSDoc annotations.
This would have the not-readily-dismissed benefits of:
Allowing users not familiar with TypeScript to carry on with their regular JavaScript, while others could submit JSDoc annotations without so much concern by the main coders that these other parties were corrupting the code.
Readers of the code could ignore the type annotations (or hide them automatically within IDEs). (Note that JSDoc need not be limited to functions. Where function annotations are not actually sufficient to allow intuiting of inline types, inline JSDoc annotations (like /** @type ... */ are also possible. Tools like eslint-plugin-jsdoc could, moreover, be used to help enforce that functions as well as any type-ambiguous structures be properly annotated, including project preferences to insist that less precise number types not be used, e.g., "number" could be "64-bit float" by default, but projects could prevent use of "number" to ensure more performant precision is enforced.)
Allowing progressive enhancement (until ready for the script attribute and/or 'use strict'-like directive which triggered type-awareness) which still worked in conventional JavaScript-only environments.
Unlike alternative comment-based annotating proposals, one could get a single standard syntax which is already pretty well-used among those using annotations.
JSDoc would need to be enhanced to take into account some TypeScript innovations, e.g., perhaps an equivalent to tsconfig.json, loading of declaration files (which could just type @typedef files if not blessing .d.ts files), and import() within JSDoc types.
But the great benefits for allowing the web to gain easy-to-read type awareness (and type awareness that doesn't clutter the main code), with an easier path for regular users, would be hard, I think, to overestimate.
This has been brought up since before ES4. Last I checked spec complexity (the number of changes required) and additional parsing complexity (possibly slowing down load times) are the primary concerns and makes it controversial/low priority. I have some notes here on types if you're interested in this direction though. Also there are no current champions that support adding static typing to ECMAScript. (There's only one champion - that I know of - that said they'd help iron out issues).
Personally I think waiting and handling these topics later is ideal. As computing power increases worries about potential parsing complexity will go away. Also in a few years they might run out of high priority proposals and have time to reconsider types. I mostly just keep an eye on proposals that use grammar rules that might make clean static typing syntax impossible, like this one.
that assumes statically-typed languages will remain relevant in application-level programming 10 years from now.
the reality of past 10 years has been as computing power increases, beginner-friendly dynamic-languages have steadily replaced static-languages in application-space.
Sure, but I'm speaking specifically about the reduction of effort needed to spec makers and parsers to allow plain old JavaScript work without needing TypeScript--just some JSDoc which was as minimal as required to provide the types.
Yeah, I wish I could edit old posts. When I wrote execute typescript directly I really just meant make let s: string = 'foo'; console.log(s) be valid (or "executable") code roughly equivalent to let s/* string */ = 'foo'; console.log(s).