Hacker News Reader

Comment by ggregoire | Hacker News Reader

Not directly related to this product (looks good btw!), but I've been using static type checking (Flow/TypeScript) for almost 2 years and since then, I haven't seen a single JS error in production. I do believe it's as important as writing tests now, if not more.

View on HN

Do you have client-side error logging setup? I find it very hard to believe you wouldn't encounter any browser bugs, or bugs due to external applications fucking around with the browser.

To give an example, I've seen lots of "antiviruses" inject code or perform unexpected DOM changes, causing certain things to break.

Other times a user shows up with a heavily tweaked browsers that behaves differently from what you'd expect.

Yes with Sentry. Also I don't make websites but b2b applications and I can so target the last browsers versions and most of our users don't try to tweak stuff.

What sort of "antiviruses" inject stuff in browsers? Do they inject their own JS? This is the first I've heard of this and would like to know more.

Shitty browser extensions mostly. It's like 99% of our sentry errors as well.

I don't remember which vendors were causing it, but yes, many inject their own JS, causing things to break and exceptions to be thrown.

Here's a StackExchange question: "How to disable Kaspersky Antivirus javascript injection?" [0].

And on Reddit: "PSA: Kaspersky injects remote javascript into all your pages. Even secure ones." [1].

[0] https://superuser.com/questions/981959/how-to-disable-kasper...

[1] https://www.reddit.com/r/privacy/comments/3frjqw/psa_kaspers...

Can also attest to this, had plenty of head-scratching issues before I realized on my home computer using kaspersky why our app was breaking.

When you look at the screenshot on the product's homepage, 5 out of the 6 shown errors are things that TypeScript would have immediately caught.

that's impressive. What would you recommend between flow and typescript for an existing react app with an already large codebase?

I know React devs tend to gravitate towards Flow (which makes sense, since both are developed by Facebook), but I personally recommend TypeScript solely because it has a larger ecosystem and far more library type definitions. The actual type systems are pretty much identical these days, but having type definitions for almost every external library makes the out-of-the-box experience much, much better. Also, I found TypeScript very easy to integrate into an existing webpack setup, whereas I had a lot of trouble getting Flow to work seamlessly (though, apparently many others have had the opposite experience, so take that with a grain of salt).

TypeScript is ahead of Flow in both tooling and type expressiveness. Both can easily be added to an existing code base in incremental steps. I'd go for TypeScript every day of the week, but both are good choices.

I'm using Flow but I'd recommend TypeScript. I love Flow but TypeScript just seems to be more seriously maintained and less buggy. I've been waiting some bug fixes for 2 years (like all the object destructing and spread issues[1]), but they prioritize the Facebook private internal roadmap.

I stick with Flow for now just because create-react-app doesn't support officially TypeScript, but it should be possible with the next major version that will include Babel 7.

[1] https://github.com/facebook/flow/issues/2405

Reply on news.ycombinator.com