I know it's easy to simply cut and paste from the original article (heck, it's one way to get people to actually read part of the article), but why not make corrections to gross errors?
Apple is not supporting WebRTC and has not implemented any of the features necessary for it. Not in desktop nor in mobile.
Or he could be the type that needs to worry about low powered mobile devices (like the type that Firefox OS initially targeted). Those devices would choke HARD trying to load jQuery.
Don't get me wrong, I definitely see the value in jQuery since it even fixes bugs in modern browsers. But lets not assume that just because someone is shying away from it that they are some newb that doesn't know better.
Minor correction -- no version of IE (or Safari if we want to be technical) on Windows XP supports SNI. IE7 on Vista supports SNI, but not on XP. Also, Android 2.x is still pretty relevant given that it currently represents 9.6% of active Android users. The original Kindle Fire did not support SNI, though I believe with the second generation it did support SNI. Anyone with a pre-BB10 Blackberry also does not have SNI support.
Trust me, I would love to go SNI-based for SSL, but support wise we're just not there yet.
I assume the parent was referring to IE's use of pointer events instead of the touch events. While many may accuse Microsoft of trying to split the web, this move was most likely done for two reasons.
As a web developer I find the pointer event method to be technically superior to touch events. At present, patches to add pointer events to Blink-based browsers (the patch might have been added before the split from WebKit) and to Firefox exist, but I do not believe they have yet landed in other browsers. Sadly, with the lack of touch events it does bloat up code to support two different event models for touch browsers at this time.
Actually, IE's ability to use their old rendering engine only goes back as far as IE7, not IE6. It's funny, given that quirks mode is really IE5.5 rendering you can test every version of IE from 5.5 up except for IE6.
Going back to the VM solution, Windows 7 Professional users are allowed to download something Microsoft calls Windows XP mode (using Virtual PC) and can create their own VMs of XP that do not require you to purchase another license. If you truly need to test in IE6, IE7, and IE8 all you need do is run all of the updates for XP for IE6 but do not install IE7, then copy that VM and run the update to IE7 and run the updates for that but do not install IE8, and then create another copy where you upgrade to IE8.
Windows XP mode is not available on Windows 8. Yet another reason why businesses may hold out on upgrading
If the developer opportunities are good, i'm in. Problem is, calling something an App Store doesn't really change things much if you're just giving people access to a web site. Maybe they're going to focus on local apps written in html+css+js?
What you're looking for are called W3C Widgets. W3C Widgets currently run on Opera, and Vodafone, while T-Mobile and the Nokia S60 have have near standard W3C Widget implementations. It looks like Android is working on it, but Apple is doing everything in their power to fight this (all while touting how great HTML5 is).
The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.
Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5.
Have the Feds, or any other major service, looked at using DOM Storage as an alternative to cookies? DOM Storage allows for more data to be stored, and it removes extra data being transferred via every HTTP request. Yes, it is only available in modern browsers, but that need not stop its use, or at least making policy towards its use.
"The way of the world is to praise dead saints and prosecute live ones." -- Nathaniel Howe