• UnfortunateShort@lemmy.world
    9·
    3 hours 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
    7·
    4 hours 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.

  • kamen@lemmy.worldEnglish
    9·
    5 hours 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
      4·
      5 hours 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…

  • RaptorBenn@lemmy.zip
    71·
    5 hours ago

    It’s nearly all just using a whole library instead of the specific single function thats actually required, because few people are actually writing any code these days.

  • AppleTea@lemmy.zip
    441·
    9 hours 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
      6·
      4 hours 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.

    • MonkderVierte@lemmy.ml
      5·
      2 hours 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.

    • Lifter@discuss.tchncs.de
      13·
      7 hours 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
        5·
        5 hours 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
          3·
          2 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 certain apps but the layperson doesn’t know.

  • rational_lib@lemmy.world
    15·
    9 hours ago

    Because the app stores keep adding new requirements that you have to add code to deal with and it gets worse every year and seemingly every day.

  • WorldsDumbestMan@lemmy.today
    272·
    11 hours ago

    Usually, instead of having 8-bit art, you have epic songs and very high definition textures. That is a good deal of why.

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

  • Realitaetsverlust@lemmy.zipEnglish
    54·
    15 hours 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.

  • devilish666@lemmy.world
    20·
    14 hours ago

    That topics always made me curious tho…take a sample AAA games back then has smaller size compared to shitty Unity 2D games nowadays and i wonder why ?

    • endeavor@sopuli.xyzEnglish
      6·
      9 hours ago

      Smaller textures, more assets, and worse audio mainly. Textures used to be like 512 for hero props. Now even random objects you see a few times get a texture 16 times larger. And they get up to 4 of those for each object/group of objects. Thanks to pbr and normals and whatever other masks and lightmaps may be required.

      Im sure there are more reasons for size bloat but this is from us artists at least.

    • gens@programming.dev
      14·
      12 hours ago

      Less triangles and smaller textures. Crt monitors had less resolution and practically built-in anti-aliasing so they could get away with (and had to) “worse” assets.

      Also since ssd-s have become mainstream unity uses less compression so it would load relatively faster.

      Basically because monitors got better, standards got higher, competition got fiercer, storage got bigger and faster, etc.

      And it’s not like there weren’t shitty games before, just everybody forgot about them.

      I like how the game Banished is made. From a requirenments/looks ratio it is IMO great. One guy made it. Ghosts of Tsushima also looks amazing and is great from a techical perspective, but it is heavy.

      • endeavor@sopuli.xyzEnglish
        1·
        9 hours ago

        Polygons aren’t that costly, they’re just a set of coordinates and pack up well and ultra expensive highpoly stuff is avoided wherever possible by proffessionals. It’s mostly textures and maybe audio that bloats size.

    • Cratermaker@discuss.tchncs.de
      3·
      12 hours ago

      Yeah but like, what new features do apps have which weren’t available in those times? Embedded videos maybe? Doesn’t justify the bloat.

  • KillingTimeItself@lemmy.dbzer0.comEnglish
    391·
    16 hours 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.

  • Stovetop@lemmy.world
    288·
    22 hours ago

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

  • blind3rdeye@lemm.ee
    331·
    17 hours ago

    It’s like Moore’s law. The number of bytes for a basic app doubles every 2.5 years.

    When I was young, we’d get a few different games games on a single 1.4 Mb floppy disk. The games were simpler, sure, but exactly the same games now would be far bigger in bytes.

    • 🇰 🔵 🇱 🇦 🇳 🇦 🇰 ℹ️@lemmy.worldEnglish
      34·
      17 hours ago

      At least games make sense, as the graphics get better. Though in some cases, the compression is also better. Like PS5 games are smaller on average than their PS4 versions, even though they have higher resolution textures in most cases, just because the PS5 has better compression/decompression tech.

      • HeyThisIsntTheYMCA@lemmy.worldEnglish
        1·
        8 hours ago

        Like PS5 games are smaller on average than their PS4 versions

        My favorite example of this is Subnautica. The system didn’t call on the assets as quickly, or a different way I can’t remember all of the details but essentially they had to put like five copies of every asset on the ps4 version to get it to run properly. The ps5 accesses the assets fast enough it only needs one copy. At least that’s how it was explained to me.

      • Flatfire@lemmy.ca
        17·
        16 hours ago

        Better than that, the lack of reliance on spinning disks means that asset duplication and data read order is less of a requirement to reduce load times. It can still be argued that there’s just too many polygons, since simply scaling things back would be plenty effective in reducing storage usage and load times.

    • Huschke@lemmy.world
      11·
      17 hours ago

      Games is the one example that actually makes sense though. The game code size hasn’t really increased tremendously, but the uncompressed assets have only gotten more detailed and more numerous.

    • jmcs@discuss.tchncs.de
      1421·
      22 hours 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
        13·
        15 hours 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
          2·
          5 hours 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
      33·
      19 hours 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.