Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript 3.5

devblogs.microsoft.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: TypeScript 3.5

#61

Post by spankalee »

DanRosenwasser wrote: post #27
PaulBGD_ wrote: post #13

Does anyone here have experience with slow TypeScript builds? I've updated to use --build and incremental, but it still takes 3s+ to build 30 files on a 8700k clocked at 5GHz.

Typically, TypeScript type-checks `lib.d.ts` every single compilation which can add at least half a second of build time. It will also do a full check of `.d.ts` files in your dependencies, which can also be pretty heavy. We're considering ways we can avoid a full type check: https://github.com/microsoft/TypeScript/issues/31417 In the meantime, you can try out turning on the `skipLibCheck` compiler option to see if t…

Is the check of `lib.d.ts` not helped by --incremental?

Re: TypeScript 3.5

#62

Post by platz »

sli wrote: post #2

I would really love to enjoy TypeScript, especially now that they've added HKTs, but I am constantly running into type errors when the types clearly match, leading to weird workaround code where the type of some key in some object is specified as: false | 'x' | 'y' | undefined Meaning passing in `'x'` should work just fine. But instead, it specializes it to just a string, then throws a type error. The workaround requ…

TS does not have HKT. The post simply described improved inference on types with several generic parameters.

Re: TypeScript 3.5

#63

Post by hermanradtke »

I wish there was a better testing story for TypeScript. ts-jest is slow because it does not benefit from incremental compilation. Having tsc compile everything creates a dist/ folder with tests, fixtures, etc and causes all sorts of subtle issues to be worked around. Also, trying to use tsc-watch and something like jests watch runs into all sorts of weird race conditions though at least the build and the tests complete in about 1 second.

I looked into combining tsc-watch and jest, but jest does not currently support a public API. tsc-watch already emits an event on success which should be able to trigger (an already running!) test runner to incrementally test again.

Re: TypeScript 3.5

#64

Post by jakelazaroff »

mattigames wrote: post #57
farnsworth wrote: post #56

Earlier quoted context omitted.

> 1) Operator overloading Please, please, please, no.

You know it would be completely transparent right? Just gets transpiled into .__add__(obj)

The explicit goal of TypeScript is to be JavaScript, with types — i.e. not introduce any features not likely to land in an ECMAScript spec.

Re: TypeScript 3.5

#65

Post by goblin89 »

hajile wrote: post #49
IceDane wrote: post #23

Earlier quoted context omitted.

I can't downvote you but I want to point out that the only thing you accomplish with such a comment is coming off as ignorant and bitter. I have no idea why on Earth you think the type system is broken. Objectively, it simply isn't, obviously, but I'd love to see you trip over your own feet trying to argue that it is. Moreover, it's honestly remarkable how they've managed to retrofit such an amazing type system on to…

I don't know if 3.5 fixes this, but here's an example from 3.4 function messUpTheArray(arr: Array ): void { arr.push(3); } const strings: Array = ['foo', 'bar']; messUpTheArray(strings); const s: string = strings[2]; console.log(s.toLowerCase()) You obviously can't push a number into an Array , yet typescript allows it. For my money, ReasonML is a better solution for type issues (hindley-milner types are awesome).

It seems like both projects have their own raisons d'être along with trade-offs.

TS is pretty well-integrated with JS ecosystem and supported by a large player, but has an imperfect type system; Reason is more “puristic” with pattern matching and all, but you have to keep your eyes peeled for impedance mismatch.

(The docs for Reason, or BuckleScript to be exact, have warnings like “If you come from JavaScript, a Reason object doesn't compile to a JS object” sprinkled here and there.)

I personally encountered the case you described a couple of times but generally using TS still saved me a lot of time I’d have wasted debugging, with minimal time spent on getting into the ecosystem.

Re: TypeScript 3.5

#66

Post by tomp »

saagarjha wrote: post #50
tomp wrote: post #42

Earlier quoted context omitted.

OCaml/Reason have discriminated unions, which means that you have to explicitly specify which variant of the union you're using, such as type union = Bool of bool | Char of char | Nothing let (x, y, z) = (Nothing, Bool true, Char 'x')

Is this not what enums with associated values are?

Probably... but in any case TypeScript also supports naked (edit: I just made up the name) unions, where you don't need to declare them upfront, and where values of different types can be included directly. Such as:

  let a = random() ? 'a' : 1
TypeScript infers type

  string | number

Re: TypeScript 3.5

#67

Post by mattigames »

jakelazaroff wrote: post #64
mattigames wrote: post #57

Earlier quoted context omitted.

You know it would be completely transparent right? Just gets transpiled into .__add__(obj)

The explicit goal of TypeScript is to be JavaScript, with types — i.e. not introduce any features not likely to land in an ECMAScript spec.

Which is a shame because JavaScript is constrained due needing backwards-compatibility above all (among other issues) but TypeScript isn't

Re: TypeScript 3.5

#68

Post by nsonha »

sli wrote: post #2

I would really love to enjoy TypeScript, especially now that they've added HKTs, but I am constantly running into type errors when the types clearly match, leading to weird workaround code where the type of some key in some object is specified as: false | 'x' | 'y' | undefined Meaning passing in `'x'` should work just fine. But instead, it specializes it to just a string, then throws a type error. The workaround requ…

"they've added HKT"

no they did not, if they did it would've been a major news.

Re: TypeScript 3.5

#69

Post by alttab »

ComputerGuru wrote: post #6
alttab wrote: post #5

Typescript 3.5: fixing the problems we introduced and providing workarounds for new features in a broken type system.

No kidding. I thought you were being facetious but reading the changelog it's clear that most of these would typically have been in a high-priority 3.4.1 release as a number of them are blocking (now there's code that compiled under 3.4 with nary a warning that won't compile under 3.5).

Right. Just read the changelog. It's literally regression fixes on compilation performance (which is introduced by typescript to begin with), and providing work arounds to do things typeless when new syntax feature XYZ is launched.

I'm getting a lot of flack on this thread but I stand by my judgement that working with typescript is slower and more frustrating for frontend work than standard JS.

My experience is just and anecdote, but I'd make a considered choice to pick typescript over minimal JS frontends. A large portion or this is based on my previous experience, so that is what it is.

Re: TypeScript 3.5

#70

Post by watt »

mattigames wrote: post #57
farnsworth wrote: post #56

Earlier quoted context omitted.

> 1) Operator overloading Please, please, please, no.

You know it would be completely transparent right? Just gets transpiled into .__add__(obj)

We already saw this play out in Scala. People end up abusing these to create absolutely unreadable "DSL"s. Even when it's tastefully done, for example the "!" and "?" operator for messages in Akka, it's not better than the names "tell" and "ask".
Post reply on HN