Earlier quoted context omitted.
Yes, but the growth aspect will move away from new native apps to new web apps as soon as 'UI side of the web' stops trailing too far. I agree with you that the competition will push either sides forward, but by how much at each end? - that is the question.
> as soon as 'UI side of the web' stops trailing too far Except not likely it ever will.
The Decline of the Mobile Web
111–120 of 209 posts
Re: The Decline of the Mobile Web
#112I 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…
Facebook comes up a lot in these discussions and it's important to provide some context. Facebook's HTML5-first strategy pre-dated the launch of the original iPhone. In the first native mobile app they were simply rendering the mobile facebook site in a UIWebView. There are so many better ways to do HTML5 and HTML5/native hybrid apps these days. Check out the Basecamp app, for instance. It's every bit as good as Face…
Re: The Decline of the Mobile Web
#113Earlier 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…
Chrome is moving towards out-of-process iframes, which should help alleviate many performance issues (ads janking your page) and give you new capability (basically web workers with a full DOM). http://www.chromium.org/developers/design-documents/oop-ifra...
Re: The Decline of the Mobile Web
#114Earlier quoted context omitted.
The "HTML5 will catch up" argument is a common fallacy. It assumes native apps are standing still, when in fact they are moving rapidly forward. If anything, the gap continues to grow. The web isn't even in their cross-hairs, there's just so much effort for each native platform to keep surging ahead of the others. If you think Android and iOS are "done", consider where they are headed and you can see they are barely…
> It assumes native apps are standing still, when in fact they are moving rapidly forward. If anything, the gap continues to grow. I'm sorry, but there are only so many ways you can display a CRUD application. I don't see the next versions of Twitter and Instagram pushing the hardware much more than they are today..
Twitter and Instagram as photo-heavy apps could eventually support 3D models of the world, drone photography, wearables etc (Twitter already has a Glass app).
Same for their notifications - all sorts are possible on watches, speech, car dashboards.
And that's just assuming they stand still functionally.
As for CRUD apps, there's loads of innovation happening. Look at Amazon's new Dash device as one of many examples that change the interaction style from clicking on a web page to speech + real-world scanning. I'm guessing it's not powered by HTML5.
Re: The Decline of the Mobile Web
#115Am I in the minority that I don't want an app for every. bloody. webpage. I visit?
I personally love apps that are stupid simple and stupid straightforward. You know, like melon ballers: they do precisely one thing, but they do it so incredibly well, you don't understand how you got along without one before.
Melon baller apps.
Re: The Decline of the Mobile Web
#116I 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…
Re: The Decline of the Mobile Web
#117Am I in the minority that I don't want an app for every. bloody. webpage. I visit?
Why download, upgrade, share memory space on my device for apps when I'm pretty sure I can't really trust the creators with my data anyway?
Re: The Decline of the Mobile Web
#118Earlier quoted context omitted.
Apps are usually better in every way than web sites (I'd love a good HN app for my iPhone). If I visit a site frequently, I'd want an app for it. But for infrequently used sites, the hassle isn't worth the benefit.
http://hn.premii.com/ great HN mobile webapp for phone, made with html5
Re: The Decline of the Mobile Web
#119Am I in the minority that I don't want an app for every. bloody. webpage. I visit?
Re: The Decline of the Mobile Web
#120In my opinion mobile web is yet to arrive, we have just gotten HTML5 standards finalized only about an year ago. While native has had roughly seven years lead when it comes to providing quality online experience, web apps can beat native easily. And no it's not that web apps or web development or talent for mobile web development is limited or is the bottleneck. The bottleneck is usually the vendors and support of st…