• cylon@programming.dev
    link
    fedilink
    arrow-up
    21
    ·
    6 hours ago

    Memory is cheap and data sells enough to many parties. Most apps are just store front for Ads and data collection.

    No wonder why open source apps are quite light.

  • the_wiz@feddit.org
    link
    fedilink
    Deutsch
    arrow-up
    4
    ·
    5 hours ago

    Is this the appropriate point to reference the suckless community? I mean, that’s THE point of the movement…

  • x4740N@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    5 hours ago

    Lazy devs not removing old non functional commented code and background code additions ?

    Though I do get it if they don’t want to remove the old code if their employer is an asshole

    • SketchySeaBeast@lemmy.ca
      link
      fedilink
      English
      arrow-up
      4
      ·
      3 hours ago

      That’s not why. It’s the dependency trees that run a dozen layers deep and end up importing “isEven”. If you’re building a react app odds are good you’ll import way more code than you ever write yourself.

      And no one should be leaving commented-out code in their app, that’s what source control is for.

  • buddascrayon@lemmy.world
    link
    fedilink
    arrow-up
    19
    ·
    12 hours ago

    Oh, they have new functionality. It’s all in the back end, detailing everything you do and sending it to the parent company so they can monetize your life.

  • UnfortunateShort@lemmy.world
    link
    fedilink
    arrow-up
    34
    ·
    1 day ago

    Because companies give zero fucks. They will tell you they need tons of IT people, when in reality they want tons of underpaid programmers. They want stuff as fast and cheap as possible. What doesn’t cause immediate trouble is usually good enough. What can be patched up somehow is kept running, even when it only leads you further up the cliff you will fall off eventually.

    Management is sometimes completely clueless. They rather hire twice as many people to keep some poorly developed app running, than to invest in a new, better developed app, that requires less maintenance and provides a better user experience. Zero risk tolerance and zero foresight.

    It still generates money, you keep it running. Any means are fine.

  • Gxost@lemmy.world
    link
    fedilink
    arrow-up
    25
    ·
    1 day ago

    It’s all because of Electron, unnecessary libraries, and just bad coders. Asus Armoury Crate weighs a lot and is so slow, but it’s basically a simple app. Total Commander has much more features, but it’s fast, lightweight, and consumes 9 MB of RAM.

    • SirQuack@feddit.nl
      link
      fedilink
      arrow-up
      13
      ·
      1 day ago

      I’ve said this on reddit before, but once for a joke I tried to make a windows program to play doot.wav during October at random, and tried programming it on Linux.

      Sinds playing audio and working with the system tray was tricky, I ended up with electron.

      So yeah, an atrocious 120 mb application to play a 6kb wav file with a Math.random(). I don’t remember the memory consumption, but it was probably just as gross.

      • Gxost@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        22 hours ago

        Once I wrote an annoying program adding acceleration to the mouse cursor, so it was difficult to click any UI item. It was written in Object Pascal with Win API and weighted 16 KB. And I think in C it would be even smaller.

  • AppleTea@lemmy.zip
    link
    fedilink
    arrow-up
    58
    arrow-down
    1
    ·
    edit-2
    1 day ago

    isn’t it a combination of younger developers not learning to programme under the restrictions of limited memory and cpu speed, on top of employers demanding code as soon as possible rather than code that is elegant or resource efficient or even slightly planned out

    • herrvogel@lemmy.world
      link
      fedilink
      arrow-up
      18
      ·
      1 day ago

      Mostly the latter. We don’t do any optimizations on our product whatsoever. Most important thing is to say yes to all the customers and add every single feature they want. Every sprint is spent adding and adding and adding to the code as much as we can and as quickly as we can. Not a single second is allotted to any discussion about performance or efficiency. Maybe when something breaks, but otherwise we keep piling on more crap at full speed non-stop. I have repeatedly been told “the fast way is the right way” followed by laughter. I was told to “merge this now” on multiple occasions even when I knew that the code was shit, and told the team as much. I am expected to write code now and think about it later.

      As you can expect, the codebase is a bloated nightmare. Slow as shit, bugs galore, ugly inconsistent UI, ENORMOUS memory use, waaaaaay too frequent DB access with a shit ton of duplicate requests that are each rather inefficient themselves. It is a rather complex piece of lab management software, but not so complex that it should be struggling to run on dedicated servers with 8 gigs of RAM. Yet it does.

    • Lifter@discuss.tchncs.de
      link
      fedilink
      arrow-up
      18
      arrow-down
      1
      ·
      1 day ago

      Much the latter.

      Plus everything better work perfecly out of the box on any hardware, and there is a lot of different hardware. Compatibility layers are often built into the package.

      Java, for instance, recommenda that you package the whole (albeit slimmed down) JVM inside the package for the target platform, rather than relying on the java runtime installed already.

      The users arent expected to know any of that anymore.

      • PrettyFlyForAFatGuy@feddit.uk
        link
        fedilink
        arrow-up
        6
        ·
        1 day ago

        yep, a lot of apps are just repackaged chrome running a web page.

        which begs the question to companies that require use of the app instead of just having a working website i can use on my copy of chrome/firefox that’s already on my phone…

        why do you need hardware access to my device?

        • drawerair@lemmy.world
          link
          fedilink
          arrow-up
          7
          ·
          edit-2
          9 hours ago

          1 reason is that they want as much data as possible. They sell the user data. Or they use the user data to improve their targeted advertising. They want more ad clicks.

          Re app versus site, many know how to block ads on browsers. With an app, the firm is hoping they can show you ads. Ads can be removed from some apps but the layperson doesn’t know.

    • MonkderVierte@lemmy.ml
      link
      fedilink
      arrow-up
      8
      ·
      edit-2
      1 day ago

      Generally maybe but for apps specifically, it’s the default choice of IDE, Android Studio, bundling tons of libraries for added functionality bound to Play Services.

      Which would probably be illegal in EU now, if any judge had the tech see-through for it.

  • kamen@lemmy.world
    link
    fedilink
    English
    arrow-up
    17
    ·
    1 day ago

    I’d argue that deploying from one codebase to 3+ different platforms is new functionality, although not for the end user per se.

    I wish though that more of the web apps would come as no batteries included (by default or at least as a selectable option), i.e. use whatever webview is available on the system instead of shipping another one regardless of if you want it or not.

    • Harlehatschi@lemmy.ml
      link
      fedilink
      arrow-up
      9
      ·
      1 day ago

      But if your tool chain is worth anything the size of each binary shouldn’t be bigger. To oversimplify things a bit: it’s just #ifdefs and a proper tool chain.

      In the web development world on the other hand everything was always awful. Every nodejs package has half the world as dependencies…

      • SpaceCowboy@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        13 hours ago

        If the goal is to not have apps be too large, you probably don’t want to send the full variable and function names and all of the comments over the wire every time someone loads a webpage. That would be a very inefficient use of bandwidth, wouldn’t it?

          • bleistift2@sopuli.xyz
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 hours ago

            I guess it’s easier and safer to make a string replace for each function name beforehand than hoping the compression algorithm will figure that out.

            Also, as SpaceCowboy points out, comments are completely useless for the final web page. There’s no need to even compress them.

        • NoSpotOfGround@lemmy.world
          link
          fedilink
          arrow-up
          4
          arrow-down
          2
          ·
          1 day ago

          Except… the compilation step doesn’t add type safety to JS.

          As an aside, type safety hasn’t been something I truly miss in JS, despite how often it’s mentioned.

  • Stovetop@lemmy.world
    link
    fedilink
    arrow-up
    328
    ·
    2 days ago

    It’s just that we have to make space for our 5,358 partners and the telemetry data they need.