Hacker News new | comments | ask | show | jobs | submit login
Future of TypeScript on ESLint (eslint.org)
233 points by ingve 28 days ago | hide | past | web | favorite | 85 comments

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...

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

Typescript is amazing!

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


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.

4000 LOC a day, every day, for 3 months? I hope that's a lot of boiler plate!

Depends on his coding style.

You can write Typescript like Java. You can also write it (almost) like Clojure. It's really very flexible, but without most of the insanity that flexibility causes in normal JS.

Typescript has a standard library like clojure for manipulating data? like the lodash of the JS world.

I would be surprised (without golfing of course) if typescript can match clojure's conciseness.

I didn't say it could match it. I don't think it can, but you can write it very concisely if you choose to.

There's not a big difference in concisesness or readability between Clojure threading macros and JS promise chaining, for example:

(-> (do x) then-do-y then-do-z then-do-q)


doX() .then(doY) .then(doZ) .then(doQ);

Of course, the Clojure version is more flexible, and the ability to define DSLs very simply allows for further conciseness, but that's all beside the point. My point is just that Typescript can be written very concisely or very verbosely, depending on your own coding style.

No, typescript adds as little as possible to support its language features. You'll need to rely on js libraries or browser features for the API.

This looks awesome, going to check it out this weekend!

FYI in a narrow (especially < ~1000px) the Features icons are overlapping content. I tried changing the class 'fa-4x' to 'fa-2x' on those icons and it appears to fix the issue.

Any chance you would ever add RSS capabilities?

Thinking about it actually but for now worried about feature creep. We will see though.

I was actually one of the original inventors of RSS 1.0 and was on the working group.


Is my other company and we have about a petabyte of content ... so definitely familiar with the space.

I'm trying to look at things a bit differently now though. I have a bunch of ideas I'm going to experimenting with.

Actually might just implement it because you guys at Hacker News will upvote me into the stratosphere ;)

So you did 750 thousand lines of code in 90 days? impressive.

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

Definitely always need help even if it's just feedback on releases.

The issue tracker is a good place to start looking :)

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.

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


>> 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.

also, looking for an answer to this question :)


Oh my god, getpolarized is exactly what I am currently trying to achieve. I tried out PDF.js to get highlighting and reading progress in my application but could never figure it out. This is amazing!!

Nice!! glad you approve! Jump on the Discord if you have any questions.

Have you used flow at all in the past? If so what would you say the major differences are/how difficult was any process to convert over? I'm a huge fan of having the types defined just from a documentation perspective nevermind bug catching and debugging and all that. I feel relatively agnostic about the particular thing we use to do it so I'm curious as to what the differences are.

But yeah it really has improved my day to day immensely and I really feel the difference when I'm working in legacy portions of our apps that pre-date the flow adoption.

I have used both TypeScript (for multiple projects) and Flow (at Facebook). TypeScript is much more feature-rich and looser in strictness. In practice, this looseness has been preferable, as I've seen many of my colleagues fighting Flow's type system vs TypeScript (prior to FB). In theory, perhaps Flow's type system prevents more bugs, but I've sometimes seen it circumvented with hacks just to get past its strictness. TypeScript's ability to infer types seems much smarter than Flow's as well.

Besides that, TypeScript has much wider adoption and community support. Most issues I have with TypeScript I can find others who have had similar issues on the web, where as I can't say the same about Flow.

There's been a lot of doubt cast on Flow outside of Facebook when Jest announced it was moving to TS.

I'm curious to hear how Typescript vs Flow discussions go within Facebook, and what engineers there think of each.

I would also like to know how many projects within Facebook, if any, use Typescript. I'd be interested in the growth rate as well (how many projects over time).

I have never used Flow beyond a basic hello world. The syntax is very similar. Some of the nomenclatures vary. All and all they will both accomplish 99% of the same thing - statically typing a dynamic language. Which gives you much more code confidence, `foobar is undefined` is very less likely. self-documenting code. (see: vs-code intellisense) And code maintenance scale abilities currently not possible with such a loose language like javascript.

So I would say if you're interested pick one and dive in.

Right now typescript has a lot of community momentum: https://github.com/DefinitelyTyped/DefinitelyTyped

And an extremely fast, open sourced, plugin enabled editor, vs-code ftw! I am a convert after being a longtime diehard vim user. (vs-code has the best vim binding emulation I have ever used in a free open sourced editor)

Facebook is deprecating their flow atom editor plugin; nuclide - https://twitter.com/fbopensource/status/1072928679695548416?...

This is all why I would choose typescript over flow if it were up to me. maybe a flow user can chime in.

I've used Flow very heavily and TypeScript a reasonable amount. They're pretty similar really, but I'd recommend TypeScript for its better tooling and larger available set of type definitions.

Flow doesn't seem to be built with the (non-Facebook) developer experience in mind. It very frequently has breaking changes. The tooling is worse. There's no good official way to publish a package to npm with Flow type definitions included. Its alternative to DefinitelyTyped requires using their own CLI tool instead of copying DefinitelyTyped's simple npm-based strategy.

There a few things Flow does better. Functions internal to a file often don't need their parameters to be typed because Flow infers their types, but honestly I don't think that's a very killer feature. I often type them anyway just to be explicit. Flow does model type variance better (a Promise<{a:string,b:string}> can be cast to Promise<{a:string}>, but not vice versa, and you can't do the same with mutable arrays, etc.) but variance doesn't come up often and you can always use the any-type escape hatch in TypeScript to make it through those uncommon situations. I do hope TypeScript gets better about that though.

Flow isn't bad; a Flow codebase is still much better than an untyped Javascript codebase. But if you're starting a new project and have the choice, pick TypeScript.

Agree on 100% of this.

Also errors in Flow are often very esoteric. The "smarter inference" sometimes made type errors appear in the callee rather than the caller (having an error on React's component type definition is not helpful). The wording isn't user-friendly if you're not familiar with typing theory.

Inference is not that much of a killer feature I feel: I don't want the type to be inferred based on how I use a variable, I want to check that I don't misuse the variable based on its type. Obviously there's use for inference too, but in the general case...

Also, if you're looking to introduce types to an extant Javascript project, there's a good chance you're already using babel. That used to be a (slight) point in flow's favor, but as of Babel 7, you can opt to have Babel transpile your TypeScript. Not that there's anything wrong with tsc. :)

Typescript's tooling is much better -- it's just a JS transpiler (and now you can use babel to do your transpiling if you prefer). Flow's daemon-style approach was a constant source of pain for me.

Flow operates very similarly: the recommended setup is to use it with Babel. Babel just strips out the type annotations from your code to make it into legal javascript. The Flow daemon executable was just to provide type checking. Before TypeScript also got similar Babel support, I considered it a strong point in Flow's favor that it was so easy to drop in if you already had a Babel setup going.

> The Flow daemon executable was just to provide type checking.

This is problematic. Now your webpack build is shelling out asynchronously to a second process. It makes it very hard to integrate type checking to a build system.

I've never connected Flow to webpack or my compile process like that. When I've used Flow or TypeScript with Babel, the build process and type checking were always two separate things. I treated type checking like unit tests: something I'd frequently re-check while working on code, but not something connected to the path of getting code running somewhere.

Don't you want your build to fail if the type checker fails? I think it's pretty important for a large project.

Not necessarily locally. On CI/staging/prod yeah definitely, but when I'm hacking around I'm fine with having type errors ("yeah yeah I know this is nullable, I don't care right now I just want to investigate this bug")

I absolutely want it locally, preferably inside my IDE where it's providing type hints, allowing navigation to type declarations, and alerting me immediately to typing issues live as I'm coding.

Of course I want the type checking locally, what we mean is that we don't want it to prevent webpack to build if the typecheck fails

Flow gives you all of that. The fact that the type checker is separated from the emitter does not mean you can't get any of that.

I don't really feel strongly about it, though sometimes Flow takes 10+ seconds to re-check a large project I work on after changes, and I wouldn't want building to have to wait on that. (I've never worked on a similarly-sized project in TypeScript, but I expect it's about the same situation.) I usually use a CI system (CircleCI) which sends me an email if any of my commits don't pass type checking or unit tests, and it flags any PRs on Github that fail too.

Only in CI, not during development. IDE warnings are enough.

I've deployed flow extensively and the biggest difference is that flow is horribly buggy (lots of false negatives) while typescript is mature. In theory flow's type system is stronger but it's so unreliable that 99% of the time I'd rather use typescript.

I found this post quite interesting. These guys migrated a big codebase from flow to typescript. https://davidgom.es/porting-30k-lines-of-code-from-flow-to-t...

The main issue I found with flow is importing type packages.

A tiny part of me still hopes that one day JS standard adopts 100% of TypeScript features.

Official support would make it hard for it to ever have any breaking changes though. I think I'd like to give TypeScript more time before risking putting any of it in stone.

Is JS a strict subset of TypeScript?

Yes. All JS code – including recent ES* flavors – is valid TypeScript.

This is true of syntax, but it’s not true of the language semantics. There is plenty of perfectly valid JavaScript that isn’t valid TypeScript, so integrating TypeScript into the ECMAScript standard would require something similar to ES5’s “use strict”.

I can’t find the link which details this right now, but I believe there are/were some cases where Flow’s syntax isn’t strictly a superset of JavaScript (to do with generics and comparison operators). I’m not sure whether TypeScript has the same problem or not.

Almost. This is valid javascript.


TypeScript code can be transpiled and executed even if there are type errors (just like how a linter doesn't stop you from running your code), so in that sense, it's also valid TypeScript.

Technically typescript is a strict superset of JS, but yes

Technically technically, it turns out that no it's not. I recently realized that `a<b>(x)`, `a<b,c>(x)` and variations mean something completely different in TS than they do in JS.

And that’s exactly why Rust has the turbofish (a :: before the <), to resolve that syntactic ambiguity. TypeScript could have resolved it by requiring a . before the <, but it didn’t, and so you can devise contrived cases like this where it differs from JavaScript.

Is that denoting generics? Can you give an example?

Yeah, it's the syntax when calling a generic function, e.g. `Array.of<number | null>(1, 2, null);` has return type `Array<number | null>`. You usually don't need to specify the type since TypeScript can figure it out, but sometime's it's necessary to specify it explicitly.

TypeScript compiles `a<b>(x)` to `a(x)`, which is a function call, but when run as plain JS, `a<b>(x)` is a less-than and greater-than comparison between a, b, and x.

That's interesting and so obvious now that you mention it. Thanks for the clarification.

How's the migration path? I use TypeScript for new React apps I build, but I'm dealing with some JS projects where there's just no way to convert everything to TS all at once.

Does TS work well alongside legacy JS so you can update individual files incrementally as you go along? I remember trying it once and facing some unexpected blockers, but I don't remember what they were.

It's very seamless. There's a flag, allowJs, that lets you import js files with only sanity checks (no actual typechecking). You can then start converting individual files to Typescript as you go.

Thanks! I wish I could remember what I ran into the last time. I guess I'll just have to try.

I believe the allowJS flag is new and disabled by default. It may not have existed when you last tried. That’s what happened with our team. We tried to switch in either 0.x or low 1.x and at the time I believe we had to convert everything to TS (although, we may just not have been aware of the allowJS flag at the time).

I'm 100% with you. I find it far more sane, and encourages better practices (in my case).

When I'm responsible for tooling in a JavaScript project, it's pretty well a given that I'll push for TypeScript.

I still feel better with thin/no tooling for transpiling, flow types in comments. There’s something nice about no or ultra flat dependencies and instant npm i that keeps me there.

Typescript also supports type checking pure JS files, as well as type annotations via JSDoc comments, if you don't want to transpile.

I like how TS also enables future JS features by transpilation. async / await was great to have quite early on.

If you use VSCode just put `// @ts-check` at the top of your files. I find a bunch of bugs with just that.

100%! Whatever happened to progressive enhancement?

It's a design trade-off. TypeScript is close enough to JavaScript but adding the compiler step actually enables worthwhile changes to improve code safety. And Typescript can import JavaScript modules anyway, so really you just lose the ability to write both in the same file.

I'd like to see at some point browsers treating TS as a typed JS variant, and using the hints to speed up things perhaps too.

I think if you make things consistently typed (as typescript will help enforce), then your JS will run faster already. Because a lot of techniques JS JITs use are basically guessing the type of variables, and then bailing out into a slow path if it turns out they guessed wrong. Codebases like lodash make use of this, which is one reason why they're so fast.

Would be nice if Chromium picks it up which can be propagated to Chrome and Safari on desktop and mobile and Edge then to nodejs and others will surely pick it up if those adopt it.

That’d be terrible as the language version changes semantics.

So same as with plain JS?

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.

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.

Typescript is not intended to work in browsers without a compile step being involved.

Finally the JavaScript community is stabilising! This is exciting

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

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.


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.


- 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.


- 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.

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.

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.

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.

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.

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.

The tests asserting certain properties are just type checks, albeit weak and less-safe ones. If you have to make sure a property exists then that is 100% not a logic concern. It's a check on the structural integrity of the module.

You can eliminate a whole group of tests in TS that you would otherwise need in a JS project.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact