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

Announcing TypeScript 2.1

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

181–190 of 226 posts

Re: Announcing TypeScript 2.1

#181

Post by dandare »

jc79 wrote: post #113
zdragnar wrote: post #8

It's interesting to me that all of the initial reactions I've seen to this announcement have been around the introduction of async and object spread, which are available with babel, but the typescript specific features such as mapped types are completely ignored. I don't really have any particular meaning behind that observation, only that it tickled my funny bone a little bit.

Well, to me at least the mapped types are the main advantage of this release. Very frequently you start building a record incrementally (so, you can't assign it to an interface where all fields are mandatory), but then at a given stage you will validate that record and copy it to another variable which has the type with all the fields mandatory. Previously you had to define two copies, one with mandatory fields, anot…

I do not understand this concept fully and I wish I could read a more detailed explanation of how this works along with plenty of example code.

Re: Announcing TypeScript 2.1

#182

Post by djmashko2 »

thejameskyle wrote: post #114
wereHamster wrote: post #70

Earlier quoted context omitted.

TypeScript doesn't split the community any more than Flow does. TypeScript remains very close to ES2016/2017, syntax-wise, with the only major difference being type annotations, but you have those with flow as well. Anybody who can read JavaScript can read TypeScript.

Flow tries to integrate with the existing ecosystem as much as possible. By taking advantage of Babel, ESLint, Atom, etc. With Flow you don't even have to opt-in to a new syntax. You can just use comments: function foo(val /* : boolean */) /* : string */ {} Using really powerful inference you can also write much fewer types. If you have well types libraries [you sometimes don't need types in your code at all]( https:…

> By taking advantage of Babel, ESLint, Atom, etc.

Doesn't TypeScript actually predate all of those tools? So that logic doesn't seem reasonable.

Re: Announcing TypeScript 2.1

#183

Post by Noseshine »

mohamedhegazy wrote: post #162
whatever_dude wrote: post #87

Earlier quoted context omitted.

> Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information? Yes and no. Typescript does a little bit of filling in the gaps of some missing features if the target platform does not support a feature you used . So your compiled code will still be ES6 (or ES5), but it may have some boilerplate added to polyfill for something if ES6 or ES…

You can just use `--target ESNext` and this will disable all ES features transformations and just erase types.

Thank you!!! This is the one answer I was looking for. And it seems to be very recent, committed Nov 7 for 2.1:

https://github.com/Microsoft/TypeScript/pull/12160/commits/7...

Looking at the discussion on GitHub for the issue that lead to this commit I'm a little amazed at how much difficulty some people seem to have had with the simple concept. "Just pass it through without code changes, only remove type information." Why does that lead to such convoluted discussions? Oh well, it's been done.

Re: Announcing TypeScript 2.1

#184

Post by [deleted] »

edblarney wrote: post #102
jensvdh wrote: post #15

Typescript is a game changer for any serious project. Never going back to plain JS.

Concur. I am basically 'anti religious' when it comes to software. So many people argue back and forth about this or that, and 80% of arguments are academic and effete (this is what I mean be 'religious'). But I'm a big supporter of TS because I believe 'it makes sense' on almost every level. I'm not a 'big supporter' of many things at all, if any. I understand the limitations, and that it enforces some things for wh…

[deleted]

Re: Announcing TypeScript 2.1

#185

Post by twfarland »

edblarney wrote: post #98

After trying TS, I basically never want to write JS again. I know that 'OO' and 'typing' is not the solution to everything ... but aside from all the nice things you can do in TS ... the 'enforced architecture' of OO-ish paradigms, combined with typing, and essential obfuscation of the prototype paradigm ... has cut the time to development in half. I can hardly think of a reason to use JS now that TS exists. Of cours…

I've stopped using those OO-ish paradigms in JS (no 'this', 'new', 'prototype'), but even still, have much preferred using TS. You can get a long way (and have great flexibility) with only interfaces and generic functions.

Re: Announcing TypeScript 2.1

#186

Post by dotancohen »

xiaoma wrote: post #175
ggregoire wrote: post #40

Earlier quoted context omitted.

> The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it. For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. Edit and disclaimer: Not sure why I'm getting downvoted, my comment doesn't contradict parent message. I personally type my code too (w…

VSCode has become a mind-blowingly good editor. It's closing in on the power of heavy-weight IDEs with much better performance than some code editors (e.g. Atom), even.

Both VSCode and Atom are based on Electron, which is slow and battery-intensive as it is based on NodeJS. Are you saying that recent VSCode versions are as performant as, say, a C++ based editor or even (shudder) a Java based editor such as Jetbrains (Webstorm, etc.)?

I last looked as VSCode (on a KDE 4 CentOS 7 desktop) about half a year ago, and it was terribly slow, even without extensions.

Re: Announcing TypeScript 2.1

#187

Post by ken47 »

I've been using Typescript for over a year, and the amount of improvement in that relatively short time span has been incredible. With 2.1, Typescript shows no signs of slowing down.

Re: Announcing TypeScript 2.1

#188

Post by friendzis »

z3t4 wrote: post #136
billti wrote: post #120

Earlier quoted context omitted.

If the code isn't typed, then you can't find all references accurately. For example, in the below, you've no idea if the "a" inside the function is the same is as on "foo". ```javascript var foo = { a: true, // Find all references on "a" here... b: "hello" }; foo.a = false; bar(foo); function bar(obj) { obj.a = false; // Won't find this "a". } ``` Call site inference can follow this sometimes. However with types it c…

Thank you for actually providing an argument for having types. The parser could however in-line the function and replace obj for foo. I do advocate using the same variable names for function arguments though, as having different names for the same variable is not only hard to refactor, it's also very confusing! So instead of using "that", me, myself, obj, str, etc, use the actual variable name! Disclaimer: I'm workin…

Either I do not understand your point or you are walking a thin line.

If a particular function can be tied to particular variable from scoping block, then the function is not entirely useful. On the other hand, if a function is general and has the same argument name as variable from scoping block, which is going to be passed in, mentally it is difficult to analyse the function without thinking about the variable which may shadow bugs in function. E.g. square root function may omit negative argument check, because variable from scoping block is always positive.

Instead of knowing scoping rules I advocate for distinct variable names, so scoping rules (name shadowing) do not even come into play.

Re: Announcing TypeScript 2.1

#189

Post by egeozcan »

taspeotis wrote: post #169
mattmanser wrote: post #168

Earlier quoted context omitted.

async/await in C# is pretty nasty and usually overused and overhyped for nothing but downside. It screws debugging, it screws call stacks, it dictates you to write bad code and it's just plain complicated. It infects your code up and down the stack and every new method MS now releases seems to be .SomethingAsync(). I likened it today to having a garden hose in a Victorian sewer but then declaring the sewer is the bot…

I think it is unfair to compare async/await on top of poorly performing code with async/await generally. Fast synchronous code being faster than slow asynchronous code is kind of tautological. async/await keeps your UI thread unblocked. Or, more generally, it keeps your threads unblocked. I have an ETL process that benefits from async/await greatly: I can stream more data in/out of the database with fewer threads. Th…

I heard from a colleague that in VS2017, the debugging is much better for async stacks. Did anyone here try it?

Re: Announcing TypeScript 2.1

#190

Post by Noseshine »

jiaweihli wrote: post #111
jasonallen wrote: post #28

Feels like Typescript is building (or has built up?) more momentum than Flow.

Very early on, Typescript cleverly built up an ecosystem around community-supported type definitions for popular js libraries. This makes type-checking and integration for those libraries dead simple. 2 years later, Flow is _still_ lagging behind in this area. [1] I'm not certain, but I think this may be due to Typescript allowing for a external header-like file while Flow requires inline types. For this reason I bel…

I don't understand what you mean by

  this may be due to Typescript allowing for a external
  header-like file while Flow requires inline types.
Flow supports external declaration files. I use them all the time for 3rd party modules.
Post reply on HN