
TypeScript 3.6 - mceachen
https://devblogs.microsoft.com/typescript/announcing-typescript-3-6/
======
Humphrey
I've been using Typescript for the past year and it's definitely one of the
best typing systems I've used (Rust might be up there too - once I've
conquered the battle of the borrow checker). The way it handles nullable
references and understands code to ensure I'm using values correctly, and the
editor integration. Microsoft, I'm impressed!

Yes it takes me "slightly" longer to write code initially, but that time is
recouped almost straight away by the intellisense suggestions, refactoring,
and code checking. My code often "just works" the first or second time.

Therefore after using Typescript for a couple of projects, I was excited to
start adding type hints into our backend Python code, but I was quite
disappointed by the value that they added. Perhaps I'd just become spoilt by
Typescript.

~~~
julien_c
Yes, Python's type system is nowhere near Typescript, and are closer to
docblock annotations.

~~~
h8hawk
How? How it's not close to typescript? I mean what are features that python's
type annotation (and mypy) lacks in comparison to typescript?

~~~
penagwin
Was battling it today. Latest stable release of python mind you 3.7.3. We have
to move structured data around from a legacy system and integrate it with our
new website. Perfect opertunity for types. This also includes trying to use
mypy.

    
    
      * it doesn't track the state of the variable. If I get a value thats Optional[int] there is no way to say 'if a is not None:' it will still complain that the variable could be none
     * even with the mypy experimental TypedDict they're basically unusable IMO
     * there is no 'keyof' 

* there is no way to constrain to specific strings (or other primitives). I don't understand what literals are supposed to be but they aren't useful for us

Coming from typescript it's been very lackluster.

~~~
emptysea
I agree that mypy can be a bit lacking, but to address a couple of your mypy
woes:

\- TypedDict is an option but if you can, dataclasses work much better

\- mypy does refine Optional[T] to T with an if check. Maybe you need to futz
with the compiler options?

\- Does Literal["foo"] not work? I've been using it with pydantic for de-
serializing a tagged union of dicts and also for function args.

e.g.,

    
    
        def call_to_service(api_type: Literal["users", "teams", "orgs") -> None: ...

~~~
penagwin
The problem I had with Literal["foo"] is that at least according to mypy "foo"
is a string and it was expecting Literal["foo"].

I think you're right, something must be mixed up. But then again this is the
latest version of python and mypy, on intellij, so I'm not sure what I did
wrong, it's using otherwise default options.

------
cageface
Typescript has massively improved my quality of life working on JS projects. I
occasionally run into constructs that are difficult to type but most of the
time TS just works. Thanks to all the people behind this project for all your
work!

~~~
MuffinFlavored

        interface IntMap {
          [name: string]: int
        }
        
        interface StringMap {
          [name: string]: string
        }
    

I really feel something like that should come standard so I didn't have to
rewrite it so many times when coding in the wild.

~~~
AaronFriel
These are:

    
    
        type IntMap = Record<string, int>;
    
        type StringMap = Record<string, string>;

------
wry_discontent
I feel like I'm the only one, but I don't care for Typescript.

After working with it for a while, the type checker ends up being painful to
work with. I'm using React, and it's difficult to write higher order
components that are correctly typed. Additionally, probably related, styled
components often get messed up with the type system.

~~~
fendy3002
Personally I prefer to not use typescript on react (I don't have any
experience on it and it seems like a hassle). I use it on mobx / redux
instead.

However it's a godsend for nodejs.

~~~
tomduncalf
It’s not really a hassle at all and adds great value with compile time
checking of proptypes etc. Give it a go. If you use MobX especially you should
find it really quite straightforward - I’m not sure what typing Redux is like
these days, didn’t used to be much fun but I’ve not used Redux for about 3
years

------
gvkhna
TypeScript is such a fundamental milestone in the web and javascript
community. (coming from Microsoft too!) I really do hope front end communities
converge on typescript in an idiomatic manner.

~~~
uvtc
There are many nice modern languages that compile to JavaScript. Personally, I
like [Haxe]([https://haxe.org/](https://haxe.org/)), which compiles to many
other target platforms/languages as well.

Here's a [comparison of Haxe and
TypeScript]([https://blog.onthewings.net/2015/08/05/typescript-vs-
haxe/](https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/)).

~~~
veidr
I'm all for more new and innovative languages, but I think the key thing about
TypeScript is not that it compiles to JavaScript, but (to quote basarat's
great free book[1]) that "TypeScript is just JavaScript with docs".

TypeScript is a strict superset of JavaScript, so all our real-world
JavaScript _is_ TypeScript already — you can literally just change the file
extension from .js to .ts.

Now, our existing JS code probably isn't _great_ TypeScript, since it doesn't
leverage those great machine-and-human-readable docs (the type system).

So, compared to code written from the beginning with TypeScript, our existing
code doesn't go as far toward reducing the likelihood that we humans miss
something while programming, and introduce a bug. And we probably won't get
all the automated assistance that we could be getting from our machines, in
terms of auto-complete, as-you-type errors and warnings, automatic imports,
etc.

But for projects coming from JavaScript, it's hard to overstate the importance
of being able to start from a place where all your existing code works like it
always has, and you can choose the right mix of when/if to upgrade your legacy
JavaScript code to TypeScript.

I think that design decision is probably the key to TypeScript's explosive
adoption and popularity. A lot of languages could give you strong typing, and
the increased code correctness and massively improved tooling that comes along
with that — but I don't know of any others that literally require no code
changes to start adopting them.

Of course, the choice to remain a superset of JavaScript does place some
significant limitations on what kinds of cool improvements TypeScript can add.
It can't break JavaScript code so lots of cool things one might imagine won't
be possible. Still, a great tradeoff IMO.

[1]: [https://github.com/basarat/typescript-
book](https://github.com/basarat/typescript-book)

~~~
k__
_> TypeScript is a strict superset of JavaScript_

I had the impression this has been debunked already.

[http://blog.jonasbandi.net/2016/10/myth-of-
superset.html](http://blog.jonasbandi.net/2016/10/myth-of-superset.html)

~~~
veidr
My own understanding is that a few persons have made comments or blog posts
along the line of, "Look at this convoluted edge case I created of valid
JavaScript that isn't valid TypesScript! Ha! Gotcha!"

There may be some cases like that (though I've never seen one in the real
world, since I started working with TypeScript three years ago). And there
have been and will be more bugs in TypeScript and its compiler, etc.

Such claims might be true in some pedantic sense, but aren't really meaningful
unless you are in some kind of internet flame-war thread on Reddit or
something.

In the real world, for the purposes of writing software, Microsoft's claim[1]
that "TypeScript is a typed superset of JavaScript" is generally true.

[1]: [https://www.typescriptlang.org](https://www.typescriptlang.org)

EDIT: Maybe I shouldn't have said "strict" superset. That might have just been
me accidentally editorializing.

EDIT 2: After reading the post you linked, and its (good) comment thread, I
understand where he was coming from, but as he notes in his update at the top,
it mainly boils down to different interpretations of what "superset" means in
this case. I think in the end his assessment is the same as mine above.

------
oliyoung
Nothing has improved my day-to-day work life more in the last 5 years than
typescript.

It's joy. Just, joy.

------
benatkin
I've noticed there's a lot of talk on twitter about making TypeScript be an
agreed upon best practice for frontend web developers. I'm glad TypeScript is
doing well because there are certainly a lot of talented and dedicated
developers working on it, but I really don't want to use static typing, even
if there is a lot of type inference happening. I will need to make sure I
don't plan on finding job or gig opportunities at the types of companies that
are going require the use of TypeScript.

~~~
sqs
Do you believe static typing is harmful (to the type of company you want to
join), or is this a personal preference (which is totally valid)? Honestly
curious.

~~~
Ididntdothis
I am starting to wonder if the preference static vs dynamic is some kind of
character trait like introvert vs extrovert. I personally prefer static typing
and use it to my advantage during development but I know very smart people who
hate static typing and think it impedes them. Both sides have valid arguments
but seem to prioritize things differently.

However I think it’s important to have used both for a while so you can make a
good decision what you prefer.

~~~
bcheung
I think it depends a lot on previous experience, what type of thing you are
developing, and your tooling. I'm very comfortable and happy bouncing between
C# in Unity, React and JS, and Haskell for more CS / intellectual curiosities.
For me it's more about fit and choosing the right tool for the job.

All things being equal I prefer something like Haskell because it is very
clean and expressive. But I hate excessive types when you are dealing with
generics 3 level deep or when you have these funky type signatures dealing
with monad transformers. It's just too many layers of abstraction that takes
you away from the actual data / parameters.

When I'm writing something small I find typing slows me down. But when writing
something bigger, working in a team, or working on a codebase for a longer
period of time the typing acts as documentation. Typing something and having
Intellisense tell you what is in a class is extremely helpful. Otherwise you
have to jump to the file or look through documentation.

For me it's less about the errors it catches and more about the time saving of
not having to read through code that I am calling in order to understand what
I need to pass to it.

In general. strong typing is great when you are working with other people's
code and 3rd party libraries, but excessive overhead when you just want to
experiment and crank out something small.

~~~
hderms
Fwiw we have a relatively large Scala codebase that's exceptionally bug-free,
performant.and easy to modify and haven't had to reach for a lot of the
extremely abstract FP patterns that warrant the most blog posts. Simple
immutability, garden variety monads (IO, Either, Option) get you a long way
and are simple to understand.

------
AgentME
I was really hoping optional chaining would be in, but turns out that's
scheduled for the next minor release, 3.7.

The generator improvements are appreciated, though I wish it went even further
and supported uses like redux-saga better (so the return type of a yield
expression could depend on the type of the value that was yielded).

~~~
veidr
Oh, it's good to hear that feature is coming in 3.7! That's something I really
miss on a regular basis.

Where did you learn it's scheduled for 3.7?

~~~
city41
[https://github.com/microsoft/TypeScript/issues/16#issuecomme...](https://github.com/microsoft/TypeScript/issues/16#issuecomment-515160784)

------
lacampbell
Is anyone else using javascript + jsdoc + .d.ts files, and using typescript as
a kind of linter?

I'm really enjoying this setup, I get to use tools that work on JS source code
without sticking them in a build typeline. I find it easier to read as well -
the function declarations are nice and short as all the type annotations are
in a comment above. Also one less transpilation step.

~~~
lhorie
I do this extensively with Flow comment syntax at work and it's great. I tried
it w/ Typescript on a side project recently, but I found it to be a bit
limited (e.g. @callback doesn't play well with RORO pattern) and the syntax is
a bit clunky.

But having runnable code without a build step is definitely a very big plus
for me.

~~~
lacampbell
I never use the callback tag, I tend to just do:

    
    
      /** @param {(x: X) => Y} f */
    

Works fine. If you can let me know a RORO pattern you had trouble typing I
might be able to help.

~~~
lhorie
The problem with @param is that it requires a binding name

I ended up doing this instead:

    
    
        /**
        @typedef {{x: string}} FooArgs
        @typedef {{y: string}} FooResult
        @type {function(FooArgs): FooResult}
        */
        export const foo = ({x}) => ({y: x});
    

It works, but the double curly feels a bit clunky. Compare to Flow:

    
    
        /*::
        type FooArgs = {x: string};
        type FooResult = {y: string};
        type Foo = (FooArgs) => FooResult;
        */
        export const foo /*: Foo */ = ({x}) => ({y: x});
    

In Flow, the declaration ends up looking essentially the same between comment
syntax and non-comment syntax.

With TS, RORO ends up looking like Flow (but with weirder indentation on large
enough structs), whereas I'd prefer to express regular functions in terms of
@callback, @param and @returns since that's more in line w/ the spirit of
jsdoc. Not a huge deal, in any case, considering the upsides of comment
syntax.

~~~
lacampbell
index.d.ts:

    
    
        type FooArgs = {x: string}
        type FooResult = {y: string}
        type Foo = (_: FooArgs) => FooResult
    

index.js:

    
    
        /// <reference path="index.d.ts"/>
        /** @type {Foo} */
        export const foo = ({x}) => ({y: x})
    

Works as well

~~~
lhorie
Good point!

------
boarnoah
I think I got off to a bad start with Typescript. Decided to add it to on the
frontend of a bog standard Vue + Vuex erp app.

Its in quite a bad state with regard to how you have to structure the code to
ensure Typescript doesn't throw linting errors (and even then I found the
intellisense gained was not much more powerful than what my IDE already
provides).

My conclusion has been that TypeScript maybe great for extremely large
frontend apps, where you want to do a lot of data wrangling on the client
itself (with defined Entities etc...).

Kind of a shame really since I'm using .NET core on the backend and loving it

~~~
skeletonjelly
> Its in quite a bad state with regard to how you have to structure the code
> to ensure Typescript doesn't throw linting errors (and even then I found the
> intellisense gained was not much more powerful than what my IDE already
> provides).

Can you expand on this?

I currently write my apps in .net core/Vue/Typescript and use the same stack
for small or large so I might be able to assist

------
kabes
I know typescript is really popular around here. And I do like it for
autocompletion and refactoring. But am I the only one who thinks typescript
makes code unreadable? It looks so messy. I can understand a piece of normal
js way faster than the same code with types. Don't have this problem with, for
example, java. Maybe it's the syntax with the colons or the fact that I'm used
to types appearing before the name instead of after...

~~~
afraca
I applaud Microsoft for popularizing gradual typing , bringing types to the js
world is an enormous task, both technical and (js-)societal.

Regarding your syntax criticism: I quite agree. I really really like the path
chosen by Haskell. Types are obviously a major part of Haskell, but there you
just separate the type signature from the implementation.

    
    
      emap :: (DynGraph gr) => (b -> c) -> gr a b -> gr a c
      emap f = gmap (\(p,v,l,s)->(map1 f p,v,l,map1 f s))
        where
          map1 g = map (first g)
    

(Of course there are other helping things like type synonyms, which TS also
supports)

    
    
      type UPath   = [UNode]

~~~
mschuetz
There are a lot of languages where even if you don't know that language, you
can figure out what's happening. I have no idea what your example is supposed
to do.

~~~
elbear
That's because it's taken from a library that deals with graphs[1]. I had to
look it up, because I had no idea what it does either and I know Haskell.
Here's a better example of what he meant in Elm, a language that looks a lot
like Haskell: [https://github.com/bryanjenningz/25-elm-
examples/blob/master...](https://github.com/bryanjenningz/25-elm-
examples/blob/master/18-editable-todos.elm)

[1]: [http://hackage.haskell.org/package/fgl-5.7.0.1/docs/Data-
Gra...](http://hackage.haskell.org/package/fgl-5.7.0.1/docs/Data-Graph-
Inductive-Graph.html)

------
whsheet
While I think that TS offers probably the best type system out ther, eg way
better than Go's, I'd love to see a more balanced view on TS in discussion
threads like this one.

TS is a must for long-term code which should be maintainable in several years
by teams. Any lead engineer with responsibility for some crucial app and dev
team not using TS is doing something wrong. But using TS comes at a cost. Even
when you are savvy in TS you won't bang out code like with pure JS.

But especially in prototyping phases you need this fast-paced coding. And
using TS or any type system slows you down, even when you are familiar with
typed languages. Often your final code faced many iterations and I sometimes
like to introduce TS later, usually at a point where I just need types but not
always and as default from the first key press. In early stages I still try to
test ideas, algorithms and their general feasibility and a fast 'mind-to-code'
interface is crucial and types would stay in the way then.

Further, finding the right type can take some time, just google what type a
React's children prop should be and find long discussions. Welcome to the TS-
what-type-is-actually-xy-rabbit-hole. And declaring everything as any
shouldn't be the answer.

A big drawback are also TS error messages which are super hard to grasp. You
get there and you even find tutorials just for understanding TS error messages
but it's unecessarily infuriating.

Moreover, VSCode, its TS language server are amazing pieces of tech but here
you face also strange behaviours. Types get full Intellisense support while
interfaces don't which doesn't make sense. So you need still to go the
definition yourself and it's not that IDE-like feeling you hoped for or people
told you.

In my setups, I use TS instead of Babel but use both JS and TS files in one
code base depending on the requirements and situation.

So, my message is, yes TS is great, has probably the best type system but the
tonality by its community/users needs to be much more balanced and less
fanboy-ish. I just can't take devs serious who praise TS to death. This is
just not true. More, maintainable code is also not just created by a type
system but also sane architectures (eg React) and many other factors. Types
won't make bad code maintainable. So, types have their place but not
everything in TS-land is shiny.

~~~
filleduchaos
I wouldn't exactly call what TypeScript has the best type system out there.
It's deliberately unsound, doesn't enforce full static type-checking, _and_
doesn't provide for runtime checks (there are third-party libraries, but if
you're bringing up third parties one might as well argue that JavaScript has a
great type system because TypeScript exists).

A lot of it is due to the project's overwhelming priority being as easy to
interop with JS as possible, but I've found that quite a few of TypeScript's
fancier features are sugar that's entirely up to the developer to enforce.

~~~
whsheet
Disagree. TS' type system is fully featured compared to others and what you
described as an disadvantage is actually an advantage or TS' killer feature:
you can gradually convert a dynamic code base into a static one where needed.
IDK of any other language that allows this.

~~~
filleduchaos
Fully featured compared to what, exactly? If you say Java I might just have to
laugh.

Obviously the compatibility with JS is TypeScript's "killer feature", but it's
a killer feature that has very explicit costs you're ignoring for some reason.
You cannot have a truly excellent type system while trying to maintain the
level of compatibility with a dynamic, weakly typed language that TypeScript
does, something that the language team acknowledges themselves[0]. I don't
quite see how one can call a deliberately unsound type system "the best".

0: [https://www.typescriptlang.org/docs/handbook/type-
compatibil...](https://www.typescriptlang.org/docs/handbook/type-
compatibility.html)

~~~
whsheet
Not going to discuss this further. You have a dogmatic view on what is an
excellent type system.

------
cutler
Typescript only solves one of Javascript's two main problems. What really
makes JS an abysmal experience is it's lack of a standard library. Compile-to-
JS languages are in a unique position to solve this problem so I urge
Microsoft to focus on a curated set of reliable libraries which can constitute
a stdlib for JS. There are plenty out there already so it shouldn't be
difficult.

~~~
megaman821
I feel like lodash and date-fns is like 80% of what I want out of a standard
library. I mostly use the built-in fetch but Axios is nice too.

I also tend to use js-cookie and uri.js because the browser has horrible APIs
for working with cookies and urls.

------
siempreb
JS was designed to be dynamically typed, just as Python and others, it is at
the root of those languages. I can totally imagine that with all the big web
apps of today type safety is a thing for some people working in large code
bases. But that doesn't mean all dynamically typed languages need to perish.

Why not create a beautiful statically typed language from scratch that
compiles to WebAssembly? Why do we have to introduce a type system on top of
an old and flawed language? I mean, maybe you'll get some type safety with TS,
although it won't be 100%, but what about the future? How long will this toy
technology stay?

For me, this is so typical for the JS community, jumping the boat in a whim.
And IMHO this creates the famous Javascript fatigue. Learning disposable
things. Therefore I moved back to C++ after 6 years of web development,
learning things that actually make sense and that I can use for years to come.
Not having to work with all those temporary black boxes that are praised by
the community.

~~~
barberousse
>For me, this is so typical for the JS community, jumping the boat in a whim.

This is Microsoft's product, the company famous for keeping legacy going,
hardly the 'JS community'

------
anonytrary
If anyone here has switched from TypeScript to Flow or vice versa, care to
comment on how that's been working out? I use flow at work, and I am starting
to really love it, but it seems like most people prefer TypeScript to flow.

------
rossmohax
Typescript is only language I came across, where documentation is in release
notes, so to learn about feature you have to crawl all of them and there is
nowhere else to find it.

------
jbaudanza
I love that static typing has come to the Javascript ecosystem and I hope that
some of these concepts make their way upstream into future versions of
ECMAScript.

------
sAbakumoff
typescript is the best thing that happened with web development within
2010-2020.

------
breck
Nice to see the TypeScript Playground ([https://typescript-
play.js.org](https://typescript-play.js.org)) getting some love.

Makes it easier to see what all options are available in TSC.

~~~
kbd
Frustrating, though, that there's no good repl for TypeScript.

~~~
JoBrad
I've used ts-node, with pretty good results.

[https://www.npmjs.com/package/ts-node](https://www.npmjs.com/package/ts-node)

~~~
breck
Ts-Node is great. Startup times are slow though. 30x slower. Example for same
script using node vs tsnode: "user 0.11s" "user 0m2.839s".

Am I doing something dumb?

~~~
kbd
Ts-node is honestly pretty terrible. By-default you need to disable some
errors that make sense in code but not in a repl. "You just imported this
thing but didn't use it yet, ERROR", which means that nobody uses the thing.
Granted, I'm pretty spoiled by how excellent ipython is, but clearly no one
actually uses ts-node. It doesn't even remember history between sessions, and
they have no interest in making that work, even deferring to rlwrap.

~~~
breck
Interesting. I haven’t used it as a repl. Just for running ts scripts directly
so I don’t have to do a 2 step compile/execute.

------
namelosw
Nice, finally, there are typed generators. That could possibly enable us to
write something like do-notation in Haskell in a type-safe way.

------
stunt
TS is probably the best solution to JS problems today. And something like
project Deno may even push it one step further.

------
dmix
> For those unfamiliar, TypeScript is a

Finally, a release notes that explains what the product is!

------
_hardwaregeek
Disclaimer: I'm currently interning at Microsoft.

Y'know, I can't think of many companies that have as much support for open
source programming language development. Between Roslyn, TypeScript, what's
left of F#, the Language Server Protocol, Chakra, V8, etc., Microsoft has a
veritable powerhouse of compilers and PL development. Google has Go and Dart,
but as far as I can tell, the development process is contained in Google
mailing lists. Apple has Swift and LLVM and Mozilla has Rust, but each of
those footprints isn't as large as the combo of .NET and TypeScript.

I mean, ffs, Richard Stallman is coming to speak at Microsoft. Well, Microsoft
Research. But still. Stallman. That's insane.

~~~
bcheung
> what's left of F#

Has it been abandoned? What did you mean by this?

~~~
xvilka
Plain OCaml is still a better and more powerful language. F# is like a poor
relative to it. The only good thing of it is .NET integration. It lacks so
many features of OCaml.

~~~
idnefju
And OCaml lacks features that F# has. Like proper multicore support,
computation expressions, unit of measure, operator overloading.

~~~
ernst_klim
> computation expressions, unit of measure, operator overloading.

We have `let` operators instead.

And F# doesn't have proper overloading, it has an SML-like hack working for
built-in types only, and only within a function, as far as I understand. It
needs typeclasses for proper overloading. There is an ongoing work on Modular
Implicits for proper overloading (and even dependent types in core language),
but they are not there yet.

