
Announcing TypeScript 3.9 - munchor
https://devblogs.microsoft.com/typescript/announcing-typescript-3-9/
======
dnpp123
I like typescript as it fixes a lot of JS quirks - that's good when you have
to write code transpiled to JS.

However coming from languages where types are a first element of the language
(c++, rust, go...), I often miss a lot of features in typescript (e.g. type
conversion overload, generic specialization, etc...)

I know that by design Typescript doesn't want those features and I understand
the rationale behind it. I'm just wondering if I'm the only one in that case
and if someone would know a language transpiling (not compiling) to JS more
appropriate to my tastes (and hence with different goals).

~~~
jonathanaird
What you’re looking for is Dart. I’ve really, really enjoyed using it so far.
Can be be aot compiled as well.

~~~
rubber_duck
Dart is much closer to TypeScript than C++/Rust in terms of static typing, it
just fixes some of the JS painpoints because it's not designed to be a 1:1
mapping to JS.

------
shroom
Any pro typescripter have any tips for how best use it in existing Node/React
codebase?

This article mentions material-ui and styled-components. My experience with
typescript has been cumbersome with these libraries. A lot of time is spent
figuring out what ”types” to return. I find this very difficult in most cases
and not fun at all.

I figure there must be something wrong in my approach or in my ts config (no
explicit any).

In short. How to best handle styled-components/material-ui/other library in ts
environment? Or is typescript just to much overhead in these usecases?

~~~
kall
> I figure there must be something wrong in my approach or in my ts config (no
> explicit any).

This is a heretic/unpopular opinion, but I think especially for existing
JS/React projects, the laxest possible TS setting is the way to go.

You should be able to get to no type errors in your existing JS project with
not too many changes. In these contexts (existing projects) I like to think of
TS as more editor experience support than seperate language. Modern React is
very friendly to TS automatic type inference, so IMHO you should be getting
decent benefits from typescript without annotating anything at all. And
instead of fixing complicated type errors for no real gain, just // @ts-ignore
and move on.

I don't know what your specific issue is with styled-components. Should work
pretty much out of the box? My suggestion would be to use CSS objects over
string literals because that way you get typechecking for your CSS.

~~~
rkwz
> This is a heretic/unpopular opinion, but I think especially for existing
> JS/React projects, the laxest possible TS setting is the way to go.

Not sure why you think it's "heretic/unpopular", but I think it's the only
reasonable way to incrementally migrate an existing codebase to TypeScript.

~~~
kall
i‘ve read things to the effect of "if you don‘t use noImplicitAny and
strictNullChecks you don‘t understand typescript" a bunch but I‘m glad to see
the other approach is popular as well.

------
dfabulich
Does anybody here know where to go to have conversations with the TypeScript
team about adding browser features to better support TypeScript?

A lot was happening back in 2018. A Googler put together a proposal to add
ignorable "pluggable" type annotations to JavaScript, which would allow
browsers to run TypeScript directly without transpilation (and without type
checking). [https://github.com/samuelgoto/proposal-pluggable-
types](https://github.com/samuelgoto/proposal-pluggable-types)

And a member of the TypeScript team at Microsoft put together a proposal to
add enums to JS. [https://github.com/rbuckton/proposal-
enum](https://github.com/rbuckton/proposal-enum)

Neither one of these seem to be active. What happened? What would it be like
to get these landed?

~~~
smt88
TypeScript already supports writing type defs as comments in JS files. You get
the static checking benefits of TypeScript and can run your code in a browser.

It also has enum support. If someone wants to add enums to EcmaScript, it has
nothing to do with TypeScript or their team.

~~~
hoten
yup, via JSDoc.

------
Rapzid
The biggest thing killing me right now with TypeScript is more of a general
ecosystem issue. That issue being how TypeScript interacts with the concept of
"workspaces" and Yarn's Plug'N'Play system. I use TypeScript with ts-node
pretty heavily. I'm also trying to use a shared source package outside the
root workspace file hierarchy :/

------
kbumsik
> @ts-expect-error

I glad to see this. One of the most painful moment was when writing tests in
TS. You will have to deal with countless type errors.

Although @ts-expect-error will partially solve the problem, what I have
learned is don't write tests in TS - you should test it in the real runtime
environment where there is no type checking.

------
kuschku
Half of the changes are due to the language server implementing refactoring
and other similar stuff.

This shows clearly why the language server protocol is such a bad design
decision and so broken — every language has to implement it itself, and there
are no shared features or functionality across languages.

Coming from IDEA, where the exact same refactoring functionality and features
work no matter if using typescript, kotlin, Rust, C#, golang or dart,
_exactly_ identical in all ways, this has been a huge issue for myself.

Languages Servers should just expose a clean standardized AST format,
representing standardized nodes, and this should in turn allow the IDE to act
upon this (which would immediately be represented in changed source).

~~~
eknkc
I feel like this is wishful thinking. There is no way you can abstract away so
many differences between languages for this to work effectively (or anywhere
near as good as a tailor fitted refactoring engine to specific languages)

IDEA does a lot of language specific stuff, it just unifies the UX. Which is
what language servers aim anyway.

BTW, I'm a long term user of powerline-go. Fantastic piece of software!

~~~
kuschku
> IDEA does a lot of language specific stuff, it just unifies the UX. Which is
> what language servers aim anyway.

Yeah, but with IDEA I have the exact same functionality for Rust, Typescript
or Java, while the language servers will never agree on the exact same
functions being called the same and doing exactly the same. It means
relearning your editor every time you switch your language.

I realize I’m probably in the minority as a person who writes basically every
project in another language, whichever happens to work best for the project,
while most others probably use only a few languages for most of their career,
but it’s still annoying.

------
nivethan
Mixing commonjs requires and imports is nice.

------
cryptica
IMO, until TypeScript gets the following features, it's not worth using:

\- Native TypeScript runtime interpreter in Deno (TypeScript alternative to
Node.js).

\- Native TypeScript runtime interpreter in all major browsers.

\- At least 20% performance improvement over plain JavaScript.

The build step has to go away because:

\- Source maps are unreliable, bulky, slow and add too much complexity for
some environments; many environments fail at using them correctly and this can
make it difficult to debug code. Being forced to debug ugly transpiled
JavaScript is unacceptable and should never happen.

\- It's slow to work with. TypeScript often claims to be 'scalable' but
reality is that large projects often take multiple minutes to build for every
change. There are no good incremental build solutions which also do proper
type checking. There is no runtime type checking.

Native browser support is also essential. The bundling step makes in
infeasible to freely mix and match modules written in the two languages in a
way which is debuggable.

Microsoft should look into Adobe Flash's ActionScript 3 migration from
ActionScript 2 for inspiration (both based on ECMAScript spec BTW, just like
JavaScript/TypeScript). I remember ActionScript 3 clearly because it was able
to deliver a 40% speedup AND runtime type checking...

In spite of these huge benefits, I remember that some developers were still
hesitant to switch to ActionScript 3! This new generation of developers has
clearly lost its ability for critical thinking - I find the current complete
lack of resistance to TS is very strange.

There are a lot more reasons to resist JS to TS migration compared to AS2 to
AS3 migration.

I remember in AS2, most people were not declaring types in their code (even
though there was support for compile-time type checking). Only in AS3 people
started adding Type annotations to their code.

~~~
azangru
> IMO, until TypeScript gets the following features, it's absolutely not worth
> using

That doesn't make sense. Browsers are unlikely to add native typescript
support in the foreseeable future; whereas meanwhile typescript offers huge
benefits compared to untyped javascript when it comes to large codebases and
refactorings.

~~~
cryptica
>> that doesn't make sense. Browsers are unlikely to add native typescript
support in the foreseeable future;

It's not my fault that browsers are not going to do it. It doesn't change the
fact that it is necessary and that TS is useless without it (the cons outweigh
the pros).

>> huge benefits compared to untyped javascript when it comes to large
codebases and refactorings

I've provided you at least 1 robust argument why this is not the case. You've
provided 0.

I can provide another argument against this:

TypeScript only protects the code from compile time type mismatches, it does
not prevent every other possible kind of error; it does not even protect the
code from runtime type mismatches (for example from JSON objects passed in an
HTTP or RPC request).

It also does not protect from race conditions, memory leaks, issues with
multiple sources of truth, unexpected asynchronous state mutations, poor
choice of abstractions, poor encapsulation of state changes, poorly handled
runtime exceptions, poorly handled runtime schema validation errors,
bidirectional data flow issues (which lead to glitchy state changes and
infinite loops), poor choice of ADTs which lead to inefficient code, poor
choice of libraries for the use case, misuse of common programming patterns,
and any other major logic errors... At best, it projects code from only 5% of
all possible bugs; typically the simplest, most obvious kinds of bugs. Please
think about this objectively. TS adds value, but very little value and also it
takes away value in other ways.

For the really difficult runtime bugs which take serious debug time, it adds
no value; it makes debugging harder because of its reliance on source mapping.

And by the way, instead of down-voting, please try to convince me otherwise
because I'm really suffering with the new TS-first reality (I'm on the losing
side). I really do want to see the light but I'm not seeing it at all.

I'm seeing masses of people running towards a cliff. I know there is a cliff
there because I pulled myself out of it (learned the hard way) and have been
walking in the opposite direction for the past few years and I don't see why I
should go back there simply because that's the direction where all the cool
people are heading.

~~~
azangru
> I've provided you at least 1 robust argument why this is not the case.
> You've provided 0.

I can share anecdotal data about my own experience while refactoring: I do
rely on the type checker (be it Flow or TypeScript) to alert me when my code
changes have introduced type errors. Every time I run the type checker I
realise that it would have taken me ages to read through my code and hunt down
the type mismatches that might have been introduced.

I can also point you to the famous AirBnB's slide, which says that they
estimate that around 40% of their bugs can be prevented with TypeScript [0]

> TypeScript ... does not

Sure. It's not perfect. It's not Haskell, or PureScript, or Scala, or OCaml.
But it does protect you from some of the errors. Protection from some of the
errors is better than no protection at all, that's my opinion.

As a bonus point, type annotations serve as a living documentation of your
code.

> instead of down-voting, please try to convince me otherwise

I did not downvote your post. I do not downvote other people's posts.

[0] -
[https://twitter.com/remohjansen/status/1093815648566894594?l...](https://twitter.com/remohjansen/status/1093815648566894594?lang=en)

~~~
cryptica
>> I can share anecdotal data about my own experience while refactoring

I totally understand what you're talking about here. I know that TS feeling of
being able to just tell the IDE to rename that variable or type anywhere and
have that change automatically applied everywhere in the whole codebase. That
said, my anecdotal data (having gone back and forth between first AS2 and AS3
for several years and then later between JS and TS multiple times over many
years) is that good tests (especially integration tests) even with modest
coverage are equally good at finding these sorts of bugs. If I forgot to
rename a variable, my tests will fail straight away.

Also, usually I try to keep my classes and functions localized with well
defined responsibilities so that any specific kind of data does not need to
traverse too many different files; that makes refactoring a lot easier. IMO,
not using TS puts more pressure on me to design code in this way and this
design approach yields many other benefits.

It takes encapsulation to another level. For example, I don't even believe in
the idea of 'cross-cutting concerns' anymore (which is central to the
Dependency Injection pattern). For me, the idea of cross-cutting concerns
implies a violation of the separation of concern principle (a violation of the
cross-cutting kind to be exact). There are almost always ways to avoid these
in your code and doing so is always worth it if the programming environment
allows it.

>> I can also point you to the famous AirBnB's slide, which says that they
estimate that around 40% of their bugs can be prevented with TypeScript

I did read that article when it came out but my point of view on this is that
if mostly the same developers rewrite a project (even if they did so in the
same language), I would expect at least 40% to 50% fewer bugs. I don't think
TypeScript should get the credit there. The reality is that people learn from
their mistakes so if they rewrite something, it's going to be better the next
time round.

