Hacker News Reader

Comment by wry_discontent | Hacker News Reader

I feel like the odd man out in discussions like these. I don't like Typescript and I regret pushing to integrate it into a project at work.

I've found it vastly increases incidental complexity and affords little to no benefit to me. The IDE completions are nice, but ultimately not worth the price, in my humble and honest opinion.

View on HN

After working in Typescript for 18 months I've moved onto a new Rails project and I miss type checking so much every single day. There are so many dumb bugs that have slipped their way into production that would have been caught by type checks and null checks. It's professionally embarrassing for the client to see this stuff that would have been stopped by better tools.

Have you looked at Sorbet?

https://sorbet.org/

Yeah I tried using this on our current project but it couldn't really handle Rails + all the gems we're using. I think it's very difficult to retrofit types onto a codebase with deep roots in dynamic code.

Just hope ruby 3 would integrate static typing.

The real benefit is with refactoring. It is built-in testing. If I change an interface because a business requirement changed, I immediately follow a trail of errors that I need to fix. If types are setup properly, making major changes is dramatically simpler to accomplish.

I also disliked my time with TypeScript, but perhaps its value hasn't made itself entirely apparent to me. Most of my programming experience has also been with dynamically typed languages. I think if you had already spent enough time with a language like JavaScript or Lua and familiarized yourself with its quirks/footguns, you learn how to avoid the common pitfalls of not having a strict type system.

Although I've found that TypeScript is a great way to attract devs who hate JavaScript to try working on front-end.

When working with devs that have grown up on dynamically typed languages I often find that they have not really thought carefully about the structure of their data and there are essentially many ad hoc data types strewn throughout the code. Thinking in types from the beginning leads to much better structured code and stronger abstractions IMO.

I couldn't agree more. I think the introduction of types in JS (either TS or flow) has been the single biggest leap in front end development in a decade.

I see the same thing, but in people who primarily work in statically typed languages. I don't think there's much of a pattern in wrt types, but people who don't think about data.

Specifying all those complex ad hoc data types in a statically typed language is so tedious I think it pushes you to start looking for unifying abstractions.

What editor are you using? If you don't use an editor that supports TS, then it's all moot.

Editors are meant to auto complete any parameters that you have typed as well as provide errors that don't fit to your typing.

Using editors like vim wouldn't work.

> Using editors like vim wouldn't work

Hi. Fellow emacs enthusiast here. We can evangelize emacs tide mode and slander vim on other TypeScript articles, but I think it's best not to do so on this article, because it specifically mentions vim in the editor support section.

https://svelte.dev/blog/svelte-and-typescript#2_Editor_Suppo...

Hey, I used VSCode. I could see how tightly integrated TS was with it, and I appreciated it.

How large is your TypeScript project? What were your type issues before you integrated?

My work has benefited from TypeScript because we can now propagate changes to our unstable API throughout our medium sized application using the compiler. We are fairly certain that all of our components are integrated if the compiler is silent. Before this certainty, we would frequently push broken API integrations to production.

The complexity of TypeScript doesn't seem to benefit projects that are already clean and tested. TypeScript gave us some confidence of correctness when we had disorganized code and inadequate test coverage.

It's about 20kloc.

I encounter seemingly nonstop opaque type errors that come usually when I upgrade TS versions. I'll stipulate this was mostly written when we decided to add TS, and I was new to TS when I added it, but I tried really hard.

As an example, it took me a full week to properly add type definitions to a HOC, and I had to rope in a couple other engineers across that time who had more TS experience. Eventually I got it working, but decided to deprecate the HOC cause the file exploded from being about 50loc to well over 250.

The last large project I added Typescript, it took several weeks to add types. It took another year to learn how to write code in a way that is more likely to be successful in Typescript.

If you have a ton of state, classes, high coupling and a lot of variance in your data structures (which Javascript really easily allows), Typescript is not an instant game-changer.

This is not that different from having good test coverage is easier during development than adding it later, as you will end up writing your code in a way that makes things more decoupled and testable.

It was way easier to get to that sweet spot with our Node.js code vs. our React code. React code is still more of a battle than non-React code, although functional components has made this better. Class based components suck the most and we just opt for using "any" instead of fighting it. Don't get me started about HoC.

Yeah by the numbers I like it (sum types!), but what put me off is in practice, TS is built for autocomplete. If you aren’t using that, it’s a real pain to guess what type you need to say, and you’re basically digging through code or bad/old docs to find out.

I also found the typing to not really help. Non-null stuff is nice, but without range types, I don’t think the trade off is worth it. It helps about as much as Go’s type system but asks you to do 3x the work, restrict yourself to typed libraries, and setup some pretty tricky tooling.

TS was designed to solve a problem. If you cannot see the problem, then you do not need it. Unless when working in teams with devs more used to thinking and structuring their code around types.

Actually TS shows you the problem when you hadn't realized.

Use it with a proper editor that supports TS like VS code or IntelliJ and figure it out.

I have used TS before, and VS Code is the best editor. I simply do not have a problem with JS, or dynamic languages for that matter.

HN has a high proportion of experienced programmers coming from typed languages. If you are a C# dev who has to write JS, I'm sure typescript is a breath of fresh air, but from where I stand it's awful. The whole point of TS is to reduce the friction in writing JS for those people.

However, from where I stand, Typescript sucks. Sucks sucks sucks. It takes everything I love about JS programming and turns it into suck.

Reply on news.ycombinator.com