Did Web-only development fail the iPhone?

You can have Dashboard widgets on the iPhone with Widgetop which keep their state persistent.

Baloney. Native apps is where it will always be at.

Ultimately, all web applications depend on stateless, crufty HTTP to get the job done. This is why, for example, AIM on Meebo sucks compared to MobileChat or Apollo.

What's unfortunate is that Apple wasn't able to provide the ability to download "widgets" developed via Dashcode on day one.

Save for those with bundled Obj-C libs, there's probably very little reason my current Dashboard widgets couldn't be run on the iPhone.

Combining client side widgets with server side web services is a good compromise, as most web sites are bloated with a bunch of markup above and beyond data (notably images). If you were using EDGE for just pure data, the performance of EDGE would be much less noticable I think. (Seriously, how much data is a list of movie listings for example?)

This ability of running current OS X widgets on an iPhone would have met a bulk of the needs of many app developers, even if there wasn't a way to persist data locally (though I think they need that long term).

I would like to hope that when the SDK comes out in Feb, that we'll get an updated Dashcode that will let us one stop design and test iPhone based widgets.

Well as someone who recently purchased a smartphone (not iPhone) I would say the biggest hurdle is the EDGE data speeds and the architecture of that web-only plan in general.

They do have a near perfect browser for handling a new generation of mobile web applications, but unfortunately the mobile web seems to mainly still be in beta. With limited speeds it's important to trim the transmission for mobile apps to a minimum. that's why there is a Google Maps app that doesn't download a pound of javascript before it begins running.

If Apple really expected to keep tight control over the included apps, they should have spec-d out the machine and/or gone with a faster network. At the end of the day it's a total waste to be constantly downloading all of the extra bits to present info in HTML, not to mention you should only access the web to find info that isnt easily offered by the handheld. Some mobile apps dont even need to communicate so what sense does that make?

I'd say that the iPhone (esp. safari mobile) is still a boon to the web2.0 community, but the device itself is not going to realize it's potential without the SDK

I wouldn't say it's an idea ahead of its time... it's an idea ahead of this phone. I would have gladly taken advantage of the web apps available, except there is no way to iconize them on the springboard. and safari on the iphone is awkward accessing addresses. i don't like to use it except for looking up something specific, i'd never just browse. i'm not going to go into safari every time i want to simply take advantage of an app. not to mention, doing so makes me tethered to the internet to take advantage of an apps services, and if i'm not on wi-fi, i want to tear my hair out waiting on the edge network.

Whine, whine, whine... There's room for both Web-based and native application development on the iPhone - anyone can see that!

Whine, whine, whine... There's room for both Web-based and native application development on the iPhone - anyone can see that!

An SDK for the iPhone was a planned intent. Announcing the product with mere web support concentrated attention on web application development and drew comparisons with other web browsers on other phones. Thus, another market and another set of developers was borne. Why else would Safari for Windows have been developed?

Now with an SDK - even if we don't know what the SDK is - brings in the other developers.

The result: a greater market for applications. A greater market for the iPhone. If the SDK had been announced at the launch of the iPhone web applications would have been ignored. Masterful.

I think the web has failed all of us as a means to create rich applications. You just cannot create apps with the consistent and reliable user experience as you can on the desktop.