What does HackerNews think of proposal-type-annotations?

> You don't get typescript to the browser without them

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

the comparison doesn't make sense. typescript inherently has advantages over javascript (well, unless Javascript officially supports types which isn't happening anytime soon (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.

And this kind of type syntax is under consideration in TC39 https://github.com/tc39/proposal-type-annotations

You're mixing a couple of ideas. There is a proposal[1] to allow for type annotations in the browser but it's only a subset of what's possible in TS. As for barreling/bundling, that's never been a goal for TypeScript. That's handled by tools like Webpack and ESBuild. In fact, there's an effort going the opposite direction. As browsers support ES style modules, we don't need to bundle anymore as the browser will load the relevant files as needed

[1] https://github.com/tc39/proposal-type-annotations

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

The biggest hurdle to using TypeScript is the build step before it can actually be run. If the type annotation TC39 [0] comes to pass this would be largely taken care of; _hype_ waxes. (unfortunately the proposal has been stagnant for more than a year now)

A lot of the new frontend codebases involve a build step before running. For such codebases, TypeScript's build hurdle has already been overcome.

[0] https://github.com/tc39/proposal-type-annotations

This is great but -if I dare - wouldn't it be time to allow js to have type annotations [1] ? As in python, treat it as comments for now but with real syntax and let interesting dialects emerge from the consensus ? I like jsdoc but the syntax is urgh.

[1] https://github.com/tc39/proposal-type-annotations

If you're happy with a single bundled file, another option is:

    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...

https://github.com/tc39/proposal-type-annotations

I think it's the right solution, though I get that it confuses people. Given that the compiler only erases static type annotations, it should not touch the imports.

> 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

Typescript for a while has focused on Stage 3 and Stage 4 proposals, so its "core elements" are almost all already in the language.

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.)

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:

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 wonder how far fetched it would be to have just the syntax of Typescript on the browser without type-checking. We'd have to use tsc locally only for the typechecking, without the need of a build process, but that would be enough for me.

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

>TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript".

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.

[0]https://github.com/tc39/proposal-type-annotations

Regarding iv), I disagree that one should not expect this to happen. There's a stage 1 ES proposal for allowing TS-like syntax in the browser: https://github.com/tc39/proposal-type-annotations So there's good reason to believe this may actually happen in the next couple of years.

> If browser vendors bundled tsc or its equivalent then we'd both be stoked.

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.

Map is in JS: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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?

> I even don't understand why browser don't start to work on supporting it directly

https://github.com/tc39/proposal-type-annotations

> There's no native typescript runtime.

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.

[1] https://github.com/tc39/proposal-type-annotations