• Stovetop@lemmy.world
    325·
    9 days ago

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

    • jmcs@discuss.tchncs.de
      1591·
      9 days ago

      And analytics. And offloading as much computation to the client, because servers are expensive and inefficiency is not an issue if your users are the ones paying for it.

      • kbotc@lemmy.worldEnglish
        19·
        9 days ago

        I saw an ad request with an inline 1.4 MB game. Like, you could fit Mario in there.

        • state_electrician@discuss.tchncs.de
          9·
          9 days ago

          The Samsung shop hands out 1.4mb JSON responses for order tracking, with what I estimate 99% redundant information that is repeated many times in different parts of the structure.

    • lobut@lemmy.ca
      35·
      9 days ago

      Web “Apps” are also quite bad. Lots of and lots of stuff we’re downloading and it feels clunky.

      Sometimes that’s bad coding, poor optimization, third party libraries, or sometimes just including trackers/ads on the page.

  • enemenemu@lemm.ee
    160·
    9 days ago

    Paypal has 500 mb and just shows a number and you can press a button to send a number to their server.

    It’s insane

      • kratoz29@lemm.eeEnglish
        131·
        9 days ago

        LMAO, he also made me check it.

        347 MB for me, no wonder why I am always struggling with storage for my 128 GB phone (with not expandable storage of course), and I don’t even have that many games, even less ROMs 😅

    • Onomatopoeia@lemmy.cafeEnglish
      16·
      9 days ago

      Check out the apps Hermit and Native Alpha. They make web pages run like an app. I’ve only run into a couple sites where they don’t work right.

      • enemenemu@lemm.ee
        5·
        9 days ago

        Native alpha sounds good since it’s foss and uses vanadium’s webview. Are you still logged in to paypal (any annoying website) a couple of months later. Or does it revoke your rights after a while?

        I only use it rarely and I hate providing my info for 5 minutes just to do one transaction.

  • count_dongulus@lemmy.world
    136·
    9 days ago

    Cheaper & faster development by leveraging large libraries/frameworks, but inability to automatically drop most unused parts of those libraries/frameworks. You could in theory shrink Electron way down by yoinking out tons of browser features you’re not using, but there’s not much incentive to do it and it’d potentially require a lot of engineering work.

    • zenpocalypse@lemm.eeEnglish
      54·
      9 days ago

      Yeah, though the joke is funny, this is the real answer.

      Storage is cheap compared to creating custom libraries.

      • Tanoh@lemmy.world
        9·
        9 days ago

        Also the storage is the cost for the user, and google in the case of play store. So the developers have no incentive to reduce the size.

      • UnityDevice@lemmy.zipEnglish
        4·
        9 days ago

        Storage is cheap on a PC, it’s not cheap on mobile where it’s fixed and used as a model differentiator. They overcharge you so much. Oh, and they removed SD card slots from nearly all phones.

        • IsThisAnAI@lemmy.world
          42·
          9 days ago

          Nah it’s fine. Clean up used apps every once in a while. Base phones have more than enough space.

    • Bytemeister@lemmy.worldEnglish
      194·
      9 days ago

      Yep. Apps are 20x bigger with no new features…that you are using.

      Let’s not forget that the graphics for applications has scaled with display resolution, and people generally demand a smooth modern look for their apps.

      • lud@lemm.ee
        1·
        3 days ago

        In the case of normal apps like PayPal graphics shouldn’t be a huge factor since it should be vectorized and there is pretty much no graphics in apps like PayPal.

        The issue comes from frameworks.

  • Blackmist@feddit.ukEnglish
    86·
    9 days ago

    Fucking Chrome/Electron is why.

    I honestly wouldn’t mind that if they could all use the exact same runtime so the apps could be a few MB each, but nooooo.

    • nutt_goblin@lemmy.world
      241·
      9 days ago

      See: Webview2

      Unfortunately, it is extremely painful to work with😔 Enjoy rolling your own script versioning and update systems instead of using squirrel et al

      Edit: I think Tauri works by targeting this and webkitgtk via their wrapper library, unfortunately I can’t get my coworkers to write rust

      • kungen@feddit.nu
        6·
        9 days ago

        Isn’t that just the same pig, just wearing different makeup? I’m not a fan of msedgewebview2.exe allocating 500+ MB RAM just because Teams is open, but maybe that’s Teams fault…

        • nutt_goblin@lemmy.world
          4·
          8 days ago

          Not quite. instead of a bundled pinned version of electron, it is an arbitrary version of edge’s WebKit fork shared across all programs using it. That means you don’t need to keep multiple copies of the webkit libraries loaded into memory.

          That’s not to say that building things on web technology is an efficient use of resources. Even if multiple programs are sharing the webview2 library, they’re still dealing with the fundamental performance and memory problems caused by building an app in JavaScript.

          As for why teams is so memory hungry? I would blame Teams.

          Discord manages to make a half decent, highly responsive webview app, and that’s with the overhead of having its own separate instance of electron.

          EDIT: the original poster was also talking about application binary size, not runtime memory consumption. Application binary size should actually be significantly helped by linking webview to instead of bundling electron.

    • devilish666@lemmy.world
      61·
      9 days ago

      Is there any alternatives to electron ? And why people’s doesn’t move on to alternatives if electron is huge & heavy resources ?

      • dpflug@kbin.earth
        12·
        9 days ago

        I mean, Object Pascal was doing the “write once, run anywhere” thing decades ago. Java, too. The former, especially, can make very small programs with big features.

        • uuldika@lemmy.ml
          33·
          9 days ago

          Java (and Object Pascal, I’m assuming) have very old-looking UIs. Discord’s gonna have trouble attracting users if their client looks like a billing system from 2005. Also, what do you do about the web client? Implement the UI once in HTML/CSS/JS, and again in JForms?

          So if you’re picking one UI to make cross-platform, and you need a web client, do you pick JForms and make it work on the web? or React and make it work on desktop?

          • dpflug@kbin.earth
            6·
            9 days ago

            I think maybe you’re confused. Java drives a significant percentage of Android apps. It absolutely can do modern UI. I can almost guarantee you’ve interacted with a Java program this year that you never considered.

            Pascal is more niche, but it can do modern, too.

            Java was doing web clients before the web could and still can. I don’t know much about Delphi’s web stuff, but I know they’ve targeted it for years now.

            WASM and transpiling blur the lines, too. LVGL can provide beautiful interfaces on the web as well as platforms Electron could never target, and works with any language compatible with the C ABI.

            I’m not saying these strategies are without their own warts, but there are other ways to deliver good experiences across platforms with a ~single codebase in a smaller payload. But mostly nobody bothers because they just reach for Electron. It’s this era’s “nobody ever got fired for picking Intel”.

            We need more people working with and on alternatives, not just for efficiency but also for the health of the software ecosystem. Google’s browser hegemony is feasting. Complexity has become their moat, preventing a fork from being viable without significant resources. Mozilla is off in a corner consuming itself in desperation.

            A US-based company holds a monopoly over the free web and a hell of a lot of our non-web software. So maybe let’s look for ways to avoid feeding the beast, yes? And we can get more efficient software in the process.

            • uuldika@lemmy.ml
              1·
              8 days ago

              Isn’t jfx still actually using HTML and CSS, though? like it’s cool that the UI logic is in Java, but doesn’t using CSS mean you still need to lug a rendering engine around, even if not a whole browser?

          • Takumidesh@lemmy.world
            2·
            9 days ago

            Yea, electron has flaws, but it’s basically the only way to make a truly cross platform native and web app. I would rather take a larger installed size and actually have apps that are available everywhere.

            The sad truth is there aren’t enough developers to go around to make sleek native apps for every platform, so something that significantly frees dev time is a great real world solution for that.

      • dbx12@programming.dev
        6·
        9 days ago

        The alternative is “just serve it as a regular website”. It doesn’t need to be an app to do its job. Name a functionality which only exists in electron but not in the standard browser API.

  • Realitaetsverlust@lemmy.zipEnglish
    57·
    9 days ago

    Simple reason - dependencies.

    Modern devs dump any dependency and sub-dependency under the sun into their project and don’t bother about optimizing it. That’s how you end up with absurdly large applications. Especially electron is a problem in this regard.

    You can still write optimized and small software. However, for most businesses, it’s just not worth their time. Rather using an additional couple hundred megabytes of dependencies on the client system.

  • AppleTea@lemmy.zip
    561·
    9 days 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
      17·
      9 days 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
      171·
      9 days 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
        6·
        9 days 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
          7·
          8 days 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
      8·
      9 days 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.

  • ThatGuy46475@lemmy.world
    521·
    9 days ago

    The hp printer app says it needs your location to connect to WiFi. It says it needs your location all the time when not using the app, again to connect to WiFi

    • boonhet@lemm.ee
      272·
      9 days ago

      I think that’s to do with how permissions work.

      Having wi-fi access can technically tell the app where you’re located so you need to give it location access

      Which is stupid because it then also gets GPS access.

    • Otter@lemmy.caEnglish
      45·
      9 days ago

      With that in mind, I LOVE how lean and fast some FOSS apps/projects are. One of my motivations to go searching for FOSS alternatives is when something seems slow for no reason.

      It’s not always the case, but it’s often the case

      • Björn Tantau@swg-empire.de
        20·
        9 days ago

        KDE Plasma has been getting so much more efficient with every release that you can almost recommend it for low-end systems.

          • umbrella@lemmy.ml
            11·
            8 days ago

            lol my laptop is from 2012, i run gnome and kde easily. windows usually needs a round of debloating every update to be usable.

        • NoSpotOfGround@lemmy.world
          42·
          9 days 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.

      • SpaceCowboy@lemmy.ca
        1·
        8 days 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.xyzEnglish
            1·
            7 days 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.

  • KillingTimeItself@lemmy.dbzer0.comEnglish
    401·
    9 days ago

    uh, please do ask, why does opening a fucking glorified text and image processing app require 1 gigabyte of ram.

    Who wrote this software? The guy from the bible who was the model for greed and gluttony? Jesus christ.

    • August27th@lemmy.ca
      231·
      9 days ago

      Nailed it. Things have changed to allow cheaper (interpretable in several ways) developers to create “good enough” software as quickly as possible. If that involves inefficient frameworks, technology, and practices that unlock this, then so be it; if the “best” code is the code that makes money, and money is what corporations prioritize above all else, and there is a way to do that quicker and cheaper, the outcome is obvious and now ubiquitous. Furthermore, if nobody at the top cares, why should anyone on the ground care? The problem compounds.

      Priorities are fucked.

      • bizarroland@fedia.io
        131·
        9 days ago

        If it runs “fast enough” on a completely clean system that would cost the average user $1500, then companies assume that that means that it is a good product.

        If you want better software, you have to give developers worse hardware to develop on, and more time to develop.

        • JordanZ@lemmy.world
          5·
          9 days ago

          If it runs slow on my laptop then there isn’t a chance it will run at all pushed to the cloud. Our cloud servers are…not great. Single core 1.75gb boxes compared to my 16 core, 32gb laptop. We can do a lot with them though. Just takes a decent amount of tinkering. In some ways the cloud was the best thing for performant code.

        • MajorHavoc@programming.dev
          4·
          9 days ago

          If you want better software, you have to give developers worse hardware to develop on, and more time to develop.

          Shhh. There could be application development managers listening… (I’m joking… Mostly.)

      • bleistift2@sopuli.xyzEnglish
        3·
        9 days ago

        inefficient frameworks

        I’d like to object to that. Frameworks are often built by dedicated and paid developers, so they tend to be above average in terms of efficiency. But being frameworks, they have to facilitate lots of use cases, so they also tend to be bigger than what you would write if you had 6 months to roll your own. And 36 more months to kill all the worms that got out of the can, to mangle a proverb.

    • TBi@lemmy.world
      91·
      9 days ago

      I wouldn’t say skill issue, more of time issue. You only get a week to implement something. Quicker to use existing libraries than try to optimise yourself.

      • Hawke@lemmy.world
        9·
        9 days ago

        It’s both, and they are in a sense the same.

        Cheaper less skilled or less experienced programmers take longer to get similar results. One week with a a skilled programmer is a lot more value than one week with an unskilled programmer.

        Even more if you want to invest some of that experienced programmer time to get the new guy up to speed.