Hacker News Reader

Comment by 734129837261 | Hacker News Reader

I really don't see the point of strong typed programming. JavaScript is fine without it. I've been working with TypeScript for a while now and I never think "this solves a problem I had!"

On the contrary, I constantly think "why..."

I feel strong typing JS is just a result of backend developers not questioning their upbringings and failing to use proper naming conventions, progressive enhancement in the form of JSDOC comments, proper unit tests, and proper peer reviewing processes.

Honestly, I don't get it. In all my 20 years as a professional web developer (full stack and specialising in the frontend for the past 12 years) I have never needed it...

I really don't understand the charm of it.

View on HN

Aren't you describing exactly the problems types help with? Must be a reason why typed backend developers allegedly don't pay so much mind to:

- "proper" naming conventions

- JSDOC comments

- unit tests

- peer review

So, I've worked with JavaScript since 2001. Up until two years ago I never used a strong typed flavour on top of JS.

And I have never needed it. Not in big teams and not in small teams.

At work we recently did a timed programming problem solving competition. 20 Teams got 1 hour each to solve multiple levels of the same problems. Some teams used TypeScript.

None of the TypeScript teams got past level 5. All of the rest got past level 15.

I've been taking job applications where applicants get a limited amount of time to make their project. Let's say 20 hours, and it's a paid job. Everyone gets the same instructions.

Those who use TS are NEVER feature complete.

Coincidentally, those who use TS are also the ones who deliver one big DIV-soup and barely seem to understand CSS to begin with.

Strong typed JavaScript doesn't solve anything, in my opinion. And nobody has been able to convince me otherwise. TypeScript seems to be a reason for many developers to completely avoid documenting their code...

I mean, TSDOC or JSDOC allows you to write human-readable comments AND strong type your code where it matters. But they don't.

In any case, this article was a fun one to read:

https://medium.com/javascript-scene/the-typescript-tax-132ff...

Yeah, Typescript does slow a project down.

It's not even about using types. Sometimes you get stuck trying to resolve Typescript issues that are not part of your core problem.

Sounds like you just don't know how to cast a type for your specific case rather than a TS bug, which is fair to say as sometimes you need decent time to learn how to do it.

Strongly typed programs tend to have less bugs. There's been a few systematic surveys of large open-source projects looking at the number of issues raised/bugs found and they all show the same results.

I recently joined a company that uses formal methods and Haskell for a globally distributed system and I can't imagine going back to JavaScript for something similar. Being able to reason about a system is important and it's almost impossible to reason about non-statically typed systems.

I don't seen how problem solving competitions are any measure of worth for a language. That's like saying, teams that wrote tests didn't complete as many of the problems, so we shouldn't write tests. What about maintainability, ease of refactoring, catching of bugs during compliation time etc. There are tradeoffs to everything, you just have to decide what matters most to you.

> At work we recently did a timed programming problem solving competition.

Thankfully, real world software development is not done under arbitrary time constraints with teams competing on who can be first to complete a prototype. High quality software is very difficult to produce, and taking the time to adopt sane development practices that reduce cognitive load and detect bugs early on in the process often leads to maintainable codebases far beyond their prototype phase.

> In any case, this article was a fun one to read:

> https://medium.com/javascript-scene/the-typescript-tax-132ff...

It might be fun, but it reads like a movie review where the author gives arbitrary scores and somehow determines TypeScript's ROI based on that(?). The rest of the article mostly appeals to authority, as the author pushes his books, expertise and vast experience as proof, something you seem to be doing as well.

I feel like the mentioned "To Type or Not to Type" paper[1] is a more realistic study of the benefits of static typing, despite TS detecting "only" 15% of possible bugs. That's still 15% of bugs detected _during development_ that the programmer doesn't have to think about, and doesn't have to write thousands of very trivial tests to _maybe_ catch them locally or worse yet, in CI. This in practice never actually happens, let alone in code reviews!

Yes, static typing is not a panacea. But it's a tool that has high chances of producing higher quality software, something that is sorely needed in JS land.

[1]: http://earlbarr.com/publications/typestudy.pdf

Also, if you are using a statically typed language there are tools for property based testing like QuickCheck which eliminates the need to write those thousands of very trivial tests. I've seen one advertised for JavaScript but you can't guarantee it'll find everything thanks to typecasting.

At work we recently did a timed programming problem solving competition. 20 Teams got 1 hour each to solve multiple levels of the same problems.

If you're looking at the kind of requirements that can be implemented in under an hour, of course a stronger, more static type system isn't likely to gain you much. It's highly unlikely that such a program is going to have lots of different people working on it over a period of possibly years, or that it's going to use lots of different but possibly related data structures, or that it's going to develop libraries with hundreds or thousands of little utility functions for working with those data structures.

However, drawing conclusions about the merits of a stronger, more static type system based on this sort of challenge is like arguing that a language where all code has to be in defined modules and functions is much less efficient than a scripting language like Python because in the latter you can write a "Hello, world!" program in literally one line.

> None of the TypeScript teams got past level 5. All of the rest got past level 15.

The TypeScript-using teams also wrote a bunch of machine-verifiable documentation and code navigation tools, so I'm not surprised it was slower. I can tell you without even looking at them which codebases will tend to be more pleasant to join as a new developer. Though probably doing that extra, unrewarded work for some kind of challenge where speed is paramount wasn't the best idea.

Suppose you're using an editor that actually gives you clever warning if types don't match?

Using plain vim with typescript makes no sense.

It gives me plenty of useful checks using TS. Lack of members, wrong types returned, missing return in switch statement etc.

Saying JS works for you fine sounds like "I have (or waste) good amount of brain memory on my program, so I don't need any further checking.", which can't be the case on code other people wrote.

TS is definitely oversold. I like the typed function signatures, a little bit better autocompletion and some refactor support. Personally I also think typing can be fun. But it doesn't increase safety or productivity, and it comes with costs: build setup, having to import type, libs that have misleading types, having to cast when TS doesn't get it, etc.

Reply on news.ycombinator.com