http://wiki.osx86project.org/

The differences however will be: 1) You do not have to use it. 2) They will take much less than 30% (so they say)

While I agree with you for small-scale apps made by individuals, I think AppStore is a problem for startups looking to monetize their apps on a larger scale. 30% is a huge chuck off your total revenue any way you slice it. And remember, there is no legal alternative to AppStore for the iPhone.

But in terms of Javascript/HTML/AJAX, it compiles separate versions for each browser (which are automatically loaded), virtually eliminating the need to handle various quirky browser behaviors. And any standard Java app server works fine for the server side, nothing special needed there.

Agree downmod would be helpful. Even if it had a very high karma or HN usage period requirement in order to use I think it would help the community.

Do you want a single monopoly controlling this? That type of situation has historically been bad for innovation.

As an analogy, how would things be if every internet web app created had to operate at the mercy of another company? Startup A has a great idea and wants to release an innovative new webapp. But they need to pay and have permission to do so, must operate in a tightly defined sandbox, and must share profits that they make. And the webapp could be kicked off the internet at anytime for breaking these rules.

Does that make you comfortable?

AppStore could be another Facebook platform situation where Apple kills startups at will simply by releasing their own version of a application. And Apple wont need to push icon updates, their apps can run as background services just fine.

I'd like to be optimistic about other emerging mobile platforms, but everyone else is so dreadfully far behind and thats a bit concerning for a developer.

The iPhone is going global and with the carrier subsidies, it will be cheap. My suggestion is to focus your efforts there.

If you use it frequently you might strain your eyes though, focusing between near and far all the time. If you start to get a headache you could just try moving it closer.

There just is no way around it, the only way to be secure is use SSL to share secrets when you register. From then on you can just transmit an authenticator (stored in a secure cookie) comprised of an expiration timestamp, any identifying user data (like userID), and a non-malleable MAC digest of the expiration and userID. Doesn't protect against replay but it helps to enforce a short expiration for the authenticator. With this approach you'll only need to use SSL for the initial login.

This is the best explanation of web authentication I've encountered on the net [PDF]:

http://prisms.cs.umass.edu/~kevinfu/papers/webauth_tr.pdf

Google has actually been doing this for a while now, even before GWT. Much of the javascript that is used in their apps is generated via compiler in one form or another.