I hate to find fault in an otherwise informative and complimentary post, but what the heck is AJAX2? XMLHttpRequest Level 2 is a revision of XMLHttpRequest, not of "AJAX", which is a fuzzy bundle of concepts referencing a style of Web application development. It has no 2.
I was interested in the "accelerationIncludingGravity" property. It seems needlessly verbose. I thought - why isn't there just isn't a separate "gravity" property to complement the "acceleration" property?
> We can't use
> acceleration & gravity in place of acceleration &
> accelerationIncludingGravity as some devices are unable to determine
> the acceleration without the effects of gravity - that's the
> motivation for the property.
Actually, a sizable portion of HN thinks that Apple will start to take after Microsoft in the 90's in regards to the web. (They also seem to think Google made WebKit's inspector pane.)
A big complaint is about the -webkit prefix, despite the fact that A List Apart and Zeldman champion it as reducing the amount of browser hacks needed due to the inconsistencies in rendering. (Think how wonderful an -ie6 prefix would be. Now, think about a CSS parser that doesn't fail in specific ways allowing the dev to target it. border-top-left-radius can't be targeted to a specific render, but screws up in different browsers, so it has to be rendered through JS or conditional stylesheets.)
I can't find the actual topical discussion in google, so here's one that links to a news article about the quote in relation to Facebook:
I think Jobs has been repeatedly clear that iOS supports two platforms: the web, an industry standard Apple tries hard to advance to the best of its ability, and iOS, which Apple keeps proprietary and advances to the best of their ability that way. Apple is devoting significant resources to developing both (in leu of focusing 100% of engineering on either), as an experiment, if you will.
Now, if only web apps on iOS could enter into full-screen mode like native apps...
Now, if only web apps on iOS could enter into full-screen mode like native apps...
They can. You need to add some additional metadata to the header, and the user needs to save that url to their homescreens (homescreens? does that even make sense?), but once done the web app looks like a native one. You can even define a splash screen to display while the page loads.
Both arguments are made. Although frankly I think with Android and WP7 presenting credible threats to Apple, they aren't in a position to dictate. With this amount of competition, MS, Google, and Apple all have to fight on all fronts.
Only until one has a monopoly like position will we know their true motivations... I prefer not to know any of their motivations. :-)
I'd love for John Carmack to spend 18 months heads-down doing an HTML5 engine. Even if he failed to do anything incredible, the feedback would be invaluable.
I love the fact that with mobile devices, we all get to witness Mr. Carmack doing what he does best for a second time: pushing resource-constrained devices to their limit.
No hardware acceleration on the browser just yet and still scripted canvas so that is slower.
So until WebGL, even then, OpenGL ES will still be needed for most games/interactives/apps until we hit 2GHz and about 1GB of RAM or higher.
Then things like Flash also start to perform reasonably enough, same with html5 animation. If they were hardware rendered now then they would be reasonable but still wouldn't be compared to compiled, native apps on the device. Just like desktop now only the current mobile hardware is the desktop hardware of the late 90's.
WebSocket support, canvas, svg etc is awesome for games though.
Yep, I track all this at drawlogic.com. Firefox and Chrome also have hardware acceleration in latest. Safari has it as well but only in certain cases (Apple actually made canvas and open sourced it and it is hardware accelerated in CoreGraphics).
It will still be a couple years before this is mainstream. Where on mobile OS updates and browser updates on iOS at least are faster to be adopted (about a 6 month OS adoption rate which is much better than even browser updates on desktop).
HTML5 in the mobile is definitely great. One of the best advantages of native apps is that you can get them into app store - of course, that's by design. Even with the large number of apps, app store provides a great distribution channel.
Good question. Opera Mobile for Android just came out and has some interesting features (tabs, bookmark sync) and SVG support, which is oddly lacking in the stock Android browser. Firefox mobile is in beta as well, with roughly equal features as Opera, plus extension support.
I'd like to see the default browser get more frequent updates, though.
Not sure why Android gets pulled into this, however in addition to the fact that Android 2.2 has far and away class leading canvas and JavaScript performance -- the poor performance on iOS is why so many apps go native on that platform for trivial needs -- and brings virtually all of the Google Gears functionality that became the foundation of "HTML5" to Android (web databases, web workers, geolocation), the next version of Android is going to feature optional javascript access to the camera, among other improvements.
Android is innovating heavily, and your comment is way off base.
Not really "accelerometer" support, just orientation. You couldn't really build a motion sensing engine with it. WebSockets should be really cool on mobile though...
Mozilla has a selector, mozResponseArrayBuffer, to get an AJAX result as an ArrayBuffer. Having worked with binary data from an AJAX query I whole heartedly applaud!
I hope Webkit has a mechanism for that, and even more so, that the W3C writes a standard for it.
We're slowly adding more ES5 features to JavaScriptCore. While Object.freeze is not in yet, we do have Object.defineProperty, which you can use to make individual properties read-only and non-deletable. Once Object.preventExtensions is added, freeze and seal should be trivial.
