5 ms·

I've done a bit of typescript and kotlin-js. It always strikes me how close those two languages are. Yes there are lots of differences but they aren't that diff

I've done a bit of typescript and kotlin-js. It always strikes me how close those two languages are. Yes there are lots of differences but they aren't that different and you can transition from one to the other pretty easily. I have my preferences (kotlin) but I can work with both. IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript? Kotlin is in the process of adding a wasm compiler and they already have a js transpiler. The same code results in a lot smaller binaries and loads a lot faster in wasm form. Browser Javascript is not a great compilation target. And who cares what the minified crap that loads in the browser looks like? The only reason for backwards compatibility is allowing javascript projects to easily transition to typescript. But that's increasingly less relevant now that a lot of projects start out being typescript from day 1. Of course, Assembly script is already a thing. But why not make that a bit more official? It wouldn't surprise me to see people doing a lot of web development in languages like that in a few years.

orra 3y ago
I'm afraid that's wishful thinking. JS compatibility is core to the TypeScript ethos, regardless of TypeScript's own popularity. Besides, enums (?) aside, and ignoring typechecking, compiling TS is really easy right now. Switching to WASM is a high ask.
- horsawlarway 3y ago
  JS compatibility is core to Typescript's own popularity.
deleted 3y ago
[deleted]
flohofwoe 3y ago
"Modern" Javascript essentially is Typescript without the type hints (e.g. if you ignore the historical baggage, JS is actually a fairly decent language).
- junon 3y ago
  I actually argue JS was a better language before all of the changes made, starting with const/let. The only thing I'd say makes sense are classes but the fact they aren't syntax sugar over prototypes was a mistake. People wanted a different language, they should have gotten more scripting languages in the browser. Not changing JavaScript so much that it's no longer JavaScript.
  - flohofwoe 3y ago
    Coming into web development fairly recently (after 2013 or so) from the statically typed hemisphere and without closely following the Javascript history from the start I naturally cannot agree ;) (things like the scoping rules for 'var' is just bizarre, same with the concept of 'prototypes') Looking at typical "old-school" Javascript code gives me the creeps the same way as looking at K&R C code ;)
  - baq 3y ago
    you can still write the old javascript. it'll feel very lonely, though.
  - shrimpx 3y ago
    > aren't syntax sugar They aren't syntactic sugar? Pretty sure `class Foo { blah() {} }` is equivalent to `function Foo() {}; Foo.prototype.blah = function() {}`.
    - bornfreddy 3y ago
      > the fact they aren't syntax sugar over prototypes was a mistake Totally different meaning.
      - shrimpx 3y ago
        What else would 'syntax sugar over prototypes' mean?
    - zdragnar 3y ago
JeanMeche 3y ago
> IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript In browsers the Wasm runtime doesn't have access to the DOM APIs. So that's wishful thinking ATM.
zero_shift 3y ago
> IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript? My fantasy for the past year has been, if I could magically program anything, bringing a compiler and spec wholesale into the world out of the void, I would create a new language (call it WebScript as a placeholder) that - featured an ML style type system, ADTs, a type syntax nearly indistinguishable from TypeScript - whose actual core language essentially resembled Kotlin or "Go with exceptions" - compiled to WASM or JS as a compatibility bridge Nothing radical. Nothing revolutionary. Just these things would be an immediate plus. But maybe AssemblyScript is a good enough step towards that.
- jitl 3y ago
  Go has exceptions: you can use `panic` to throw/catch just fine. The community will bring out the torch and pitchforks because it’s “not idiomatic” but if you’re programming solo or with other pragmatists don’t let it stop you.
  - madeofpalk 3y ago
    Or just pass pointers because you need optionality, and get null pointer exceptions for free :)
  - skybrian 3y ago
    Does the community care if it’s not in a public API? If it’s caught within the same library it doesn’t affect anyone else.
- andrewcobby 3y ago
  I’m actually working on a language like this. I quite liked ReScript/ReasonML, but having to manually write binding to use TypeScript or JS code is a drag. I’m making a functional language that looks and feels like TS and lets you import TS directly. Mostly just stripping imperative statements, removing class declaration and adding pattern matching and better data constructors (never liked the discriminated unions). WASM as a target is a bit further off.
- 3y ago
AgentME 3y ago
Typescript is defined to run exactly as the equivalent Javascript you get when all the type declarations are stripped out of the source. There's no benefit in compiling it to WASM unless you had a WASM JS engine (or JS->WASM converter) that executed the JS faster than the browser's built-in JS engine (or created WASM binaries that were smaller than compressed minified JS, which seems extra unlikely when you'd have to include a JS runtime). If that existed for general JS, browsers would just upgrade to use that internally on all JS. Well, you could in theory get benefits by having optimizations based on the type declarations. This could be awkward to do when Typescript allows zero-runtime-cost interop with untyped JS anywhere and allows any value to be cast through the `any` type and then to any other type. If Typescript with these optimizations is still intended to execute in the same way as its untyped JS equivalent, then the optimizations all need to handle being opted out of when an unexpected value is received, in the same way optimizing runtime-type-tracking JS engines have to be able to abort out of their type-based optimizations. This optimization would be equivalent to pre-warming a JS engine's knowledge of runtime type information, which is an optimization that could be done for JS in general rather than by doing it just in the Typescript project through compiling to WASM.
- hibbelig 3y ago
  Your parent suggested to make changes to TS so that TS is no longer compatible with JS (in the sense you described). Once that happens, compiling to WASM instead of transpiling to JS is a very valid design choice.
  - wiseowise 3y ago
    The whole purpose of TS is better JS.
  - AgentME 3y ago
    That's fair, though there have been several projects that have attempted to be "JS-ish but with some behavior changes with strict type handling sprinkled in for optimizations" like the Strong types proposal (cancelled) and Dart (which switched to being a compile to JS language just like Typescript), so I'm currently convinced that the trade-offs aren't obviously worth it and that it's unlikely Typescript will change its priorities in that direction in the near future.

orra 3y ago

I'm afraid that's wishful thinking. JS compatibility is core to the TypeScript ethos, regardless of TypeScript's own popularity. Besides, enums (?) aside, and ignoring typechecking, compiling TS is really easy right now. Switching to WASM is a high ask.

horsawlarway 3y ago
JS compatibility is core to Typescript's own popularity.

deleted 3y ago

[deleted]

flohofwoe 3y ago

"Modern" Javascript essentially is Typescript without the type hints (e.g. if you ignore the historical baggage, JS is actually a fairly decent language).

junon 3y ago
I actually argue JS was a better language before all of the changes made, starting with const/let. The only thing I'd say makes sense are classes but the fact they aren't syntax sugar over prototypes was a mistake. People wanted a different language, they should have gotten more scripting languages in the browser. Not changing JavaScript so much that it's no longer JavaScript.
- flohofwoe 3y ago
  Coming into web development fairly recently (after 2013 or so) from the statically typed hemisphere and without closely following the Javascript history from the start I naturally cannot agree ;) (things like the scoping rules for 'var' is just bizarre, same with the concept of 'prototypes') Looking at typical "old-school" Javascript code gives me the creeps the same way as looking at K&R C code ;)
- baq 3y ago
  you can still write the old javascript. it'll feel very lonely, though.
- shrimpx 3y ago
  > aren't syntax sugar They aren't syntactic sugar? Pretty sure `class Foo { blah() {} }` is equivalent to `function Foo() {}; Foo.prototype.blah = function() {}`.
  - bornfreddy 3y ago
    > the fact they aren't syntax sugar over prototypes was a mistake Totally different meaning.
    - shrimpx 3y ago
      What else would 'syntax sugar over prototypes' mean?
  - zdragnar 3y ago

JeanMeche 3y ago

> IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript In browsers the Wasm runtime doesn't have access to the DOM APIs. So that's wishful thinking ATM.

zero_shift 3y ago

> IMHO typescript could just cut loose from its javascript compatibility. Why not compile it to wasm instead of transpiling it to javascript? My fantasy for the past year has been, if I could magically program anything, bringing a compiler and spec wholesale into the world out of the void, I would create a new language (call it WebScript as a placeholder) that - featured an ML style type system, ADTs, a type syntax nearly indistinguishable from TypeScript - whose actual core language essentially resembled Kotlin or "Go with exceptions" - compiled to WASM or JS as a compatibility bridge Nothing radical. Nothing revolutionary. Just these things would be an immediate plus. But maybe AssemblyScript is a good enough step towards that.

jitl 3y ago
Go has exceptions: you can use `panic` to throw/catch just fine. The community will bring out the torch and pitchforks because it’s “not idiomatic” but if you’re programming solo or with other pragmatists don’t let it stop you.
- madeofpalk 3y ago
  Or just pass pointers because you need optionality, and get null pointer exceptions for free :)
- skybrian 3y ago
  Does the community care if it’s not in a public API? If it’s caught within the same library it doesn’t affect anyone else.
andrewcobby 3y ago
I’m actually working on a language like this. I quite liked ReScript/ReasonML, but having to manually write binding to use TypeScript or JS code is a drag. I’m making a functional language that looks and feels like TS and lets you import TS directly. Mostly just stripping imperative statements, removing class declaration and adding pattern matching and better data constructors (never liked the discriminated unions). WASM as a target is a bit further off.
3y ago

AgentME 3y ago

Typescript is defined to run exactly as the equivalent Javascript you get when all the type declarations are stripped out of the source. There's no benefit in compiling it to WASM unless you had a WASM JS engine (or JS->WASM converter) that executed the JS faster than the browser's built-in JS engine (or created WASM binaries that were smaller than compressed minified JS, which seems extra unlikely when you'd have to include a JS runtime). If that existed for general JS, browsers would just upgrade to use that internally on all JS. Well, you could in theory get benefits by having optimizations based on the type declarations. This could be awkward to do when Typescript allows zero-runtime-cost interop with untyped JS anywhere and allows any value to be cast through the `any` type and then to any other type. If Typescript with these optimizations is still intended to execute in the same way as its untyped JS equivalent, then the optimizations all need to handle being opted out of when an unexpected value is received, in the same way optimizing runtime-type-tracking JS engines have to be able to abort out of their type-based optimizations. This optimization would be equivalent to pre-warming a JS engine's knowledge of runtime type information, which is an optimization that could be done for JS in general rather than by doing it just in the Typescript project through compiling to WASM.

hibbelig 3y ago
Your parent suggested to make changes to TS so that TS is no longer compatible with JS (in the sense you described). Once that happens, compiling to WASM instead of transpiling to JS is a very valid design choice.
- wiseowise 3y ago
  The whole purpose of TS is better JS.
- AgentME 3y ago
  That's fair, though there have been several projects that have attempted to be "JS-ish but with some behavior changes with strict type handling sprinkled in for optimizations" like the Strong types proposal (cancelled) and Dart (which switched to being a compile to JS language just like Typescript), so I'm currently convinced that the trade-offs aren't obviously worth it and that it's unlikely Typescript will change its priorities in that direction in the near future.