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?

  • cisco87@programming.dev
    link
    fedilink
    arrow-up
    11
    arrow-down
    4
    ·
    3 months ago

    To be honest Typescript and Javascript for me are both very bad Hacks driven languages. I explain myself: I’ve worked on a project for a client, with other devs who were experienced js/ts devs. Before to get on, I’ve read a book about them, went through the docs. But in the end, I would push PRs, and there was some hacky way to do stuff, now some stuff is just bad developers, choosing the hacky “obscure” undocumented way to do something, but other solutions were clear enough that deserved to be documented. Overall I am better off without using those

    • aluminium@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      3 months ago

      Unpopular opinion perhaps, but I rather have a language that allows me to implement hacky solutions than one that requires me to completely scrap and rearchitect everything.

      I for example once had to overwrite a dozen or so of prototype methods in a JS class because the library a we were using just fell apart when doing certain things inside a Shadow DOM - it was a library that was released long before that feature. And completely rewriting huge chunks of code that interacted with that library would have wasted 100s of hours and the end result might have been really akward as well since many other systems are architected around how that one library worked. So instead it was a matter of patching in a few checks and workarounds for shadow dom elements.

      And since its extremely well documented why we decided to to that, what these hacks do I don’t see an issue with that. Obviously this shouldn’t be the modus operandi everytime but its always good to have the option i.m.o. to dig yourself out of a hole.

      • cisco87@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        Oh speaking of dependencies changes, you know one of the contributions to that team for me was to fight against them depending directly on third party libraries? I have to spend a lot of energy making people go through the pain of creating a middle layer between our code and frameworks code, because it’s not needed, because its repetition, because etc. until the dependencies change and everyone has to sweat blood, I don’t think that’s a good argument for languages allowing hacky code, I think it’s an argument to improve developers awareness, and a team culture that doesn’t foster hacks over bad design decisions

      • 0x1C3B00DA@fedia.io
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        I would argue that overriding methods on a prototype is not a hack. It’s equivalent to overriding super methods in Java classes, but using javascript’s prototype-based inheritance instead of class-based inheritance.

        But I agree with your main point about choosing a language that lets the developer implement their solutions freely.