Hacker News Reader

Comment by Arainach | Hacker News Reader

This comes up from time to time and I still don't see it. The idea of packaged web apps and web sites is as old as the smartphone (and older on some platforms). Even today, I can tell what experience on my devices are packaged web apps and I don't enjoy them. UI elements don't look right, navigation elements don't behave properly, keyboard shortcuts are wrong. Web apps can be sufficient for some scenarios, but they don't lack the magical feeling of native apps.

View on HN

Wait until mobile OSes start building a native presentation layer built on WebAssembly.

Apple already tried that approach with the iPhone one. It failed because the technology wasn't mature, but there have been nothing but advances since then.

The web is a more flexible and portable platform, so the economic incentives will always be there. And while native toolkits are still based on 1970's lab research, the web as a platform benefits from mainstream usage by the whole world. At some point, the new tech will overcome and replace the old approach. The gap is getting smaller every day even if the old approach has decades of advantage, and all major tech providers are pushing for it.

With the security sandbox of the browser functionality is inherently limited (by design) compared to native apps which have less-limiting restrictions.

Security and usability are inversely proportional and the browser needs that security more than anything else.

That being said, it's great to see the innovation in the web space. But it will always be limited to specific application domains and the standards move slowly

Even by 2009 it worked fine -- I had a Palm Pre, and the experience of using webOS on that hardware was always responsive and pleasant. (Palm Inc. and the Pre both had lots of problems, but webOS wasn't one of them.)

In fact if I had the opportunity to buy a webOS device today I would ditch Android in a hot minute...

You can buy some webOS devices today: LG's "smart" televisions. It's actually quite slick.

XUL again?

If it's more convenient to Google and Apple, they'll push for it, and we can only adapt.

But don't expect developers to ask for it. As it happens with those things, each platform will have their own, incompatible toolkits, and programming for them will not be much different than native programming.

Why haven't they built a native UI toolkit for JS, though? What will WebAssembly give them that makes it worthwhile?

The ability to leverage more native capabilities than JS can. A more generalized, less platform specific format for executable code already seems to be a goal for iOS and Android. Android of course has always used Java (well, Dalvik technically) bytecode, and Apple recently has started pushing their LLVM-based bitcode to reduce dependence on specific architectures.

If WebAssembly does a good job of exposing features needed for high-performance code, it could become feasible to move everything to WebAssembly and ditch support for native code on both platforms.

WebAssembly doesn't make native integration any easier than JS. Neither defines the exact way so called non-web embeddings actually are defined and both can support it. I honestly have no idea the relevance of WebAssembly in this discussion. Could you provide an illustrative example?

Edit: I should clarify that for certain types of apps WebAssembly might be relevant but the discussion seemed to be out UI layer and I don't understand how WebAssembly fills a gap that a native API in JS could also provide along with the same challenges.

I'm sorry, I'm using "native" in an unclear way (that should have been obvious to me). I don't mean it will help with native API integration (JavaScript can do that just fine), I mean as a replacement for machine code on both platforms. iOS of course uses machine code for everything, but on Android it's mostly whittled down to the minimum: things that Java can't do efficiently, or code that isn't Java. That's the role I hope WebAssembly can fill, but it still remains to be seen how usable their solutions for threads, SIMD, etc. are.

A good example is games. Some do manage to use Java, but it's mostly a hindrance; being able to compile languages with a C style ontology to a platform-independent and efficient VM would be very helpful here.

> Wait until mobile OSes start building a native presentation layer built on WebAssembly.

Is there any active project you can link to regarding this?

WebAssembly is too new for this to be a thing yet.

>native presentation layer built on WebAssembly

Is your prediction that companies will start compiling their UI toolkits for browsers?

Not op but it seems like a logical step to at least attempt to do this, or something similar.

For the operating system makers?

I don't understand why people love websites so much.

If a site is plaintext and has minimal JS, it's usually fine on a mobile device.

But the moment there are interactive elements or menus or web fonts or whatever else, things are visibly broken, or they become broken once you start scrolling. Even relatively inoffensive websites with simple menubars have stuttering scrolling animation.

Any decent native app doesn't animate that poorly. I'm an iOS user because design and UX are clearly valued by (non-shovelware) iOS developers. Having buttons jump around the screen or some weird JS stealing scrolling momentum would be unacceptable if it were in an app, but I visit at least one popular website a day where that's one of the problems.

URLs.

View source.

Standards.

Cross-platform.

Why is that more important than UX?

Those things ARE the user experience.

I disagree wholeheartedly.

Packaged web apps are the worst of both worlds: the inconvenience of apps and the speed of web sites.

But the article isn't talking about packaged web apps, it's talking about browsers, and has an interesting redefinition of that term.

What is the inconvenience of apps?

Besides having to wait for the installation, one important recurring inconvenience for me (on iOS) is the lack of autofill. Especially autofilled user names and passwords.

I really wish Apple would add a password-manager extension point to iOS. Since they're trying to push iCloud Keychain I'm not optimistic about this happening, but it would be a really nice way to make password managers more attractive.

Maybe it's just specific apps integrating with 1Password, but Mint, among other apps, already can do this (and it brings up what appears to be an iOS share sheet). But this feature has largely become irrelevant to me thanks to almost every app I use that requires sign-in supporting Touch ID.

> I really wish Apple would add a password-manager extension point to iOS.

They kinda have in 2 ways - as of iOS 9 or 10 your app can utilize login credentials from your web domain name if certain requirements are met, and there's touchID for instant login after the first authentication.

I use Lastpass and a lot of apps offer a weird icon next to the password box that opens a share sheet with LastPass as an option.

If you see an interesting link on the web, you generally feel safe clicking on it, and often click on it. Sometimes you get rick-rolled or whatever, but you just hit back.

If you see an ad or pop-up article about an app, what are the chances you install it, even if it looks interesting?

I feel very safe installing apps on my iOS devices. The sandboxing and app store review process gives me confidence that it's not going to be malware.

I click on links more than I install apps because loading web pages is a lot faster than installing apps. The flip side is that I hardly ever return to those "interesting links," while I use my installed apps frequently.

Most people only use 4-6 apps a day, or less. Users are spending more and more time in fewer apps. I reckon a good bit of that is the friction of installing new apps.

> The sandboxing and app store review process gives me confidence that it's not going to be malware.

I would re-evaluate that stance if I were you: http://www.wired.co.uk/article/xcode-apple-app-store-hack. Hundreds of apps injected with malware by a compromised version of Xcode made it through the App Store review process.

Needing to install, open and update an application to use a service as opposed to the 'convenience' of just entering a URL in a browser.

Web page does not need opening? Interesting… Updates happen automatically now.

After installing it, you need to open it (ok, it's easy). Updates frequently require approval of new permissions (android).

But the alternative seems to be browser exposing APIs for all those permissions through Javascript and the end-user not really having any control over that. Perhaps I'm just naive about it, since I really don't do Javascript-based development, but this seems to be a worse idea than apps.

Web pages don't require uninstalling when you decide they're not worth it.

On lots of old android devices: having to remove apps to make room for a new one

Even when you have tons of spaces on a huge sdcard even. This is incredibly frustrating as some devices were shipped with very very little space and too much of that taken up by the stuff that shipped with the phone that for whatever reason cannot be moved to your relatively large sdcard.

I think merged storage is either here in the latest version of android or coming which will hopefully let us stop worrying about storage again but many devices will sadly never see the update.

Having to install them, remember what screen and folder it's in, etc.

> remember what screen and folder it's in

How is this fixed by a web app you have to remember the address for, or at best, remember where on your favorites you saved it?

How much work is installing the app? Single tap? The same of less than opening a web page? No need to remember screen and folder, just use global search on your phone.

Assuming I'm linked right to the exact app to install.

Click install. Review and approve permissions. Wait for some ungodly amount of megabytes to download. Wait for installation. Then open. Then approve some new permissions. Splash screen. Woo, content! But I'm not "deep linked" to the place I need to be.

Or, for a website: I'm just there.

Well, it's not a lot of work. But it feels like way more work. It's visible even in the way we talk about it - "viewing a website" vs "getting an app". Looking at something is effortless, getting it implies effort. Often, too much of it, if I just want to check some stuff out quickly.

Also, I feel like after installing an app, it takes more time to get to the actual content, because every app has a few screens of "Welcome to Foo! Here's how you do stuff in here." Websites are pretty instant compared to that.

Whoa. If you want content quickly many apps will offer it in widgets. Many will show you notifications with ability to interact with them without even opening the app. There is nothing instant about websites.

I believe the contrast was between the following.

Open browser, create new tab or focus url, enter url

Open app store, search for app name, click on the one that seems correct, read reviews, click install, wait for installation to finish, open new app.

This of course is only valid for the trying a new application or website which hypothetically is 0.001% of your usage of an app.

My point was: There's no problem with casually checking out a website. But I'm probably not gonna install an app unless I'm pretty sure it offers me some value. Not rational? Possibly :)

Similar, but web pages are usable before fully "installed". Data has repeated shown that users quickly abandon websites that don't load extremely fast. Apps are like that, but even slower.

It's simple, when you want to do X, you want to do X, you don't want to do a lot of setup work before you start doing X.

In what world native apps are slower than web apps? And where do you find "extremely fast" websites, with all this JS frameworks crap and gazillion of trackers being pushed to your poor browser?

In ever world since you have to install them and you don't have to install web apps.

Where do you find those extremely small native apps that are smaller than a website?

It doesn't matter; worse is better. 1999 Yahoo Mail was not a good user experience, but it (and other web-based mail services) destroyed the likes of Eudora.

Ubiquity >>>>> UX.

Well its that, and that the users didn't need to configure a single thing when using the web thingy.

Problem is, imo, that so much of the web assumes a mouse and keyboard. I keep running into "mobile" sites that are so crammed with links and other tap targets that i have no chance to hit the right one on first try with consistency.

...so HN is your first point of call, where the tap targets are so easy on the web first interface...

Content is King

Not for me: HN is awful on a mobile browser, so I use an app (MiniHack). It's so much better than the mobile site that it has become my go-to counterargument whenever someone insists that the mobile web is going to displace apps any day now.

It used to be awful. Basically you would get the desktop site without resizing, small text, have to zoom etc. It's not like that now. Haven't seen an app that's any good and you don't need one. Site works well in mobile now.

HN is an outlier because there's no business model or team of OSS maintainers with motivation to improve it. I can't think of any other sites I visit in the same position.

It's not the only example though, just the one with the widest disparity. Reddit and Tumblr are also both considerably worse experiences on their mobile sites than their apps, assuming you know enough to get the good apps.

I just keep hearing posts about how the mobile web is so clearly superior to apps and it never tallies with the reality on the ground for me.

Though, being fair, MiniHack is literally one of the best and most focused apps on my phone! Such an amazing product, was well worth the couple dollars.

I'd say that ubiquity is a factor of UX.

Not for everyone.

I still use Thunderbird.

I agree.

Mobile is already maturing. By the time web technology is good enough to create a native-feeling experience, we will be on to the next runtime.

(Disclaimer: I do iOS consulting, so hugely biased)

You are one of the exceptions, most of us are happy with it.

Reply on news.ycombinator.com