6 ms·
We use TypeScript not based on preference, but because we want to make money
- labrador 3y agoI've noticed in a few examples that the people who dislike TypeScript and use pure JavaScript generally are really good at keeping track of things in their head so they can go fast when they write. I'm not good at doing the housekeeping in my head, so I appreciate tools like TypeScript. I go slower, but it saves me time in the long run. edit: right -> write
- iddan 3y agoAlso, quality doesn’t scale. These people can do whatever they like when they work alone but once you get more people to work with them their claim falls apart like an unsafe function call
- moron4hire 3y agoThey're also just blissfully unaware of all the bugs in their code.
- doctor_eval 3y agoRight, I always suspect there’s bit of Dunning-Kruger going on when I read about people who reject compile time type safety.
- moron4hire 3y agoYes, there's really no reason to believe someone when they say they get along perfectly fine without strict typing. Every project I've converted from JS to TS, no matter the size, even the small, only a few hundred LOC projects, has had at least one major "how the hell did this ever work" type bug that the type checking discovered immediately and would have prevented from happening in the first place. So I don't really do even small projects without TS anymore. Anything more than can fit in my text editor, without scrolling, with the editor window tiled so I can see the app and the debug log at the same time.
- doctor_eval 3y agoYes, exactly my point. How do you know that your code doesn’t have subtle bugs when one of the systems that detects subtle bugs isn’t available? I used server side JavaScript for a decade before Node existed, so I have lots of experience with this sort of thing. And don’t even get me started on refactoring.
- manuelabeledo 3y agoThis. I get that there are some devs that dislike verbosity and love flexibility, but I'm not one of them, and in larger teams, there are more than one like me, so we are going to make mistakes. Any tool that prevent me from shooting myself in the foot, is appreciated.
- egonschiele 3y ago> generally are really good at keeping track of things in their head Inherent in that is their teammates will not be able to go as fast as them.
- justrealist 3y agoWell it helps that the iteration loop on the FE is generally really fast, so type errors are really quick to debug. You rarely even have to run a test suite, just load the page on a local node instance, get an error, print the object, refresh, takes 10 seconds. For BE code it can take 10 minutes to hours to deploy with debug info, so type errors are a huge PITA and strong types are critical.
- doctor_eval 3y agoThe problem is not debugging the type error, the problem - as in this article - is not detecting it in the first place.
- rhaway84773 3y agoI dont get this defense of using JS. Ok, maybe a dev is much faster writing JS because they keep stuff in their head better. But I’m assuming they also use third party libs, or functions that other devs in their team have written that they just need to call. Typescript makes it easy for the IDE to show you what exactly you need to pass to call the teammate’s function (and this was the originally motivation behind typescript…improving MS dev tooling) without having to dig into the code or read the documentation. And type inference means you’re rarely actually writing out the types. So I find it hard to believe that anyone writing a relatively complicated piece of code would be faster using JS over TS. Small scripts and the like, sure. But complete complex applications? I doubt it.
- andrewstuart 3y agoHere is a question for the TypeScript experts. I have been reading about Zod which gives runtime type validation. Is this a good fit to TypeScript and are we likely to see such functionality added to TypeScript?
- elliottkember 3y agozod and yup both give runtime types and they're great. They can also export typescript types. But as far as I understand it, typescript is a layer "on top of" javascript that does not exist at runtime. It all gets stripped and you're left with valid javascript. So no – I doubt it. They exist in different worlds.
- btown 3y agozod or yup gets you quite a bit of the way there in practice - when you would reach for a Typescript type, making it in zod instead is more verbose but gives that runtime layer. But for those who actually want full-stack non-stripped runtime type reflection based on Typescript syntax alone... https://deepkit.io/ https://deepkit.io/ - https://deepkit.io/blog/introducing-deepkit-framework https://deepkit.io/blog/introducing-deepkit-framework - is a really promising and cool project. It patches the typescript compiler (which pointedly considers runtime type information out of scope) with its own type compiler that emits a bespoke bytecode that is executed in a bespoke VM to communicate runtime type information to both server and client as needed. https://docs.deepkit.io/english/runtime-types.html https://docs.deepkit.io/english/runtime-types.html And from that baseline, there are very cool things you can do like an ORM entirely based on type annotations https://docs.deepkit.io/english/database.html https://docs.deepkit.io/english/database.html or strongly-typed RPCs https://docs.deepkit.io/english/rpc.html https://docs.deepkit.io/english/rpc.html . It's very much in the alpha stage, but it's really well thought out - there's a tremendous degree of care the developer is taking towards code cleanliness and developer experience. I'm torn between wishing this project to have a fully funded team and take the world by storm, vs. "letting them cook" so to speak and seeing the developer experience unfold organically. Either way, it's a breath of fresh air into the Typescript ecosystem!
- artursapek 3y ago
- kellysutton 3y agoNow feels like a good time to mention the talk "Ideology" by Gary Bernhardt. https://www.destroyallsoftware.com/talks/ideology https://www.destroyallsoftware.com/talks/ideology Tests and Types are useful for preventing errors, but the types of errors they can prevent differ. You probably need both!
- nateabele 3y agoSure, but the point is, a halfway decent type system will eliminate whole classes of errors—consequently eliminating whole swaths of things you would ever need to write tests for. What's more, though, is that a good type system will help you 'Make Impossible States Impossible'[0]—even more behavior you don't have to test because bad behavior is simply not representable in your program. Tests are strictly more powerful in the small, because they can be arbitrarily complex, but I would say a (really good) type system is more powerful in the large, because you get way more leverage in terms of overall program correctness. A lot of my personal projects are in Elm (yeah, yeah, bring on the hate)—the models are really well-defined, but the test suites usually only have a handful of tests of behavior I really want to verify. Haven't even played with the property checker yet, but again, that's something that is strictly more powerful than unit tests, but you can only get it* if you have a type system. [0] https://www.youtube.com/watch?v=IcgmSRJHu_8 https://www.youtube.com/watch?v=IcgmSRJHu_8 * Okay that's not really true: see clojure.spec in Clojure—but there are so few counterexamples that it's true for most practical purposes
- totallywrong 3y agoIt's pretty unreal that the only real choice for the web is still JS and a language that transpiles to it.
- willsmith72 3y agowe already have new frameworks and now runtimes every week, I really don't want that to carry over to the language level too
- theonething 3y agoDoes he not have autocomplete on his editor?
- Georgelemental 3y ago> The any type was a mistake and never should have been included in TypeScript in the first place. Disagree. `any` is important for incremental adoption, not having it would just make it harder to introduce type-safety to a codebase.
- DarkNova6 3y agoAgreed. The success of TypeScript can only be explained by its direct interoperability with JavaScript. But it is also the bane of its existence.
- cogman10 3y agoThe fact that Typescript was (is?) a superset of Javascript is the reason it won over Dart. You can't be a Javascript superset without any.
- caesil 3y agoCasting and `as unknown as <type>` are just as useful, probably more so because they specify what the type _should_ be.
- ravenstine 3y agoIMO, it's a million times better than accepting something as any, if the latter is possible to avoid. Sadly, every Typescript codebase I've worked with is riddled with `any`, and developers seem skeptical of `as`. That doesn't make sense to me. Throwing your hands up and saying "whatever" is better than declaring what the type should be when Typescript can't infer it otherwise?
- OJFord 3y agoI don't really use JS or TS, so sorry if it should be obvious, but why is that so much better? You just move the (incorrect) assumption from the logic to the type annotation? And you're still not going to get a compile-time error for it, because you're explicitly telling the compiler to make that assumption?
- iteratethis 3y agoThey lost hundreds of thousands of dollars on an issue that was in production for several days. On the one and only feature generating revenue: showing ads. No unit testing, no integration testing (as was admitted) and no production sanity test at all. I guess the accountant was asleep at the wheel as well. You have bigger issues than strong types.
- rhaway84773 3y agoYou’re assuming this was the only location they showed ads. It could have been one of the many components displaying ads. And this specific component might have accounted for a small percentage of those ads. And presumably this wasn’t the only feature deployed so any noticeable change in revenues could have been attributed to many other things before a typo in the ID would have been discovered.
- rmbyrro 3y agoThen they need to incorporate all components that display ads in the ad counting integration tests!
- rmbyrro 3y agoExactly. Look at what he says: > But how strong and reliable are your test environments to ensure that this all works correctly? How much effort, time, and money does it take to maintain full testing solutions? Seriously? The entire company revenue depends on counting ad views and you don't have resources to make sure you're counting right? Oh, c'mon! Strong typing has its place, but this was a bad argument in favor of it...
- OJFord 3y agoVery selective quoting, they clearly have integration testing. The resolution of the post mortem was to both add 'an' (they were already set up for it) integration test, and strict typing. The criticism of the test was that it would only cover that specific path, not others or potential future ones. Which is true.
- 3y ago
- doctor_eval 3y agoI see type safety as akin to the “Swiss cheese” model in aviation safety. It’s creating one more barrier against accidentally crashing your application. The thing with type safety is that systems like typescript are so easy and cheap to deploy, relative to E2E or even unit tests; it’s a small investment that pays off in multiple ways over time (quality, documentation, developer onboarding). I really struggle to understand the sometimes vehement arguments against it. https://en.m.wikipedia.org/wiki/Swiss_cheese_model https://en.m.wikipedia.org/wiki/Swiss_cheese_model
- SkyPuncher 3y agoOur team actually dropped FE testing entirely with Typescript. We found that our E2E tests took way too long to write and didn’t really cover the visual defects we often hit.
- qudat 3y agoWe definitely skip all automated tests with the exception of integration testing by mounting the app and robo-interacting via jsdom. I think our BE engineers are surprised by the lack of testing while at the same time rare runtime exceptions. We have enough critical flows tested and with TS to prevent runtime errors, we have a decent degree of confidence. If only we had a good way to test webauthn…
- tmikaeld 3y ago> If only we had a good way to test webauthn Preach, we had to check the source of the official test suite to figure out how to test it.
- johnnyworker 3y agoMake it part of the Javascript standard and see me using it the second Firefox supports it. Are there any arguments against that?
- doctor_eval 3y ago
- mostlysimilar 3y agoPerhaps this means I'd have a lot of adapting to do if I were to work at a larger organization, but my first thought was "did they test the code they wrote"? I'm not talking about automation or integration testing or any of that. I mean did you try using the thing you just built. It seems to me like it would be immediately obvious there was a problem. I could never ship something as critical as this without seeing with my own eyes that it functions as expected.
- doctor_eval 3y agoBut the advertising tracking system is not the thing they just built. That’s the problem. They included a tag that included information that was to be passed to that other system, to indicate that this tweet was billable. Presumably the tag was optional, the tag was just misspelled, so everything appeared to work just fine. It’s the downstream systems that cared about this tag and they were presumably not even running on the dev machine on which the offending code was written. The only thing that could have prevented this was some kind of schema that would have rejected an unknown tag at build time. Hence, typescript.
- rmbyrro 3y agoThat's one of the main reasons why automated tests exist: to make sure a change in one area is not breaking anything else in the system. I'm not against strong typing. Just saying this is a bad argument in favor of it.
- doctor_eval 3y agoBut the comment I was replying to said, > I'm not talking about automation or integration testing or any of that
- mostlysimilar 3y agoI see your point but the article says this: > This property was then used when logging visible Tweets that it was in fact displayed. It was a relational ID that told the backend systems exactly which Tweet from which advertiser was being displayed. It was supposed to be storing these IDs. Did nobody think to test that the thing was, in fact, storing IDs? Especially for something that puts hundreds of thousands of dollars on the line? Even if you're actually passing that value off to some 3rd party system somewhere, you can verify that this slice of your problem (the React component that receives a prop) is doing its job properly. Even if that means stubbing it to log locally. Something?
- striking 3y agoI love strong types, but I disagree with the final note here: > The `any` type was a mistake and never should have been included in TypeScript in the first place. It is disappointing to see the number of published libraries that embrace `any` types, making it difficult to verify with certainty that code is correct. `any` is a consequence of TypeScript being JavaScript under the hood. Is `unknown` a better type to use when you're not sure what something might be? Sure, the fact that TypeScript forces you to carefully pick apart what it actually is by guiding you through the appropriate type narrowing is great. But sometimes you actually just want to write some code and sort out the types later, especially when you have a lot of interfaces that came from JS or from an only partially converted TS codebase that would otherwise be full of `as unknown as T`. I think the only mistake here was allowing the `noImplicitAny` tsconfig option to be off by default. When TypeScript can't figure out what a type is and that setting is off, it just decides that the type is `any`. But when that setting is on, it's an error to not explicitly state the type, even if you explicitly state it's `any`! Then any usage of `any` is explicit, auditable, lintable, etc. and then it's much less of a problem to use effectively.
- ravenstine 3y agoIf all code was Typescript, maybe the author would have a sound point. Because of JavaScript (godblessit), there are many things that were written in a way that makes types difficult to implement. I work on Ember codebases and, while some of my colleagues who happen to work on Ember probably would disagree, there are things about the way it lazily resolves things makes it extremely difficult for everything to be typed properly without lots of recasting and bureaucracy that wouldn't have happened had the whole thing been written in Typescript from the very beginning. Typescript in Ember will always be a shitshow because of this design flaw that was encouraged by the era of JavaScript it was spawned from. Nevertheless, we shouldn't replace things that are otherwise working just fine, hence it's better to just accept that some things are going to be "any" or "unknown" and deal with them properly.
- jacquesm 3y agoAnd I used plain JavaScript for my latest project, not because 'I wanted to make money' (or lose money) but because that removes one barrier to contribution by outsiders. Requiring a compiled toolchain and a second language (some of the libraries the project relies on are in JavaScript) is a step up from just a browser and a text editor (and in the case of a GitLab hosted project: just a browser). JS is a terrible language, let there be absolutely no doubt about it. But TypeScript is not what browsers run. It's nice that the author puts their main reason for using this particular tool up front: they want to make money. But wanting to make money is not necessarily correlated with the use of TypeScript, JavaScript or any other programming language. And it misses that 'wanting to make money' even if it does correlate with the use of TypeScript would still be a preference. Finally: what's missing from the story about the typo is why there wasn't a system around all of this code that would notice that a particular KPI's relationship to another KPI came in wildly outside of the predicted range. Obviously: typed languages are great, but typos can happen in any language and such a defense-in-depth strategy against silly mistakes will benefit you regardless of the kind of language that you use. Awaiting the 'we use Rust because we want to make money' blogpost that is sure to follow.
- ranting-moth 3y ago> Warnings are pointless. They are nothing but noise and invisible ... I absolutely abhor the the trend to accept that this is OK. Your code shouldn't generate warnings and the build system should treat them as errors.
- BoiledCabbage 3y agoIf they should be treated as errors then how are the different than errors? The only difference between a warning and an error is if it's ignorable to still proceed to execution. If it isn't it's an error, if it is, it's a warning. If all warnings should stop builds then they are no longer warnings. And to be clear you can argue that point - that there shouldn't be such a thing as a warning. And that's a fair argument to make (regardless of if I agree or disagre), but saying "the build system should treat all warnings as errors" isn't really coherent.
- ranting-moth 3y agoBecause to the compiler errors are non negotiable. It doesn't understand what you are trying to say. Warning is the compiler saying that yes, he understands but you're probably doing it wrong. Unused variable. Yeah, legal. But why? Most code that generates warnings can be written in a way so it doesn't. For the rare extreme nonsense warning, deactivate that warning with a comment and justification why to the next reader. Because if you don't treat warnings like errors they become just a background din. > ... isn't really coherent. It's supported by many compilers and isn't a new idea.
- orwin 3y agoYes! The code you deploy should be compiled with stuff like -Werror or whatever will stop the deployment if a warning exist. It's fine for development but it encourages lazy practices. Any accepted warning should be explicitly declared in code.
- addisonj 3y agoThis will be... a "fun" comment section ;) I will put my conclusion first: as an industry, there is so much room for real research and understanding in what does and doesn't work in reducing defects. However, this itself is a pretty difficult problem because of the difficultly in tracking, quantifying, or even defining what a "bug" is. Until we have that data/research, any conversations about type systems vs testing vs process vs monitoring and saying which is "better" I think very rarely changes opinion and is more likely just to reinforce opinions held by different groups. That isn't to say this article isn't useful, it is a good real-world perspective of things that do happen. I think the problem is that something about most of our brains (either in the writing or in the reading) causes a huge portion of us to immediately look the issue with such absolutes that most of the learning/discussion that could be had are drowned out through disagreement about the basics. So in an attempt to try and hopefully start a discussion that goes beyond the argument about the value of types, I would love to learn about any research/products/ideas/success stories of how we as an industry can make software more resilient? In my (limited) research over the years, it seems like a lot of the research is often limited to a single company (MS did a lot of measurement in the past) or looks more at the people aspect and less at the tools/technology. I would think that LLMs might make some analysis, like measuring the impact of bugs, more tractable as I think an LLM could probably do an okay job of assessing the real impact of a bug (assuming there is a post mortem doc) better than just having a label like "major" that determines impact. That, combined with some okay understanding of the code that fixed a bug, could maybe help give a more complete understanding of how different tech/process/team structure impacts defect rates?
- johnnyworker 3y agoI would love to have types in JavaScript. But I also don't want to add a compile step for the small to medium things I use it for. I'd rather have something like "use strict, types". And if I made something really complex purely client side I'd rather spend the time to learn Rust and compile that to WASM, so I actually get something out of it. > Because there was no real error, just a warning, this issue went into production If you don't at least parse a new warning to figure out what causes it and decide why it's okay to ignore in this case, there's your problem. Types are fine but if this is the lesson you took from that, you learned nothing.
- bgoldste 3y agopromotedContemtId is a hilarious typo. Nice post.