Hacker News Reader

Comment by sbjs | Hacker News Reader

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

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.

View on HN

Does this release actually fix the generic spread type issue? I believe that issue is being worked on elsewhere [1]. Would love to be wrong though because that error is quite annoying.

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.

[1] https://github.com/Microsoft/TypeScript/pull/13288

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.

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.

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

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.

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

> 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

Typescript is definitely great and brings a lot of new ideas to type systems. I really wish python had such great tooling. Mypy leaves a lot to be desired.

Reply on news.ycombinator.com