8 ms·
TypeScript 2.4
- moomin 9y agoThey've just fixed what I regarded as the top reason for avoiding it completely: the broken type checking on functions. It's a source of mystery that they didn't realise that was going to be a problem right from the start.
- boromi 9y agoglad to see this fixed
- zeusly 9y agoI only know a little bit of JavaScript, what's the best way to learn TypeScript? Read Eloquent JavaScript then some TS related stuff? Or is there a TypeScript for Dummies that don't know JS?
- munchor 9y agoIf you want a quick overview, then https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html https://www.typescriptlang.org/docs/handbook/typescript-in-5.... If you want the full immersion, then read the entire Handbook: https://www.typescriptlang.org/docs/handbook/basic-types.html https://www.typescriptlang.org/docs/handbook/basic-types.htm....
- Scarbutt 9y agoFor anything serious you are going to need to know JS, so yes, level up your JS first (up to ES5 is good enough) before switching to TS.
- josephst18 9y agoI learned JS through Eloquent JavaScript and did the various projects in the book, then changed all my .js files to .ts, turned on all of TypeScript's checks, and started adding types to my files. I'd recommend doing a similar path; transitioning existing code to TS is IMO a better way to learn it than from scratch. TypeScript Deep Dive is a great resource.
- stuffedBelly 9y agoJavascript the Good Parts by Crockford is a great book for people who already know a bit of JS but want to learn it proper and deeper.
- rickdg 9y agoUse it as a javascript syntax checker, it's probably the easiest to work with right now. And, when you learn more javascript, you may eventually take a look at actual typescript.
- sleazebreeze 9y agoOne way of learning TypeScript would be to fork a straightforward open source project, add type information and make the whole thing work with TS.
- smt88 9y agoThe TypeScript compiler is strict and descriptive. You can honestly just learn JS and then mess around with TypeScript until your code compiles. Being good at JS is a requirement, of course.
- drk4 9y agoThe string enums don't seem to work the same way as the number enums, there's no 2 way access. For example. enum Test { a } let a = Test.a; let b = Test[ 0 ]; // isn't available on the string ones I wonder why its like that.
- RyanCavanaugh 9y agoIf there were a reverse map like for numeric enums, there'd be no way to (at runtime) distinguish a Name from a Value. With a numeric enum you can use typeof Test[x] to figure out if x was a valid Name or valid Value, but this doesn't work for string enums because they're both typeof == 'string'.
- drk4 9y agoThat seems like a much minor situation compared to not being able to reverse map. You could have a situation where you have a string as a code, and then the display name for example, and you can't really do that as is now. This seems more useful than checking for the type (which in a numeric enum is either a number or string, so you would still need to do some work to properly validate it).
- RyanCavanaugh 9y agoIf you want to have the reverse map, you can trivially build it yourself. But if the reverse map did exist (rather, if the map started off as bidirectional, which is the only option on the table), it'd be impossible to properly construct the one-way map.
- drk4 9y agoYou mean because of using the same string for a key/value? I guess I see the potential problem. Anyway just think that it might be a bit confusing to have the enum work slightly different depending on whether its using numbers or strings. It can caught some people off guard.
- DaiPlusPlus 9y ago
- azr79 9y ago> String enums This language is getting better and better with each release
- Scarbutt 9y agoIs Typescript goal to be the Java/C# of the browser/nodejs? static type checking, tooling and heavily OOP(as in Java/C#) based?
- mohamedhegazy 9y agoNo. TypeScript has no dependency on classes the way Java or C# does; nor is class-oriented code the recondeded style by the TS team. As a matter of fact the typescript compiler core is all written as functions and immmutable objects with no classes (except for a polyfill for Map and Set). TypeScript 2.3 has support for vue.js this injection style patterns (see https://github.com/Microsoft/TypeScript/pull/14141 https://github.com/Microsoft/TypeScript/pull/14141) which are way out of the realm of class-centric programming languages. Similarly the inference cabalities (expanded in 2.4) and the fundamental nature of the type system being structural rather than nominal is another give away of the language nature and direction. So the short answer is TypeScript is a superset of JavaScript; and is as class-centric as JavaScript is.
- dtech 9y agoIt only adds types to Ecmascript/Javascript, so it's not more or less OOP then ES6 is.
- PhrosTT 9y agoWon't we stop transpiling everything once ES6 support (& modules) are ubiquitous? I kind of feel like this is when everybody converted codebases to CoffeeScript and are now stuck with having to undo that... Yes, I get strong typing has merits - but so does writing the native language.
- moogly 9y agoThis is just me, but there's no way I ever go back to vanilla JavaScript after having used TypeScript for a year.
- netcraft 9y agoI think there will continue to be es-next stuff that can be made available - im hoping that one day we will get macros in TS so we can experiment with new features/syntax and a compiler is a great way to do that. But even if all of that does go away, types outweigh writing without types imo - but you can always take the output of TSC and stop using it going forward, its not obfuscated.
- joshuacc 9y agoI won't. TypeScript in particular has made my code much more maintainable and pleasant to work in compared to vanilla JS, even recent versions.
- untog 9y ago> Yes, I get strong typing has merits - but so does writing the native language. Naturally. But the merits of strong typing far outweigh those of writing the native language, for me at least. If you have a project of any reasonable size, TypeScript is such a huge productivity boost it's incredible. I was very sceptical (having indeed been burnt by trying CoffeeScript before) but the comparison doesn't really work with TypeScript. If it died tomorrow and we all decided to go without it, we'd just transpile to JS and be done with it - CS -> JS looks very, very different, but TS -> JS is the exact same code, just with types stripped out.
- Risord 9y agoES6 is mostly just syntax sugar and standard library stuff compared to ES 5 just like CoffeeScript. TypeScript is about about static analysis (and required metadata called type annotations in code which allow the analysis). Big difference is that ES 6 has indeed replicated most solutions of CoffeeScript. However so far I can tell ES won't be ever(?) statically typed and therefore it won't ever(?) solve same problem space as TS.
- olingern 9y ago> Dynamic import() expressions This is exciting. About a month ago, I tried this just expecting it to already be supported. I was sad to learn it wasn't. Kudos to the Typescript team for the awesome, continual improvements.
- pitaj 9y agoDarn. Unfortunately they didn't fix this issue [1] which I was really looking forward to. Bumped it to TS 2.5 Of course, it does look like this release has no? Salsa-related fixes or improvements, so it doesn't surprise me. https://github.com/Microsoft/TypeScript/issues/15809 https://github.com/Microsoft/TypeScript/issues/15809
- tkubacki 9y agoDart with dynamic js compiler (DDC) is getting better too: http://news.dartlang.org/2017/06/a-stronger-dart-for-everyone.html http://news.dartlang.org/2017/06/a-stronger-dart-for-everyon...
- adrianlmm 9y agoThe problem with Dart, is that it is a pain to interact with JavaScript libraries, let's see if Dart 2 makes it better.
- thebosz 9y agoLuckily, the story is getting better. Now all it takes is a "definitions" file much like @types for Typescript[1]. [1]: https://medium.com/@thebosz/creating-a-dart-to-javascript-interop-library-c97da204c34a https://medium.com/@thebosz/creating-a-dart-to-javascript-in...
- hamstercat 9y agoI'm really excited about String enums. I've been avoiding enums in TypeScript until now, since every time I've wanted to use them, I realized that a literal union was easier to use when the times come to log or persist the value. But with this you keep the string representation, and get a typed constant at the same time. Dynamic imports is pretty huge too, that should come in handy for a lot of people.
- donatj 9y ago> Strict contravariance for callback parameters ?TypeScript has always compared parameters in a bivariant way. There are a number of reasons for this, and for the most part it didn’t appear to be a major issue until we heard more from users about the adverse effects it had with Promises and Observables… > TypeScript 2.4 now tightens up how it checks two function types by enforcing the correct directionality on callback parameter type checks. I understand what they mean after quite a bit of wrestling with that and the example, but I feel like that could have been far better worded for laypeople.
- Analemma_ 9y agoI would love for an ELI5 explanation of covariance/contravariance, but I've never seen one. I get it now, but only after reading and rereading explanations very carefully.
- dotancohen 9y agoSo, then how would you explain it to a five year old?
- Arnavion 9y agoImagine a pipe that only fits dogs. The pipe has two ends. One side has person A pushing dogs into the pipe - the source. The other side has person B pulling dogs out of the pipe - the sink. The source can push anything into the pipe that is a dog or more specialized than a dog, ie they can push in specific dog breeds like only terriers. So the source can treat the "Pipe of Dog" as a "Pipe of Terrier". It's okay because they're dogs and the pipe accepts dogs. The source cannot push in any animal that isn't a dog. When the sink pulls something out of the pipe, they can expect to receive anything that's a dog or less specialized than a dog, eg they can expect that everything they receive will be an animal. So the sink can treat the "Pipe of Dog" as a "Pipe of Animal". The sink can expect not to receive anything that isn't an animal. The sink can't expect that they'll only receive terriers, since the source may decide to push bulldogs instead. The source end of the pipe is contravariant on Dog. The sink end of the pipe is covariant on Dog. Edit: To bridge this with programming: A function is a pipe. The input of the function is the source. The output of the function is the sink. A function that accepts a Dog could be given a Terrier, and a function that returns a Dog can be considered to return an Animal. Data structures are equivalent to functions in this respect. A data structure that produces instances of Dog is the same as a function that produces a Dog - IEnumerable<Dog> in C# is also an IEnumerable<Animal>, Promise<Dog> in JavaScript is also a Promise<Animal>. A data structure that both accepts and returns instances of Dog is invariant on Dog - List<Dog> in C# can't be List<Animal>, Array<Dog> in JavaScript can't be Array<Animal>, because that would let someone push Cats into them. Edit 2: By the same reasoning, a callback parameter flips the input-output-variance association for every level of nesting. For a first-level callback, the inputs to the callback are produced by the function, so the input of the callback is equivalent to an output of the function, and the output of the callback is equivalent to an input of the function. Eg consider a JS function `function foo(x: (y: A) => B): C { }` This is covariant on A, contravariant on B, covariant on C.
- brokebook 9y agothis is great news. the code below failed to compile in 2.3 but works in 2.4. it was an annoying bummer when working with ADTs in typescript. It's also nice that you can use string enum for the discriminators now. "{ kind: Kind.Ok, value: 'bla' }" feels less stringly. interface Ok<T> { kind: "ok"; value: T; } interface Err { kind: "err"; error: string; } type Result<T> = Ok<T> | Err const maybeNumbers: Result<number>[] = [ { kind: "ok", value: 10 }, { kind: "err", error: 'some error' }, { kind: "ok", value: 9 }, ]; function isOk<T>(thing: Result<T>): thing is Ok<T> { return thing.kind === "ok"; } const okNumbers: Ok<number>[] = maybeNumbers.filter(isOk);