• EnderMB@lemmy.world
    link
    fedilink
    arrow-up
    194
    arrow-down
    1
    ·
    3 months ago

    I’ve honestly never understood why someone at Google or Mozilla hasn’t decided to write a JavaScript Standard Library.

    I’m not opposed to NPM, because dumb shit like this happens everywhere. If such a package is used millions of times a day, perhaps it would make sense to standardise it and have it as part of the fucking browser or node runtime…

    • mindbleach@sh.itjust.works
      link
      fedilink
      arrow-up
      29
      ·
      3 months ago

      That’s basically how Javascript gets extended. I put off learning jQuery for so long that all the features I’d want are now standard.

      • dan@upvote.au
        link
        fedilink
        arrow-up
        17
        ·
        3 months ago

        Vanilla JS is pretty good on the client side, but leaves a lot to be desired on the server side in Node.js, even if you include the standard Node.js modules.

        For example, there’s no built-in way to connect to a database of any sort, nor is there a way to easily create a basic HTTP REST API - the built in HTTP module is just raw HTTP, with no URL routing, no way to automatically JSON encode responses, no standardized error handling, no middleware layer, etc.

        This means that practically every Node.js app imports third-party modules, and they vary wildly in quality. Some are fantastic, some are okay, and some are absolutely horrible yet somehow get millions of downloads per week.

    • Blackmist@feddit.uk
      link
      fedilink
      English
      arrow-up
      10
      ·
      3 months ago

      Support for int64s out of the box and without jumping through hoops would be nice.

    • seatwiggy@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      30
      arrow-down
      1
      ·
      3 months ago

      There’s a js runtime called bun that is 90-something% feature equivalent to node and also has built in alternatives to many packages like express and bcrypt. I haven’t used it myself so I can’t speak to its quality but it’s always nice to see a little competition

      • jaemo@sh.itjust.works
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        3 months ago

        Bun is used by us in production, in dev, everywhere. It’s great. We don’t even use (p)npm to build js packages on our docker images for apps anymore.

      • Dr. Moose@lemmy.world
        link
        fedilink
        English
        arrow-up
        20
        ·
        3 months ago

        So is Deno! You can easily import npm: and node: packages and run typescript without transpiling. With Bun and Deno there’s no reason to use Node tbh.

        • sfxrlz@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          3 months ago

          For starting new projects i absolut agree. At work we have a legacy react app that just will not run on bun and for deno we would probably have to rewrite some stuff.

          • Dr. Moose@lemmy.world
            link
            fedilink
            English
            arrow-up
            5
            ·
            3 months ago

            I’ve updated some legacy nodejs to Deno recently and it’s actually not bad! If you’re using serverless Denoflare is super convenient and DTN is a tool for building Deno to NPM (both esm and commonjs) so you can have easy backwards compatibility if needed, it even shims all of the Deno standard lib.

            It’s really impressive what Deno and Bun people have done - for the first time I actually somewhat enjoy server side JS!

            • sfxrlz@lemmy.world
              link
              fedilink
              arrow-up
              3
              ·
              3 months ago

              That sounds neat. For our nodejs server this could be done without too much effort. Will keep that in mind, thanks. But I also have to check for the cra app we’re having a lot of issues with.

    • DefederateLemmyMl@feddit.nl
      link
      fedilink
      arrow-up
      53
      arrow-down
      2
      ·
      3 months ago

      I’ve honestly never understood why someone at Google or Mozilla hasn’t decided to write a JavaScript Standard Library.

      • BlackRoseAmongThorns@slrpnk.net
        link
        fedilink
        arrow-up
        4
        ·
        3 months ago

        This picture honestly looks more like C++ than JS, and before you yell at me, JS doesn’t have any standards let alone competing standards so ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

        • stetech@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          2 months ago

          JS doesn’t have any standards

          ECMAScript would like to have a word with you.

          If however by “doesn’t have any standards” you meant it’s willing to sink to new low grounds every day, you would be correct.

          • BlackRoseAmongThorns@slrpnk.net
            link
            fedilink
            arrow-up
            2
            ·
            2 months ago

            The latter, and the underutilization of the fact that the standard library exists, and consequently the existence of so many micro dependencies.

    • rimjob_rainer@discuss.tchncs.de
      link
      fedilink
      arrow-up
      32
      arrow-down
      6
      ·
      3 months ago

      I wish they would replace JavaScript with something that was made for what it’s used for. JavaScript should have died years ago.

    • dan@upvote.au
      link
      fedilink
      arrow-up
      46
      arrow-down
      1
      ·
      edit-2
      3 months ago

      someone at Google or Mozilla hasn’t decided to write a JavaScript Standard Library.

      Core APIs (including data types like strings, collection types like Map, Set, and arrays), Browser, and DOM APIs are pretty good these days. Much better than they used to be, with more features and consistent behaviour across all major browsers. It’s uncommon to need browser-specific hacks for those any more, except sometimes in Safari which acts weird at times.

      The main issue is server-side, and neither Google nor Mozilla have a big interest in server side JS. Google mostly uses Python and Java for their server-side code, and Mozilla mostly uses Rust.

      Having said that, there’s definitely some improvements that could be made in client-side JS too.