8 ms·

Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I inpu

Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that... is there anything else on the horizon? [Edit: Nevermind: I went looking for the github issue about adding types as comments, and it turns out it's already supported by flow: https://flow.org/en/docs/types/comments/ https://flow.org/en/docs/types/comments/ - is there anything like this for TypeScript?]

_hardwaregeek 8y ago
TypeScript works with JSDoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...
- sephoric 8y ago
  Can confirm, have sometimes added /* * @type Foo */ above a type and VS Code assumed that type was Foo everywhere else in my project, as if I typed `foo: Foo` directly. Didn't even have TypeScript in the project itself, purely an IDE feature. Extremely well thought out and useful ecosystem.
- deleted 8y ago
  [deleted]
Vinnl 8y ago
Yes, TypeScript can do type checking on regular Javascript (annotated with comments) as well: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j...
lmm 8y ago
If you're using Babel for compatibility with particular browsers then that can already handle TypeScript. What distinction are you drawing between a compile step that "strips away the type annotations" and one that does something else - what else is it that you consider compiling TypeScript to include? I have to ask what you're trying to achieve here. Moving types into comments just gives people who build without your typechecker the chance to break your code.
- mrspeaker 8y ago
  The comment stripping is optional (just for saving bytes on download). The goal is moving away from Babel, and any other unnecessary transpiling steps. Now that JavaScript has (a semi-working) module system, I find my projects having fewer and fewer dot files and far fewer dependencies. If I can have a folder of plain JS that I know will work in a browser 20 years from now without having to resurrect an ancient/abandoned toolchain, then I'll do that!
  - lmm 8y ago
    Are you gonna hardcode all the HTML and CSS as well? I would expect resurrecting a 100% compatible toolchain for a mainstream source format 20 years from now will be easier than resurrecting a 100% compatible browser. Especially if that format is a stricter/less ambiguous one like typescript.
scrollaway 8y ago
> I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. That's what Typescript is. Type annotations don't change your code, they're stripped away by babel at compile time. In fact, by default, tsc does compile TS code which fails typechecking, into valid JS code (which will likely error when you use it at least in some circumstances, but can run just fine). Typescript is a clear superset of JS, so there's no actual logical changes or even syntactical changes done by the compiler. However, you may be confused by the often-used "compilation target" features of babel (and tsc), which is that you may write ES2018 code, target ES5, and have your ES2018 syntactical sugar be turned into ES5-compatible code. This is entirely opt-in, and not related to typescript (other than the fact that Typescript is always compatible with the latest ES spec, so you can use any legal ES2018 syntax in it). Hope that clears it up…
- dntrkv 8y ago
  This is where I see a big difference between Flow / TS. With Flow, the type annotations are just stripped away, none of your Flow code affects runtime code. This is not so with TS since you have things like Enums, which will be compiled into objects and are part of your runtime code.
  - RyanCavanaugh 8y ago
    If you write type annotations in TS, they're stripped away. If you write type annotations in Flow, they're stripped away. There's no difference. TS has some additional features which are purely optional that don't get purely stripped out, but you're not mandated to use them.
    - MehdiHK 8y ago
      Is there any compiler option or linter config that prevents the use of these extra features?
      - 8y ago
Jach 8y ago
Not exactly what you're asking, but a "third choice" in general to typed ECMAscript has been ActionScript. A quick google found a transpiler project, but it looks to be abandoned: https://github.com/Cleod9/as3js https://github.com/Cleod9/as3js Still, I once did Flex development (would compile to a SWF file, or with Adobe Air to a native executable). It was a pleasure -- so long as you used the Flex/Flash Builder IDE (which was itself built on top of Eclipse). Trying to develop in vim was harder, though mainly because of the MXML part, but I still liked MXML better than HTML. Later at the same job I did Node and found that pretty enjoyable too, plus I could use vim all the time. Tooling is always a concern with a language. I think dynamically typed languages are partially successful because they let you get away with so much less tooling. Though not all dynamic languages are equal in the tooling they can trivially support, e.g. Common Lisp with Slime enables all the usual stuff (who calls x, who sets y, who specializes method z...) and you can use Slime from a variety of other tools.
deleted 8y ago
[deleted]

_hardwaregeek 8y ago

TypeScript works with JSDoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...

sephoric 8y ago
Can confirm, have sometimes added /* * @type Foo */ above a type and VS Code assumed that type was Foo everywhere else in my project, as if I typed `foo: Foo` directly. Didn't even have TypeScript in the project itself, purely an IDE feature. Extremely well thought out and useful ecosystem.
deleted 8y ago
[deleted]

Vinnl 8y ago

Yes, TypeScript can do type checking on regular Javascript (annotated with comments) as well: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j...

lmm 8y ago

If you're using Babel for compatibility with particular browsers then that can already handle TypeScript. What distinction are you drawing between a compile step that "strips away the type annotations" and one that does something else - what else is it that you consider compiling TypeScript to include? I have to ask what you're trying to achieve here. Moving types into comments just gives people who build without your typechecker the chance to break your code.

mrspeaker 8y ago
The comment stripping is optional (just for saving bytes on download). The goal is moving away from Babel, and any other unnecessary transpiling steps. Now that JavaScript has (a semi-working) module system, I find my projects having fewer and fewer dot files and far fewer dependencies. If I can have a folder of plain JS that I know will work in a browser 20 years from now without having to resurrect an ancient/abandoned toolchain, then I'll do that!
- lmm 8y ago
  Are you gonna hardcode all the HTML and CSS as well? I would expect resurrecting a 100% compatible toolchain for a mainstream source format 20 years from now will be easier than resurrecting a 100% compatible browser. Especially if that format is a stricter/less ambiguous one like typescript.

scrollaway 8y ago

> I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. That's what Typescript is. Type annotations don't change your code, they're stripped away by babel at compile time. In fact, by default, tsc does compile TS code which fails typechecking, into valid JS code (which will likely error when you use it at least in some circumstances, but can run just fine). Typescript is a clear superset of JS, so there's no actual logical changes or even syntactical changes done by the compiler. However, you may be confused by the often-used "compilation target" features of babel (and tsc), which is that you may write ES2018 code, target ES5, and have your ES2018 syntactical sugar be turned into ES5-compatible code. This is entirely opt-in, and not related to typescript (other than the fact that Typescript is always compatible with the latest ES spec, so you can use any legal ES2018 syntax in it). Hope that clears it up…

dntrkv 8y ago
This is where I see a big difference between Flow / TS. With Flow, the type annotations are just stripped away, none of your Flow code affects runtime code. This is not so with TS since you have things like Enums, which will be compiled into objects and are part of your runtime code.
- RyanCavanaugh 8y ago
  If you write type annotations in TS, they're stripped away. If you write type annotations in Flow, they're stripped away. There's no difference. TS has some additional features which are purely optional that don't get purely stripped out, but you're not mandated to use them.
  - MehdiHK 8y ago
    Is there any compiler option or linter config that prevents the use of these extra features?
    - 8y ago

Jach 8y ago

Not exactly what you're asking, but a "third choice" in general to typed ECMAscript has been ActionScript. A quick google found a transpiler project, but it looks to be abandoned: https://github.com/Cleod9/as3js https://github.com/Cleod9/as3js Still, I once did Flex development (would compile to a SWF file, or with Adobe Air to a native executable). It was a pleasure -- so long as you used the Flex/Flash Builder IDE (which was itself built on top of Eclipse). Trying to develop in vim was harder, though mainly because of the MXML part, but I still liked MXML better than HTML. Later at the same job I did Node and found that pretty enjoyable too, plus I could use vim all the time. Tooling is always a concern with a language. I think dynamically typed languages are partially successful because they let you get away with so much less tooling. Though not all dynamic languages are equal in the tooling they can trivially support, e.g. Common Lisp with Slime enables all the usual stuff (who calls x, who sets y, who specializes method z...) and you can use Slime from a variety of other tools.

deleted 8y ago

[deleted]