• RandoCalrandian@kbin.social
    link
    fedilink
    arrow-up
    55
    ·
    1 year ago

    Refusing rust and wasm is a signal you don’t care about code quality or security

    See? You can keep playing that game all the way down to the most onerous language

    • upstream@beehaw.org
      link
      fedilink
      arrow-up
      13
      ·
      1 year ago

      Writing code that can’t be scientifically proven to be correct on all hardware it might run on means you don’t care about code quality. /s

      The Internet is full of people with a bloated ego trying to justify their opinion and gatekeeping others.

      I see this more and more in software as well.

      Not sure if it’s always been like this, or if I just notice it more.

      Same way there’s thousands of people giving you a guide to write a task list in , but as soon as you want to use anything slightly more complex than what you can learn from working a few hours with something you quickly run out of material and is usually left to fend for yourself.

    • MrGG@lemmy.ca
      link
      fedilink
      arrow-up
      9
      ·
      1 year ago

      Actually, if you really care about quality and types on the front end rust+wasm is not a bad idea 🤔

      Now that I’ve typed that and read it back, were people using TypeScript for anything other than front-end web dev?

      • PenguinCoder@beehaw.org
        link
        fedilink
        English
        arrow-up
        12
        ·
        edit-2
        1 year ago

        Because at the end of the day TypeScript is still Javascript and it’s still bad. Just has some verbose formats to try and make weakly typed language (javascript) appear to be strongly typed. It adds more build steps to what shouldn’t be there; build steps make sense for apps, they make much less sense for libraries.

        https://dev.to/bettercodingacademy/typescript-is-a-waste-of-time-change-my-mind-pi8
        https://medium.com/@tsecretdeveloper/typescript-is-wrong-for-you-875a09e10176

        • pjhenry1216@kbin.social
          link
          fedilink
          arrow-up
          8
          ·
          1 year ago

          I’m sorry. Whoever wrote that should give up trying to write articles. It’s poorly written and will never convince anyone to change their mind. It’s shit. “I know how to convince people they’re wrong. Insult them. Setup a ton of strawman arguments. Genius.”

          Whoever wrote that is bad and should feel bad.

            • pjhenry1216@kbin.social
              link
              fedilink
              arrow-up
              5
              ·
              1 year ago

              Second one. Just realized there were two. Being close together and the first being long enough to get trailing “…” it all just looked like one big link when I first saw it. May just be Kbin displaying it that way.

        • Fushuan [he/him]@lemm.ee
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 year ago

          build steps make sense for apps, they make much less sense for libraries.

          This might be true, but it’s not about build steps, it’s about having detailed iformation of the types of the objects that the library is serving. not knowing the typing of the functions a library is serving is… poor. Maybe typescript is too strict and having something like type hinting like python has would be enough since linters pick up the hints from the libraries, but doing just JS only fuck the people that use the library.

      • upstream@beehaw.org
        link
        fedilink
        arrow-up
        5
        ·
        1 year ago

        We use TypeScript for our node.js backends.

        We had two that started out vanilla, but it became too painful to maintain.

        • MrGG@lemmy.ca
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          That is disturbing. From my perspective, anyway. There are already so many great (and more appropriate) stacks for web backends, why Frankenstein a Frankenstein into it?

          • Knusper@feddit.de
            link
            fedilink
            arrow-up
            10
            ·
            1 year ago

            Well, usually because you’ve got a team of frontend folks needing to do a backend.

            There’s one other advantage, which is that you can have a compile-time shared model between backend and frontend. You also have that advantage with WASM, but not with a traditional backend/frontend technology split…

            • abhibeckert@beehaw.org
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              1 year ago

              Compile time is my biggest issue with TypeScript. I’ve used JavaScript for decades with compile time measured in, what, a millisecond or two. Having to wait for TypeScript drives me nuts.

          • The Cuuuuube@beehaw.org
            link
            fedilink
            English
            arrow-up
            3
            ·
            1 year ago

            🤷 people like nodejs and people like type hinting and IDE reflection. Typescript helps a lot with that

      • Kangie@lemmy.srcfiles.zip
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        I wrote some TypeScript modules to process a bunch of documentation in markdown to a ton of output formats via pandoc + latex.

        No real reason for it, except that I was able to start with the export module of a node-based thing written in JavaScript and iterate from there until I had a working system in CI/CD.

      • TehPers@beehaw.org
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 year ago

        It can with some glue code that you better be writing in TypeScript if you care about code quality.

        (As far as I know, it can’t manipulate the DOM directly. Maybe things changed in the past couple months since I checked, but I doubt it.)

      • abhibeckert@beehaw.org
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        1 year ago

        WASM allows arbitrary code execution in an environment that doesn’t include the DOM… however it can communicate with the page where the DOM is available, and it’s trivial to setup an abstraction layer that gives you the full suite of DOM manipulation tools in your WASM space. Libraries for WASM development generally provide that for you.

        For example here’s SwiftWASM:

        let document = JSObject.global.document
        
        var divElement = document.createElement("div")
        divElement.innerText = "Hello, world"
        _ = document.body.appendChild(divElement)
        

        It’s pretty much exactly the same as JavaScript, except you nee to use JSObject to access the document class (Swift can do globals, but they are generally avoided) and swift also presents a compiler warning if you execute a function (like appendChild) without doing anything with the result. Assigning it to a dummy “underscore” variable is the operator in Swift to tell the compiler you don’t want the output.