7 ms·

Is Typescript necessary for front-end Javascript? In the many years I've done front-end with Javascript, type-related bugs were very, very rare. Textbook logic

• place1 9y ago
  Type errors might not be the biggest issue up-front when writing new frontend code, but refactoring JS becomes really hard as the LOCs grow. Typescript (static typeing in general) really helps with this as you can get instance feedback about how you're changing interfaces between parts of the system. Another reason i've enjoyed TS is the editor intellisense support. It's really helpful when using a library to get type info in your editor instead of having to google when you forget what a function returns, for example. This is also helpful when you're coming back to code you wrote a long time ago, or a colleague wrote it, and you don't know what particular variables/function arguments/object properties are at a given spot in the code.
  • emodendroket 9y ago
    Oh yeah, that's another great point (although you're still stuck with the fact that somebody can access object properties by key).
    • davidjnelson 9y ago
      Couldn't you solve this with privates, either via a naming convention or with symbols, as well as using getters?
      • emodendroket 9y ago
        Not really. If I declare that an object has property xyz obj.xyz and obj['xyz'] are both valid ways of addressing it.
  • davidjnelson 9y ago
    Absolutely. Typing is a real timesaver as it adds so much to how much an ide can help you.
• nkohari 9y ago
  One major argument is that TypeScript gives you arity checking on function calls, especially as you're refactoring. Seems like a simple thing, but after using TypeScript I realized how much time I wasted solving things like that.
• erokar 9y ago
  I agree. Type-related bugs of the kind that TS can catch are indeed rare and trivial. However, TS does help with documentation, intellisense and refactoring. Personally, I will usually go with Babel/JS, since I don't find that the benefits of static typing outweigh the costs.
  • emodendroket 9y ago
    I find the costs of static typing very low. What costs do you have in mind?
    • martin_drapeau 9y ago
      Everything required to add that to regular Javascript: transpilation, extra markup and understanding and mastering a new tool. Another layer to manage and debug if you will.
      • emodendroket 9y ago
        Oh. But these days most JS projects are in some task runner anyway.
      • mercer 9y ago
        Assuming you use ES6+ in production, so you need a build step anyways, would you still say TS adds costs that aren't worth it to you? And if so, which costs? I mean that in full honesty, as I generally find myself conflicted whenever I start a new project: TS or ES2015+?
        • chr1 9y ago
          Now browsers support most of ES6, so you only need build step for deployments, and can have fast reloads without a build step when developing.
• epidemian 9y ago
  > In the many years I've done front-end with Javascript, type-related bugs were very, very rare. Wow, really? My experience has been the complete opposite. Most of the bugs that slip into production have been dumb type errors. Things like accessing a property on an null/undefined value, or on an object that doesn't have that property and unfortunately JS just returns `undefined` instead of complaining (these silent ones can live longer before being spotted). It's because of these kind of bugs that i've found many JS codebases tend to become brittle to the slightest change, and very difficult to refactor into a good shape. And why i'm seeking statically typed languages like TypeScript on that front at the moment.
  • rubber_duck 9y ago
    It's more likely that OP finds such errors just as frequently but because they are relatively straightforward to fix he doesn't weigh them as much as edge case debugging. I've heard this same argument from a coworker working on a different project recently working on React/ES6 stack - I check their TFS history and find 3 such fixes in last 2 weeks (and they have reviews before checking in to TFS).
    • shados 9y ago
      There's a lot of type bugs in my code as I type it, and while I'm writing the unit tests, but I've been keeping track for the last year or so when they happen in QA or Prod and they are quite rare for us (as part of an evaluation of if we should move to Flow/TS). But there was a heavy correlation between type bugs and the kind of code being written. Our transactional frontend apps? Most bugs are browser css issues, weird environment specific edge cases, misunderstandings of the backend, memory leaks, etc. In apps that are data heavy though, or backend JS apps, its a whole other story. Type bugs all day every day (though a part of it is because we don't do many and they aren't high profile here, they're very light on tests). So we moved the later to using tests. While it helps a lot, we did end up with a different kind of issues: broken type definition issues and bugs in the type system. Turns out a very large portion of DefinitelyTyped definitions (especially those of the more obscure libs) are broken and you can't trust them, but you lose a lot of time fixing runtime bugs the type system forced you to make. And while they never hit production, there's more bugs than expected in TS itself, and it takes a while to figure out if I'm doing something wrong before I go look at the bug tracker (the issues I hit have almost always been reported already, but I don't expect them). Fortunately that last category rarely cause issues in production.
• hyperpallium 9y ago
  Agree the academia-touted benefit of type-checking isn't that helpful in practice. But types help with documentation and tooling (completion, data-mapping etc). Types are (apparently) crucial for large projects. However, the #1 benefit is speed, which I don't think Typescript can provide. Sorry I can't quantify any of that. EDIT I am curious why this was downvoted.
  • weberc2 9y ago
    The number one benefit is that it makes it painful to write certain classes of error prone and hard to read code.
  • deleted 9y ago
    [deleted]
  • deleted 9y ago
    [deleted]
• emodendroket 9y ago
  Is it "necessary"? Of course not. Lots of people have done without. I do find that it makes it more productive and easier to debug, especially if you're making something like a SPA with complex functionality. Also, the point isn't so much that there is one major, hard-to-fix bug, but that there are lots of small ones that you never encounter.
• jeremyjh 9y ago
  For me it is not about catching bugs that would make it into production; I agree those are relatively rare. It is about catching simple mistakes while I'm in the middle of coding or refactoring. These are mistakes that even without the warnings would probably not even make it into a commit, but the warnings directly in my editor in real-time are an even shorter round-trip than test executions. It results in less fumbling around to find the actual cause of some failure.
• krylon 9y ago
  > Am I alone here? I am not a Javascript person, but my personal experience has been similar. FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript. Lately I have warmed up to statically typed languages, but among all the bugs I have run across in dynamically typed languages, unexpected/invalid/wrong types were very, very rare. The benefit of good type system - IMHO - is not that it keeps you from putting string where a number is required. That kind of problem happens, but is usually easy to fix. But a type system that helps you distinguish between, e.g., numbers that are temperatures and numbers that are air pressure measurements is worth having around. EDIT: I admit, C's type system is exactly the most sophisticated one I've seen.
  • koolba 9y ago
    > FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript. How is that a non-issue? If you don't have unit tests covering your entire code base you wouldn't notice a bug like that until it broke in production. Having type checks let's you catch obviously wrong things like accessing a Promise return value directly rather than interacting with it as a Promise (i.e. then or async/await).
    • krylon 9y ago
      > How is that a non-issue? In C, there is a distinction between a value and a pointer to some value. In Javascript, as far as I understand, everything is a reference, so the specific mistake the C compiler caught would be impossible to make in Javascript in the first place. (Then again, C does not have concept of promises.) I am not saying type checks are bad or useless. In fact, over the years, I have grown to appreciate every little bit of advice a static analyzer can give me. But among the bugs I have produced using dynamically typed languages, few had to do with using the wrong type.
  • krylon 9y ago
• knocte 9y ago
  > Javascript, type-related bugs were very, very rare. That's because you're not seeing them. I bet that if you plug your frontend to an error-reporting tool (e.g. Sentry) you will be overwhelmed to see all the corner-cases you are overseeing.
  • k__ 9y ago
    but how much of these edge cases are really happening?
    • mdellabitta 9y ago
      Sentry and tools like it are reporting errors that are happening in production to real users.
      • k__ 9y ago
        Ah okay, so it's not reporting theoretical edge cases but real errors?
        • knocte 9y ago
          Yes
• watwut 9y ago
  I have seen quite a few of those - mostly in returning promise vs actual value from function in some special case. The other class of errors was with objects that reference other objects - e.g. function takes `loggedUser` parameter which is expected to have property `finishedLevels` or some such and someone sends it `bestFriend` object that kinda looks similar but does not have 'finishedLevels` property. Most importantly, you have to code differently when writing without typing. It felt as if my hands were cut of at first - I was often in "I would solve this easily in Java just by making interface that would communicate list of needed methods, but cant in javascript because there is no such thing as interface". This is also the likely reason why you do not see many bugs - you probably learned to avoid all those patterns and idioms. Even more importantly, it really helps with refactoring if you can rename function/variable or change number of its parameters and have all the places (and exactly them) that call that place return error. I can refactor much more aggressively when working with java vs javascript. In java, I spend a lot of time changing existing stuff, when I am tired to do hard work. In javascript it is special thing you do when you are well rested and fully focused.
• cloverich 9y ago
  Catching wrong-type bugs is, for me, relatively low on the list of reasons I enjoy using Typescript. A few of my higher items would be: strictNullChecking, intellisense, and refactoring.
• computerex 9y ago
  Javascript without type info is nearly impossible to refactor effectively.
• 5ourpu55 9y ago
  Types document the code. Types replace a whole class of tests. A lot of code written with TDD is the result of a bad type system IMO. Also it makes intellisense and refactoring easier. Types are great! Believe in types!!
• westoque 9y ago
  Like others, my experience was also complete opposite. The app I did was a financial related app so we do some good amount of number crunching. From calculations, to transfers, and storage. You won't believe how many type errors we had throughout the stack. It's definitely because of JavaScript's inability to do type checking. One workaround people did was to do the type checking in the first few lines of the function call, which is how people that still do raw JavaScript, do it today. function add(a,b) { if (typeof a !== 'number') { ... } if (typeof b !== 'number') { ... } return a + b; } This eventually creeps throughout in the code and introduces this code smell. This above can be solved by just using TypeScript.