How else would you recommend working around the $300 per year* overhead cost of developing native iOS applications and the iOS application approval process? If phone makers want to diminish their products' battery life by promoting battery-inefficient application platforms, let 'em.

* Breaks down as follows: $100 per year for the cert, $500 every 5 years for buying a MacBook Air and a copy of Windows to run in VirtualBox instead of a Windows laptop, and $250 every 2.5 years for an iPod touch on which to t

Yes, but even those programmers in the second and third world are more than capable of paying $300 a year (which is mostly inflated since you add a bunch of artificial costs that are not absolutely necessity for iOS development) for the development tools. Hell you'll pay more than for Android development since you'll be forced to buy way more than just a single device to check compatibility of your apps.

(which is mostly inflated since you add a bunch of artificial costs that are not absolutely necessity for iOS development)

What might those artificial costs be? The $99 per year for a certificate is unavoidable outside the underground jailbreak-only ecosystem. People have criticized me for adding the price of a Mac, claiming that someone would have bought a computer anyway. So instead, I added the rough difference in price between a MacBook Air and a Windows 7 Home Premium license on the one hand and what someone would have bought otherwise (a midrange laptop that comes with Windows 7 Home Premium) on the other hand.

Not all people are in a financial position to move to a place with a high concentration of employers willing to pay a professional programmer $300 per day. They have to start it as a hobby and build it up into a profession in order to build a portfolio to show to employers. They also need some source of income on which to relocate and live while seeking a job, and that source of income might not pay $300 per day.

No. There is a reason why Python is still a very minority language and Javascript (ECMAScript to be exact) is not. Javascript is good enough. For the great majority, Python is a PITA. Practicality trumps perfectionism, every single time.

Even if only 10% of the zombie touchpads in the field continue to run webOS, the loyal user base will continue to develop for it. Perhaps they are wrong or misguided...but people still buy Morgan cars and build wooden sailboats. And I, wierdo that I am, Bluetooth tether a Pre to an Android tablet and can run the same HTML5 on both.

They can have icons and everything, and can be launched right from your home screen.

There's currently a speed discrepancy between apps launched this way and the exact same app navigated to from within Safari due to an older version of Webkit being used from the home-screen-launched version, due to security and sandboxing complexity (the new version is faster, but would create a security problem without a proper sandbox), but this is being fixed in iOS5.

1. Refused to adopt POSIX standards.
2. Has its own calling conventions for C/C++ incompatible with the GNU ones.
3. Released Direct3D to try and kill OpenGL.
4. Actually had people on the OpenGL board trying to actively stall its development.
5. Tried to release J++ to compete with Java.
6. Maintained its own Java VM for years, slightly incompatible with Sun's.
7. Released C#, to compete with Java.
8. Opposed open document formats.
9. Released it's o

This will fail over time but it will fail. We can only hope it fails sooner rather then later.

The idiocy of mixing a layout specification with code is going to open us up to more and more interesting types of viri and malware.

Remember CORBA? It has never seen the light of day in any serious way. It WAS a great idea.

Why have we not learned that a layout engine is most assuredly not the right tool for the job? The amount of hacks and just plain insanity you have to go through just to get thinks to work from one browser to another is starting to make lots and lots of people just go dust off their RAD tools, eg: Delphi, Power Builder, etc and just write the damn app and call it a day.

At some point the browser will have to be so huge to support the never ending flow of committee designed API's that they will make MS-Access look like a memory efficient application.

Applications are not documents and the browser needs to get back to doing document presentation and we need to build application processor that takes in application specifications and then runs them because trying to do both has been, is and will forever be a fucking mess.

I agree with your sentiment. However, when's the last time you installed a binary from a company you've never heard of? When's the last time you've visited an active website from a similarly obscure company?

The barrier to entry for web apps is so absurdly low that many companies or projects are going to use them just because it's the only way to run code on users' computers. Given web apps are here to stay for at least a certain market segment, ask yourself if WebAPI is a good or a bad thing; that's real

I think that the ideal compromise might be a combination of a VM (e.g.: Java,.NET or NaCl), some object sharing/serialization protocol (like CORBA or even just JSON), a distribution system (like an app store) and some low-level APIs.

Imagine if webpages were not made of HTML+CSS+JS+Images and a bunch of other files, but instead just code. You go to some URL, and each page is an app, that can run in its own window (or even spawn multiple windows). You wouldn't have to install anything, you just go to the

What's hilarious though is that almost everything that the majority of Slashdot bashes over and over becomes successful (look at Firefox and Chrome usage numbers months after everyone started saying "people are jumping ship left and right"). This is all just "No Wireless. Less space than a nomad. Lame" all over again.

The comments from the Mozilla haters seem pretty short-sighted and stupid.

Apple's first SDK for the iPhone was HTML/JavaScript based. It only failed because the renderer and JavaScript engine was pretty horrid and made it hard to produce good quality apps.

HTML5 is now pretty robust, and between PhoneGap and a UI toolkit (like Dojo Mobile) it is possible to produce good/great applications and be able to take a huge portion of code from iOS to Android to others.

It sounds like this is just a series of APIs to try and make the hardware of a mobile device available to an HTML 5 application? It would be nice for HTML 5 to have hardware acceleration, and for HTML 5 apps to be able to take advantage of GPS, accelerometer, etc data, but I don't think its the right approach. Personally, I like Adobe's approach to the problem of OS fragmentation with AIR better: create and maintain client-side run-time environments (VM's) that can execute pre-compiled code to facilitate OS