
TypeScript 3.4 - traderjane
https://devblogs.microsoft.com/typescript/announcing-typescript-3-4/
======
ng12
Wow. The const assertion is huge. My codebases are littered with things that
I, the developer, know are constant but TypeScript does not and it often takes
extra work to get type safety because of it. Can't wait to start using it.

~~~
coldtea
Now following their examples clearly.

Why not just make that "let x" a "const x" which JS already allows?

~~~
kentor
"const a = {}" disallows reassignment to "a" but still allows you to mutate
the object e.g. "a.b = 1". The const context does not allow you to mutate the
object.

~~~
coldtea
OK, the example with the "hello" literal string they have is quite bad then.

~~~
karanlyons
`as const` is useful there as well, as TypeScript’s type inference only
narrows as far as the type and not the literal value. `let z = {text:
"hello"}` has the shape `{text: string}`, with `as const` it has the shape
`{text: "hello"}`.

~~~
coldtea
Yeah, but shouldn't it use: const z = 'hello' and then get the shape {text:
'hello'} automatically?

Why use "let" along with "as const" instead of mere "const x = 'hello'" for
that?

~~~
karanlyons
Because `const` is a js level keyword that has different semantics: it applies
only to the reference binding being immutable, not the _value_ as being so.
`const a = "hello"` does have the shape `"hello"` as you’d expect, since
strings are immutable in js and the `const` keyword makes the binding
immutable as well. But objects are mutable, so TS can’t be a superset of
javascript and change the semantics of that behavior. Hence `as const`.

This is different to the widening of value types within objects, which is a
tradeoff made towards unsoundness with the belief that it would otherwise make
interoperability with existing js too difficult, for which `as const` now
serves as a way to explicitly opt into sounder behavior.

------
tombert
I haven't written anything in TypeScript, though I have some friends that love
the language; I got annoyed at having to supply bindings for obscure
languages.

If you can get past the initial hurdle, is TypeScript worth it for Node.JS
stuff?

~~~
pas
what does bindings for obscure languages mean in this context? does TS count
as obscure?

~~~
skybrian
I'm guessing it's a typo for "libraries".

~~~
tombert
You guessed correctly.

------
scanr
Excited about “Higher order type inference from generic functions”. Great for
libraries like RxJS, Ramda and axax.

------
mark_l_watson
The type inference looks good.

Pardon a question here: Will ES6 Code ‘just Run’ under TypeScript? I think the
answer is yes for ES5, but I don’t know about ES6. Thanks.

~~~
stareatgoats
Not sure what you mean by running ES6 code under Typescript. It is my
understanding that Typescript 'transpiles' to whatever flavor of Javascript
you need, and then the code is executed as Javascript.

If your question is whether you can just change the file extension of a
working ES6 file to .ts without Typescript complaining then answer is 'yes',
you should be able to do that no problem.

Edit: of course there is little sense in doing nothing more than that, but it
is a good starting point for decorating existing Javascript with TS features.

~~~
Someone1234
The biggest pain-point with renaming a ES6 file to *.TS is that TypeScript
will flag every library or browser specific object you reference as missing.

That isn't wrong behavior on TS's part, just getting started with TypeScript
is very configuration heavy, particularly for targeting browsers.

~~~
jahewson
You can use the ‘allowJs’ flag to have the compiler accept unmodied JavaScript
and for untyped modules you can use shorthand ambient module declarations so
they use the ‘any’ type, with one line of code.

------
truth_seeker
Oh dear, look at those features. Typescript is becoming the big valley of
types and syntax overheads. In order to be productive, as a developer I should
learn or know almost all the distinct syntax rules and tons of best practices.

An ideal (or close to it) typed language will have only few type rules and
better way to compose them.

I prefer either ReasonML or PureScript

ReasonML is great if you are looking lightweight alternative for compatibility
with existing JS libraries. It has relatively far less type syntax than
TypeScript.

I find PureScript (which also compiles to JS) to be more succinct and solving
the right problems for the developer. Although you need to spend some time
writing monadic adapter layer over existing JS library API interface if you
want to use them but given the confidence and safety provided by PS compiler,
I think it's worth the time.

[https://blog.functorial.com/posts/2017-08-09-Why-You-
Should-...](https://blog.functorial.com/posts/2017-08-09-Why-You-Should-Use-
PureScript.html)

------
jasonhansel
Just waiting until TypeScript's type system becomes so powerful that inference
accidentally becomes Turing-complete.

~~~
mickael
Apparently, Typescript type system is already Turing-complete:
[https://github.com/Microsoft/TypeScript/issues/14833](https://github.com/Microsoft/TypeScript/issues/14833)

------
cryptica
There has never been a worse time to be a software developer.

Practically all of the most popular tools encourage anti-patterns, add
unnecessary complexity or solve superficial problems instead of focusing on
critical problems that exist in today's software projects.

Some examples:

\- TypeScript: Unfortunately, we cannot reduce a language's complexity by
adding extra complexity on top. The complexity will keep rearing its ugly head
no matter how much we try to hide it. The TypeScript project has had over 20K
issues raised and 9K pull requests (that's not even mentioning the
DefinitelyTyped repo)... To put it into perspective, the Linux project has
only had about 380 PRs on GitHub. But how much value does TypeScript add? All
evidence points to the fact that TypeScript does not have any positive effect
on bug density. Its value is purely subjective and speculative. If humanity
had invested a quarter of that time and energy towards coming up with and
documenting proper JavaScript design patterns and architectures, TypeScript
would have been completely redundant to begin with.

\- NestJS: Makes heavy use of decorators; these aim to allow developers to
handle cross-cutting concerns within their code. Unfortunately, cross-cutting
concerns are an anti-pattern because they imply a violation of the principle
of separation of concerns between components. It takes a bit of thinking and
discipline to come up with components which have clear and distinct
concerns/responsibilities, but this is not a problem that can simply be
ignored by injecting decorators all over your code.

\- InversifyJS: Dependency injection is a failed concept. It's been proven
over and over. Angular 1 provided us with plenty of evidence for why we should
avoid dependency injection (e.g. it's impossible to find stuff and you end up
with a pseudo-global scope for everything which is as bad as simply using
global variables). Again, dependency management is not a solution which can be
automated away; it requires developers to make careful design decisions.

\- Code coverage tools like Istanbul and others add very little value to
projects. 100% coverage is not a useful goal to have, in fact it's
counterproductive. When it comes to test coverage, quality of that coverage is
WAY more important than quantity (this cannot be over-emphasized). Did you
test all the right inputs? Do the tests focus on the most important code paths
(and those which are more complex and therefore more likely to fail)? I'd
rather have 10% quality coverage of the right parts of the code than 100% poor
quality coverage. Also, you need to take into account that the more unit test
coverage you have, the harder it is to make changes to your code.

\- Linting tools such as ESLint/TSLint: These tools can be very nice if used
correctly and not treated as a silver bullet for all programming problems. We
should never forget that linters can only detect superficial problems. If your
code passes all the most strict linting rules, it still says almost nothing
about your project's code quality. I'd MUCH rather have code that fails ALL
linting rules possible but has good architecture and good separation of
concerns between components; at least the linting is easy to fix. Linting does
not prevent architectural mistakes AT ALL; it only prevents superficial
mistakes which are usually easy to identify anyway (if you have half-decent
testing).

I hope that over the next decade, the masses of new developers will develop
their critical thinking skills and that they will be able to see value beyond
the hype which is always being shoved into their faces by various misguided
organizations.

It's particularly difficult for me to see what has happened to software
development because 10 years ago, I used to roll my eyes when I read comments
like this from older and more experienced developers. New developers are often
attracted to complexity like moths to a flame, but eventually we all learn
that complexity is a silent killer - It's the ultimate enemy. Complexity is
always trying to quietly sneak its way into your code (and I do mean ALWAYS;
no matter how good your code is at any given point) and you must identify and
stop every single attempt. It takes most developers at least a decade or two
of coding to really appreciate this.

For me, starting a TypeScript project is like accepting unnecessary complexity
from the beginning of the project. It's a bad start, a slippery slope.

~~~
frankpf
> But how much value does TypeScript add? All evidence points to the fact that
> TypeScript does not have any positive effect on bug density. Its value is
> purely subjective and speculative.

This is objectively false. There is plenty of evidence showing that modern
type systems reduce bugs considerably.

In Airbnb, they found out that 38% (!) of bugs could have been prevented by
using TypeScript[1].

Another scientific study discovered that TypeScript and Flow could prevent
about 15% of bugs in committed code [2]. And these aren't even measuring
reduction of bugs in non-committed code!

Stripe is also writing their own type checker for Ruby and engineers have
reported an increase in productivity[3].

[1]:
[https://news.ycombinator.com/item?id=19131272](https://news.ycombinator.com/item?id=19131272)

[2]: [https://blog.acolyer.org/2017/09/19/to-type-or-not-to-
type-q...](https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-
quantifying-detectable-bugs-in-javascript/)

[3]:
[https://sorbet.run/talks/StrangeLoop2018/#/](https://sorbet.run/talks/StrangeLoop2018/#/)

~~~
jondubois
>> In Airbnb, they found out that 38% (!) of bugs could have been prevented by
using TypeScript[1].

I don't buy these hypotheticals and also I don't believe in this kind of
anecdotal evidence.

I think that the real root problem is that they didn't break down the code
into logical components and didn't test them correctly - That was the real
problem, not JavaScript.

When you look at reports of bug density across large samples of projects, it's
clear that TypeScript does not solve any problems. See
[https://medium.com/javascript-scene/the-shocking-secret-
abou...](https://medium.com/javascript-scene/the-shocking-secret-about-static-
types-514d39bf30a3)

~~~
frankpf
> I don't buy these hypotheticals and also I don't believe in this kind of
> anecdotal evidence.

The only anecdotal evidence I've linked is Stripe's experience with Sorbet.
The paper linked is an actual scientific analysis with great study design. I
couldn't find the Airbnb slides or talk but an engineer involved claims the
study was carefully designed[1].

> When you look at reports of bug density across large samples of projects,
> it's clear that TypeScript does not solve any problems. See
> [https://medium.com/javascript-scene/the-shocking-secret-
> abou...](https://medium.com/javascript-scene/the-shocking-secret-abou..).

Go read the "study" referenced in that article. It's just blog post with a
terrible methodology. It's basically

(number of issues with bug label) / (lines of code)

The author doesn't even normalize for LOC (larger codebases tend to have more
bugs) or take into account project complexity.

[1]:
[https://twitter.com/swyx/status/1094857103863209985](https://twitter.com/swyx/status/1094857103863209985)

EDIT: add disclaimer about airbnb talk

~~~
z3t4
I would love to read the Airbnb study. Do you have a reference ?

The other study you referred to sponsored by Microsoft is very vague on the
methods used to conduct the experiment. So its not repeatable. You can't say
something is scientifically true unless the results are repeatable.

