
Announcing TypeScript 3.0 RC - DanRosenwasser
https://blogs.msdn.microsoft.com/typescript/2018/07/12/announcing-typescript-3-0-rc/
======
sbjs
This is really exciting! I actually ran into two problems that this already
solves, one of which I briefly touched on in the article I posted to HN this
morning.

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

~~~
smt88
I love TS but don't see it as the future of the web. It's currently the best
way to write JS and use the JS/Node ecosystems, but compile-[insert better
language here]-to-wasm will be more compelling than TS in the future.

~~~
sbjs
I don't think wasm and JS are competitors. From what I can tell, wasm
currently isn't blessed with the same first-class citizenship in the browser
that JS is, and I don't think that's in the works either. It looks like wasm
is mainly meant for porting C libraries to the browser (Emscripten style) and
maybe the occasional Doom or Quake just because.

~~~
smt88
You may end up being right, but here are my premises:

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

~~~
sbjs
1\. That's just so wrong. CoffeeScript came out _9 years ago_. The transpiling
craze peaked years ago, and most of the good features of all those other
languages have been pulled into modern ES. There's only a few of them left in
somewhat common usage and mostly because they're niche (Haskell-like or Lisp-
like). TypeScript solved a totally different problem, it's just a layer of
type safety _on top of_ JavaScript, it's actually still JavaScript, so if
people like TypeScript then they like JavaScript.

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.

~~~
smt88
> _The transpiling craze peaked years ago_

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

~~~
paavohtl
> You can't run it with JS runtimes, and it has features JS will never have.
> It's definitely transpiled.

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.

[1]
[https://www.typescriptlang.org/docs/handbook/enums.html](https://www.typescriptlang.org/docs/handbook/enums.html)

------
nojvek
Typescript magic build stuff is useful. Although a realization needs to be
made that webpack is the king of front end build systems. Mostly because it’s
able to package all sorts of things into a single js/css file.

So any speedups in wbepack with Typescript would be very much appreciated by
the community.

~~~
syspec
webpack is king, but ill take browserifys speed via watchify anyday

~~~
cphoover
webpack is a monolithic build tool.

I prefer substack/browserify's unixy approach to software design.

