App sizes are out of control • Hacker News Board

Re: App sizes are out of control

#361

Post by sebcat » Wed, Aug 02, 2017, 4:14 AM UTC

richardwhiuk wrote: post #198

jayd16 wrote: post #192

Earlier quoted context omitted.

>Surely the 275 MB isn't all useful data (I wonder what compression ratios you get on 'apps'), and it should be possible to cut it down to a few MB. This is pretty tone def. The bulk of apps are audio and ui assets and the compression rates on those are quite good. That said, the compression rate for iOS apps is horrible as Apple decides to encrypt and then compress the binaries, completely blowing apart the compress…

Compress then encrypt is continually a source of vulnerabilities.

For protocols yes, but you need to look at the full picture. e.g., what would the oracle be in this case?

Encrypt then compress makes no sense at all. Compress then encrypt, or don't compress at all.

Re: App sizes are out of control

#362

Post by abdulmuhaimin » Wed, Aug 02, 2017, 4:15 AM UTC

Kiro wrote: post #152

dallamaneni wrote: post #82

I have been replacing traditional apps with PWA's or mobile websites wherever possible (on Android). They hardly take up any space and also seem to behave well (drains less battery) compared to traditional apps. I could replace the following with PWAs: - Twitter - Uber - Lyft - Google news - Instagram - Flipboard - Shopping sites like Walmart, Wish and many more. Facebook and Amazon have no PWA's but have mobile webs…

What exactly is the difference between a PWA and a mobile website?

I can say that I use it accidentally without realising(at first) it was a PWA website. So, Im just gonna tell it in layman term. From what I can tell, its a website, but definitely felt more like an app rather than a website.

the best way to understand it is just to try it. Its just a website(PWA) pinned to your homescreen, so theres not much cost to try it.

Re: App sizes are out of control

#363

Post by lelandbatey » Wed, Aug 02, 2017, 4:29 AM UTC

stevenwoo wrote: post #360

mtl_usr wrote: post #177

Earlier quoted context omitted.

I'm as far to mobile development as I can be but is there no shared libraries on those platforms ? Other than the environment provided ones, isn't it possible to bundle some dynamically loaded libraries that can be shared by multiple apps ? Makes absolutely no sense for each application to implement it's own web browser/runtime. Can't believe we are constantly reinventing the wheel again.

The Facebook API library provided by Facebook is notoriously huge in source code at least, and they're pretty proud of the size of it, can't find the link right now, but they had a blog post talking about it a few years ago ago.

Here's a link to the oft-mocked slides from the talk where a Facebook engineer spoke about how iOS can't handle the scale of their app because they do the very logical thing of using over 18,000 classes: https://www.columbia.edu/~ng2573/zuggybuggy_is_2scale4ios.pd...

Re: App sizes are out of control

#364

Post by FraKtus » Wed, Aug 02, 2017, 4:46 AM UTC

We released 2 apps on iOS and Android. One is 0.8 MB and the second just at 1.8 MB. Obviously we have not a lot of graphics embedded. We use mostly C and 2 cross platform projects SFML and Nuklear for the GUI. The GUI is more in the gaming style but for us it fits the bill and we render at 60 FPS on most devices including the iPad mini original of my daughter.

Re: App sizes are out of control

#365

Post by hamandcheese » Wed, Aug 02, 2017, 4:52 AM UTC

People here seem to be blaming over eager use of third party libraries for a lot of bloat. Is there no such thing as dead code elimination for apps that would eliminate the unused portions of your dependencies?

Re: App sizes are out of control

#366

Post by tehlike » Wed, Aug 02, 2017, 5:10 AM UTC

I'm pretty surprised nobody mentioned proguard. Almost noone enables that, unless they have to, and that's part of the problem.

Re: App sizes are out of control

#367

Post by cyphar » Wed, Aug 02, 2017, 5:12 AM UTC

jamescostian wrote: post #127

cyphar wrote: post #70

Earlier quoted context omitted.

I don't think that's the right solution to the problem. Nobody wants libleftpad.so, and as someone who works on a distribution the very concept is horrific (making distribution packages for every three-line package does not make anyone happy). What I think GP was arguing for is that you have libstring.so which you can strip down to just having leftpad or w/e with Kconfig or similar configurations (preferably at link…

JavaScript people do not create libleftpad.so, they create libleftpad.o (metaphorically speaking), which will not clutter up your distribution, it will just clutter up some apps. I'd rather see 50 little files like libleftpad.o than 5 gigantic libraries. But I agree with what you're saying in the second paragraph, which actually sounds just like what my GP meant by using "Webpack to throw away what isn't used". Havin…

> which will not clutter up your distribution, it will just clutter up some apps.

Not necessarily. Distributions have to build everything, and in openSUSE we have an integrated build system[1] which has a lot of very useful features (rebuild when dependencies are updated, and automated QA runs before releases). Those features require you to have all of the dependencies of a project in an RPM package. Even if you don't end up shipping that package, the package is used for tracking security issues and backports and so on. You can't pull anything from the internet during a build, you have to depend on your BuildRequires.

Now take any average JS application that has over 800 dependencies. Ruby was already bad enough with ~80 dependencies, but adding another order of magnitude is just not maintainable. One of my colleagues gave a talk at LCA about this problem[2].

[1]: https://build.opensuse.org/ [2]: https://www.youtube.com/watch?v=4ua5aeKKDzU

Re: App sizes are out of control

#368

Post by juiyout » Wed, Aug 02, 2017, 5:44 AM UTC

fireflash38 wrote: post #102

DamnInteresting wrote: post #92

One of my first jobs was as a technician at a tech support call center. For a while around 1997-1998, a good 1/3 of our calls were customers who ordered a new system with a hard drive over 2.1GB, but Windows/DOS could only make partitions as large as 2.1GB. Customers wondered why they got a smaller hard disk than they ordered, not realizing the extra space was that Drive D under My Computer. Fast forward to today, wh…

This misses a large point of the article: It's not the storage size that is problematic as much as the transfer size. Websites and developers really need to be aware how long it will take for someone to even get your product. If a website doesn't load in X seconds, you're losing Y customers. If your app takes an hour to download, your customer has probably already moved on in frustration.

OP is saying that what we think is large now could be considered negligible tomorrow. storage or transfer alike.

Re: App sizes are out of control

#369

Post by Groxx » Wed, Aug 02, 2017, 5:48 AM UTC

verdy_p wrote: post #309

TylerE wrote: post #266

Earlier quoted context omitted.

Hand tweaking for specific resolutions is an art. You can't expect to just render SVG and get equivalent results.

SVG stadnardisation and support is growing fast, notably because it is now part of HTML5 and has strong support in browsers, which are the most active software development needed for all kinds of apps. SVG includes many tests to assert the conformance and is one of the best graphic standard in terms of standardization with very precise requirements. It's in fact easy to get the expected results on wide ranges of devi…

It definitely is improving, and it's fantastic to see the progress. I really enjoy SVG assets, and I'd love to see them mostly take over (obviously they'll never be 100%, nor should they).

But that still means it's years away from widespread support, because large companies can't rely on it for large user-bases, and feature-sets are still pretty widely varying in my experience. Some support animations, some complex gradients and masking, and huge variance in text rendering (which is absolutely essential to finely crafted images) cripples some of the most-valuable use-cases (internationalized images without making dozens or hundreds of near-duplicates).

It's just not there yet. I hope it gets there, but there are significant hurdles that don't seem to be getting a lot of attention.

Re: App sizes are out of control

#370

Post by allannienhuis » Wed, Aug 02, 2017, 5:58 AM UTC

s73ver wrote: post #278

allannienhuis wrote: post #156

Earlier quoted context omitted.

Not if they use caching (whether service worker based or not) aggressively.

If an organization isn't taking the time and effort to make sure their app isn't bloated full of stuff, what makes you think they'll do that?

caching can be done reasonably well for straightforward cases with yet-another-library https://serviceworke.rs/

oh, the irony!