Forgot your password?

The Web, Not Apps, Is the Future


Over the years since Apple started their app craze I always felt that most of these apps were poor excuses for Low-Fi website frontends. I am not talking about games but rather actual apps. This has not stopped more and more apps from being released on multiple platforms fragmenting things further and further. HTML5 holds some real promise in bringing the full power of the web with app-like benefits. The reason is pretty simple and Dave Winer sums it up perfectly in his rant on “why apps are not the future” by simply stating the obvious advantage… “Linking”

Visualize each of the apps they want you to use on your iPad or iPhone as a silo. A tall vertical building. It might feel very large on the inside, but nothing goes in or out that isn’t well-controlled by the people who created the app. That sucks!

The great thing about the web is linking. I don’t care how ugly it looks and how pretty your app is, if I can’t link in and out of your world, it’s not even close to a replacement for the web. It would be as silly as saying that you don’t need oceans because you have a bathtub. How nice your bathtub is. Try building a continent around it if you want to get my point.

It seems like RIM is definitely agreeing with Winer on this one. They are putting a huge emphasis on a solid web browser and HTML5 support as their future app platform for BB10. Even on the PlayBook and other devices I find myself preferring solid websites over apps that try to replicate a subset of a websites features. I think Andy Gryc, QNX’s HTML5 guy, does a great job explaining why that makes a difference even to car manufacturers in this video:

I would take Winer’s argument one step further. The future cannot sustain the current model where every developer or service needs to create apps for every platform and form factor out there. The number of devices and fragmentation grows by the day making the “Apps” model untenable and linking them impossible. Developers are already feeling the strain of trying to launch features on multiple devices at the same time. Think of apps like Foursquare that need to first add a feature and then roll it out to all the different device variants out there with a service that would be better served as a HTML5 website or a bundled webapp.

What do you think?

14 total comments on this postSubmit your comment!
  1. Ronen, I can’t agree with you more. I have been thinking to myself lately that HTML5 will eliminate the overall need for apps.

  2. This is a very one-sided argument, or rather, marketing promo. Don’t believe all the hype.

    In reality a developer will select the technology that is most suited to solving the problem at that point in time. In some cases that may be HTML5, in other cases it may be C/C++, Java, Air, PHP, or a mixture of one or more.

    While HTML5 has made some progress recently, the stakeholders have been arguing about it since 2004. That’s right, 8 years! And still we have no standard that works across all platforms – each browser/device manufacturer has it’s own interpretation of the “standard”. In reallity, there is no standard, and I doubt there ever will be. That’s the “open” in “open standard”, and that’s what happens when you try to design a rapidly evolving technology by committee.

    Whether something is an app or a web-app has nothing to do with the technology used to build it. You can create both apps and web-apps with HTML5. You can create both apps and web-apps with AIR/Flex/Flash. You can even do both in C++ if you like.

    As for apps vs web-apps: the line is blurred, and it will become more blurred as we move forward. The arguments Dave gives don’t make sense: whether the code is stored on the device or on the web makes no difference – the people who created the app (on device or on a site) still control it’s function. So the silo still exists. For instance, Google has total control over both the web-app version of GMail as the on-device app versions.

    The silo is created by the OS. On IOS, the ability to share information between apps is very limited. On Android, it is much, much more open. I hope QNX will be more like Android than Apple, and it looks like it is heading in that direction.

    When asking which solution is best, the answer is, as always: it depends. Sometimes a web app is more suited to the problem. Sometimes a “classic” app is better. Sometimes native code is the way to go, other times it’s Flash, maybe it’s HTML5.

    Why choose to keep one and kill the other? Surely it is better to have options. If you think about it, the only ones who really want such a choice to be made are the people who make money from one but not the other. For us users and developers: the more the better!

  3. Jon you have a good point that developers will develop based on the right tool for the task. We seem to be agreeing more than disagreeing but the trick is not necessarily HTML5. HTML5 just enabled more app like functionality from the Web. In other words it compliments the power of the web.
    To put it this way. Take Gmail’s app on Android, iPhone, etc and compare it to their gmail desktop or mobile site. The reason Google does not have desktop Gmail apps is the same reason that mobile Gmail apps are struggling to keep up with the feature set in the Gmail website.
    In short the concept is that Apps will always be around but ask yourself how many “apps” you are using on your desktop compared to 5 years ago and you will start to realize why the web wins in most use cases over apps.

  4. I’ll give you an example of an application (aka app) limitation. For instance, The Daily, content rich, with videos and interactive charts, etc. By noon, the Daily feels old. That’s why the publisher pushes another version when it merits, which you have to fully download. The NYTimes application does this in a better fashion by triggering updates at launch or on demand. However, this is way slower than just checking the web site.
    Point here is ‘apps’ take longer to update, and real time content is on the web.

  5. I can see the value of apps over web in the following way. Apps need to go out look at websaites and give me the information I want.

    I use expedia, but I don’t want to go to the expedia website to look at my trips, I want the BB travel App. Plus sometimes I don’t use expedia and the travel app can work to get me all travel info in the same place.

    I do see a role for apps in this way.

    Also, I like reading the NYT mobile site on my playbook but I would prefer an apps that downloads the whole paper so I don’t need to be connected to the web and so that articles open lightning fast rather than having to go to the web each time to grab the new article I want to read.

  6. Ronan,

    the trick is to have a single code-base that adapts to, can be tweaked to run on, and be optimized for multiple devices & media. No app dev wants to write, re-write & support different technologies for different platforms. HTML5 may provide a solution. So may other technologies such as Qt and Air. My point is: one size does not fit all.

    Whether code & content is stored on the web or on the device, depends on other factors, such as update frequency and offline usage requirements. Often it’s a mixture. In any case, it’s a different issue.

    • I agree Jon there have been many attempts to create single codebases like Titanium and Marmalade. On the other hand I find the server based browser client model to be the best for 90% of the services I use. The only real value I have seen in apps is for caching but that is the one place where HTML5 actually shows promise in changing that for web technology.

      In a nutshell what I have found is that most apps I use are just watered down versions of the website. Even BlackBerry apps like App World would benefit from having an HTML5 variant… 🙂

    • one size doesn’t fit all? not HTML5 is more intelligent than you think, try and then try to resize the browser on your desktop and see how seamlessly it renders the content according to the size of the window.

  7. My biggest issues with “web apps” on BlackBerry has always been the crappy browser and the fact that most developers don’t take the time to detect the client properly and have their “web app” act accordingly. A “web app” that looks and functions fine on a Storm2’s size screen and OS5 is often total crap on a Curve/Tour/Bold size screen with OS6/7. But then again, most of those developers don’t build dedicated apps anyway for BlackBerry, so it’s all pretty pointless regardless.

  8. couldn’t agree more, want to see the power of html5 first hand? try and then try to resize the browser on your desktop and see how seamlessly it renders the content according to the size of the window.

  9. I wasn’t talking about screen size.

  10. It’s perfectly fine to use HTML 5 for some things where you know you will have to be connected to use them anyway, or where the majority of features benefits from being connected.
    Eg Movie apps.

    At the same time it is necessary to account for the likely hood that the user will have an unstable web connection and cover for the possibility of drop outs. Eg caching of data being posted so it is not lost during a brief loss of connectivity.
    Causes: Overcrowding, remoteness, moving at speed, technical outages.
    Eg if my net goes down I should still be able to access emails I downloaded, Caching is still a great tool.

    Then there are apps that just don’t need to be on the web and simply work better locally, and can benifit from having wifi off to save power.
    Such as ebook readers, Survival applications, text writers, basically anything that does not at it’s core need to be constantly connected.

    Such apps best serve us by not being web based freeing up limited wireless internet bandwidth for apps that do.

    • Oh I agree that there is a need for offline applications but it looks like web technologies are trying to step into that space. There will always be offline apps. Even web apps require an offline app, namely a browser. I am not negating them it is just that all of these one off apps at some point will need to be consolidated. This sort of sprawl is already killing cross platform development houses.

1 pingback on this post

BlackBerry© is a registered Trademark of BlackBerry Limited. BerryReview is in no way affiliated with BlackBerry Limited though sometimes their lawyers send us love letters...

Copyright © 2007-‘2018’ BerryReview LLC