BBC News iPad app re-done in HTML5 | Hacker News Reader

BBC News iPad app re-done in HTML5

whitherapps.com

66 pointsjamesgpearce36 comments

Anybody that plans a business on a mobile platform based on app sales should take note of this, even if it isn't there yet I really think that it is the future. We've already seen this movie before, and if google docs is possible on a desktop/laptop + serverfarm you really have to wonder how long it is going to take before history repeats itself and 'apps' will go the way of a large number of desktop applications that are now 'web-apps'.

You forget that 'apps' started off as web-apps in the first iphone, and neither the users nor developers liked them, so the SDK was released.

The future lies in thicker clients, particularly for mobile where the internet is not as assured as on a desktop.

Considering most of those thick mobile applications would rely on the internet for one reason or another, it's not wrong to assume that web-apps could take the reign in the future. After all, HTML offers more capability now than it did back when the iPhone was released.

I've been doing a fair bit of development with jQTouch, jQuery, offline web apps and the SQL database engine accessible from JavaScript in Safari and it's a pretty sweet combination.

>fter all, HTML offers more capability now than it did back when the iPhone was released.

Over all web apps offer more control for the developer as well.

Web app situation on iPhone has improved considerably since pre-SDK days:

• In 1.0 there was no offline cache or local storage. You had to download whole app each time over 2G.

• JS was many times slower (pre-SquirrelFish engine, slower hardware).

• No CSS transitions or animations. Now you can have 3D hardware-accelerated layers in CSS.

• You couldn't get rid of status bar and Safari toolbars. Now iOS allows apps to take over entire screen (if user bookmarks page on home screen).

Also developers needed some time to learn how to use WebKit features. Instead of dumbed-down CSS you can use some CSS3 and -webkit- properties. Instead of slow and limited onclick you can use non-standard touch events, etc.

Gmail as a web app is pretty awful. Web apps have improved somewhat, but in general they suck a lot compared to native apps.

Web developers want the web to take over from apps, in spite of the fact that the market has CLEARLY chosen native apps over web apps. Web apps had a year and they gained no traction. Compare that to the native apps traction: huge difference. Wishing it were not so does not change that.

The future lies in native shells mixed with HTML5, and this is just for portability reasons.

It's not that CLEAR to me. Native apps are popular on iPhone because Apple promotes App Store heavily. App Store is on every iPhone screen, in every iTunes copy.

From technological perspective superiority of Cocoa it's not that clear either. In my "native" application I've used WebKit views in many places, because it was easier for me to create complex layouts in CSS rather than Cocoa views.

Kind of a side-note but I have seen a few times something along the lines of "seeing the reaction to web-apps, Apple decided to release an SDK".

My opinion on this is that they had planned all along to have an SDK but, since it wouldn't have been ready on day 1, they said "oh no, make web-apps they're great!" so that developers would do something while they're finishing polishing the SDK.

Sure, I have no proof for this either, but it sounds unlikely that 1. they wouldn't have thought about it, 2. they would have been able to turn around an SDK in just a few months.

I agree. It's always seemed obvious to me that the SDK was planned from the start, not knocked together in a few months as a response to developer rejection of web apps.

Looking at the way the proxy was created on the Nginx server, it seems he's created an open http proxy that's asking to be abused. Anyone could make a curl request to that /apps/bbc-news/proxy uri and pass whatever URL they wanted to hit via the x_bbc_url http header. Doing this, any request they make would appear to come from the whitherapps.com (or whatever) domain. I can see the 4chan guys having a field day with this posting spam to boards their own IPs have been banned from. Seems like the server should only allow http proxying to a white list of domains, or better yet, a white list of urls.

Yeah - you're right... I hadn't expected this little experiment to hit Hacker News in quite the way it did, so the proxy is getting locked down.

You've gotten pretty far with this, and for that it's worth commending. Nice job. I look forward to seeing a polished version of this. You should offer it up to the BBC. :)

Thanks. Stay tuned. I'm actually waiting for a Cease & Desist letter from them ;-)

Q: why not do an offline application? As far as I can tell, you don't talk about manifests and "offlining" it as if it were the normal BBC application. Any reason?

I will put a manifest on it, for sure... and the AJAX-stuff is cached via localStorage, so that already gets offline-ness

Html5 on the ipad is still wishful thinking by people who don't want to bother being an ios developer. This demo is clearly worse than the BBC app and i have yet to see an ios web app that doesn't feel hacky and make me wish for a native version.

In a couple generations when mobile CPUs are faster and ipads have more than 256mb of ram, we will see a repeat of the web app takeover that occurred on the desktop.

Amen. I am more than a little sick of people opinionating about the greatness of all things HTML5 when they've clearly never tried to develop anything for either Android or iPhone, but simply wish that their existing experience directly translates.

If you're downvoting, please shoot me an email with your html5 mobile app to prove me wrong: einar@lcrnd.com

It's not expected to be the same quality as the BBC app, it's a demo. More precisely a proof of concept. The message here is that if the BBC spent as much money making a high quality "mobile" html5 version of their site as they spent on the iPad app they would have just as good an end user experience with a lot fewer issues. For one you save all the money it takes to get an app into the app store (remembering that developer time and effort == money). For another you get the benefit of supporting more platforms instantly, iPad, iPhone, netbooks, android phones, etc.

A disclaimer: my company develops iOS apps on contract so I am a bit biased in preferring native code, but I have tried to do HTML5 as a substitute in the past.

In my experience trying to develop HTML5 apps instead of a native app:

1) Development (and design) time is roughly equivalent between an iOS developer and an HTML developer, because of time trying to copy things that native code gets for free.

2) It's a bad idea to use a cheap HTML developer because there is a lot of stuff to work around, a good HTML5 iPad app is not something you can really do by dragging things around in dreamweaver.

3) What you wind up developing will have to be majorly modified for another platform due to iOS specific bugs, features and chrome.

4) You will never reach the same quality in HTML5 because the iPad has issues relating to CPU, RAM, and bugs or missing features in Safari that Apple doesn't seem too bothered to fix.

As a proviso, in some circumstances, like for simple apps that don't need to be perfect, HTML5 is a good idea. What I'm saying is that in most cases native will be better in time/money spent and quality of resulting product.

> You will never reach the same quality in HTML5 because the iPad has issues relating to CPU, RAM, and bugs or missing features in Safari that Apple doesn't seem too bothered to fix.

But those are known (or knowable). It's not like you're dealing with 5 different browsers in 10 different versions here, you're dealing with a single browser in a single version (well two by the end of the year with iOS4.x on iPad) on a single, uniform hardware platform.

So the CPU and RAM constraints are well known (and I don't think the BBC app is taxing there), and the bugs or missing features in Safari Mobile can be worked around.

Furthermore you can easily rely on proprietary stuff such as custom JS or CSS rules for transforms & stuff, which is a much bigger issue on the open web.

>> It's not like you're dealing with 5 different browsers in 10 different versions here, you're dealing with a single browser in a single version

If you're only targetting iPhone/iPad/iPod, then what's the point of doing it as a HTML5 app? The implied advantage of HTML5 is portability.

The main downside of HTML5 for iPhone apps is that they don't appear in the App Store. How many installs has the BBC News app got because it's been featured in the App Store? Thousands, I bet.

The 'app' culture is pretty ingrained in iOS users now... if it's not in the app store, it doesn't exist. Notice how major services like Facebook have both native apps and iPhone optimised web apps.

App and HTML5 are not mutually exclusive You can always make a trivial iOS/android/BB/etc app that does nothing but show a webview.

Are there any apps like this in the App Store? It wouldn't surprise me if Apple chose not to allow such "apps" in.

Have you guys seen the HTML5 version of the NPR app? The scrolling is actually smoother in the web version.

http://touch.sproutcore.com/npr/

After trying to use that on my ipad for five minutes, I lost count of the obvious bugs. And no, the scrolling is not faster.

Same here. What i wonder is whether mobile web app thingie is going to get better over time or if it's going to stay half-broken forever.

NPR app was put together quite quickly and was intended by it's authors as a demo of though capabilities of www.Sproutcore.com

Let's not miss the larger point here. HTML5 have become a real option of application development. A business that relies on mobile/tablet form factor should seriously consider HTML5 as the application platform. The cost of porting iPhone/iPad apps to Android phones/tablets is much less with HTML5 than with native code.

Lack of distribution and monetization of HTML5 apps doesn't need to be an issue. A web app can be embedded into a native app to be sold on the AppStore.

To be fair, the App version's scrolling is "just plain broken"[1] so that isn't hard.

[1] It is better than it used to be. There used to be a weird lag at the start. Now it is nearly subliminally jerky. It also crashed when I opened it to check for this comment.

> we will see a repeat of the web app takeover that occurred on the desktop

Desktop apps are not like iOS apps. They don't have very easy purchasing/billing built-in, they have to be downloaded and installed in a weird way (very few of my non-geek friends can install anything except apps on their iPhones), and they cost a fortune.

Apple will be doing a good job of maintaining AppStore the easiest option for both users and developers, and, well, people tend to use the easiest option.

It's an ongoing series... yes, it rough right now, but I'm pretty sure I can make it equivalent - to the pixel - to the app.

In fact the only real challenges are scrolling (since Safari has a strange opinion on overflow:scroll) and embedded video (because the BBC is using some native iPlayer approach, as far as I can see).

Otherwise, my expectation is that a few 100k of HTML5 will be hard to distinguish from 6Mb or so of app. If you have a capped data plan, that might be, er, good news...

I just happened across http://abcnews.go.com the other day on my iPad and thought it was fairly well done and the page turn animations were decent. Check it out.

I love this type of stuff. The project I'm working on right now is all about having a better experience than the iPad magazine apps, while using HTML/JS instead of proprietary tech.

Here's a video demo of some of the layout, for the curious: http://www.youtube.com/watch?v=Pt2iJZGqMpw

I was surprised when I was checking caniuse.com today that cross origin requests were supported pretty much across the board.

Is there a reason you couldnt use them? http://caniuse.com/#feat=cors

The server needs to know what to do with them. Since I am only writing a client here, I can't do the server-side piece of the preflight checks etc

Also the service needs to have a particular user-agent to work, so the proxy doubles up as a rewriter for that.

Html/js is good for some UI parts of an app but eventually makes one yearn for native threading/locking, queueing, posting notifications, for that last 10-20% of code.

Reply on news.ycombinator.com