• merthyr1831@lemmy.world
    link
    fedilink
    arrow-up
    59
    arrow-down
    4
    ·
    6 months ago

    The trick to writing a JavaScript web app is that first you consider literally any other technology to solve your problem and only then consider using javascript.

    • NuclearDolphin@lemmy.ml
      link
      fedilink
      English
      arrow-up
      28
      ·
      6 months ago

      The 15+ electron apps on my devices would like a word with you. I think I dislike JS more as a user than a dev because at least Typescript exists now.

  • ebc@lemmy.ca
    link
    fedilink
    arrow-up
    39
    arrow-down
    2
    ·
    6 months ago

    To any non-js dev taking this too seriously: A good half of the technologies mentioned in this meme are redundant, you only need to learn one of them (in addition to the language). It’s like complaining that there are too many Linux distributions to learn: you don’t, you just pick one and go with it.

    • NuclearDolphin@lemmy.ml
      link
      fedilink
      English
      arrow-up
      12
      ·
      6 months ago

      Part of the problem is choosing from those options (when you have a choice). Open-ended questions like that nuke my productivity when starting a project because I spend more time researching and weighing options than actually programming.

      As time has gone on, I’ve increasingly become a fan of restricting how many ways devs can do something.

      you just pick one and go with it.

      Might be my ADHD, but I can never just do that. But I posit that excess choice hurts feature development pace by wasting effort on reinventing the wheel.

      A good example is the Nix ecosystem:

      Nix expression language provides almost no constraints, leaving users to do the same things in a bunch of ways, and preventing a clear notion of which way is generally best from arising…which makes upstream super conservative with implementing new features the community wants, because any decision might break one those things. Leaving us with a 5+ year old “experimental” feature + CLI used by 80% of users, but no consensus on an official implementation. So many simple upstream changes become a series of 3 competing community projects providing a solution for that feature, further preventing consensus.

      • ebc@lemmy.ca
        link
        fedilink
        arrow-up
        7
        ·
        6 months ago

        It’s true that you can easily fall into analysis paralysis when you start learning JS, but honestly things have somewhat stabilized in recent years. 10 years ago everybody was switching frameworks every 6 months, but these days we’re going on 8+ years of absolute React dominance. So I guess that’s it for the view layer.

        The data layer has seen some movement in more recent years with Flux then GraphQL / Relay, but I think most people have settled on either Apollo or react-query now (depending on your backend).

        On the backend there was basically only express.js, and I think it’s still the king if you only want to write a backend.

        Static websites came back in fashion with Jekyll and Github Pages so Gatsby solved that problem in js-land for a while, but nowadays Next also fulfills that niche, along with the more fullstack-oriented apps.

        Svelte, Vue, Aurelia and Mithril are mostly niche frameworks. They have a dedicated, vocal fanbase (see the Svelte guy as sibling to your comment) but most of the industry has settled along the lines I’ve mentioned.

      • MonkeMischief@lemmy.today
        link
        fedilink
        arrow-up
        4
        ·
        6 months ago

        This is exactly why I always tell myself it’ll be super fun and easy to replace a Linux distro on one of my machines, and I do the fun part of balancing release style, desktop environment, all the shiny stuff…know what stops me dead in my tracks upon install?

        Deciding a file system. Because it feels like such a weighty decision with far-reaching effects.

        According to internet research, they’re all the right one, they’re all the wrong one, they’re all just fine, and don’t use any of them because they’ll wipe all your data. Lol

        Your documentation on file system choice is either anecdotal or engineering-masters-thesis, seemingly no in-between.

        I’ve just decided BTRFS with snapshots is great, and keep good enough backups that I shouldn’t have to fiddle with the fanciest deep-knowledge features to save my system.

        Might be my ADHD as well. XD

        • NuclearDolphin@lemmy.ml
          link
          fedilink
          English
          arrow-up
          2
          ·
          6 months ago

          Your documentation on file system choice is either anecdotal or engineering-masters-thesis, seemingly no in-between

          God, I feel this so much. All the benchmarks are such ass too.

          I have also struggled with picking a disk layout + FS, and landed on using a single BTRFS partition with FDE.

          For now, I’m happy. Unless there’s a new FS that definitively beats BTRFS on NVMe perf and supports copy-on-write and something that makes FDE as easy as subvolumes that definitively beats BTRFS on NVMe drives, I won’t even bother looking into it again.

          I’ve considered moving to a RAID setup, but it seems like more trouble than it’s worth, since I do regular /home backups & NixOS keeps my entire system config in version control.

          If I ever consider a different disk setup, I’m just going to fire up a clean distro install on a spare NVMe and benchmark my most common tasks myself.

          NixOS has killed my decision paralysis for choosing distros and desktop env stuff since I can just enable whatever in my config, try it out, then revert if I don’t like it enough to switch.

          Only thing I can’t trivially test is disk layouts, but with disko, it might be easy enough to create a custom NixOS installer that:

          • auto-installs a disk layout & your config
          • reboots
          • runs your benchmarks
          • writes the results to disk
          • reboots into the live image, repeating this for a list of disk layouts.
      • Empathy [he/him]@beehaw.org
        link
        fedilink
        arrow-up
        4
        ·
        6 months ago

        I want to add that, like you, I’ve become a big fan of restricting the numbers of ways to do something.

        IMO, It’s more time wasted choosing, more time wasted reviewing, and makes it easier to overlook errors. I want more opinionated languages and frameworks.

        • NuclearDolphin@lemmy.ml
          link
          fedilink
          arrow-up
          2
          ·
          6 months ago

          I reallt like the approach taken in Rust’s borrow checker, where good, safe, and sometimes overbearing design choices are enforced by default, but you can explicitly declare exemptions. Makes identifying potential problem code blocks easy too.

      • Tekhne@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        ·
        6 months ago

        I feel the same way. Designing good, opinionated APIs is HARD, but it also provides the best experience for both the author and the consumer.

        • Prettier is the undisputed king of JS formatters because it has no options by design. You set and forget.
        • One of the reasons iOS is so successful is because they lock down their APIs and put strict standards on apps, making it hard to write something that doesn’t at least look good and slot into the OS well.

        Among other examples.

    • GlenTheFrog@lemmy.ml
      link
      fedilink
      arrow-up
      11
      ·
      6 months ago

      … until you run into a problem which you can’t figure out on your own. Then you search the web, and only find how to do it with Y, instead of the technology you used which is called X. So after determining that you’re truly stuck, you switch to Y. Until you get stuck again, you search the web, and can only find how to do it in Z. And everyone online tells you you’re stupid to use X or Y in the first place. And the cycle continues.

      This is why I gave up on being a web developer and stayed far away from JS.

      • grrgyle@slrpnk.net
        link
        fedilink
        arrow-up
        7
        arrow-down
        1
        ·
        6 months ago

        I came from a cpp background and loved it the moment I saw it. Like, you mean I just go var foo = ... and then I can put anything? No type casting?? No types??? Finally, I was free.

        But I’ve always been more of a hacker than a real programmer. I’ve since learned that there are advantages to using types, static checking, etc…

        • kingthrillgore@lemmy.ml
          link
          fedilink
          arrow-up
          15
          arrow-down
          1
          ·
          6 months ago

          Don’t ever come to me saying “finally I am free from types” very few things make me angry. Rejecting types is one of them.

          Also its let foo and const foo depending on how you plan to use the variable…

          • jjjalljs@ttrpg.network
            link
            fedilink
            arrow-up
            5
            ·
            6 months ago

            I mostly work in Python, but we use types at work. For a hack day project I skipped typing stuff for like an hour, and then went “wait this sucks” and added types. It was easier overall.

    • kingthrillgore@lemmy.ml
      link
      fedilink
      arrow-up
      7
      ·
      6 months ago

      Yeah all of them are converging on WebComponent so really its all interchangable and eventually, WebComponent will replace the need for them.

      Kinda like how we slowly made all of jQuery part of ECMAScript 5. Now I know what you’re thinking: kingthrillgore, if ES5 has all the functionality, why do we still see a big chunk of CPU time lost when jQuery is loaded in the webpack? And to that I would reply…yes, yes we do! 😂😭

    • monk@lemmy.unboiled.info
      link
      fedilink
      arrow-up
      7
      arrow-down
      1
      ·
      6 months ago

      To any non-js dev taking this too seriously: A good half of the technologies mentioned in this meme are redundant, you only need to learn

      how to stay the fuck away from webdev

      (in addition to the language).

    • ebc@lemmy.ca
      link
      fedilink
      arrow-up
      26
      arrow-down
      2
      ·
      6 months ago

      C is crazy. While you are learning it you are learning Make and gcc without your consent.

      Java is crazy. While you are learning Spring you are learning Maven or Gradle even without your consent.

      • NuclearDolphin@lemmy.ml
        link
        fedilink
        English
        arrow-up
        13
        ·
        6 months ago

        All of these bring me a sense of dread, each in a unique way.

        Java I have a special loathing for, but the ecosystem isn’t too wild, just verbose and so XML heavy.

        JS is its own hell because of the sheer number of permutations of technologies a given project will use. There’s always at least one nonstandard framework or tool lingering around from an old trend.

        Python reimplemented the same dep management wheels 5x each, and I have no idea what common stacks look like anymore, but every time I encounter Python projects, something is always broken.

        C is nice and easy from what I’ve used (just GCC & make), but idk what complexity arises in bigger projects.

        Just so glad I’m not a webdev anymore and work with mostly just Rust, cargo, and containers.

        • ebc@lemmy.ca
          link
          fedilink
          arrow-up
          6
          arrow-down
          1
          ·
          edit-2
          6 months ago

          Honestly I think the main thing that the JS ecosystem does well is dependency / package management (npm). The standard library is very small so everything has to be added as a dependency in package.json, but it mostly works without any of the issues you often see in other languages.

          Yeah, it’s not perfect, but it’s better than anything else I’ve tried:

          • Python’s approach is pretty terrible (pip, easy_install, etc.) and global vs local packages
          • Ruby has its own hell with bundler and where stuff goes
          • PHP has had a few phases like python (composer and whatnot) and left everyone confused
          • Java needs things somewhere in its $PATH but it’s never clear where (altough it’s better with Gradle and Maven)
          • C needs root access because the only form of dependency management is apt-get

          In contrast, NPM is pretty simple: it creates a node_modules and puts everything there. No conflicts because project A uses left-pad 1.5 and project B uses left-pad 2.1. They can both have their own versions, thank you very much.

          The only people who managed to mess this up are Linux distributions, who insist on putting things in folders owned by root.

          • qqq@lemmy.world
            link
            fedilink
            arrow-up
            2
            ·
            edit-2
            6 months ago

            You can use ~/.local/lib and LD_LIBRARY_PATH for shared libs.

            Or better yet just give in and use the nix package manager, it is basically a virtual environment for your C programs.

        • MajorHavoc@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          6 months ago

          Python reimplemented the same dep management wheels 5x each, and I have no idea what common stacks look like anymore, but every time I encounter Python projects, something is always broken.

          We need just one more complete re-engineering of the packaging standard. We promise to get it right, this time. No take-backs.

    • kingthrillgore@lemmy.ml
      link
      fedilink
      arrow-up
      10
      ·
      6 months ago

      PHP is crazy. While you are learning Laravel or Drupal you are learning the deep seated desire to shoot yourself over the lack of consistent use of type hinting, regardless of consent. :skull:

  • Nick@lemmy.world
    link
    fedilink
    arrow-up
    34
    arrow-down
    1
    ·
    6 months ago

    Isn’t it great? And it all lets you shoot yourself in the foot equally as bad, if you misunderstand the frameworks’ design principles

  • TheDoctor [they/them]@hexbear.net
    link
    fedilink
    English
    arrow-up
    11
    ·
    6 months ago

    Writing plain old JavaScript without a library or framework is nice while you’re learning. Too many people will learn a single framework and not have any idea what the underlying APIs are, so the transferable skills are minimal.

    • rwhitisissle@lemmy.ml
      link
      fedilink
      arrow-up
      4
      ·
      6 months ago

      I do a lot of systems and backend programming and HTMX is the only way I can actually be productive with frontend work when I have to do it. It’s so simple and straightforward.

      • NuclearDolphin@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        ·
        6 months ago

        Wait are people writing Go for frontend code now? Or do you mean just replacing the node back end with Go?

          • NuclearDolphin@lemmy.ml
            link
            fedilink
            arrow-up
            2
            ·
            6 months ago

            Gotcha! I’ll have to look into it. I heard of it being used with Rust, which is probably the only lang I want to use for backend anymore. If it minimizes JS boilerplate, that’s a big win.

      • rwhitisissle@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        I’ve heard nothing but good things about HTMX

        I’ve only ever heard anything “bad” about HTMX and it was here on Lemmy, actually. I ran into someone who was absolutely certain that HTMX was unsafe by design because it leveraged HTML over the wire and was therefore susceptible to HTML injection attacks, specifically by injecting malicious scripts that could be ran from domains you didn’t control. I tried explaining that proper utilization of access-control headers innately prevented this because they worked on the browser level and couldn’t be intercepted or interfered with by HTML injection by design, but he kept insisting it was unsafe while refusing to elaborate. He was very wrong, of course, but also very confident.

    • Howdy@lemmy.zip
      link
      fedilink
      arrow-up
      12
      ·
      edit-2
      6 months ago

      I unironically did for production apps (some of which that are still running). The last thing I did with JS was vanilla. I’m a simple person.

      • EtzBetz@feddit.de
        link
        fedilink
        arrow-up
        5
        ·
        6 months ago

        Well, if it gets the job done. I’d only argue about maintainability there maybe, as other devs get involved.

        In my final apprenticeship work, I also only used vanilla php and argued that it would take too much time in this project to evaluate and learn a framework and that I know the vanilla way pretty good, so it’s valid this way around.

    • fibojoly@sh.itjust.works
      link
      fedilink
      arrow-up
      2
      ·
      6 months ago

      That’s what I did and I loved it. jQuery, some jQuery API, some dataTables, my backend in C# and off I go! Not perfect, but really enjoyable. Also SCSS is wonderful and I’m never going back.

    • NuclearDolphin@lemmy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      6 months ago

      Every person I know who used JQuery seems to really miss it. My only impression of it is that it looks goofy. Similar for PHP, but my only experience with it is Nextcloud causing me nightmares.

      • MrPoopyButthole@lemmy.world
        link
        fedilink
        English
        arrow-up
        6
        ·
        6 months ago

        I used to use JQuery (and I still do occasionally when doing scripts for WordPress where its included natively), but modern vanilla JS has solved 90+ % of the reason why we needed JQuery back then.