back to article How to make your HTML apps suck less, actually make some money

Your web apps probably suck, according to Google, but there are solutions if developers get progressive. Not just because of mediocre coding, legacy baggage, and half-hearted optimization, but also because the mobile ecosystem is full of pitfalls like slow network speeds and underpowered devices. At the Chrome Dev Summit on …

  1. ratfox Silver badge
    Paris Hilton

    56MB for its iOS app and 9.6MB for its Android app

    I'm not sure whether it's terrible or not; after all Apps are downloaded once and used forever. But I'm wondering: Anyone know why the iOS one is so much bigger? More feature for the premium user, or is it an OS thing?

    1. Robin

      I've wondered about app download sizes before. For example, Facebook's last iOS update was about 200 meg if I remember rightly. Seeing as it's all online content, WTF is in there to make it that big?

      I realise the answer is probably 'all the spyware' but it would be interesting to know what goes in there.

    2. Malcolm 1

      I will prefix this with the proviso that I have never written an iOS app but my understanding was that they still require bitmap assets in many different sizes for all the various iPhone/iPad screen sizes and resolutions. I think they used to also require 32 + 64bit universal binaries, but I thought that requirement had ceased with the recent iOS release.

      Android has always used more resolution independent resources due to the vast potential differences, so not such a big deal there (although it paid for it in terms of UI responsiveness for many years).

      If I'm completely wrong I'm sure someone will be along to correct me shortly - this is the internet after all...

      1. myhandler

        Can't they use SVGs for 90% of the use cases?

        1. ThomH Silver badge

          @myhandler

          There's still no native supplied SVG renderer outside of a web view, which makes developers more conservative. Apple's current advocated solution is to produce your assets as PDFs, after which Xcode renders them to the appropriate size classes at build time.

          For iOS 11 onwards, there are two size classes, as there are no @1x 64-bit devices.

          It's unclear exactly to what this article refers, but Apple's App Store uses a process called 'app thinning' to deliver to each device only the assets that device will use. So a 56mb upload is rarely a 56mb download. Or, if they genuinely mean a 56mb download, then that should vary.

          I would guess that they're holding off on SVG support because it's a many-tentacled thing, requiring both SMIL and JavaScript support for a full implementation. But it's a real hassle that they don't support, say, a static subset or some other vector format, especially as they provide COLLADA support for SceneKit.

    3. HieronymusBloggs Silver badge

      "I'm wondering: Anyone know why the iOS one is so much bigger?"

      I would guess (and I could be wrong) that the iOS one needs to be bundled with some large (maybe statically compiled) libraries but the Android one uses system-provided dynamic libraries.

    4. DJ Smiley

      Higher res graphics for those times when your holding your phone 0.2 cm away from your eyeball ?

    5. Ilsa Loving

      I am guessing some kind of porting libraries.

      I would guess that the original code was written for Android as Java, and then ported to iOS as an afterthought. So its possible that there's a huge pile of libraries added in to support running the app in iOS without the developer needing to go through a huge redevelopment effort.

  2. pauleverett

    hang on ...

    firstly, chrome really sucks, and google are evil.

    what they really want to teach us is how to make a site that might work, with their browser, and how to make a website that integrates all of their advertising BS, whilst being less awful. Google, and its like, are pretty much responsible for the diabolical, laggy, error prone, state of the entire internet. Advertising may have paid for this internet, but it has also created a snowball of negatives. This data hungry behemoth, requires ever more resources, for the simplest of tasks. I blame google for this mess. They now want to teach us how to work around problems of their making.

    1. ecofeco Silver badge

      Naw, google is just the largest. Blame the advertising server houses, their code is no better than a teenager's at best and optimization is an idea that will get your fired.

      Then blame the fucking morons who think 12+ unique servers are required to run and pay for a website.

  3. RyokuMas Silver badge
    Devil

    "... while outdoing them in terms of discovery and distribution"

    ... provided you bend over and take it from Google in order to feature anywhere near the top of their search rankings. Which probably involves adding their tracking and tagging, and hell, their proprietary, non-standard extension to the base set of HTML.

  4. Anonymous Coward
    Anonymous Coward

    Google advising on page speed?

    "According to Google the average time to load a mobile landing page is 22 seconds"

    Not really, it's much quicker once you block all Googles tracking and adverts

    1. Anonymous Coward
      Thumb Up

      Re: Google advising on page speed?

      I've upvoted you once, as that's all I can do. But imagine at least 1000.

      Google are attempting once more to apply a small dirty plaster to the large weeping sore they caused in the first place.

  5. Detective Emil
    Meh

    Kool-Aid duly drunk

    Google wants you to make web apps because, unlike native apps, their content can be crawled.

    1. bombastic bob Silver badge
      Unhappy

      Re: Kool-Aid duly drunk

      it's part of the "content consumption" model for devices and applications.

      and the "advantage" of having all of that stuff on a cloud server? The built-in monitoring and tracking, of course! Just have that web-based-app "phone home" every time you use it. no problem! And with the crappy performance expectations from an online "app", nobody will notice if there's a bit of tracking in there, too.

      And don't forget the ad-servers. hey, just an OCCASIONAL popup or embedded banner... for now...

      and the frogs continue to "not notice" that the water temperature has gone up another 15 deg C.

  6. BinkyTheMagicPaperclip Silver badge

    'PWAs need to be fast, engaging, and work offline'

    So, basically a desktop/mobile app then, and not one using Chrome because that's far too heavyweight..

    1. Malcolm 1

      Re: 'PWAs need to be fast, engaging, and work offline'

      Yes, but presumably you already have Chrome (or Safari, or Edge) installed so you get to reuse that functionality and obviate the need to install a separate app without having to "install" anything.

      Compare this approach to various cross platform apps such as Slack or Atom which include a complete (and possibly obsolete) copy of Chrome to use as an application run time.

      I'm not saying this is more efficient than a bespoke native application (it's almost certainly not) but the developer overhead is much reduced and may permit apps on more platforms than might otherwise be possible. And the "cost of entry" is practically zero so you don't get bounced to an app store to install an app to get back to the content you were actually interested in (or giving up instead, which is perhaps more likely).

      As a real-world example, mobile.twitter.com is a PWA that does practically everything the fat client app does in a fraction of the space. It doesn't necessarily scale to more complex apps (yet) but for a decent subset it's a nice solution.

  7. Saul Dobney

    Still too heavy...

    Current web apps are too resource hungry and don't cache well, leading to over large downloads of things like frameworks, fonts, stylesheets and then bringing in too much asynchronously. It's pretty easy for a simple web-app to be requiring 1-2MB of download just to get started before rendering where a simple HTML switch to a new page might be 20-30kB if the cacheing is done well.

    The second problem is that web-apps tend to be designed with one route/journey for use. Eg on an airline booking, the expectation is that you pick departure airport, departure date before moving on to arrival airport. Users don't necessarily do this. They see something on screen and click on it to see what happens, and the routing/journey model breaks down. As a result, designing a web-app is much less like web-development and much more like full software development in terms of skills, and requires much better design and testing.

    And your web-app has to fall-back to simple HTML because some users have work policies that limit or preclude access to third-party resources for companies known for tracking online behaviour.

    1. bombastic bob Silver badge
      Unhappy

      Re: Still too heavy...

      best example of why NOT to do 'web-based' things: google docs online editor. Try a spreadsheet some time... one with actual formulas in it that auto-update every time you change something [because a junior "programmer" developed it].

      any amount of latency, or if you like listening to streaming content while working on things, or someone in your household is playing youtube videos, and your performance will SUCK like a Kirby. [and Kirby vacuum cleaners suck on MULTIPLE levels]

  8. -tim

    If only ...

    Had some smart people figured all this out in 1970s and published a book about how humans cope with slow interfaces, all this would have been avoided.

    Its almost like a mythical man microsecond just magnified 32 billion times.

    1. bombastic bob Silver badge
      Unhappy

      Re: If only ...

      "Its almost like a mythical man microsecond just magnified 32 billion times."

      good analogy.

      I cope with slow interfaces by SCREAMING PROFANITIES and ranting online.

      Micro-shaft is the worst for unnecessary bandwidth pollution. I don't know how many times I have to click on 'temporarily allow all this page' (in NoScript) for ANY of their online stuff (like MSDN) to work these days... the number of 3rd party scripts is OUTRAGEOUS and it's only getting WORSE.

    2. This post has been deleted by a moderator

  9. rmullen0

    Sounds like complete BS...

    to me.

  10. dch0ar
    FAIL

    Android garbage

    It would be good if the garbage could be stripped out. Also Android accumulates dead space in its caches and data space. At least it is better than IoS on iPads where rescuing memory can only be done by reinstalling an app, which is impossible with compulsory apps.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019