https://github.com/microsoft/TypeScript/issues
Please count the number of open bugs
JS tooling is already an enormous jenga tower as it is, with tooling breakages eating a double digit of developer time. Adding typescript on top of that would be the real madness.
Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them.
On the down side, even certainly not cheap to hire devs with 6-7-8-10+ years of experience have to battle JS tooling every day.
Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs.
Imagine doubling that digit when they have to also spend time on learning typescript, and fixing it.
No, it does not pay off at all
You realize you're probably creating bugs yourself by removing typescript manually, which is a thing.. typescript itself can do, by compiling down to JS?
This is some prime dailywtf material.
Nothing was said about whether typescript code is more or less buggy, just that the typescript tooling had issue to work with other tooling.
Who are these mythical people?
Do they just magically decipher what interface an argument conforms to? What methods are accessible on a returned result from any random library they're using?
I see TypesScript as a VERY opinionated linter that affects how you think and write JS. JS is a dynamically typed language, which means you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns. Yes, I get it, many programmers think best and are most productive using strongly typed languages, but for those of us that can think dynamic or both, TS just gets in the way.
>> Do they just magically decipher what interface an argument conforms to?
This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply.
>> What methods are accessible on a returned result from any random library they're using?
Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.
For what it's worth, my experience with programmers who think like you is that rarely they're actually genuinely talented and right, and mostly they just spew forth bugs which often sit dormant until they rear their ugly heads years later. Most people are better off thinking about their API's before they implement them, much like one would do in a real engineering discipline. Types are often (and yes, not always) a good way to draw the effort out to the front of your process.
Only the first and last sentences actually addressed the topic, the rest was just an angry emotional attack on those who think differently from you. Hope you're feeling better now.
Interfaces as a general concept applies whether there is a type system to ensure that they are satisfied or not. Do you have function parameter lists? Do you have expected shapes for function inputs and outputs? Do you have distinct types? Then you have interfaces. Your shit breaks when they aren't conformed to. It has nothing to do with strong typing or object orientation. Strong, static typing is just a way to ensure at compile-time that the expected interfaces are satisfied.
> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.
Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm not convinced.
>>Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm not convinced.
It wasn't me. Maybe a TypeScript compiler will help you correctly follow the comment threads? ;)
Not really. My definition of a language feature is something the compiler supports and checks for. JS does not have interfaces. What you're talking about are patterns and best practices, so you're getting there...
JS is a dynamic language. Just deal with it already... you sound smart enough to support both paradigms at the same time in your head.
I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript?
You are called to edit a function that takes 2 arguments:
function handle_req(request, options):
What is request in this context and what is options?
What makes me more productive, going up the stack and seeing who might call this function and with what argument, or instantly knowing what the domain of values it operates on is and being able to treat this as a separate unit?
>Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.
A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?
Okay.
Well... but Typescript doesn't ensure those situations won't happen, ironically because it's a superset of Javascript and it's not strict enough. Typescript is just documentation that compiles. If a library has bad documentation, it's likely to have bad Typescript as well, and bad Typescript can be a giant curse.
Typescript will happily allow you to force a typecast that doesn't reflect reality -- it will happily allow you to say that a method always returns a string when sometimes it returns a number, and it will happily compile in those scenarios.
Tracking those bugs down are a giant pain. I don't hate Typescript, but people who look at this and think, "I don't have to care about what libraries I'm using, I can just trust the interface" are fooling themselves. I've debugged plenty of errors in Typescript code that ended up being the result of me trusting an interface that didn't reflect the reality at runtime.
There's value in Typescript for some projects, but it does not remove the need to be careful about documentation and dependencies, because it's so easy for both dependencies and downstream code to circumvent the protections Typescript gives you.
Why would the suggestion to explore non OOP, strongly typed languages sounds patronizing to you? The more different languages you play with, the broader your mental modelling toolset becomes. It is painfully obvious to me that someone worried about interfaces in JS is not very familiar with more dynamically typed or/and functional languages. JS is a VERY FLEXIBLE language which can be coded in any style, which is why I've suggest playing with something more opinionated to get the gist. Languages like XSLT, Erlang, LISP, Haskell etc.
> You are called to edit a function that takes 2 arguments:
> function handle_req(request, options):
> What is request in this context and what is options?
The fact that you can edit handle_req means it is application code. So how you figure that out comes down to the structure and patterns you and your team use (if any) and the available documentation (if any). You'd be surprised how far Eslint and JSDoc will take you. TypeScript accomplishes the same, and I've no problem using it within a team that needs it but personally, it feels like an overkill I don't really need to.
> A whole lot of the time, especially in JavaScript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?
The decision to use TypeScript or any other tooling should really be made at the BEGINING of a project, so why are we talking about projects that already missed the boat, and even worse lack documentation and tests? This just proves my point, what you really need is discipline (documentation, tests, best praise etc) and a good linter, not a whole new language or programming paradgim.
If you actually use Typescript with a lot of dynamic/unsafe types, in practice you will very quickly end up with a lot of code littered with `any` casts, and those unsafe code blocks will end up (for lack of a better word) infecting the rest of your code and making the compile-time errors much less useful.
For whatever it's worth, my advice is in the instances where you decide Typescript is right for you, commit to it. For the most part, use interfaces, and use strict types that don't get recast a whole bunch.
You don't want Typescript to be guessing too much about your code, because some of those intuitions are fragile and can turn into bugs later if you assume Typescript just knows what you mean. I've had code that works until it gets refactored and Typescript stops being able to intuit what a type is. At that point, going back and retroactively trying to make things more explicit becomes a lot harder and a lot more error prone. The temptation there is to just shortcut the entire process and force Typescript to accept that a type is what you say it is -- and that can lead to very subtle bugs that are hard to track down.
The best Typescript code I've seen is code that embraces the rigidness. When I see a Typescript project with a lot of `any` casts, I start to get kind of nervous.
A decade ago isn't very long ago. JavaScript is more than 24 years old, and we had to get along without good design patterns or good linters or good debuggers or good libraries or good documentation or good IDEs or good compilers or even good interpreters back then. It sounds like you were late to the party and missed all the fun! ;)
I'm still waiting for a browser to come with an inbuilt server like netscaape 3.
Ha ha! You remind me of Larry Wall:
https://news.ycombinator.com/item?id=22210073
>"I think IDEs make language developers lazy." -Larry Wall
https://www.youtube.com/watch?v=AO43p2Wqc08
To which James Gosling replied:
>"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling
Andrew Hejlsberg also made some good points in that same discussion:
>Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly.
>A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with.
>But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago.
>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm.
>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".
>It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already.
>And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist.
>It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster.
In the HN discussion of that talk, I wrote:
https://news.ycombinator.com/item?id=19568860
>Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users.
>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.
>But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)
Andrew Hejlsberg's point is that TypeScript is a "multi-paradigm" language: it's not just strongly typed, but also structurally typed, interface based, plus everything else JavaScript itself is: dynamically typed, duck typed, functional, imperative, event driven, class based, prototype based, object oriented, etc.
Even the term "object oriented" has a broad spectrum of independent meanings: JavaScript has many but not all of the a la carte menu of features or properties of "object orientation" that Jonathan Rees listed in response to Paul Graham's essay "Why Arc isn't Especially Object-Oriented".
http://paulgraham.com/reesoo.html
http://mumble.net/~jar/articles/oo.html
http://paulgraham.com/noop.html
Andrew Hejlsberg said:
>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".
It's a mistake to think that TypeScript restricts you to just one way of programming, and you have to give up the ways you used to program JavaScript. TypeScript ADDS to the number of ways you can program JavaScript. It's a superset of the multiple programming paradigms that JavaScript supports.
You don't "loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns" -- quite the opposite, you don't "lose" anything: you actually gain more "flexibility" and more "language" patterns.
If you held a gun to my head and forced me to recklessly provide conjecture on what the difference is, I would say that static languages encourage devs to build large interfaces that take tons of options and pass around a bunch of parameters. This is highly, highly subjective, but:
I think there's a grain of truth in what other people are saying about how Typescript projects tend to be kind of verbose. People start reaching for interfaces that are split across multiple files, people start reaching for classes. When you have really rigid types that need to be formally extended all over the place, this also encourages a lot of casting, which tends to be error prone.
I've seen some really complicated logic/type flows in Typescript that would be extremely error prone in Javascript, but there's basically no reason for them to be that complicated in the first place. There are paradigms in Javascript the codebases are not taking advantage of which are forcing them into these over-complicated logic/data flows. Basically, the more crazy boilerplate, casting, and giant interfaces that a codebase has, the more type errors will occur. The more a project is split up into dozens of dependencies and modules and whatever, the harder it is to reason about what a method or class needs passed in. But Typescript projects tend to grow in that direction very quickly, so the need for Typescript tends to become a self-fulfilling prophecy.
As a comparison, most of the personal projects I work on don't have classes at all, they're using a lot of functional interfaces, and they don't include a bunch of random libraries. Most of the dependencies in my projects are libraries that I've personally vetted. Most of my projects are careful about where state is being stored and how its being passed around.
I dunno. All of that is pure conjecture, but people in general are very dismissive of dynamic typing, but it's just not a real problem for me. There's a general consensus that dynamic languages were a mistake, and I don't dismiss the people saying this, but I also pay a lot of attention to where bugs are coming from in my own code, and I can't get past the point that typing really doesn't seem to matter that much in most things I build.
I was on the Typescript train for a while. I still use it in some projects, there are some org structures where it makes a lot of sense. If I'm working with a Java-to-Javascript dev, I want strong interfaces for them. The projects where I don't use it are because I've spent a long time paying attention to where my bugs are coming from. I can't prove to you its not a problem, I can only speak to the experiences I've had.
TS tooling either replaces JS tooling or interacts with it seamlessly. It's not like you're skipping JS altogether and there's no type-checking in JS anyway so where's the interference?
Can you give a concrete example where TS is a blocking issue for your development?
People who spent time with JS and webdev in general got to learn that JS is a minefield of a language, and they work with that in mind. Typing discipline is pretty much the first thing people learn when they try doing JS seriously.
How to say. There is no way just adding typing to JS will make JS less of a JS. You still have to be a very disciplined dev to work with a typescript for it retaining many other tricky parts from JS.
> Can you give a concrete example where typescript is a blocking issue for your development?
Typical example: the tsc transpiler plainly dies, and you know nothing how to debug it, you know nothing of its internals, and you loose the rest of the day doing fruitless email exchanges with typescript dev team, and trying to trace a breaking commit.
Second example: you got a prod breakage report in some hard to reproduce case. You fire a debugger in chrome through vscode, and then you find out that the debugger completely loses the execution flow in transpiler/tooling garbage, and broken source maps. Having a debugger pick code that went through webpack (be it cursed) is already a 50/50 lottery, and additional layer of tooling makes it even worse.
If you're saying that you can't handle the overhead of Typescript config because your devs already spend so much time struggling with the rest of your tooling, by all mean get your shit together with your tooling, this amount of time spent on it isn't any sort of acceptable. You have huge problems.
> most of devs we hire are long past the stage when typing errors are a thing for them
This is just not a thing.
You do realise the large number of open issues almost certainly relates to Typescript's compiler and language implementation? When a project is written in Typescript, it does not mean all those bugs will inevitably plague the project itself. If I wrote "hello world" in Typescript with a Webpack + Babel project starter, it doesn't suddenly mean I now have thousands of open Typescript bugs to deal with.
Also: the number of closed issues outnumbers open ones by almost x5. Moreover, the total number of issues exceeds 20 thousand; the number is only so high because so many people have already adopted Typescript into their dev workflows. It's a sign it's been battle tested extensively.
> Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs.
Half? This just seems totally implausible; this could only be true if you were constantly modifying your webpack and babel setup and config files and breaking things.
I’ve done JS with and without types. I’d find a new job before going back to working without them. That’s how dramatic the benefits have been in my code.
Nonsense. Static type systems help you write correct code. They're also extremely helpful for refactoring. They also help readability. Outside the JavaScript world, they also help performance. The list goes on.
No-one is too smart for type systems to be helpful.
> it does not pay off at all
You've entirely ignored that TypeScript helps reduce bugs, and helps catch them earlier.
It's genuinely terrifying to think that people out there with this attitude are producing software that I might be at risk of using.
