6 ms·

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 c

by habosa 13y ago

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, and 20% do it because the app store and home screen placement is better for branding and content discovery than just sticking up your website on a server somewhere. I think there's room for some sort of hybrid product but I'm not sure what it would look like. Maybe a mobile browser with super-aggressive caching (like not even a HEAD request for JS and CSS) and the ability to improve performance for the foreground page to the point where it's near-native. I'd use that for the mobile websites that I use less frequently, and continue to download the native apps for the things I use every day.

marknutter 13y ago
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 Facebook's mobile app but it makes heavy use of HTML5.
- elwell 13y ago
  Agreed. Check out this attempt with the Sencha Touch Framework from a couple years ago: http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/ http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l...
  - bsaul 13y ago
    This demo from sencha touch has always seemed dubious to me. I remember having coded extremely basic mobile web app with this framework and having had layency issues from almost day one. My guess is that what they are doing with their framework to get to this result is pretty far from a normal use.
    - marknutter 13y ago
      Agrees but it was written by the people who created the framework so I'm sure they're much more aware of how to keep it performant.
      - yblu 13y ago
        Then again, you don't need to be the creators of Cocoa Touch to build high-performance iOS apps.
        habosa 13y ago
        This. Anyone can make native fast for your average app, it takes a top-notch JS developer to make a similar web-app fast.
    - tonglil 13y ago
      I think if you develop from the ground up to be a mobile optimized web app you can achieve good performance. I recently built this as a side project using Bootstrap and it feels similar to an app (or faster) on iOS 'saved to my homepage': http://moneytrackr.ca/ http://moneytrackr.ca/ Then later I found out about the Ratchet framework, so I think the potential is there.
yesimahuman 13y ago
The article is discussing a very different thing. It's not web vs native on technology alone, but on which platform users are spending their time (in a browser or in an app). There is a growing number of apps being built with web technologies for the app stores, and that will only grow as the tools get better there (disclaimer, I am very much invested in that space).
veesahni 13y ago
> Maybe a mobile browser with super-aggressive caching (like not even a HEAD request for JS and CSS) appcache does something like this and is something that Firefox OS is pushing.
wodenokoto 13y ago
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 much harder to accomplish. But if the systems were actually optimized for open web, then content producers could build 1 web-app, that could have important logic and graphic stored offline in an app container, while still being just as functional via direct web access. This could work great for 90% of all the apps that are basically just glorified websites. This of course is the main mission of FirefoxOS.
- habosa 13y ago
  I don't think that's a fair critique, at least not about Google. They are pushing JS with V8 as far as anyone besides maybe Mozilla. They also have made cross-platform Chrome/Android/iOS toolchains and in general promoted the use of apps based on web technologies. It's pretty clear that Google wants web apps to be awesome also, it's just hard.
  - madads 13y ago
    Google showing results that go directly to an App is an important piece of this whole puzzle: https://developers.google.com/app-indexing/webmasters/ https://developers.google.com/app-indexing/webmasters/
    - rainedin 13y ago
      That's a good thing though right? Isn't that how a URI/link should work?
      - madads 13y ago
        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.
cousin_it 13y ago
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.
- lugg 13y ago
  Only in the last few years has SAAS applications really taken over native. Native has only been taken over so recently due to abundance in network latency and javascript engine improvements. We've also been pushing for web app models as developers as a collective quite hard. Not so much with the mobile side of things (all got dollared eyes maybe?) We will likely see a push back into the web side of things once mobile browsers become less painful to use and more powerful in what they can do. In other words, "decline of the mobile web", yea right. (don't forget half the article was about how we're spending more and more time in mobile web over desktop web.)
- techscruggs 13y ago
  Gmail is faster than any native email client I have ever used.
- habosa 13y ago
  As lugg said, it took a long time for web apps to rival native apps in functionality, and there are still a lot of places where they don't (large files, graphics, etc). In ~3-5 years the class of web apps that are lightning fast on desktop now will be fast on mobile.
  - blueskin_ 13y ago
    >and there are still a lot of places where they don't This would be better phrased as "and there are still only a few places where they do". Google Docs, for example, is great for basic collaborative editing (as long as you don't mind the NSA reading it), but has a UI that it a total pain (especially the world's worst keyboard shortcuts, e.g. having ctrl-enter and shift-enter reversed, and completely lacks advanced features.
malandrew 13y ago
FWIW, Dave Fetterman, the Facebook's former head of dev relations who helped create the Facebook developer platform (developer.facebook.com), later led mobile at Facebook and was the one who made the call to go HTML5 and then made the call to switch over to native is back working on high performance HTML5 at famo.us as VP of Engineering. There is still a future for for pure web apps that feel great. The framework will be released on Wednesday night. disclaimer: I work at famous.
vdm 13y ago
> a mobile browser with super-aggressive caching ServiceWorker (WIP) will do this. Its a WebWorker proxy in the browser's request/response pipeline for a particular origin, with a new cache API built on local storage. It can process page requests and responses with similar semantics to what a WSGI/Rack/MVC controller normally does on the server. It does away with bullshit 'offline mode' divining and encourages apps to work 'offline first'. https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md https://github.com/slightlyoff/ServiceWorker/blob/master/exp... The polyfill is actually a node.js headless implementation, which makes this look more and more like an isomorphic controller API. https://github.com/phuu/ServiceWorker-Polyfill https://github.com/phuu/ServiceWorker-Polyfill Jake Archibald's talk at Chrome Dev Summit, December. https://www.youtube.com/watch?v=Z7sRMg0f5Hk https://www.youtube.com/watch?v=Z7sRMg0f5Hk Chromium bug. https://code.google.com/p/chromium/issues/detail?id=285976 https://code.google.com/p/chromium/issues/detail?id=285976
blueskin_ 13y ago
Facebook's mobile website doesn't want permissions to access camera, mic, location, and SMS. That's why I use that and not their stupid app, especially since it lets me switch between other sites as I like as well.
acdha 13y ago
> 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. Except that anyone who actually uses the Facebook apps knows that the performance is horrible in the native apps– jerky scrolling, lots of on-demand loading requiring you to wait for multiple RTTs on every click, etc. I would be hesitant use Facebook as an argument for anything other than the need to place UI performance on equal priority with marketing.

by habosa 13y ago

marknutter 13y ago

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 Facebook's mobile app but it makes heavy use of HTML5.

elwell 13y ago
Agreed. Check out this attempt with the Sencha Touch Framework from a couple years ago: http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/ http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l...
- bsaul 13y ago
  This demo from sencha touch has always seemed dubious to me. I remember having coded extremely basic mobile web app with this framework and having had layency issues from almost day one. My guess is that what they are doing with their framework to get to this result is pretty far from a normal use.
  - marknutter 13y ago
    Agrees but it was written by the people who created the framework so I'm sure they're much more aware of how to keep it performant.
    - yblu 13y ago
      Then again, you don't need to be the creators of Cocoa Touch to build high-performance iOS apps.
      - habosa 13y ago
        This. Anyone can make native fast for your average app, it takes a top-notch JS developer to make a similar web-app fast.
  - tonglil 13y ago
    I think if you develop from the ground up to be a mobile optimized web app you can achieve good performance. I recently built this as a side project using Bootstrap and it feels similar to an app (or faster) on iOS 'saved to my homepage': http://moneytrackr.ca/ http://moneytrackr.ca/ Then later I found out about the Ratchet framework, so I think the potential is there.

yesimahuman 13y ago

The article is discussing a very different thing. It's not web vs native on technology alone, but on which platform users are spending their time (in a browser or in an app). There is a growing number of apps being built with web technologies for the app stores, and that will only grow as the tools get better there (disclaimer, I am very much invested in that space).

veesahni 13y ago

> Maybe a mobile browser with super-aggressive caching (like not even a HEAD request for JS and CSS) appcache does something like this and is something that Firefox OS is pushing.

wodenokoto 13y ago

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 much harder to accomplish. But if the systems were actually optimized for open web, then content producers could build 1 web-app, that could have important logic and graphic stored offline in an app container, while still being just as functional via direct web access. This could work great for 90% of all the apps that are basically just glorified websites. This of course is the main mission of FirefoxOS.

habosa 13y ago
I don't think that's a fair critique, at least not about Google. They are pushing JS with V8 as far as anyone besides maybe Mozilla. They also have made cross-platform Chrome/Android/iOS toolchains and in general promoted the use of apps based on web technologies. It's pretty clear that Google wants web apps to be awesome also, it's just hard.
- madads 13y ago
  Google showing results that go directly to an App is an important piece of this whole puzzle: https://developers.google.com/app-indexing/webmasters/ https://developers.google.com/app-indexing/webmasters/
  - rainedin 13y ago
    That's a good thing though right? Isn't that how a URI/link should work?
    - madads 13y ago
      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.

cousin_it 13y ago

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.

lugg 13y ago
Only in the last few years has SAAS applications really taken over native. Native has only been taken over so recently due to abundance in network latency and javascript engine improvements. We've also been pushing for web app models as developers as a collective quite hard. Not so much with the mobile side of things (all got dollared eyes maybe?) We will likely see a push back into the web side of things once mobile browsers become less painful to use and more powerful in what they can do. In other words, "decline of the mobile web", yea right. (don't forget half the article was about how we're spending more and more time in mobile web over desktop web.)
techscruggs 13y ago
Gmail is faster than any native email client I have ever used.
habosa 13y ago
As lugg said, it took a long time for web apps to rival native apps in functionality, and there are still a lot of places where they don't (large files, graphics, etc). In ~3-5 years the class of web apps that are lightning fast on desktop now will be fast on mobile.
- blueskin_ 13y ago
  >and there are still a lot of places where they don't This would be better phrased as "and there are still only a few places where they do". Google Docs, for example, is great for basic collaborative editing (as long as you don't mind the NSA reading it), but has a UI that it a total pain (especially the world's worst keyboard shortcuts, e.g. having ctrl-enter and shift-enter reversed, and completely lacks advanced features.

malandrew 13y ago

FWIW, Dave Fetterman, the Facebook's former head of dev relations who helped create the Facebook developer platform (developer.facebook.com), later led mobile at Facebook and was the one who made the call to go HTML5 and then made the call to switch over to native is back working on high performance HTML5 at famo.us as VP of Engineering. There is still a future for for pure web apps that feel great. The framework will be released on Wednesday night. disclaimer: I work at famous.

vdm 13y ago

> a mobile browser with super-aggressive caching ServiceWorker (WIP) will do this. Its a WebWorker proxy in the browser's request/response pipeline for a particular origin, with a new cache API built on local storage. It can process page requests and responses with similar semantics to what a WSGI/Rack/MVC controller normally does on the server. It does away with bullshit 'offline mode' divining and encourages apps to work 'offline first'. https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md https://github.com/slightlyoff/ServiceWorker/blob/master/exp... The polyfill is actually a node.js headless implementation, which makes this look more and more like an isomorphic controller API. https://github.com/phuu/ServiceWorker-Polyfill https://github.com/phuu/ServiceWorker-Polyfill Jake Archibald's talk at Chrome Dev Summit, December. https://www.youtube.com/watch?v=Z7sRMg0f5Hk https://www.youtube.com/watch?v=Z7sRMg0f5Hk Chromium bug. https://code.google.com/p/chromium/issues/detail?id=285976 https://code.google.com/p/chromium/issues/detail?id=285976

blueskin_ 13y ago

Facebook's mobile website doesn't want permissions to access camera, mic, location, and SMS. That's why I use that and not their stupid app, especially since it lets me switch between other sites as I like as well.

acdha 13y ago

> 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. Except that anyone who actually uses the Facebook apps knows that the performance is horrible in the native apps– jerky scrolling, lots of on-demand loading requiring you to wait for multiple RTTs on every click, etc. I would be hesitant use Facebook as an argument for anything other than the need to place UI performance on equal priority with marketing.