Help stop the spread of NIBS (Native is Better Syndrome)

John Gruber, well known and highly successful opinionista, is perhaps the highest profile carrier of the “native” apps are intrinsically better than web apps meme (let’s call it Native is better Syndrome, or NIBS). I think it’s time for some vaccination.

Let’s take a look at the most recent outbreak of NIBS.

In response to Jim Balsillie’s (co-CEO of Research In Motion) observation

Why do you need a YouTube app if you play YouTube? Why do you need an app to follow the Tour de France if you can just follow the Tour de France?”

Gruber’s essentially states that this is flat out wrong. He asserts (among many other spurious things)

Many native iOS apps are web clients — they’re just written using CocoaTouch instead of HTML/CSS/JavaScript. The results, in terms of user experience, speak for themselves

The logic here is simple. If you write an app with Objective-C/CocoaTouch (does the same logic hold for JavaME (Android), C++ (various other platforms) and so on?) the user experience created is by that very fact better.

Now, in order for this assertion to be true, there must be not a single web app better than a single native iPhone app. This is trivially false. For any crap web app, I can show you a crap native app. Many of the most successful and lauded native apps, particularly games, are built with development environments that don’t use CocaTouch. So, the difference is logically not the development environment.

So, can we all please STFU about how native apps are intrinsically better than web apps?

At present, on various platforms, it’s true that the full capabilities of the platform are not exposed to web technology based applications, particularly via the browser. However, with solutions like phoneGap and Appcelerator, for iOS and Android, as well as “native” web platforms such as webOS, and RIM’s WebWorks means this is less of an issue than it was when iOS apps debuted.

But, I will argue, in the contrary, there are things intrinsic to web apps that “native” apps can’t, and will likely never be able to do.

1. Linking

The heart and soul of the web is linking. Right now, very few people see the power of app to app linking. But try these two links

Link to app with default settings
Link to app sharing settings

Yes it is a reasonably simple example, but it demonstrates how web apps can share state trivially via URLs, without the need for server side intervention, in (effectively) any browser.

Native apps don’t do linking. They push stuff to and from a server. Sorry Mr Gruber they aren’t web clients, they’re simply client server apps running over http.

2. Reach

Want to write a “native” :

  • iOS app? – use Objective-C
  • Android App? – use Java
  • webOS app? – use HTML/CSS/JS
  • BlackBerry app – use Java

And of course, underlying each of these platforms is its own API – so even if your app does identical things on each platform, you need to learn and write to different APIs.

The implication for developers is they need to maintain different code bases for each platform, in perpetuity. And, perhaps with the exception of the very largest development shops, you are going to have to pick winners, because it is not feasible to target more than a couple of platforms.

This is never going away.

But, apps built with web technologies can already access many of the underlying device APIs, either directly as in the case of Geolocation, or via phoneGap, or similar harnesses.

Additionally, the W3C is working on standardizing Device APIs, through the Device APIs working Group.

So, already, and increasingly into the future, you’ll be able to develop with a single code base, and deploy to (ultimately) any platform. The web. So why wait?

3. Control

As a developer, here’s a simple question – who do you want to control your business or the distribution of your application? You, or a third party (any third party)? With “native” apps, you must go through a third party, who owns the platform, and also potentially competes with you. You cede them arbitrary authority to shut down your business, or the reach of your application, with no notice, and no right of recourse, for almost any reason.

This is the opposite of the web. The core principles of the web include

In a way, native apps are parasitic – consuming the resources of the web/internet, resources like HTTP, TCP/IP that would never be there to be built on, taking advantage of the network effect of hundreds of millions of users, who would not be there were it not for the web, all the while subverting the guiding principles of the web.

In brief

The argument that apps built with Java on Android, or Objective-C on iOS (and so on) are intrinsically better (particularly because their UX is better) is simply BS.

While applications running in browsers do continue to have less access to underlying device APIs than “native apps” there are technologies for minimizing this, and in time (and not a great deal of it) this will be less and less of an issue. It’s frankly not a technical issue, it’s IMO a control issue by platform developers. Is it any wonder newer platforms make web technologies first class citizens?

Despite this, web based apps do have intrinsic benfits – they are intrinsically more connected, and connectable, and are intrinsically freer. You may or may not care about such things, but this is simply not in dispute.

And because I’m an opionista too, here’s my big bet. In as little as 5 years time, pretty much every screen based experience you see will be driven by web technologies – TV UIs, mobile devices, in flight entertainment systems, car dashboards, ATMs, clock radios, vending machines – it’s got a screen, the UI will be web technology based. Objective-C, Java, C++, all other development paltforms and languages will become niche at best (and with JavaScript on the server exploding, we’re likely to see JavaScript take the place of many traditional server side languages as well).

So, you want to bet big? Invest in web technologies – learn them, develop with them, build tools for them, immerse yourself in them. We aint seen nothing yet.

No responses to “Help stop the spread of NIBS (Native is Better Syndrome)”:

  1. I couldn’t agree more John!

    I think the W3C’s DAPI stuff is a good start…but I think it needs to be much broader with all sensors (including across devices) being surfaced up to the javascript API level.

    See my Patterns of Interest proposal from ISWAR

    I think the blend of sensors and the web will totally reshape our world…and this power should be available to users too…not just us developers.

    • By: misteraidan
    • October 21st, 2010

    Well said, good sir.

    • By: Lucien
    • October 21st, 2010

    Good work. I thought I was the only one who thought apps that just reproduce what the web can do anyway were a bit strange.

  2. For me I would love if I could build a web app that has full access to the device, PhoneGap is a good example of the possible but not fully there yet. And truth be told that covers mosts apps. The look of apps is down to the designer. I think people building web-apps live still in band-width land and forget to use image rich designs as they forget the web-app is pre-downloaded to the device (referring to PhoneGap type apps).

    That said I had a client yesterday who wants their sales people to take iPads out clients to show an interactive catalog. I am like great, we will build you a web app. His response was “I want native”. I tried to explain to him that a webapp will do everything he wants, look and feel native with the added benefit that it can be refreshed in real-time (no app store submission) plus the fact there is only 10 people who will download it. Then I had to get technical and explain that you can use MANIFEST files which will download it to his device for offline viewing.

    I think Apple has trained people so well that they think ‘if it is not native then it won’t work’. Clearly they haven’t read iTunes webapp is better then their native app.

    I just wish it was a lot easier to build native HTML 5 apps.

    • By: Nick
    • October 21st, 2010

    Although I can see your point, and it is a very strong one, you are missing some very valid arguments for the side of native apps.

    1. Games and graphically intensive apps: JavaScript can’t do them with any credibility. Native apps allow native access to hardware acceleration such as OpenGL ES and while I understand that HTML5’s canvas element will allow some hardware accelerated vector processing it still means that the code has to run through JavaScript and the browser to get there.

    2. Speed. Yes loading data from the internet in a native app is still going to take some time but when a (albeit not all) web app needs to load an entire page from the server every time you want to move to see the next piece of data it’s hardly what you’d call ‘instantaneous’. A native app may already have the graphics prepared and simply need to load a simple XML list to populate the a table or two. Don’t get me wrong on this, a well written web app like Google’s mobile reader can be very quick but that is by far one of the better examples.

    3. Offline data. Without an internet connection you simply can’t see a web app. Having not used a blackberry browser I can’t say for certain but as soon as an iPhone runs out of memory it clears your pages from mobile Safari and without an internet connection you can’t get them back. A native app can store as much data as it likes, and cache it, and retrieve it when ever you need it. Imagine a note pad app which you want to pop open and jot down some ideas but you can’t even open it, let alone save the data to a server, if you don’t have an internet connection at that very moment.

    Sorry to be a downer and I have to say I’m a massive fan of the idea of web apps, I use google reader and twitter every day while commuting but there are some areas where they cannot touch a native app and probably never will.

    • By: John
    • October 21st, 2010

    Hi Nick,

    thanks for the thoughts.

    Firstly, I was particularly addressing the assertion that native UX is inherently better. However, let’s take a look at the excellent points you make.

    1. Games
    A great many iPhone native games are actually developer with Unity3D – and the game itself is developed using a scripting language, like Lua or JavaScript.
    While at present, it’s true that JS performance is such that on devices like iPhone it’s not feasible to develop FPS style games for these devices, I’m not sure that a game like Angry Birds couldn’t be done with HTML5 Canvas.

    Take a look at Sketchpad as a simple example of a graphics intensive app. There are many others.

    2. Performance is always a bit of a canard when it comes to web apps. These can of course be cached locally in most browsers and on most devices nowadays. And there’s this funny little thing called ajax to help us send and receive only small pieces of information to and from server and browser ;-)

    3. Offline data is done and dusted.
    Manifest files for caching, client side storage and online/offline events are supported in almost all modern browsers and on all modern devices.

    So, in pretty much al these cases, not only will it not ever happen, but it already has.

  3. Hello,

    I like your post. I truly believe in web apps and rely a part of my business on it. Your post is essentialy about technical issues (GPL, sensors, languages competition, …).

    I think the main weakness of webapps today is they do not have a dedidcated “WebApp Store”. One more time, the main issue is about ease of use, not technic. It is easier to find something on the App Store than on Google. This is the main point.

    Put WebApps on the App Store or create a good WebApp Store (Google is working on) then web apps will be popular.

    Ease of use is mighter than technical possibility. Always.

  4. I don’t think that native is necessarily “better”, but I do think that there are certain types of apps or functionality that are best performed by native code. If you’re writing a camera-based app like Instagram or Vignette (for iOS and Android respectively), it’s just masochistic to try to do it in HTML and JavaScript and then use PhoneGap or whatever to get access to the camera, and then apply filters to the resulting images.

    But the most common and popular apps are indeed just consuming web services, and in those cases I totally agree with you.

    I do have a few nitpicks with your post, though:

    1. At the top of the post, you refer to JavaME in the context of Android development. Android doesn’t run JavaME, it runs a Java VM called Dalvik which, other than using the Java language, has pretty much nothing in common with JavaME.

    and 2. Your point about control (“With “native” apps, you must go through a third party, who owns the plat­form, and also poten­tially com­petes with you. You cede them arbi­trary author­ity to shut down your busi­ness, or the reach of your appli­ca­tion, with no notice, and no right of recourse, for almost any reason.”)

    This is true with respect to iOS apps, but not to Android apps. An Android app is just an APK file, you can download it and throw it on your phone, the market is just there for convenience and as a payment gateway. I could develop an Android app and sell it on my own site, I’d just need to provide slightly more complicated installation instructions to my users.

    • By: Nick
    • October 21st, 2010

    Hi John,

    Thanks for your response. You’re certainly right about the use of ajax for refreshing sections of web pages and many web apps make excellent use of this, though I still stand by my assertion that the inability to access anything to do with a web app in ‘offline mode’ is a real deal breaker for some people. Especially iOS where the OS will decide that it needs more ram and release any pages open in the background without consulting them first and you will need to reload them from scratch the next time you visit. There is no winner here, only different ways of doing things – thin client or fat client.

    Games on the other hand still require native access for anything beyond Angry Birds – I’m thinking more like Need For Speed. The Unity3D engine is an excellent example since any app compiled using it will actually natively access the 3D capabilities of the OS for which it has been compiled. All Unity3D offers is a facade API to access those hardware graphics features – along with all the other scripting and asset management tools that make it so useful. Compiling with Unity3D on iPhone, Windows, OSX etc. will forward those API calls to OpenGL ES, OpenGL and DirectX respectively, it just gets hidden from the developer. The Unity3D web player will also allow access to the native hardware acceleration through the browser’s plugin system much the way that Flash 10 does and does not play back in just any browser without this plugin installed.



    • By: Brendan Kay
    • October 22nd, 2010

    Hi John,

    I am a big fan of your work and enjoy your posts and talks however I think this post has started by misinterpreting Gruber’s position in order to ridicule it.

    I do not believe that Gruber’s has ever said (or even implied) that native apps are better “by that very fact” that they are native. He has said that there are many cases of native apps that are better than their “equivalent” web apps and that many users select native apps even when web versions exist.

    It is debatable how long this may remain true but I think it is certainly true rig now and as much as I would prefer to be writing single web apps it is rare to find business opportunities where that works right now. HTML5 holds great promise but it is yet to deliver (or at least the browser vendors are yet tocomsistently deliver).

    I also note that two of your arguments (reach and control) are primarily aimed at things that make life easier for the developer (as opposed to the user). As a developer I love things that make my life easier but I do not believe they increase the products success. The thing that really determines a products success is how it works for individual users which is why there is still so many native apps making money. Sure there are some great web apps and games but in most cases the user will pick a native client if it can provide a better interface.

    The best example of this is twitter. Every user could run the twitter web site but a huge number choose a native client for an experience they prefer. Until the web apps can produce the same level of UX they will be second fiddle to native apps. I hope this doesn’t last forever but I don’t think web technologies are there yet for many uses. You can do what you like to make it easier for the developer but until that translates to things working better for the end user it will be of limited I pact.

    I don’t know the future of web versus native apps but I don’t think Gruber’s was saying what you claimed and I think that he is currently right (about this point at least).


  5. You overall point is that native app are not inherently or intrinsically better than web apps. As argument for that point, you provide reasons why web apps are inherently better (connectability, reach, control) than native apps. I wouldn’t argue with any of these points. There are aspects of web apps that are intrinsically “better” than native apps.

    However, there are aspects of native apps which are intrinsically better than web apps, too. Among them:

    1. Performance: There’s just no getting around it. Compiled code (ObjC/Java) is faster than JavaScript. Period. An argument can not be made to the contrary.

    2. UI consistency: While you can attempt to replicate a native UI in HTML/CSS/JS, it’s just not possible to make it absolutely consistent with native UI elements. No place is this more clear than scrolling. Scrolling in JavaScript just doesn’t feel the same as scrolling in native apps (at least on iOS…I’m not sure about Android/BB).

    3. Discoverability and ease of sale: You say that “control” to sell your app however you want makes web apps “better.” But that depends on your definition of “better.”. For many developers, trading 30% of the revenues for the kind of discoverability they get in the App Store is “better” than having to create a whole online store to sell their apps and then promote it to the point where anyone actually finds their stuff.

    Look, I love web apps. I’ve built several mobile web apps, and I’ve also built PhoneGap apps. I think web apps make a great deal of sense for a great many products. But the fact that is both web and native have their advantages and disadvantages, and to suggest that web apps have all these inherent qualities that makes them “better” without pointing out that native apps do, too, is either delusional or disingenuous.

    For a given project, you need to weigh the inherent advantages of each platform and decide what makes sense. My feeling is that a lot of native apps would have been better to be built as web apps. But there are cases when native makes sense, either from a technical or business perspective. Let’s not pretend otherwise.

    • By: Chris Drackett
    • October 24th, 2010

    Jeff~ I have to disagree.

    1. If you use 3d transforms in mobile safari everything is hardware accelerated. While you won’t be able to do page curls like in iBooks, why would you ever want to? Slides, flips, and other animations are just as fast as their native compiled counterparts. Sure this isn’t available on android or webOS, but you could just not have animation on those platforms (and at least you would have an app that is cross platform.)

    2. This is true if you are trying to match apple or android’s UI, but even maybe native apps don’t. I think as long as an app is consistent with itself and well designed, this isn’t an issue. There are also javascript scrolling implementations that take advantage of the hardware acceleration mentioned above that are nearly impossible to tell apart from native scrolling (check out iscroll or touchscroll)

    3. This is probably the one piece that isn’t possible, but while being featured in the app store is great only a small percentage of apps get this boost. Web apps are just as discoverable online and through social means as native ones (and many could let you try them out on your computer or phone without installing anything at all.)

  6. Chris:

    1. That’s great…for 3D transforms. But ALL compiled code runs faster than JavaScript. So unless your app is made up of nothing but 3D effects, a native app is going to be faster. Enough faster to practically matter? That’s up to you to decide.

    2. I agree that matching a native UI is not always what is desired, but in many cases, it is. And you just proved my point about scrolling when you said “nearly impossible to tell apart.” If it’s nearly impossible, then it’s possible. So they’re not the same. Does this practically matter? That’s up to you to decide.

    3. Even if you never get featured in the App Store, you still don’t have to go to the effort and cost of building your own store. Submit, sell, done. Is this worth giving 30% of your revenue to Apple? That’s up to you to decide.

    (I hope you see the theme, here.)

  7. Jeff,

    While compiled languages have traditionally been faster than interpreted code, Javascript has been catching up. Javascript is now within an order of magnitude of Java and between Spidermonkey, V8, and Squirrelfish there’s lots of competition for performance. And as devices get faster it matters less to some degree.

    I think your point about native UI is actually the biggest hindrance. In my experiences with jqtouch and iScroll it was a nightmare trying to emulate native scrolling, and it never looked quite right. Also, any Java app ever built for Mac is a great example of how almost-but-not-quite native can be really distracting.

  8. Good article, John. In the end, it will be the market forces that’ll take care of NIBS. For most use cases, high-quality native apps (like the ones Gruber likes) are just not economically viable to create & maintain. Soon, the quality & performance of webapps will be on par with native – for a fraction of the cost and superior ROI.

  9. Very good article, John. I completely agree. What we are seeing now is the mobile ecosystem adapting and web technologies will be the standard. Very much like what we have seen with desktop apps moving to the web, but at a faster pace in mobile

    • By: Jose
    • October 24th, 2010

    What happened with the “use the best tool for your application”. Oh, you are a web developer so you want ALL the code to be web based. In other words you have personal interest in that succeeding, you want this happening. You are confusing your desires with reality.

    What you said in the article is right, because you hand picked the advantages web coding has, but you omit the obvious drawbacks as if they don’t exist at all.

    The web apps that success are very good at managing documents(pages), information like facebook or Apple Appstore. They are the best tool for this application.

    BUT Don’t fool yourself, You can’t code an Autodesk inventor,AutoCAD, Photoshop a sound synthetiser,sound recognition, an OS kernel, a wavelet CODEC or google earth in web(you just can make frontends like google does), sorry about that. If you try, you get a BS product, with can’t stand against competition.

  10. As long as the big mobile players like Apple and Google continue to pour resources into keeping their rendering and js engines competitive, I think native and web apps will be able to coexist just fine.

    As Jeff seemed to hinting at, and Jose mentioned briefly, the strengths and weaknesses of each camp need to be evaluated on a project to project basis. This is such a polarizing topic for some people, but the dust isn’t even starting to settle for the best approaches to mobile development. As browsers gain equal footing for features like hardware access, native apps will be evolving to connect and share resources as ubiquitously as the web.

    Right now feels like awkward mobile puberty. Be more concerned with users seeing your app’s zits than who has the more virile development approach.

    • By: Ankush
    • October 24th, 2010


    I agree with you. Gruber is drunk on Apple flavored Kool-Aid. His default position is to side with Apple. Who knows why. To say that Apple is “one of the great web companies” in front of a crowd at MacWorld because iOS apps make extensive use of HTTP is disingenuous at best. By his own logic Microsoft must be the greatest web company of all time. A great web company embraces the entire web stack, not just the part that benefits its own interests.

    The Web has been successful precisely because of the reasons you outlined above. Apple is moving in the opposite direction.

  11. […] Help stop the spread of NIBS (Native is Better Syndrome) | Web Directions (tags: web development apps mobile iphone android webapps native) […]

    • By: John
    • October 25th, 2010


    Thanks for the detailed thoughts

    My overall point was intended to be that Gruber’s argument that native apps have a better UX by virtue of being native is demonstrable BS.
    I’d also argue, holding my nose, that if you must develop a native app (and their are currently reasons why you might have to do so) you can (and in almost every circumstance should) use web technologies and phoneGap, Appcelerator, or some such, to do so.

    You also argue 3 very commonly held assertions about the inherent advantage of native apps – all of which I argue are assertions, with some plausibility, but little basis in reality.

    1. performance. As a software developer of commercial software going back nearly 20 years, I have in every circumstance chosen a less performant language/environment of the possible tools. Typically, only rare cases require absolute performance. Time to market, ease of development/maintenance, these are also incredibly important factors in choosing tools, languages and frameworks – I’d argue outweighing performance in almost every circumstance.

    2. UI consistency. Well, Apple don’t even try for UI consistency on the Mac, let alone on iPhone, and people don’t praise the Twitter iPad app for its consistency.
    So, to my mind, UI consistency is really low down on the list of things anyone much cares for anymore.

    3. Appstore benefits for developers
    I’m as set against AppStores now as I was 2 and a half years ago when I wrote this
    I’ll have to write another “provocative” ;-) piece on Appstores soon. But I’d have to see some evidence that on the whole AppStores are beneficial to developers (as opposed to just the winners). We’ll see for sure when the Mac Appstore arrives – will the massive plummet in prices be made up for by increased sales (by say an order of magnitude?).
    But I think the day of selling software is fast ending. Software is just a piece of an overall service you provide your customers, not the service in itself, at least that’s how I see the trend.

    I’m not alone (or without actual evidence) for this position BTW.

    The money quote:

    The development of the typical app cost $35,000 and the median paid app earns $682 dollars per year after Apple took its cut. You see where this is going


    I really do think this stuff through you know ;-)

    • By: John
    • October 25th, 2010


    BUT Don’t fool your self, You can’t code an Autodesk inventor,AutoCAD, Photoshop a sound synthetiser,sound recog ni tion, an OS ker nel, a wavelet CODEC or google earth in web(you just can make fron tends like google does), sorry about that. If you try, you get a BS prod uct, with can’t stand against competition.

    Of course my position is an extreme one – so there will be edge cases, but let’s take a look at your suggestions

    AutoCAD etc – if these don’t move toward hosted services with web (and initially at least) native front end I’ll be very surprised. Just as with computationally intensive 3D, animation etc apps, the actual computation (and storage of data) will surely move into the “cloud” – a huge opportunity for AutoCAD (or a competitor).
    PhotoShop – ditto – you’ve seen things like Darkroom and Sketchpad? Yes, they aren’t yet current day Photoshop/illustrator etc – but they are strong proof of concept.
    Firefox 4 will ship with a prototype sound sampling interface – it’s clear where standard web technologies are headed.
    Just as before Google Maps, no one really thought that level of mapping sophistication could be done in the browser, I predict that in a couple of years (at the outside) Canvas based in browser 3D mapping a la Earth directly in the browser will be a commonplace.

  12. This is how I like to think of it…

    Native apps are like vendor-prefixed CSS properties: they live in an unencumbered land where developers can absolutely push the boundaries and have full access to the computing device it runs on.

    We need a world with both native app and web app development, just like we need a world with vendor-prefixed CSS properties and standards-agreed properties, because technology progresses much more quickly when the people (the web) can define what’s possible, not browser vendors or standards bodies.

    In terms of shipping end-user products, I think performance is the biggest killer for web apps.

    HTML+JS is high-level and cross-platform, but the price is paid by every single user if you can’t get the browser to behave as you need. Native app developers can assume all responsibility for providing a great experience, paying the price on behalf of every user. If you’ve ever seen a iPhone developer work on the fine details of how a native app interface transitions from portrait to landscape, or fine-tuning a 10000 row table with lazy image loading and smooth scrolling, then you’d understand why they’re able to create a better user experience.

    UX aside, I still think that it’s inevitable that many more devices will have a HTML5-based web browser and touch screen, and that this will mean that most people will be build cross-platform web-based apps before building a native app (which is a good thing!). Just don’t expect or argue that they’ll have exactly the same quality of user experience.

  13. and none of that is to say that most people should be developing native applications, most shouldn’t. I just don’t see how you can argue they’re equivalent in terms of UX.

  14. A browser is a fairly complex app in itself. Purely from a user’s point of view, does it make a difference to performance when your device has to first launch a browser, then load a web app before the user can do anything, as opposed to launching a native app that is ready to go straight away?

    My personal experience with an earlier model Android phone is yes, it does make a noticeable difference. It’s not a show-stopper… I use & love the mobile Google Reader web app every day. However if there was a native app that had the same functionality but took away those few seconds of delay where the browser app has to launch first then load another app inside it, I’d use it.

  15. John-

    Your counter-points make sense, and I pointed out myself that whether or not the advantages I noted for native apps actually matter in a practical sense is questionable, and depends very much on the project.

    I still think, though, that the App Store is a huge practical advantage for many developers. Many small developers don’t have the skill, time, resources, or motivation to create their own platform for selling apps and are happy to give 30% of their revenues to Apple in exchange for them handling it. I agree that, less-and-less, selling software is a “thing,” but it still exists today, and will for some time.

    I still maintain that there are times for native apps, times for web apps, and times for PhoneGap (or similar). Like I said earlier, I think web apps and PhoneGap apps are the right choice very, very often. But I believe these things, like all technology decisions, should be evaluated on a case-by-case basis.

    In this industry, tying yourself to one technology, no matter how open it may be, is a death sentence.

  16. […] Help stop the spread of NIBS (Native is Better Syndrome) We like the acronym and approve of the sentiment. Mobile web has already surpassed native apps in some regards and shows no signs of stopping as more and more websites optimize for mobile. […]

  17. […] month, John of Web Directions gave a pretty good summary of the benefits of using a mobile web application instead of a mobile app.   I thought his initial debunking of the myth a little slow but his points for the benefits of […]

  18. A browser is a fairly complex app in itself. Purely from a user’s point of view, does it make a difference to performance when your device has to first launch a browser, then load a web app before the user can do anything, as opposed to launching a native app that is ready to go straight away?My personal experience with an earlier model Android phone is yes, it does make a noticeable difference. It’s not a show-stopper… I use & love the mobile Google Reader web app every day. However if there was a native app that had the same functionality but took away those few seconds of delay where the browser app has to launch first then load another app inside it, I’d use it.

    • By: Arlen
    • November 3rd, 2011

    First, I’d point out your logic is a bit off. To conclusively prove Native is not an advantage for UX there must exist at least one web app which is better than ALL native apps. A badly executed UX design will suck, no matter whether native or web. An analogy might be, round wheels are a speed advantage over elliptical ones. But it’s still possible for a car which is otherwise excellent to go faster than a poor car with round wheels.

    The most accurate test would be to have the same UX implemented each way and evaluated, of course.

    And, btw, there exists a good argument for java not being a compiled language, but rather a hybrid. It “compiles” to byte codes which them are interpreted by the jvm at the time of execution. So going almost as fast as java still puts JavaScript at a speed disadvantage to a compiled language.

    As for speed data, it generally comes under the heading of proving gravity works, but here’s a place you can start, benchmarking node.js vs an objective c http server:

  19. […] is really just a far better argued, more evidenced-​​based version of this comment on a blog post I wrote about performance 3 years […]