Live data from Hacker News

The Decline of the Mobile Web

cdixon.org

201–209 of 209 posts

Re: The Decline of the Mobile Web

#201

There is a point here that many websites don't need an app, but have them as part of a fad. However, on the flip side as wearable tech becomes more and more prevalent (think Google Glass, but also things like Jawbone), it make a lot of sense that more and more of our internet usage goes via these interfaces which are inherently non-web.

I've coded for google glass, and I don't think our internet usage will go via wearable things -- at least not ones like glass.

Information displayed needs to be understandable at a glance and relevant to the very here and now. Usable real estate is extremely limited in glass and interaction is limited to voice, simple gestures against the right frame, and GPS/accelerometer. So doing interaction with any amount of complexity gets frustrating and annoying very quickly.

Re: The Decline of the Mobile Web

#202
post #99

Earlier quoted context omitted.

I agree that this is a significant factor in the problem, but it is far from the only one. The problems with the mobile web are far broader than that. Being tied to JavaScript (a language whose semantics remove significant optimisation opportunities, unless you write in something else and target via asm.js), a UI layer that doesn't cleanly map to being hardware accelerated, and missing or incomplete APIs for everythi…

Being tied to JavaScript (a language whose semantics remove significant optimisation opportunities, unless you write in something else and target via asm.js) In a world where V8 exists, I'm not so sure. JS running on the main thread absolutely is a problem, and Web Workers are a clunky solution. a UI layer that doesn't cleanly map to being hardware accelerated Agreed this part is tricky. But existing hardware acceler…

"But existing hardware acceleration on mobile web isn't that bad."

Mobile users are extremely demanding, in my experience. They DEFINITELY notice the difference between web & native interfaces. When mobile is accounting for huge %s of traffic and revenue, its a hard sell to settle for good-enough for philosophical issues. Particularly when the competition isn't.

Re: The Decline of the Mobile Web

#203
post #108

I think Facebook is an instructive example here. They tried for a long time to make their native app (for Android, anyway) just a wrapper over the mobile web client, but they could never get the performance all the way there. They went native and have seen great results. They resisted as long as they could but eventually the products had to diverge. I'd say 80% of developers who choose native do so for performance, a…

This was the main critique of the original article - that Apple and Google are blocking the open mobile web in order for native apps to thrive. Both Android and iOS are built around promoting apps. The web is a second class citizen. On iOS I would go as far as to say a third class citizen, since Apple are blocking the fast Javascript engine in native apps. This makes the idea of having an app as a simple web-wrapper…

I wish firefoxos and available hardware could have the word-of-mouth momentum for friends and family installation that the browser had. I would do this, but alas, its much more difficult to install on a family member's phone than the browser was on their pc.

Re: The Decline of the Mobile Web

#204
post #77

Earlier quoted context omitted.

The entirety of current web design practice is taking full control over the UX. Gone are the days when you sent a GET and got an html document back, the most interactive element of which was a textarea box. The other reason flash was a pain, incidentally, was because it was easy to bog down a client computer with overzealous flash stuff... just like the current tendency to use javascript to do all your rendering and…

Rendering on the client side is fast, especially on the newer high end devices like the S4 & the IPhone5. It will only continue to get faster. The biggest issues are bandwidth/asset file sizes & using heavy-weight frameworks. They bog down the UX on mobile devices. On my current project, I'm using browserify, Backbone, jQuery, & compiled Handlebars. The same codebase supports rendering on the web server, rendering on…

Rendering on the client side is not even possible with the vast majority of handheld devices in use around the world. The biggest issues are, as they have always been, the fact that commercial interests have triumphed over any kind of inclusive standard practice.

Please understand I'm not passing judgment on the matter -- but I would like to highlight the relatively elite status of people with quad-core telephones.

Re: The Decline of the Mobile Web

#205
post #100
post #58

Earlier quoted context omitted.

>Why should the app stores decide what can and cannot be on our phones This is not a freedom problem. You have the freedom to buy an Android device, and you have the freedom to install any apk you want without ever even opening the Google app store. Moreover, Google even allows 3rd party app stores on their devices. And of course these new players are acting as middlemen, but you are forgetting the fundamental differ…

That argument definitely doesn’t work for Apple but it also doesn’t really work for Google. Yeah, installing any apk is possible, but hard to do. Any apks and apps in the app store are a million miles from being on equal footing.

i dont get why its considered hard to install an apk.. u download it and run it..and android will say u need to tick some box to install this and u do.. and then it installs.. people download and install windows software all the time, it works almost the same...

Re: The Decline of the Mobile Web

#206
post #166

Earlier quoted context omitted.

Google showing results that go directly to an App is an important piece of this whole puzzle: https://developers.google.com/app-indexing/webmasters/

That's a good thing though right? Isn't that how a URI/link should work?

I guess, but they really are just directing traffic to a an app rather than a browser. A subtle difference to sum, but when you take into consideration that that app would have probably been downloaded through their store, it keeps people in the same loop.

Re: The Decline of the Mobile Web

#207
post #108

I think Facebook is an instructive example here. They tried for a long time to make their native app (for Android, anyway) just a wrapper over the mobile web client, but they could never get the performance all the way there. They went native and have seen great results. They resisted as long as they could but eventually the products had to diverge. I'd say 80% of developers who choose native do so for performance, a…

This was the main critique of the original article - that Apple and Google are blocking the open mobile web in order for native apps to thrive. Both Android and iOS are built around promoting apps. The web is a second class citizen. On iOS I would go as far as to say a third class citizen, since Apple are blocking the fast Javascript engine in native apps. This makes the idea of having an app as a simple web-wrapper…

Third class citizen on iOS? Safari does have the fast JIT javascript runtime, but native apps don't - so it's somehow not good for the open mobile web but good for native apps? I fail to see the logic in that. If you have a pure web-app - which you can pin on your homescreen, you do have the full speed Javascript engine, just look at the financial times app (app.ft.com) for a good example.

Also - 'the mobile web' did not exist before the iPhone popped up. Now you have a blazing-fast mobile webkit used in Android, iOS and on more recent Blackberries, and have a quite decent mobile IE on windows phone. Each generation of mobile OS, the mobile browser performance improves massively, adding more and more features with every generation. But somehow they are blocking 'the open mobile web'?

Also - a browser is not the only 'web application'. You already have mail, RSS readers, calendar apps, twitter clients, ... in whatever form, webapp, native desktop app or mobile apps - they all exist. They're all using 'the open web'. I think inter-operability is more important than "it has to be html5". The open web is in my opinion: open API's and data format. And that is exactly what we have, a large amount of mobile apps are just a native more intelligent client for some web API or content for which a website is also available. Twitter, Facebook, Reddit apps, Kickstarter, ... all have 'native' apps - does that mean it's less open than using a web-browser? No - it's just optimized for mobile use, something that is very hard to do with pure html5. REST/JSON api's have taken over the open web. Native or web-apps are just front-ends for these api's - that's the direction it's moving in.

I don't see the problem really, web-browsing still is one of the killer apps of a mobile device - tablet or phone, and that's something neither Google, Apple, Microsoft, or any other large corporation will ever limit. Yes some apps are rejected for whatever reason, but there is competition to choose from if one of iOS, Android, Windows Phone, Firefox OS or Mobile Ubuntu makes choices in their rejections that conflict with your personal beliefs.

Re: The Decline of the Mobile Web

#208

Earlier quoted context omitted.

Rendering on the client side is fast, especially on the newer high end devices like the S4 & the IPhone5. It will only continue to get faster. The biggest issues are bandwidth/asset file sizes & using heavy-weight frameworks. They bog down the UX on mobile devices. On my current project, I'm using browserify, Backbone, jQuery, & compiled Handlebars. The same codebase supports rendering on the web server, rendering on…

Rendering on the client side is not even possible with the vast majority of handheld devices in use around the world. The biggest issues are, as they have always been, the fact that commercial interests have triumphed over any kind of inclusive standard practice. Please understand I'm not passing judgment on the matter -- but I would like to highlight the relatively elite status of people with quad-core telephones.

I understand. But then, those low end phones are using something like Symbian.

I actually do handle the low end phones by rendering a basic html page on the server. Same codebase :-)

Re: The Decline of the Mobile Web

#209

Earlier quoted context omitted.

Sure, native apps have better performance on mobile. But the same thing is true on desktop, yet the web somehow stays popular on desktop. That suggests that the behavior of platform owners (Apple and Google) is the real reason for the popularity of apps on mobile, and performance is just a distraction.

Isn't the whole performance discussion based on synchronizing versus not synchronizing? There's no reason to synchronize on a Desktop as one can assume there's wifi available.

Since "desktop" as a platform includes laptops, which have pretty similar connectivity issues as mobile devices, that's really not true.
Post reply on HN