Hacker News Reader

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.

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.

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.

The whole purpose of TS is better JS.

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.

JS compatibility is core to Typescript's own popularity.

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

Yeah, having just jumped into ts after a long js hiatus since back when The Good Parts was still surprising, it's quite awesome to see how much of what I assumed to be "ts stuff" is actually just postdeluvian js. Makes ts more attractive, not less. I do wonder however of it was possible to identify parts of that language superset that are fully redundant (as in not even required for exotic edge cases) and let loose some draconian linter?

You already can kinda do that using ESLint and rules like https://eslint.org/docs/latest/rules/no-restricted-syntax, https://eslint.org/docs/latest/rules/no-restricted-propertie... or https://eslint.org/docs/latest/rules/no-restricted-imports.

Sure, but that's still seems quite mix and match, anything goes, choose your own adventure. There are many positives about this approach, but as a learner a little more common ground between codebases would certainly be appreciated.

True. I always thought that we should have additional mode stricter than https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe....

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.

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

> aren't syntax sugar

They aren't syntactic sugar? Pretty sure `class Foo { blah() {} }` is equivalent to `function Foo() {}; Foo.prototype.blah = function() {}`.

There are a few very specific differences. In a subclass, 'this' doesn't exist until you call "super" for example, and the constructor will throw an error of invoked without the "new" keyword. [O]

These differences let you extend built-in things that simply can't be done with old prototype constructor syntax. [1]

[O] I should probably be using a more recent reference like MDN, but the 2ality series always sticks out in my mind whenever "just syntax sugar" comes up: https://2ality.com/2015/02/es6-classes-final.html#safety-che...

[1] https://2ality.com/2015/02/es6-classes-final.html#subclassin...

Thanks. It sounds like subclassing built-ins is where transpilers hit a hard wall. Other syntactic features of es6 can be transpiled.

http://kangax.github.io/compat-table/es6/

This page lists features from es6 (and newer versions linked at the top) along with compliance to the spec. First column is the current browser, second is babel+corejs polyfills.

Overall, babel gets about 70% of the way there.

The result of `let x = Foo()` when Foo is defined as a function is whatever Foo's return value is. Trying `let y = Foo()` when Foo is defined as a class throws a TypeError.

They are not, no.

My example is incorrect because it doesn’t cover all the edge cases but you can desugar es6 to es5, except in es5 you can’t subclass builtins.

> the fact they aren't syntax sugar over prototypes was a mistake

Totally different meaning.

What else would 'syntax sugar over prototypes' mean?

you can still write the old javascript. it'll feel very lonely, though.

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

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.

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.

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.

Or just pass pointers because you need optionality, and get null pointer exceptions for free :)

I've been hoping to see alternative targets to JS for TS as well. WASM makes a lot of sense but TypeScriptToLua¹ also looks interesting.

1: https://typescripttolua.github.io

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