What does HackerNews think of proposal-type-annotations?
ECMAScript proposal for type syntax that is erased - Stage 1
In the most literal sense of course you can: Typescript has its own compiler!
But more broadly it is a bummer that you need a build tool to use TypeScript. Fingers crossed the “Type annotations as comments” proposal happens: https://github.com/tc39/proposal-type-annotations
deno does not have any inherent advantages over node if they continue to support node functionality. I won't be surprised if package.json support is next. literally the purpose and sole advantage of deno was that they did not have node cruft. things like speed are not inherent advantages. it's true deno is written in rust, but node is basically v8, which has its own advantages.
[1] https://github.com/tc39/proposal-type-annotations
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
Once EcmaScript adopts optional static types or some kind of standardized type annotations [1] I will probably use those. At least in Node, where I have more control of the runtime version.
A lot of the new frontend codebases involve a build step before running. For such codebases, TypeScript's build hurdle has already been overcome.
deno bundle 'https://esm.sh/@observablehq/plot' > plot.js
My browser development workflow looks somewhat like the following:Imports / versions in importmap.json:
{
"imports": {
"plot": "https://esm.sh/@observablehq/[email protected]"
}
}
Code in app.js: import * as Plot from "plot";
const plot = Plot.rectY({length: 10000}, Plot.binX({y: "count"}, {x: Math.random})).plot();
const div = document.querySelector("#myplot");
div.append(plot);
For development use dev.html:
Then you can then bundle with: deno bundle --import-map=importmap.json app.js > bundle.js
And have as your prod.html:
Note that `deno bundle` is deprecated. You can almost replace it with esbuild but it currently lacks builtin support for import maps: deno run --allow-all https://deno.land/x/[email protected]/mod.js --bundle app.js --outfile=bundle.js. # errors, see: https://github.com/evanw/esbuild/issues/2230
I'm really looking forward to the ECMAScript proposal on Type Annotations making it into browsers some days as this would effectively unlock transpiler free typescript development, leaving just a simple optional bundling step for production.https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
> entire language is incompatible with a JS interpreter
If this proposal will ever be accepted, TS will be (in large parts) valid JS: https://github.com/tc39/proposal-type-annotations
Unless you mean the type annotations itself? The good news there is that there is a Stage 1 proposal to take the Python/Ruby approach of bringing them into the language: https://github.com/tc39/proposal-type-annotations
Were that to happen, that proposal doesn't apply any type checking semantics for the browsers themselves and you would still want a type checker, such as Typescript, to actually check the types that are annotated. (Just as you want to run Mypy or Sorbet, respectively, in the cases of Python/Ruby.)
https://github.com/tc39/proposal-type-annotations
(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.
I know there's JSDoc but the normal syntax is so much better.
EDIT: Looks like there's a proposal: https://github.com/tc39/proposal-type-annotations
That's another language. Javascript doesn't have type annotations - even the suggested addition of type annotation syntax to JS[0] doesn't actually do anything because it can't and still be Javascript. Javascript doesn't have enums. Javascript doesn't have interfaces. That 1% (although it's probably more than that) matters. If it can't run, unaltered, in a Javascript interpreter it isn't Javascript.
If you want to follow along, the proposal to allow type syntax to be part of JavaScript is here:
https://github.com/tc39/proposal-type-annotations
(To repeat Daniel, there is still a huge amount of work ahead)
Not exactly this, but there was a proposal that would allow for typescript type hints to be considered as normal JS syntax: (in the same way python PEP 484 – Type Hints are considered optional type hints)
https://github.com/tc39/proposal-type-annotations
Deno on the server side is pretty cool and uses https://swc.rs/ (Speedy Web Compiler) - doesn't take forever to start, but kinda implements typescript as if it was just a type annotations without the more in-depth actual type checking, so it is possible.
It doesn't matter how fast a type checker is at that point at runtime.
The only reason to bring back type checking at runtime would be if V8 et al ever also started using type hints as JIT hints and you want to triple check you are sending the right type hints and not accidentally stomping on your own runtime performance. (Which is intentionally not in that Stage 1 proposal mind you: no one is expecting runtime type hints in the near future.)
TypeScript is designed in such a way that type annotations can't influence the runtime behavior. This is unlike e.g. Haskell, where types can drive code generation. Happy to elaborate more if necessary.
This means that transpiling TypeScript to JavaScript consists merely of stripping the type annotations + transpiling some of the syntactic features that might not be supported by the target JS version.
The "Type Annotations" proposal (https://github.com/tc39/proposal-type-annotations), IIRC championed partly by the TS team, will allow type annotations with almost-TS-like-syntax in plain JavaScript, which will make the "stripping type annotations" step unnecessary. You would still use the TS tooling to actually type-check the code, though.
Which exact part of TS do you want to be built into browsers?
... as comments. Which superficially resemble the syntax of type hints but do nothing. Which has to be one of the worst language design decisions of all time.
A proposal was actually floated recently to grandfather in TypeScript-like annotations[1]. It would be ignored by the runtime and treated purely as a comment, and would be optional. This is what native runtime support for TypeScript would look like. Not sure if it will ever gain official support in the language though.
> it doesn't enforce types at runtime, only at build time
Runtime type "enforcement" is just your program breaking, for example "undefined is not a function". Well, I guess it isn't so simple, because JS does a lot of implicit type translation behind the scenes, like helpfully converting "123" to 123. It would be possible to "enforce" types at runtime by turning off that language feature in certain situations, but I don't think it will happen, for back-compat reasons.