Seems like a great foundation to build something like F# type providers on top of.
Announcing TypeScript 2.1
161–170 of 226 posts
Re: Announcing TypeScript 2.1
#162Question: 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? I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly…
> 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.
Re: Announcing TypeScript 2.1
#163The noImplicitAny flag just doesn't make sense. You changed the new default behaviour to be the thing you don't recommend?
`--noImplicitAny` is the recommended flag. It is not set by default to ease the use on JS code bases.
The new changes makes `--noImplicitAny` require less type annotations; where the compiler can figure out the type of a variable through following the control flow.
Re: Announcing TypeScript 2.1
#164Been a Linux developer for ages C# was never my taste, I'm still a bit Microsoft-hatred as of now(Visual Studio Code is the only item I adopted for JS development, the rest languages I still use vi/Geany). How tightly TS is related to C#? That has been the main reason I had not tried TS seriously so far. Don't want to have anything to do with C#. I know...
Once sometimes asked me "Isn't Typescript a language for C# developers that don't know JavaScript" It's unfortunate that people think that TS is similar to C# just because it came from Microsoft. Flow language is like 80% similar to TS, but no one says it's similar to C#. TS is just JS + new features from future JS specification + optional type system. And optional type system is fundamentally different than the one…
Thanks. That makes me feel better and I will give TS a shot this holiday.
Re: Announcing TypeScript 2.1
#165One thing I never understood with Babel is which features are shimmed in the output JS and which features are re-implemented? What I means is: I didn't know how to tell Babel which browsers I was targeting, and I'm pretty sure that some of their feature implementations do not feature test the platform before activating, since they were so compiled in. Is that the case? Also, do you have to tell TypeScript your target…
They're getting better at describing which features are shimmed, but the easiest way to check is by running a single plugin on a bit of code and seeing for yourself. For instance, I decided just now to check if `transform-object-rest-spread` included an Object.assign polyfill (because spread syntax transpiles to Object.assign behind the scenes.) With the following input: var foo = { x: 1, y: 2 }; var bar = { a: 3, b:…
There's actually a useBuiltins option to remove the _extends helper if you want to use that.
https://babeljs.io/docs/plugins/transform-object-rest-spread...
Might be cool in combination with preset-env
Re: Announcing TypeScript 2.1
#166Earlier quoted context omitted.
$Keys for keyof, $MapObj for mapped types. They are sorely missing lookup types though.
I can't seem to find any info online about $MapObj ? I searched the docs, google ... nuthin'. Am I just missing something?
Apologies, it's $ObjMap. And it's unfortunately not in the documentation, which could admittedly be improved.
Re: Announcing TypeScript 2.1
#167If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. 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.
I'm not the best Javascripter, is there a TypeScript resource to learn it from scratch without diving deep into js first?
Re: Announcing TypeScript 2.1
#168Earlier quoted context omitted.
TypeScript PM here - the reason for that is that when we implement a feature in TypeScript, we take lengths to ensure that it is typed appropriately and that its performance characteristics are reasonable. That means that when using object rest/spread, we didn't want to just ship an experience where type type is effectively `any`, leading users to be frustrated if they make an error. With async/await, we had to rewri…
As a long-time .NET dev... Thank You for Async/Await in TypeScript.
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 bottle neck, async/await to the rescue!
Most people use it in totally inappropriate scenarios, for no good reason but adding a load of complexity to your code and debugging.
But your sewer is now even bigger! Look at how you can throw that hose around!
I was working on a code base where the old developers had started going async/await for 'performance reasons'. Cue me ripping it all out, actually fixing the performance problems and downsizing the client from a P1 to a S1 in azure with 3x the load and vastly better page load speeds.
It's almost always a premature optimisation. My opinion is don't ever use it unless you actually know what the specific bottleneck is that async/await will fix and you actually need it.
async/await in javascript is actually useful.
Re: Announcing TypeScript 2.1
#169Earlier quoted context omitted.
As a long-time .NET dev... Thank You for Async/Await in TypeScript.
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.
That's not unique to the task-based asynchronous pattern, but it's far fewer lines of code to write than BeginExecuteReader/EndExecuteReader etc. so my appetite for doing it is much higher. And I believe asynchronous streaming (à la DbDataReader.ReadAsync) has no non-TAP equivalent.
Two steps forward, one step back. (You're right about debugging.)
Re: Announcing TypeScript 2.1
#170Earlier quoted context omitted.
They're different things, TS is a transpiler while Haskell (GHCJS) and Scala (Scala.js) compile respective host languages to javascript. In a perfect world you'd go with the latter, but there's overhead involved (relatively slow compilation and large generated binaries) that is mostly absent in TS. Also worth noting that TS' community is gigantic in comparison to that of Scala.js and GHCJS.
I was asking about the native languages themselves and their typesystems, not the compile-to-js versions of those languages. Regardless, I don't see much of a difference between TS -> JS and haskell->JS and scala -> JS. It's all from one language to another. the fact that TS is still considered a form of javascript is kind of irrelevant other than for semantics
TS->JS is very different from both in that the resulting JS code is the same as the typescript code with the types removed. In contrast Haskell and Scala compile to entirely different (and mostly unreadable) code