I was talking to my manager the other day, discussing the languages we are using at $dayjob. He kind of offhandedly said that he thinks TypeScript is a temporary fad and soon everything will go back to using JavaScript. He doesn’t like that it’s made by Microsoft either.

I’m not a frontend developer so I don’t really know, but my general impression is that everything is moving more and more towards TypeScript, not away from it. But maybe I’m wrong?

Does anyone who actually works with TypeScript have any impression about this?

  • Vincent@feddit.nl
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    If TypeScript still is a fad at this point, his definition of fad is far lengthier than mine is.

    I’m fairly sure TypeScript will remain in popular use longer than whatever project you’re working on 😅

        • jeremyparker@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          1 year ago

          And I’m sure Microsoft would be happy to not have to do it anymore. And I personally would much prefer an actual typing system rather than a glorified linter.

          Tho I wonder if it will end up being like jQuery, in the sense that, by the time core jQuery features got added to vanilla js, jQuery had developed new features that validated its continued existence. Maybe TS will go further than what gets absorbed into JS and keep it alive.

          • aidan@lemmy.worldBanned
            link
            fedilink
            arrow-up
            0
            ·
            1 year ago

            Honestly, I’ve never used jQuery despite writing JS for over 10 years. Just because I hate the reliance on massive nebulous packages so many have. Especially when I looked into it years ago, so much of what I saw jQuery being used for was stuff that was extremely easy to implement yourself. How has it changed?

            • jeremyparker@programming.dev
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              jQuery is a lot smaller and less nebulous than its competitors (looking at you,React literally every JavaScript framework).

              Jquery was what was popular when i learned js. I’m kinda glad it was, honestly: jQuery is a little unique in that it doesn’t have magic to it the way js frameworks do. Everything you can do in jQuery, you can do in vanilla JavaScript pretty easily. With, say, React, how is a newcomer supposed to understand how a series of React components become HTML?

              So jQuery kept it “real” for me. Fewer abstractions between me and the HTML meant it was easier for me to connect the dots as a self taught developer.

              As for how it’s changed, it’s more any how vanilla JavaScript has changed. A lot of the things that made jQuery so much easier and cleaner than vanilla are now baked in, like document.querySelector(), element.classList, createElement(), addEventListener()… It had Ajax methods that, before jQuery, were a tremendous pain in the ass.

              jQuery was great, but, you basically had to use it with something like PHP, because it had no back end. So when angular came out (and a few others that aren’t around anymore and I’ve forgotten), it allowed you to replace both PHP and jQuery, and developers rejoiced.

              Why did they rejoice? I’m not actually sure there was reason to, objectively speaking. As developers, we like new tech, especially if that new tech requires us to think about code differently, even if, in retrospect, it’s a hard argument to make to say that, if we had just stuck with PHP and jQuery we would be somehow worse off than we are with React.

              Of course, in tech, when a new system changes how we think, sometimes (not as often as we’d like) it helps us reconsider problems and find much more elegant solutions. So, would we have all the innovations we have today if all these js frameworks has never existed? Obviously we can’t really answer that – but it’s a toke of copium for when we get nostalgic for the PHP/jQuery days.

              (Also, for you newer people reading this, you should probably be aware that the PHP/jQuery mini-stack is still very quietly used. You’ll definitely see it, especially in php-baaed COTS.)

              • aidan@lemmy.worldBanned
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                Thanks for informing me, but I still kinda wonder why someone would use it today?

      • lemmyvore@feddit.nl
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        1 year ago

        And also JS.

        Well “kill” is perhaps a strong word but it definitely won’t be JS anymore at that point. The changes required to bake in strong type support would be radical.

  • AlecSadler@sh.itjust.works
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    In a small company with a non-complex product, there is a chance that TS creates more slowdowns than not.

    In a large company with multiple cooks in the kitchen and a complex product, I’m personally of the mindset that there is substantial gain from typescript. I’ve had coworkers tell me it’s bullshit, and then I do the smallest lift possible to convert and the amount of bugs it reveals are insane.

    Is it necessary? No, probably not. But unless everyone’s a 10/10 dev working on the world’s simplest product, why not just do it and enjoy the benefits?

    INB4 JavaScript blahblah, yeah I’ve added type hints to pure JS projects too and discovered bugs. At this point I don’t get it. Typical resistance I get is that it’s too prescriptive and lacks JS’s dynamic nature - well, fuck off, I don’t want to read through 200+ lines of code where you’re changing types and shit on me willy-nilly.

  • Lmaydev@programming.dev
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    1 year ago

    When anyone in a professional setting says they don’t like having a mega corp supporting something I lose a bit of respect for their opinion tbh.

    Yes we all know mega corps suck.

    But if you’re using anything in a professional production environment that is meant to last in the long term this is 100% what you want.

    • Valmond@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      Some of us are old enough to remember the browser wars and EEE, so I definitely understands not wanting to be sucked into some mega corps eco system with future lock-ins. Often you can’t do anyhhing else, but that doesn’t mean it doesn’t suck.

    • cbarrick@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      arrow-down
      1
      ·
      1 year ago

      Dynamic typing is not a fad.

      Python is older than Java, older than me. It is still going strong.

      • Dark Arc@social.packetloss.gg
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        1 year ago

        Python also has a statically typed option these days.

        Edit: Previously said “strongly” instead of “statically”

            • FooBarrington@lemmy.world
              link
              fedilink
              arrow-up
              0
              ·
              1 year ago

              Ah, gotcha, thanks! I’d have loved a strongly-typed option.

              The static typing system is slowly getting there, but many useful Python patterns can’t be expressed yet. You can, for example, write a function that appends an item to a generic tuple - but you can’t concatenate two tuples. I really hope they keep expanding on the system!

      • hascat@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 year ago

        This just blew my mind. I had always assumed Java was older. I started writing hobby projects in Java in the 90s. I don’t think I heard about Python until the early 2000s.

      • kameecoding@lemmy.world
        link
        fedilink
        arrow-up
        0
        arrow-down
        1
        ·
        1 year ago

        “Strong”… how many actual projects run on python?

        Half of the internet ( backend) runs on java, banking, your government systems, etc.

        It’s not a fad, it’s just unusable for anything other than research project and small time scripting, which to be fair, it’s what it’s designed for.

        • cbarrick@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          You have no idea. Python (and Ruby) are used widely in the industry. Large parts of YouTube are written in Python, and large parts of GitHub are written in Ruby. And every major tech company is using Python in their offline data pipelines.

          I know of systems critical to the modern web that are written in Python.

  • hawgietonight@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    Technicalities aside, TS is being pushed by MSFT in their SaaS custom components, and that right there will keep it relevant a while. MSFT is known for changing names a lot, but not for killing technologies.

    After over 5 years of writing TS, I have had to do plain JS sometimes, and it is scary. It feels like walking blindfold. I’m spoiled.

  • TCB13@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    1 year ago

    I believe both are true… and I also develop a LOT in Angular (with TypeScript).

    TypeScript is great but the thing is that if you look at the history of TypeScript and JS/ECMAScript you’ll find out that TypeScript sometimes is the testing ground for the future features of ECMAScript - pretty much like what happens with Sass and CSS that how even has nesting and scopes.

    The issue with TypeScript/Sass etc. is that it requires a compiler and that’s totally obnoxious and completely defeats the point of having interpreted code on browsers. Depending on the project it might be better to go for TypeScript + Angular/React or other compiled solution or simply something vanilla with jQuery or the Vue runtime (no compilation) and other libraries.

    If TypeScript ever goes away the underlaying features that make it great will be implemented in ECMAScript in the same way that we got modules, classes etc. and I really hope it happens. Less compilation usually equals code more maintainable in the long run because you won’t require hundreds of dependencies (that will eventually break) to get it to compile.

    • SorteKanin@feddit.dkOP
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      The issue with TypeScript/Sass etc. is that it requires a compiler and that’s totally obnoxious and completely defeats the point of having interpreted code on browsers.

      Shouldn’t WebAssembly be a solution to this? I.e. so you don’t have to interpret code but rather run the wasm binary (which is kinda interpretation as well but you get what I mean).

      • redcalcium@lemmy.institute
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        I love seeing webassembly getting traction because it enable cool stuff never thought possible before running in web browsers. But webassembly is a blackbox that can’t be tinkered with by end users. I dread the day webassembly become so widely used that average websites run under webassembly because that would be the end of blocking ads or tweaking websites behavior with greasemonkey scripts.

        • SorteKanin@feddit.dkOP
          link
          fedilink
          arrow-up
          0
          ·
          1 year ago

          I don’t think adblockers rely on interpreting JavaScript, I think they would still work even if a site used WebAssembly.

          Source: I can assure you every single ad-funded website would be doing this if that was the case.

          • redcalcium@lemmy.institute
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            1 year ago

            ublock origin won’t help you blocking the ad elements if the entire website ui is rendered in a canvas (already starting to happen thanks to some frameworks like flutter) and can’t block the ad logic if it bundled in the wasm along with the rest of the app. It might still able to block the requests, but they’re starting to serve the ads from the same domain that serves the website so it can’t be blocked without breaking the website itself, and might begin to serve those over websocket so adblockers can’t block it by url path. With javascript, an ad blocker might still be able to monkey patch the ad logic on runtime to break it, but with black box like wasm I’m not sure if such thing is possible.

            Once tooling and frameworks make it easier for average webdevs to use webasm, I’m sure ad companies will begin to offer it in their ads sdk. Thankfully most websites with ads are still care about SEO so at the very least we can be sure it won’t happen anytime soon, unless something changes in how google works that could enable this.

            • shnizmuffin@lemmy.inbutts.lol
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              the entire website ui is rendered in a canvas (already starting to happen thanks to some frameworks like flutter)

              That sounds like an accessibility nightmare.

  • nick@campfyre.nickwebster.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    1 year ago

    Hi, I’ve been doing TypeScript in my day-job and hobbies for six and a bit years now. I would not write JS in any other way.

    TS is also a superset of JS so all JS is valid (unless you turn on strict mode). So there is no productivity loss/learning curve unless you want there to be.

    In fact, a lot of people who think they’re not using typescript are using it because their editors use typescript definitions for autocomplete and JSDoc type signatures are powered by typescript.

    • aidan@lemmy.worldBanned
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      So there is no productivity loss/learning curve unless you want there to be.

      It’s not significant but an extra build step can be annoying

  • Conyak@lemmy.tf
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    If JavaScript implements type safety then I believe it will go away. If not then it will continue to be used.

  • Cyclohexane@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    The only valid argument against typescript is that it is too similar to vanilla JavaScript. It does not go far enough. We need type systems like Ocaml’s.

    I suppose you can also complain about needing a build step, but I find this silly. There are so many tools that make this easy or automatic.

    • jamon@lemmy.world
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      1 year ago

      You should check out Google Web toolkit, totally signs like your kind of thing.

      Typescript is for people who hate JavaScript, for the most part. The bulk of the people who have been writing JavaScript for years and aren’t Java converts are still using JavaScript and will continue to do so. The Java developers will continue writing Java, no matter what language they are programming in.

  • hperrin@lemmy.worldBanned
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    TypeScript might not be here to stay, but typed JavaScript definitely is. I’ve switched to writing 100% TypeScript, and haven’t looked back. The fact that just adding types to one of my (admittedly more complex) libraries surfaced 3 unknown bugs was eye opening to me.

  • treechicken@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    1 year ago

    I hope not. I’m pretty sure me and my coworkers would be at each others’ throats if it were not for some form of typed JS holding our Frankenstein codebase together.