I keep seeing posts of some drama with typescript. What happened?

    • glockenspiel@programming.dev
      584·
      1 year ago

      Same boat: people who hate typescript and therefore ensuring type safety probably also hate unit tests because they are too inconvenient to awesome rockstar developers.

      • 9point6@lemmy.world
        364·
        1 year ago

        One hundred percent this. It reeks of the kind of ego you get from devs that think their code is so perfect it’s inherently easily maintainable.

        I know junior devs that don’t struggle with types and unit testing—any dev that thinks they’re too good for either is immediately sub-junior in my assessment, because they’re clearly unable to write code intended to be maintained by a team.

      • gravitas_deficiency@sh.itjust.worksEnglish
        27·
        1 year ago

        Lmao I’ve literally had conversations with people who have asked me to not be as rigorous with unit tests because you have to change some tests when you make a modification to the business logic.

        Bro: that’s the fucking point.

        • o_d [he/him]@lemmygrad.ml
          5·
          1 year ago

          I know you’re joking, but this isn’t even true. The feedback loop that you get from pre-written tests in watch mode is pretty much instantaneous. This helps me to arrive at the correct solution much more quickly than trying to validate each case as I go.

      • linearchaos@lemmy.worldEnglish
        3·
        1 year ago

        I love unit tests but I hate the eternal struggle behind them.

        We should make unit tests so we can tell when the build runs that the app is going to be consistent

        Everyone cheers

        We lose a sprint setting up unit tests

        Oh this one test just went yellow, somebody spends a few hours figuring it out and finds that it’s a bug in the unit test. No no we’re good That’s just a bug in the unit test we’ll plan to fix that in the next Sprint.

        Oh look now this unit test is going red we’re blocked. 2 hours later they find out that it’s a real problem but it’s not so bad that it overrides current feature work. Well we’re going to need to override that and we’ll have to fix it in the next sprint.

        Unit test failures slowly degrade in priority to try to get feature work done. You end up with a backlog full of yellow and red known problems and no one pays any attention to you that tests anymore.

      • Dioxy@programming.dev
        1·
        1 year ago

        I think it’s more of a JSDoc > TS thing. I need to check the drama, but I don’t believe anyone would want to write vanilla JS without some type declarations…

        • 9point6@lemmy.world
          101·
          1 year ago

          I don’t believe anyone would want to write vanilla JS without some type declarations…

          I really hate to burst your bubble, but that’s exactly what’s going on

    • SubArcticTundra@lemmy.ml
      10·
      1 year ago

      I feel like (and it was created by Microsoft which would support this) the purpose of TypeScript is to make web development palatable for C#/C++/Java developers.

    • TootSweet@lemmy.worldEnglish
      73·
      1 year ago

      If I’m writing a Go app with a JS frontend component but then I decide to use Typescript, suddenly I have NPM, Node, and realistically probably some JS build system like Grunt as dependencies of my project.

      Basically, it just adds more moving parts to the project when I could get away with a) a simpler build process and b) less separation between me and the browser.

      To be fair, I’ve never used TypeScript, but this is what’s kept me from using TypeScript.

      • 9point6@lemmy.world
        13·
        1 year ago

        For your Go code to be useful, you’ve got to set up the Go compiler right?

        As much as I wouldn’t recommend it, you can even install the typescript compiler via an OS package manager (at least in most Debian distributions)

        At that point (and once you’ve added it to your makefile, or however else you’re triggering your go build), surely then there’s zero additional moving parts needed to compile your front end vs your backend?

        Not least of all, I’d argue having a compiler tell me I messed up immediately is a bonus too vs poking around for some time until I get an error in the JS console

        • TootSweet@lemmy.worldEnglish
          32·
          1 year ago

          I’m definitely not saying I don’t know how I’d go about adding TypeScript to my build process if I wanted to. (Though I might should mention that I don’t usually use any build system that isn’t just straight up part of the Go compiler. go generate specifically.) But it’s one more thing (actually at least 2 more things – the TypeScript compiler and Node, and that’s if you’re not counting the package manager) that I’d need to keep up to date and hunt down backwards incompatible changes or bugs when updating breaks my build.

          There are dependencies that are pretty much absolutely necessary (the compiler or interpreter, depending on language, obviously), and if you need a feature badly enough that in practice isn’t worth writing yourself (and isn’t in the standard library), but beyond that you just kindof have to evaluate what dependencies are worth adding and what aren’t. I definitely fall on the side of eschewing dependencies in most optional situations just because adding dependencies willy-nilly has burned me so many times (though I do usually do JS/HTML/CSS minifying).

          Meanwhile, build-time type safety isn’t a substitute for (automated and/or manual) testing. And whether the benefits of build-time type safety are worth the drawbacks of having TypeScript/Node/whatever is a calculation everyone has to do. Plus, let’s be honest, there are plenty of other dependences one could add for which the argument is at least as strong as for TypeScript. If you’re using TypeScript, then why not jQuery and Vue and Underscore and Handlebar and Backbone and Grunt and Require and Bower and most importantly these seven jQuery plugins etc? In proactice the alternatives aren’t so much “basically no JS-related dependencies” vs “basically no JS-related dependencies other than TypeScript.” They’re more “basically no JS-related dependencies” vs “a veritable menagerie of JS dependencies.”

          What I’m going for here is also about opting out of the samsara that is the ever changing fashion-of-the-week in JS development. And about the only way to do that is to just opt not to use JS dependencies. (Not to say one would have to be absolutist about it. You could say “TypeScript and that’s all,” but if you’re drawing a line, why not draw it one dependency earlier?)

      • DaleGribble88@programming.devEnglish
        81·
        1 year ago

        You are making a lot of false assumptions about typescript and bringing in a lot of outside problems that don’t have anything to do with the language. Try working with typescript. It is a strict super set of javascript. So if you like vanilla JS, you can just keep writing it, then slowly introduce the syntactic sugar that typescript provides. I did the javascript and coffee script thing for a long while, and typescript is just the better way for most use cases at this point.

        • TootSweet@lemmy.worldEnglish
          21·
          1 year ago

          problems that don’t have anything to do with the language.

          My concerns about it don’t have anything to do with the language. More the tooling that would come with it.

          If browsers natively understood TypeScript, I’d use the type-safety features. But I don’t want things like the TypeScript compiler or Node to be a dependency of my build process. Not if the only payoff is type safety.

      • Zikeji@programming.devEnglish
        2·
        1 year ago

        I usually write Typescript with Vue and SSR so my server and client are using the same tooling. If I was writing a basic frontend with minimal JavaScript I would just (and have) use jsdoc for typing.

        But let’s be fair, what you mentioned as dependencies are development dependencies and don’t impact the end user (outside of poorly optimized build systems causing issues). Build systems can have some great benefits. Such as reducing file size by utilizing methods such as tree shaking to prune out the unused classes in a CSS library.

        It just comes down to choosing the tools to suit the job. Sure, you can use a table saw to cut a stick but it’s probably easier just to use a handsaw. Whereas if you’re cutting a large plywood board you could make do with a handsaw but it’ll take longer and the result might not be pretty.

        • TootSweet@lemmy.worldEnglish
          21·
          1 year ago

          don’t impact the end user

          They do if I the developer am spending time maintaining my dependencies rather than implementing feature X that the end user wants.

          Build systems can have some great benefits.

          As does not having multiple distinct yet interacting build systems in one project.

          unused classes in a CSS library.

          I have yet to have a use for any CSS libraries. Maybe that has more to do with the problem domain in which I write than anything. Maybe some day I’ll run into a situation where I feel I’d be better served using a CSS library, but it hasn’t happened yet.

  • De_Narm@lemmy.world
    74·
    1 year ago

    Some rather big projects started to remove TS, which upset the community. One if not the biggest is Turbo, from the Ruby-on-Rails guy. He said: “[TS] pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard”. Now there is a bit of a battle whether or not TS is actually all that great.

    • yyyesss?@lemmy.world
      632·
      1 year ago

      In my experience, that means they’re doing it wrong.

      I find that Typescript adds a lot of joy to my development experience. And I haven’t need any “gymnastics” since I invested in learning Typescript.

      • Veraxus@kbin.social
        141·
        1 year ago

        Same, but I come from a C++ background so strong typing is in my blood. This sounds like people who write bad code complaining because the language/transpiler won’t let them write bad code.

        • Bipta@kbin.social
          42·
          1 year ago

          That doesn’t seem a fair assessment at all. In strongly typed languages the types are part of the base syntax and usually not onerous, but rather straightforward to write. In TypeScript they’re tacked on in a way that makes quite a lot of work for developers while also making the code difficult to read and reason about (although good syntax highlighting certainly helps.)

      • AnUnusualRelic@lemmy.world
        7·
        1 year ago

        I don’t do java- or typescript but that guy’s comment definitely translates as “I want to keep on writing messy code and you can’t force me to learn to clean my shit up”.

      • Cratermaker@discuss.tchncs.de
        41·
        1 year ago

        I’ve heard it’s more of a problem on the library side. But I’ve personally had pains with ts when working with quirky features such as enums or discriminating unions. Part of the problem in my opinion is that the types all disappear at runtime, so you lose a lot of the joy of a statically typed language. For example, an API can pass you unexpected garbage and all your ts type wrangling helps not at all.

        • FooBarrington@lemmy.world
          3·
          1 year ago

          Well yes, if you don’t take care of properly typing external data, you won’t have it properly recognised. But that’s the same in any language that e.g. consumes external JSON data. Use the tools that Typescript gives you (like type guards) or the tools the community has built (like io-ts).

        • jpeps@lemmy.world
          1·
          1 year ago

          For your API issue, have you tried using type guards or something more sophisticated like Zod?

      • lobut@lemmy.ca
        20·
        1 year ago

        They just say the typing is too much and JSDoc is good enough for them as they get intellisense from it.

        Svelte, Turbo and a few others I think.

      • buzziebee@lemmy.world
        3·
        1 year ago

        It’s more for library devs when writing their libraries. Using TS means you’re writing in one language and then distributing the compiled version for users.

        As users can use things in a lot of different ways you have to do a lot of type “gymnastics” to make your library API as useful as possible.

        That means spending a lot of time setting up types when a jsdoc and .d.ts file will do the same thing for library consumers.

        It’s really a non issue. If some library devs think they can ship code which is easier for them to maintain correctly, and end users have the same developer experience, then it’s totally cool.

        Of course people with no nuance are using this as an argument for why no one should write in typescript (because they don’t like it for some reason). This thread has a bunch of people doing this. That creates drama, but there really shouldn’t be any. TS is bae for me, but I totally get why library devs might want to not use it.

  • tunawasherepoo@iusearchlinux.fyi
    192·
    1 year ago

    I’m not really involved in javascript land so im parroting off of what i’ve heard for “why js over ts?”

    • it reduces file size since you no longer need to ship source maps
    • ctrl+clicking stuff will take you to the definition rather than an unhelpful type declaration
    • if you spot a bug in the library, you can edit the source directly than having to recompile/reimport
    • ts adds some unnecessary type “gymnastics” (can’t speak for what this means), when all they really want is intellisense thru jsdoc

    So mainly: devs who don’t prefer strongly typed languages, and library devs who find typescript to be less transparent and more time consuming for new and old contributors than it’s worth

    • naught@sh.itjust.works
      31·
      1 year ago
      1. Why do you have to ship a source map? It compiles to vanilla js
      2. Not sure what editor, but in neovim (which uses tsserver on my end for LSP) I can either jump to the type declaration or the actual implementation. This is a tooling problem not inherent to typescript
      3. This doesn’t make any sense. You’d have the same problem with minified js or css etc.
      4. It means they are forced to use types properly and do the tiniest bit of thinking and planning that results in fewer type errors (think undefined variables and properties, etc)

      Not a bad summary, but I take issue with all the points

      Edit: The sourcemap comment is relevant to package size and not to final bundle size per the HN comment linked below. Also, the cmd+click critique rings truer now that I know it’s in the context of an installed package. Another critique is build time which is fair enough.

      • NewDark@unilem.org
        3·
        1 year ago

        I understand why some hobbyist individuals with small-ish scripts might not see the value, even though I even still disagree there.

        The more code and people touching the code, the more value you’ll see.

        • naught@sh.itjust.works
          2·
          1 year ago

          Hell I even write my tiny userscripts in TS and compile it to JS. The editor/“intellisense” support is nice

      • tunawasherepoo@iusearchlinux.fyi
        3·
        1 year ago

        Thanks :) I didn’t see anyone mention the points made by the svelte guys https://news.ycombinator.com/item?id=35892250 which is a shame since I thought they made better points than the dramatic “type gymnastics” argument haha (i am biased toward type-safety, as long as there is idiomatic, algebraic data types w/ pattern matching)

        Overall it sounds like a major change with a few minor/moderate benefits, but it’s their choice and time will tell if it was worth it :P

  • sdw@lemmy.ca
    15·
    1 year ago

    Where do y’all get your programming drama? I’m missing out

  • OscarRobin@lemmy.world
    8·
    1 year ago

    Basically some JS library devs have decided that JSDoc will work better for their specific use case as libraries than TS.

  • jamon@lemmy.world
    58·
    1 year ago

    As a person who has been writing JS for a very long time, and was building SPAs before the term existed…

    It all comes down to return on investment. The arguments I always hear in favor of TS are solutions to problems I’ve never had, at the expense of writing more code to do the same amount of work.

    It’s the same for people who tell me that they think everything should be tested then show me the tests they spent the last 40 hours working on, which I can quickly see are extremely brittle and unlikely to ever show any ROI. You will never be able to test every scenario, increasing the amount of things you test arbitrarily just increases the cost of building and maintaining your software. Each test you add should be something worth building and maintaining.

    Excess code that isn’t providing value is far more detrimental than not having a few extra tests or type safety.