Announcing TypeScript 3.0 RC
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
One is project structure. I came up with a solution for type-safe RPC that required a shared file for type definitions, and my solution was to symlink that file. It looks like the new project feature should let me get rid of that and have a "shared" TS project as a sibling to "server" and "client"!
The other is spread arguments. I recently ran into the error "Spread types may only be created from object types" [1] and I think this feature is addressed by TS 3.0!
[1] https://github.com/Microsoft/TypeScript/issues/13557
Call me crazy, but I really think TypeScript is the future of the web and I'm betting my whole career on it by diving deep into it and becoming an expert on it so that I can do consulting as a TypeScript & React expert.
1. People are dying to stop writing JS. The evidence is CoffeeScript, TypeScript, and the million other compile-to-JS options.
2. Wasm is in every major browser, and direct DOM access is in the roadmap.
3. There are lots of people who don't want the context switching that's been required in web frontend programming. They want to use a single language on the front and back ends. If wasm can access the DOM, this becomes possible with any language that compiles to wasm (Rust, .NET family, probably others).
2. That may be true, but that doesn't mean wasm can take over JS in terms of features. For example it still has no GC, which for some things (embedding Doom) may be good, but for general app development it's better to have a GC and the other high-level features JS has that wasm doesn't.
3. That just means some people want wasm to take over, for that one specific reason. It doesn't mean it's actually going to gain traction to evolve in that direction.
That's a bizarre comment from someone who just said they're dedicating their career to transpiling. Flow is a layer of safety on top of JavaScript, while TypeScript is a different language. You can't run it with JS runtimes, and it has features JS will never have. It's definitely transpiled.
See also: Elm, ClojureScript, NativeScript, PureScript, Haxe, and the staggering number of transpile-X-to-JavaScript projects out there.
> but for general app development it's better to have a GC and the other high-level features JS has that wasm doesn't
The features that are missing from wasm can be implemented in the original language. Rust, at least, doesn't have garbage collection. There are also multiple proposals to add garbage collection to wasm.
> That just means some people want wasm to take over, for that one specific reason. It doesn't mean it's actually going to gain traction to evolve in that direction.
People wanting something to happen is all that's needed to make it happen. If you concede people will want it, then you concede it will happen. wasm replacing JS as the API for the browser makes more sense than, say, JavaScript on a server, and yet here we are...
AFAIK TypeScript has a grand total of one non-typesystem related feature which doesn't already exist in JS (or as an ES proposal) - enums[1]. All the other parts of TypeScript can be transpiled just like Flow - by stripping away the type annotations.
Still a really strong release though. The tuple changes are going to cut down an insane amount of overloads that I currently have to write myself (while maintaining the arms race of "just one more overload"). The unknown type is wonderful for a strict alternative to any--will be super useful at the seams of your app.
So any speedups in wbepack with Typescript would be very much appreciated by the community.
I prefer substack/browserify's unixy approach to software design.