If you don't want to take the performance hit of type checks, you can still check and then remove type annotations during bundling. Having this would just mean that we will never ever ever get actual static typing in javascript, so it's actually worse than doing nothing.
Since that backtrack, the Internet has always been about displaying something at all times.
Adding types to JavaScript and hard failing when they’re incorrect is not a JavaScript anyone wants to publish. We’d rather have the forgiving but messy JavaScript than the one that stops a webpage from working when it gets a different data shape from a JSON endpoint due to runtime checks.
Nobody actually wants runtime checks on the web unless you’ve a way to opt in to them. And guess what? You could. There’s nothing stopping you from writing a compiler that adds runtime checks to your code. In fact, that’s pretty much what code generators do for typescript when they create validation functions to make writing or working with APIs a bit easier.
By allowing but ignoring types, you get the best of both worlds - optional type checking and runtime compatibility - without further compilation.
Frankly I think of this feature as a Node.JS feature and a reduce-duplication feature. You can store and run the same TS syntax in a file with a .JS extension.
Today, I often find TypeScript samples that I copy into JS projects and then have to painfully remove the TypeScript bits to get it to run. This fixes that. Your IDE can benefit from reading the types and tell you about errors - that’s where you can fix them anyway.
If you want <script lang="TypeScript" … /> to work, with compile type checks and everything, that’s a different feature?
Why should javascript add syntax just to make users of another language more comfortable?
>Today, I often find TypeScript samples that I copy into JS projects and then have to painfully remove the TypeScript bits to get it to run. This fixes that.
The purpose of typescript is to be compiled into javascript, it isn't meant to be run in a browser. If you're going to use it, use it properly, otherwise, "picking out the typescript bits" makes about as much sense as "picking out the C#" parts of some .NET code to run it in a C compiler.
Type annotations in a language that don't actually annotate types for an interpreter of that language literally do nothing. Might as well just use the existing comment formats to do the same thing, and be more syntactically explicit:
function foo(bar /*TS:int*/, baz /*TS:int*/)What we’re talking about, though, is the reason the ES6 arrow syntax exists. And it’s not just because of “this” binding. It’s because JS developers are lazy. What you’re suggesting is extra characters. And clutter.
These days if you pick a JS project or dependency and try to ignore the ones written in TypeScript, you’ll be left with very, very few viable alternatives. Do JS-only projects exist? Yes. Plenty. But the number of modern JS-only projects are far outnumbered by the number of TS projects, and the discrepancy is only going to grow over time.
What’s sealed the deal was TypeScript adhering as much as possible to JS standards and not inventing new runtime conventions and weird syntax. When they made that pivot, to a JS + types approach, that was genius. It helped everyone remind themselves that TS was JS with types, and not something different like Dart.
Taking this another direction, the power of TypeScript has been its ability to evolve as a language without breaking JS compatibility. If you bake types into JS, you risk breaking compatibility with some improvements to the type system. By keeping types out of the runtime, only the developer toolchain needs to worry what version of Typescript might be required to build a particular package. We don’t have to invent a way of marking some scripts as v3 and others as v4 TS.
Until now, JS has been largely future-compatible while TS has rapidly evolved and occasionally broken existing code. It’s of course possible to add types to JS, but are we convinced we have a perfect type system to do so now, or could it not wait and evolve a bit first?
We can always make a backwards-compatible language change later, such as a syntax to turn on or turn off runtime checks.
ECMAScript 4 was canceled for a whole host of reasons. Trying to blame browser vendors is just bonkers. The standard made too many changes all at once and existing work on implementations had progressed too far.
We can’t change the past. Unfortunately we are reinventing a lot of what was done in that early work, but now with some strange syntax because of compatibility with dead features or 3rd party libraries that picked up the slack. At least we finally have a standard for importing packages…again.
JS engines could do the same!
Let's start with the first steps: getting the information.
or only warn.
i don't think anyone would consider turning it on by default everywhere. this seems like an extreme non-issue.
There's nothing I see in this proposal to prevent a user-agent from running a static analysis on JavaScript input into the console or DOM editor before trying to interpret it. If what you're saying you want is for the typechecking to be done by the user-agent for every piece of downloaded JavaScript... Why? I mean, a user-agent could be constructed to do that, but it'd be inefficient over just trusting the vended code (which, in a sense, we should probably just default to doing, because nothing stops the developer from type-asserting or omitting types so in the grand scheme of things, the code is exactly as provably sound if we typecheck it before running as if we don't).
What would "actual static typing in JavaScript" look like that this proposal isn't?
I want the browser to reject feeding a string into a number parameter of a function, at which point it does this isn't important to me as much as that it should be more than just a comment that is ignored completely.
There would absolutely have to be an escape hatch, or configuring one's browser in this way would make most of the web fail to work (and unfortunately, the golden rule for features in browsers is "if it breaks most existing sites, you can't add it because most users aren't savvy enough to understand what is happening and will uninstall your browser in response"). But I can't actually see anything stopping a given user agent from choosing to offer that as a development feature for a specific domain, which would be pretty swell.
I think we will never have enforced static typing in Javascript, because of legacy code.
The solution is to use something higher level. Maybe Elm.
If you don't want to this, you can still build your own real types, that's the beauty of JS.