
Future of TypeScript on ESLint - ingve
https://eslint.org/blog/2019/01/future-typescript-eslint
======
_robbywashere
It's very nice to see all of this consolidation going on in the Typescript
ecosystem. For example Babel 7 shipping with direct Typescript support back in
August,
[https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...](https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-
and-babel-7)

I am a Typescript convert myself and would suggest any daily JS developer give
it an honest try.

~~~
burtonator
Typescript is amazing!

I spent the last 90 days porting about 350k lines of code to Typescript plus
implementing another 400k.

[https://getpolarized.io/](https://getpolarized.io/)

It's basically a document and annotation manager for PDF and notes. Kind of an
Open Source Mendeley/Evernote/Github if you will.

This code base is changing often and I really hit a dead in in terms of JS
scalability.

I was just refactoring too much, breaking things, etc.

Now I can just rely on the compiler when I break things.

If I want to change a function type in TS it's no problem.

In JS it's a nightmare.

~~~
misiti3780
your project is amazing, i would love to help contribute as i have time.
please reach out if you need development help.

~~~
jondubois
WTF. The project seems completely useless and gimmicky to me.

My problem is that I read a LOT of articles and publications. If I started
highlighting things in articles, I would never have enough time to go back to
them. Besides, why would I want to? I already read it, which means that it's
already in my mind! What's the point of reading stuff if not to put
information inside your mind? I'd rather use my time to read more new stuff
than to revisit things I already know.

Maybe the solution is not more tools, it's just to stick to topics that
interest you and to pay attention and put more thought into what you're
reading.

~~~
misiti3780
maybe you should be a little less critical about someone who actually built
something extremely useful and spend some time investigating the topic of
"incremental reading" \-- reading info and retaining info are two different
things

[https://www.supermemo.com/help/read.htm](https://www.supermemo.com/help/read.htm)

~~~
jondubois
>> reading info and retaining info are two different things

I apologize, I projected my own experience and assumed that other people were
able to remember the main points of what they read. I guess most people don't
have have great memory. I never thought of myself has having good memory but I
remember the main points of most of what I read.

------
mikewhy
One of my favorite things about typescript was being able to ditch Babel and
eslint and their myriad of requirements to get things that are considered
standard. I get why they do it, it's just something I prefer.

Take create-react-app and the now deprecated create-react-app-typescript. The
node_modules folder of the CRA app is over a hundred megs bigger than that of
CRA-ts, and it doesn't even have feature parity.

~~~
QML
Is this still dependent on browser adoption? I recently had to transpile a
Typescript library via Babel to JavaScript since Chrome didn’t like the
original import statements.

~~~
crooked-v
Typescript is not intended to work in browsers without a compile step being
involved.

------
iddan
Finally the JavaScript community is stabilising! This is exciting

------
hiccuphippo
Would it be possible for TS to skip JS and compile directly to Wasm? Would
that bring noticeable difference? At least for mobile browsers?

~~~
fermuch
With AssemblyScript you can do exactly that, but I've never seen it being used
for big projects, since it doesn't support the "any" type.

[https://github.com/AssemblyScript/assemblyscript/blob/master...](https://github.com/AssemblyScript/assemblyscript/blob/master/README.md)

------
jondubois
I'm disappointed by the growing popularity of TypeScript.

My very first programming language was ActionScript 2 (which was also based on
the ECMAScript standard without types; just like JavaScript) and I clearly
remember that I was really enjoying ActionScript 3 when it came out in 2006
(that's when ActionScript became a statically typed language; very similar to
TypeScript).

Then a few years later, I got back to JavaScript/Node.js (dynamically typed)
and I noticed that I could create libraries and applications a LOT faster
without types and that writing libraries was also a lot more enjoyable.

My view now is that statically typed languages are like training wheels on a
bike. Statically typed languages force you to think about software in a
structured way and in doing so, they teach you some fundamental concepts about
abstraction. That said, if you're experienced enough to know how to structure
and test your code correctly, then, much like training wheels on a bike; they
only slow you down.

I've been using TypeScript for the past couple of years at work so I can
confidently say that it creates more obstacles than it solves for me.

Pros:

\- Easier to keep track of all the places in the code which are affected by a
refactoring (especially if the code is messy, poorly tested and components
have poor separation of concerns; it gives useful warnings).

\- Easier to find class and method definitions in the code.

\- Easier to rename classes, functions and properties.

\- Much less likely to leave forgotten unused variables or functions in your
code.

Cons:

\- Slow debug cycle due to increased compile time. If using TDD, it takes
longer to run tests.

\- Sporadic source mapping issues/bugs which makes it hard to fix things (I
had an issue with Mocha tests last week where it was always telling me that
the issue was on line 1). I've worked with TypeScript on multiple projects
across different companies but every single time, there has been source
mapping or configuration issues of some kind.

\- Type definitions from DefinitelyTyped are often out of date or have missing
properties/methods. It means that I can't use the latest version of a library.

\- Third party libraries are difficult to integrate into my project's code due
to conflicts in type names or structural philosophy (e.g. they leverage types
to impose constraints which are inconsistent with my project requirements).

\- Doesn't guarantee type safety at runtime; e.g. If parsing an object from
JSON at runtime; you still need to do type validation explicitly. The
'unknown' type helps but it's not clear that this whole flow of validating
unknown data and then casting to a known type adds any value over regular
schema validation done in plain JavaScript.

\- Whenever I write any class/method, I have to spend a considerable amount of
time and energy thinking about how to impose constraints on the user of the
library/module instead of assuming that the user is an intelligent person who
knows what they're doing.

\- Compiler warnings make it hard to test code quickly using console.log(...);
I'm more reliant on clunky debuggers which slows me down a lot and breaks my
train of thought.

\- The 'rename symbol' feature supported by some IDEs is nice, but if a class
or property is mentioned inside a string (e.g. in a test case definition) then
it will not rename that; so I still have to do text search after doing a
symbol rename and manually clean up.

\- It takes a lot of time think of good names for interfaces and they are
renamed often as project requirements evolve. It's not always clear whether
similar concepts should be different types or merged into one. It often comes
down to what constraints you want to impose on users; This adds a whole layer
of unnecessary mental work which could have been better spent on thinking
about logic only.

\- Setting up TypeScript is a pain.

\- Adds a lot of dependencies and complexity.

\- Makes the bundling step a necessity. This goes against innovations like
HTTP 2 which could potentially remove the necessity of the bundling step by
allowing us to preemptively push scripts to the client.

~~~
matchbok
Any project of substantial size needs types. Either explicit (TS) or implicit
(JS with tons of type checking and assertion garbage). TS makes this much,
much better.

~~~
jondubois
I strongly disagree. A well structured project which is broken up into
meaningful modules with good separation of concerns and where each significant
module is tested in isolation; that kind of project does not need TS.

You don't need to do type assertions with JavaScript; in the tests you may
need to assert that certain properties exist but only to the extent that this
property is relevant to the test case. This is purely a logic concern, not a
typing concerns.

Types are just labels which try to make sense of reality so it makes no sense
to assert their correctness.

~~~
audiolion
Any project of sufficient size will have warts. Python added type checking
after Guido saw how hard it was going to be to port Dropbox's 2mil LOC
codebase to python 3. There is a reason the two most popular dynamic languages
have added a type system.

~~~
jondubois
There is also a reason why Java lost popularity. People think that languages
like TypeScript are somehow different, but they're not. TypeScript encourages
exactly the same patterns as those used in Java. Mark my words, it will suffer
from exactly the same problems. It will just take a few years for people to
realize this.

~~~
matchbok
Comparing the type systems of Java and Typescript shows a lack of
understanding of the differences between them. Modern type-safe language have
numerous things that Java never had and probably never will.

Any project of size will need types. Either they will be explicit (static
typing) or the project will be riddled comments, tests, assertions, and bugs.

