Putting Typescript into the browser would make it very hard to evolve Typescript since we would have to wait for browser compatibility. Better to keep it in the compile toolchain.
It would be nice to have some more targeted solution for working with typed arrays, though.
Right. We will soon need TS to TS compilation as TS progresses way too fast for browser adoptions to catch up.
If everything is typed in TypeScript, I see a lot of serious potential for optimization, like using only the memory needed per object exactly like a struct in C or C++.
TypeScript isn't sound, so you can't rely on the types for optimization. The shape/hidden class optimization that JS engines already have is probably about as good as you can do.
The last soundness issue I'm aware of is the bivariant function issue which they resolved in 2.6
You can still do something like this:
let x: number = "some string" as any;That's sort of tautological. "Any" and type assertions are designed as the escape hatch of the type system. If you're trying to develop type safe typescript you obviously won't use those. The followup question is for typed code (excluding usage of any or type assertions) does typescript have an unsound type system? Afaik the answer is no.
In the real world you are forced to use "any" when the type definitions for a third-party library are not perfect.
This actually happens a lot with types from DefinitelyTyped that are not maintained by the original author of the library.
That would be the equivalent of static_cast in c++, or casting via (object) in C#. Both of those are considered type safe but can still be abused also.
I don't get it, I though the whole purpose of typescript is to prevent things like that?
You could still infer sound areas such as certain structs and patterns for using them. They could introduce sound mode or patterns for areas as well.
There is WebAssembly for that now.
I'm not a fan of WebAssembly. I like js because you can instantly reload and test changes to your code without lengthy build or compile times and I'm hoping for typescript to become standard so that the same applies for typescript. I doubt the same will ever be possible with WebAssembly.
Anything more complicated than a little jQuery stuff is going to need build tooling anyway, at least Webpack and probably JSLint and Mocha. Since those are already there, adding either Babel or TyepScript isn't all that difficult.
Just took .284s to re-compile a Rust (stdweb) app targeting WASM.
And well over 2 seconds for Webpack to deal with (just) bundling 6 JS files and the .wasm file.
Re:Announcing TypeScript 3.0
by gameswithgo on Monday July 30, 2018 @04:15PM
(#17647602)
what is lengthy to you?
some languages can compile ~30k lines in 0.5 seconds
e.g. I've got data like this:
Reading, generating, and manipulating data like this is a bitch in javascript. Typed arrays have to be aligned to the byte size of it's type and because the offset of gps_time isn't at a multiple of 8, it's not possible to read it with Float64Arrays. DataView works but it's an order of magnitude (!!) slower than typed arrays so the best thing I can do for now is to read a double by treating everything as Uint8Array(), and then read the 8 bytes of the double into a temporary ArrayBuffer that can be used to convert between types.My hope is that Typescripts type system is good enough to be able to treat this kind of data similarely as you can in C++, and that it would then become standard.