• hblaub@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    10 months ago

    TypeScript of course. The compiler often times catches mistakes in variable names, API methods, whatever. So it saves time by not having to run the whole application all the time. Also the input help is much better, when the editor knows sth is a string or a number, for example.

    • o_d [he/him]@lemmygrad.ml
      link
      fedilink
      arrow-up
      1
      ·
      10 months ago

      Oh yeah. Or when it’s a union of multiple strings or an enum and you get that sweet popup of all your options. So good 🥹

      • fidodo@lemm.ee
        link
        fedilink
        arrow-up
        2
        ·
        10 months ago

        And being able to use more complex object types like discriminated unions without having to constantly look up what’s in them!

  • demesisx@infosec.pub
    link
    fedilink
    English
    arrow-up
    2
    ·
    10 months ago

    I’m idealistically/philosophically committed to a Purescript Halogen front end with a Haskell Servant backend, biatch. Maybe someday I’ll get WASM in there. One thing I will not do is use TS or JS.

  • Deleted@kbin.social
    link
    fedilink
    arrow-up
    2
    ·
    10 months ago

    I’d rather stay out of the frontend all together but I’d rather chop my balls off than go back to JS.

  • mark@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    10 months ago

    I like TypeScript for its types and type-checking, but I also want to write JavaScript to avoid having a local build step, and having to wait for things to transpile/compile/etc when running locally. I have a pretty large project where I’ve gotten both worlds by just using JSDoc and only using TS for type-checking. VSCode still offers built-in type-checking with JSDocs and ofc the type-checking can also be run separately if needed.

  • Phen@lemmy.eco.br
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    10 months ago

    Typescript may have a million problems that make getting into it annoyingly hard and even seem pointless, but once it’s settled in your project and used well… Damn is it fucking good.

    And I’m saying that even though I had to disable intellisense and most of those advanced features because the project I work for is too large and typescript would easily use over 20GB of RAM and get my computer to freeze.

    But if you’re trying to use it like a traditional typed language, you’ll only see the bad side of it and you’ll certainly hate it.

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

      You can even compile Fortran code to wasm and run it on a web browser. Who need Javascript’s puny 64bit floating point precision when you can have Fortran’s superior 128bit floating point precision?

  • Nerd02@lemmy.basedcount.com
    link
    fedilink
    English
    arrow-up
    0
    ·
    10 months ago

    I think there’s a positive coming from this competition, though. Apparently this infighting has re-lit the want for type annotations to be embedded in vanilla JS (ECMAScript proposal). I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.

    You can get as close as it gets to this experience by using alternative runtimes such as Deno or Bun, which have native TS support (meaning you can just execute a .ts file without having to transpile it), but of course as soon as you have to write code for a browser you are back in the middle ages.