• Deleted@kbin.social
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

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

  • Phen@lemmy.eco.br
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    1 year 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.

  • hblaub@programming.dev
    link
    fedilink
    arrow-up
    2
    ·
    1 year 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
      2
      ·
      1 year 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
        3
        ·
        1 year 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
    ·
    1 year 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.

  • mark@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year 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.

  • fidodo@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    To be perfectly frank, I’ve only seen the drama on social media platforms. Outside of this one library Ive hardly seen anyone trying to fight typescript in the professional community.

    • JakenVeina@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      More like a tourniquet and a prosthetic. It doesn’t solve the underlying problem, but it’s the best solution we’ve come up with.

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

    What Typescript drama is there? It’s fantastic. It’s been an industry standard for years. In my anecdotal experience the only people that hate it are juniors who did pure JS at their bootcamp and seniors that have refused to learn anything for the last 5 years.

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

      DHH (guy who founded Ruby on Rails) ripped typescript out of a supporting library and swapped it for JavaScript. He did it in his typical fashion of not allowing discussion and being a dick (PR only open for a couple hours and then merged disregarding all the negative feedback about the change) . So people are mad at him again.

      He does stupid shit like this all the time because he’s a fucking knob.

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

        RoR will always have a special place in my heart, but yeah… DHH sure does have opinions. What possible justification is there for removing it when it’s already there? Guess someone could just shift the types out to DT.

        Edit: So I read his blog post about it. He’s dropping it because he just doesn’t like it and he’s allowed to not like it. Okay then 🤷

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

          From his blog post:

          While you may compile dialects into it, you still have to accept the fact that running code in the browser means running JavaScript. So being able to write that, free of any tooling, and free of any strong typing, is a blessing under the circumstances.

          By his logic, JS linters are bad because they’re tooling that restricts your access to all of Javascript. But linters mean you don’t have to read PRs with a fine tooth comb to make sure there’s no footguns like using == instead of ===.

          Also, you could use that same logic to advocate for writing JVM bytecode directly instead of Java/Kotlin/Scala/Clojure/etc.

          The question is really whether tooling pays its way in terms of lower bug rates, code that’s easier for coworkers to read, and code that’s easier to reason about.

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

          His blog to me sounds like he did it because it was too difficult for him to understand a few errors. Says it all.

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

    I’m kind of a beginner… Can someone explain why you would make/use/have a dynamically and/or weak typed language? Is it just to not write some toInteger / as u64 / try_from()? I mean the drawbacks seem to outweigh the benefits…

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

      If you are writing small and simple apps it will give you more velocity and much less boiler plate.

      As apps grow it becomes harder to keep track of things and can quickly grow into a mess. You then start to need external tools to give you the features of a strong static type system.

      Also from a web point of view you don’t want the website to crash and burn with every error. JS will power through things like invalid types. Imagine if any error caused the website to just stop.

        • Nerd02@lemmy.basedcount.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          There’s no real alternatives to JS “for websites” (meaning on the frontend, the part of your code that gets executed on your client’s browser). That’s what JS was invented for and what it does best.

          I say “no real alternative” because technically we also have WebAssembly, which is a tool that allows you to run code written with any language on the web, but if you indeed are a beginner approaching to web development you should just forget about this for now and stick to JS as you learn.

          Of course this doesn’t mean that you can’t use Python on your backend, your server.

    • redcalcium@lemmy.institute
      link
      fedilink
      arrow-up
      1
      ·
      1 year 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
    ·
    1 year 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.