Hacker News Reader

One of my favorite things is to see a problem I think is trivial and learn its hidden complexities, like the "X things developers think about Y" series of articles.

However, to take the parent's example of an HTML doc with an associated script...the browser does do this, and a rebuttal has to reckon with that. My Chrome web browser runs on thousands of different devices, countless OSs. A small Hello World file can run _with_ a header that supports RTL languages, can very simply say what version of HTML it's using (doctype yadda yadda...I grant that the situation is considerably more complex for JS nowadays!), and can run in any browser size imaginable. It doesn't have a "large library" of useful layouts—the developer just includes what they need. Yes, I'm sure running native on the phone brings many difficulties browser apps don't have to deal with, but from the comment alone I'm not sure what those are beyond signing.

The sample app, with it's 1.5 million wasted bytes that 'do nothing' handles those problems.

If all apps have to include 1.5MB of code to handle the same set of problems, then it sounds like the perfect place for that code is in a shared library, perhaps distributed with the OS.

A large amount of that 1.5 MB of code is to shim around the incompatibilities between different versions of the shared libraries that ship with Android. The root of the problem is that not everyone is on the same version of Android.

The root of the problem is that not everyone is on the same version of Android.

Alternatively, it seems the root of the problem is that all the different versions of Android don't have enough commonality for compatibility. I have apps which were originally written for Win95 and continue to work on Win10. Microsoft hasn't always made great decisions, particularly recently, but seeing a single small binary run unchanged over 20+ years of platform differences is something that IMHO other companies can learn much from.

(I know Android devices, despite mostly being ARM, cover a wider range of architectures... but isn't that what basing everything on Java was supposed to solve?)

I don't really see a difference. Android's API changes are almost always backwards compatible. There are a few exceptions, like AudioManager.setRouting (now a no-op), but they're very rare. For the most part, apps built for for early versions of Android still work fine on modern devices.

The support libraries which the parent referred to are optional utilities. They're often the most convenient way to implement something like a snackbar (https://material.io/guidelines/components/snackbars-toasts.h...), but they're by no means required. Just like on the Windows side, WPF is probably the most convenient way to create a ribbon, but you could build your own with the old win32 APIs if you wanted to, or just not use ribbons.

Not everyone is on the same version of Chrome either. It works out just fine. If you want a feature that the user's version of Chrome doesn't have, you detect that and inform the user.

That shim is still same in all apps bundling the same version, though. Thus it is possible to distribute it out of band as a shared component just like system webview.

These things don't justify wasting over a million bytes. Many of them are not even real issues.

> Where is the header bar

Why should there be one if I haven't defined one? If I define it, then I will tell you where to put it and how to render it. Better yet, if it's a standard, I expect the system to already include the libraries necessary to facilitate its usage.

> What color is it? What font? What placement

If it's implemented in the standard library, these can all have default values (like html pages do). Even if I define these, they should not take more than a few bytes. Not even a kilobyte.

> What about users who don't read English? What about users who's languages don't fit in ASCII.

Why do I need to include extra bytes to tell the system to use UTF-8? It should be the default. At most, deciding which unicode encoding to use should not take more than one byte. I don't think there are more than 4 or so options anyway. UTF-8. UTF-16, UTF-32. Did I miss something?

> What about users who's languages aren't read left-to-right.

What about them? Doesn't the system come with text rendering facilities? Don't they support international languages? What kind of OS is this? Haven't the OS designers heard about HarfBuzz?[0]

> How should the header bar even be drawn?

Did you just repeat a previous question to make the list bigger?

> It's easy to say "I saved 5k bytes by dropping RTL" but... you dropped all RTL language support.

No, because adding or dropping "RTL" does not require any bytes.

The sample app does not even include any i18n so there is no text in any RTL language.

You only need to support RTL if you are writing an OS or a text rendering library. This is not an issue that applications need to deal with.

> Some poor souls at Google waste a lot of time making sure developers get a large library of useful layouts and controls that all mostly-just-work mostly-consistently across a huge spectrum of devices and API releases.

The Android API is notorious for being terrible. I know Google spends a lot on it, but damn IT SUCKS!

Just because someone wastes a lot of time on something does not mean they managed to do it well.

(Not that _I_ would do it any better; So spare me the ad-hominem criticism).

[0] https://freedesktop.org/wiki/Software/HarfBuzz/

> What does this app do on phones? On tablets? On laptops?

The same thing, by default. Scale pictures and text automatically. <img src="some-image.svg" style="width:0.1cm;height:0.1cm"> for universal compatibility without those godawful hdpi mdpx xxhdpi qxfhdpi directories and whatnot. Use something like CSS3 selectors or code if you want different layout on phones/laptops/tablets. The default should be to just display the same thing. Different layouts usually happens several months into an app's development cycle, and that's only if they actually gain traction. For most apps, targeting only phones is plenty good.

> Where is the header bar (the original has one, yours doesn't).

There isn't one. If you want one, add it:

    <header-bar style="background:#ff00000;color:#ffffff">
        Hello World
        <hamburger id="mHamburger" style="float:right;"/>
    </header-bar>

> What color is it?

The default, unless the developer styles it otherwise.

> What font?

The default, unless the developer styles it otherwise.

> What placement?

Left, unless the developer styles it otherwise.

> What about users who don't read English?

Don't worry about it and just display the text. When I have enough traction in my initial market, be that English or Japanese or French, I'll consider internationalizing later. Until then, everyone gets the same thing. In a lot of apps, until the content being offered for consumption is internationalized, it makes very little sense to waste time internationalizing the UI. And even if your app doesn't offer any content it probably still makes more sense to build and ship quickly (read: make building easy!) and worry about internationalizing later.

> What about users who's languages don't fit in ASCII.

Just default to UTF-8 already for all source files. End of story.

> Some poor souls at Google waste a lot of time making sure developers get a large library of useful layouts and controls that all mostly-just-work mostly-consistently across a huge spectrum of devices and API releases.

Great! I appreciate all that. But they should live on the system. An full-blown HTML5 app can be a few tens of kilobytes and support RTL languages and everything you mentioned. Chrome takes care of all that consistency stuff. Android should do the same for native. I shouldn't have to go through hell just to draw a button on the screen.