April 2012 - Posts
Last week the question of HTML5 and sensors came up. This wasn’t really strange as we where talking about the HTML5 GeoLocation features and using the, optional, GPS is just one device or sensor you might want to use.
It turns out the W3C has a Device APIs Working Group working on this problem. They are working on a whole range of interesting devices like:
- Battery Status API
- Contacts API
- HTML Media Capture
- Media Capture API
- Network Information API
- Sensor API
- Vibration API
- Calendar API
- MediaStream Capture Scenarios
- And more..
The Sensor API covers a group of others
A ambient temperature
A pressure sensor
A releative humidity sensor
A light sensor
A ambient noise sensor
A magnetic field sensor
A proximity sensor
Sweet, this should open up some nice capabilities in the future. The problem is that for now this is just one of may standards out there and it seems it will be some time before these standards are actually usable. Guess we have to stick to native clients, or something like PhoneGap, for now.
I hadn’t really been paying attention to the popularity of browsers a whole lot for the last few months until this week as I was teaching HTML5 and the usage stats influence what is usable and what not. Sure I heard some time ago that Chrome was larger then IE but as most of these statistics are more about politics then anything else I tend to ignore them and just check some sites I know are producing real numbers for me. And the best I know way is to compare Google Analytics on some large sites.
And was I surprised this week when I checked.
These are the stats I collected last December for an HTML5 presentation I did back then:
As you can see there are three big players and Internet Explorer was the biggest with a 42% market share. Now your stats may vary slightly but I would be very surprised they where very different for a general purpose website.
However when I checked this week things where very different.
The total number of visits may be down quite a bit but we arte still looking at more than half a million visits here. And not only did Google Chrome pass Internet Explorer but so did Firefox. And even with the overall traffic being down more than 25% Chrome still manages to get more visits in now then it did in December.
Didn’t see that one coming, it sure seems we are living in a very interesting time as HTML5 developers.
jQuery is one of the most useful frameworks out there for web development. And while most of jQuery is very much about working with the browser DOM there is also another side to it that makes doing networking real easy and that is all based around the $.ajax() and related, like the $.getJSON(), functions. Now HTML5 contains a real useful part in Web Workers for doing work that should not block the background thread. And using the XMLHttpRequest for network IO is fine in a Web Worker.
Unfortunately however working with the DOM is not ok in the Web Worker, which makes total sense, but as a result using jQuery, which has lots of DOM related code is not fine in a Web Worker. And that is a shame because using jQuery for just network IO would be much easier that the XMLHttpRequest and totally fine if it would load.
So removing the DOM code from jQuery should solve the problem right?
Enter the jQuery - No DOM Edition
It turns out Konstantin Pozin did just that with the jQuery - No DOM Edition
You can find it here or download a test version here.
In deze podcast spreekt Maurice de Beijer met Patriek van Dorp over zijn TechDays presentatie over NuGet packages voor Windows Azure.
Met dank aan onze sponsor RedGate.
Here are the slides from my securing REST services session I did at Engineering World 2012.
You can download the ASP.NET WebAPI demo here and the SignalR demo here.