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.
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.
"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?
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.
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 ;)
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]
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.
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.
> 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.
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.