3 ms·

It's been shown I think that keeping JS a simple dynamic compile target has much more value and allows languages compete and evolve separately from browsers. Le

It's been shown I think that keeping JS a simple dynamic compile target has much more value and allows languages compete and evolve separately from browsers. Let us have things like ClojureScript, TypeScript, Elm etc compete & coexist on a level playing field on their own merits.

runarberg 5y ago
This proposal is pretty much just adding a standard specialized comment syntax to the language. Different tools can still utilize these comments in their own way. The proposed syntax is pretty on target to what the existing static type analyzers have converged on. I don’t see how it is giving an unfair advantage to one tool over another. If anything it will lower the barrier of entry for new static type analyzers which can compete on how good their type system is, as opposed to the new language they are currently forced to create along side the type system.
- deleted 5y ago
  [deleted]
ketzo 5y ago
The beauty of this proposal is that it would keep JS as exactly that. Optional type annotations, packaged as a part of vanilla JS instead of requiring a build step, would be the only benefit. They'd be stripped out at runtime; the compiled JS would be identical.
- fulafel 5y ago
  The complexity / change cost: Since this would be a JS language addition, this would add complexity and churn to the JS language syntax. (There is no separate runtime / compile time in the JS model as implemented by JS browsers and tooling - except when run through JS-to-JS compilers). The benefit: Sown by TS users or possibly some kind of of TS-lite using this subset of TS features. Not benefiting: non-TS languages targeting the browser, like Elm, ClojureScript, ReScript, PureScript, Haxe, Nim, Kind, and <the next big language here>.
  - ketzo 5y ago
    > Not benefiting: non-TS languages Why? If anything, this gets vanilla JS users more comfortable with types in their JS. That seems like a win, and a good gateway to more strongly-typed languages. Even if other languages aren’t actively benefiting, does it hurt them in any way? They wouldn’t even have to make any changes to their compilers; their compiled JS would stay just as valid. The benefit is not to just Typescript users and advocates; the benefits are for everyone who wants more sanely developed JavaScript. Seems pretty good.
MrJohz 5y ago
I'm not entirely sure that that has been shown. By far and away the most popular compile-to-JS language is JavaScript itself, via tools like Babel. After that, you've got Typescript, which is still basically just JavaScript with some type annotations stuck to it. It's only after that that you start getting to languages like Cjs and Elm, which have more varied semantics and treat JavaScript more like a true compile target. My reading of that would actually be the opposite: JavaScript is a pretty poor language to target, and, for all its flaws, it's easier to stick to languages that mostly have JavaScript-like semantics and syntax than opt for a different (and potentially better) language, but have to deal with the more complex debugging processes. I think this will be different for Wasm, which has been explicitly designed as a compilation target, but that's still getting off the ground in terms of being suitable for general usage.
- fulafel 5y ago
  The languages I listed don't really suffer from JS impedance mismatch or other major practical problems. The interop of course is still a hump from a programmer POV, a FFI to another language is always a portal to another culture.. But even there the shared object system and GC makes it much better than interop between native code languages. WebAssembly suitability for general HLLs is possible in the far future but there don't seem to be many eager consumers. People prefer JS interop, browser API access, and builtin high performance GC and a JIT of JS that can efficiently handle dynamic constructs with advanced compiler magic. Reimplementing those in your wasm targeting compiler would be a huge effort and complexity cost, and added bloat to compiled programs, even if wasm supported it.

runarberg 5y ago

This proposal is pretty much just adding a standard specialized comment syntax to the language. Different tools can still utilize these comments in their own way. The proposed syntax is pretty on target to what the existing static type analyzers have converged on. I don’t see how it is giving an unfair advantage to one tool over another. If anything it will lower the barrier of entry for new static type analyzers which can compete on how good their type system is, as opposed to the new language they are currently forced to create along side the type system.

deleted 5y ago
[deleted]

ketzo 5y ago

The beauty of this proposal is that it would keep JS as exactly that. Optional type annotations, packaged as a part of vanilla JS instead of requiring a build step, would be the only benefit. They'd be stripped out at runtime; the compiled JS would be identical.

fulafel 5y ago
The complexity / change cost: Since this would be a JS language addition, this would add complexity and churn to the JS language syntax. (There is no separate runtime / compile time in the JS model as implemented by JS browsers and tooling - except when run through JS-to-JS compilers). The benefit: Sown by TS users or possibly some kind of of TS-lite using this subset of TS features. Not benefiting: non-TS languages targeting the browser, like Elm, ClojureScript, ReScript, PureScript, Haxe, Nim, Kind, and <the next big language here>.
- ketzo 5y ago
  > Not benefiting: non-TS languages Why? If anything, this gets vanilla JS users more comfortable with types in their JS. That seems like a win, and a good gateway to more strongly-typed languages. Even if other languages aren’t actively benefiting, does it hurt them in any way? They wouldn’t even have to make any changes to their compilers; their compiled JS would stay just as valid. The benefit is not to just Typescript users and advocates; the benefits are for everyone who wants more sanely developed JavaScript. Seems pretty good.

MrJohz 5y ago

I'm not entirely sure that that has been shown. By far and away the most popular compile-to-JS language is JavaScript itself, via tools like Babel. After that, you've got Typescript, which is still basically just JavaScript with some type annotations stuck to it. It's only after that that you start getting to languages like Cjs and Elm, which have more varied semantics and treat JavaScript more like a true compile target. My reading of that would actually be the opposite: JavaScript is a pretty poor language to target, and, for all its flaws, it's easier to stick to languages that mostly have JavaScript-like semantics and syntax than opt for a different (and potentially better) language, but have to deal with the more complex debugging processes. I think this will be different for Wasm, which has been explicitly designed as a compilation target, but that's still getting off the ground in terms of being suitable for general usage.

fulafel 5y ago
The languages I listed don't really suffer from JS impedance mismatch or other major practical problems. The interop of course is still a hump from a programmer POV, a FFI to another language is always a portal to another culture.. But even there the shared object system and GC makes it much better than interop between native code languages. WebAssembly suitability for general HLLs is possible in the far future but there don't seem to be many eager consumers. People prefer JS interop, browser API access, and builtin high performance GC and a JIT of JS that can efficiently handle dynamic constructs with advanced compiler magic. Reimplementing those in your wasm targeting compiler would be a huge effort and complexity cost, and added bloat to compiled programs, even if wasm supported it.