HTML5 offline webapps vs Google Gears Localserver

Google Gears is a fantastic browser plugin; it allows a developer to create applications that run while offline, syncing with a server when online. Two great examples of the power of that mechanism are Gmail (both the “desktop browser” and the mobile Android-version) and Mindmeister (only while in trial, for paying Mindmeister-accounts after that period). The problem with Gears however is that it’s a plugin and not a lot of people have it installed: only Chrome-users have it by default. And that’s where HTML5 comes in; one of the areas where the new spec offers vast improvements over html4/xhtml is the ability to take webapps offline by allowing a developer to store files for offline usage and to write data to a local, browser-embedded database. Both Safari 4 and Firefox 3.5 support these features, so maybe HTML5 makes Gears already redundant in those browsers with more to come?
I haven’t gotten around to experimenting with offline databases yet, but I did already look into offline files. At first sight, Gears Localserver and HTML5 Offline Webapps indeed seem very similar; your html-page points to a manifest-file which contains a list of assets (pages, images, css, js, …) that the browser has to store for offline usage. Easy enough, no?
To get a better feel of how offlining in HTML5 works, I decided to try to write a simple WordPress plugin to replace its ‘Gears Turbo’-option. Turbo (which you can find in the Options-menu) essentially stores 1Mb of files locally, to speed up delivery of the WP-admin pages. To make a long story short; my plugin didn’t work. For starters, by default requests for non-local data are blocked, but it’s easy enough to unblock network access by adding “NETWORK:*” (with a newline before the wildcard) to the manifest. But more fundamentally; HTML5 Offline Webapps not only stores the files specified in the manifest-file, but also every html-page which points to the manifest (see my test here). There’s no way you can exclude those “master entries” from being stored. So if pages are stored, that means they have to be static and that all dynamic parts should be handled by javascript (fetching data using ajax and updating your page with it). And that, my friends, is clearly not a use-case that is applicable to WordPress admin-pages.
So HTML5 Offline Webapps is no drop-in solution to speed up delivery of dynamic pages, you’ll still need Gears to take care of that (or rely on old-fashioned carefully configured expiry- and cache-headers). But, as Google proves with the iPhone-version of Gmail, Offline Webapps combined with a HTML5 offline database can work miracles if you use it the correct way.

http://blog.futtta.be/2007/04/06/cache-header-magic-or-how-i-learned-to-love-http-response-headers/

Voorspellingen 2009: browser-oorlog, ook mobiel

ballmer vs jobs: mobile (and/or) browser war (from iphoneblog.com)Naar aanleiding van de publicatie van de voorspellingen van 20 online experts door Netlash, zijn dit enkele van mijn verwachtingen voor het web in 2009;

  • Uw job als (front-end) webdeveloper (of tester) wordt er door de grotere concurrentie tussen browsers niet eenvoudiger op. Ge zult niet alleen moeten ontwikkelen voor Internet Explorer (het nieuwe IE8, maar ook nog altijd voor het verwenste MSIE6 en voor versie 7 natuurlijk) en Firefox, maar ook voor Safari en Google Chrome. Samen zullen deze Webkit-gebaseerde browsers eind 2009 immers tot 15% van de browsermarkt pakken (nu al 9%), tegenover 25% voor Firefox (nu 21%) en pakweg 60% voor (MS)IE (nu nog 68%). Gelukkig zult ge wel iets meer kunnen terugvallen op standaarden (MSIE6 buiten beschouwing gelaten) en zullen componenten als JQuery, YUI of Dojo uw cross-browser inspanningen blijvend verlichten.
  • Bling-developers mogen die dure cursussen Silverlight en JavaFX annuleren, Adobe blijft immers oppermachtig met Flash en -ondanks de gigantische hype in 2008 in veel mindere mate- met het nauw verwante Flex. 2009 zal overigens niet het jaar van Flash op mobile zijn. Een volwaardige versie van Flash voor GSM’s zal immers pas op het einde van het jaar uitkomen en zal dan nog enkel vlot werken op smartphones met ARM Cortex gebaseerde processoren, die nu ook nog niet te koop zijn.
  • Webagencies staan voor een belangrijke uitdaging; “mobiel internet” groeit (mede dankzij krachtige Webkit-gebaseerde mobile browsers) zowel aan vraag- als aanbodkant en kosten-bewuste klanten zullen convergentie tussen hun mobiele en hun “gewone” website hoog op het verlanglijstje hebben staan. Mobiel web wordt dé groeipool, ge kunt dus maar beter mee zijn, zowel functioneel (“mobile usability“) als technisch (er is meer dan Mobile Safari, niet iedereen heeft een uitgebreid toetsenbord en device-dependant rendering is een moving target).

En voor een recessie tenslotte, heb ik in 2009 echt geen tijd. U ook niet, toch?

Webkit Konquering the mobile world

With the nineties browser wars and the quasi MSIE monopoly that followed after the Netscape debacle behind us, the desktop browser scene can be considered a mature market, with some very good products vying for our approval. Time to shift our attention to the next battleground; mobile browsers. Netfront and Pocket Internet Explorer dominated this emerging market for quite some time, but as of late some newcomers are making great advances in this area. And apart from Opera Mobile and Mini (the Mozilla-guys are really ages behind here), these all share the same open source core; WebKit.
The history of WebKit in 10 1/2 sentences
WebKit is a fork of KHTML, the html rendering-engine that was developed by the KDE-community for its Konquerer-browser. In 2002 Apple decided to build it’s own browser based on KHTML and thus WebKit was born as the core-component of what would become Safari. Since it’s inception, WebKit has gained enourmous momentum; Safari now has a market share of approx 6% on the desktop, but smaller projects such as iCab and Epiphany (the Gnome browser!) picked up WebKit as well. But there’s more; Adobe decided to incorporate it in Air (the Flex-like platform for building desktop-software). And Trolltech, the company behind the Qt GUI-toolkit and one of the primary backers of KDE, announced they would include Webkit in Qt 4.4 as well.

WebKit 0wnz Mobile
But the mobile area is where WebKit is really taking the world by storm; it not only powers the mobile version of Safari on the iPhone and the iPod Touch, but WebKit (in its S60webkit form) it’s also the basis of Symbian’s S60-browser. Nokia ‘s Mini Map Browser, as it’s officially named, was first released in november 2005 and thanks to the succces of Symbian it’s probably the most widespread mobile browser by far. Being a proud Nokia e61i-owner myself, I can testify that it is a great browser indeed; I didn’t even bother with installing Opera Mini (which I used instead of Netfront on my Sony-Ericsson w810).
Next to these two well-established WebKit-derivatives, the lesser known Iris (for Windows Mobile), newcomer Digia (for Symbian UIQ-devices) and last but not least the browser of Google’s highly anticipated mobile Android OS are also part of the family.
Mobile Web, but there’s more then One
So thanks to KDE’s great job on KHTML and Apple’s (and Nokia’s) subsequent work, we are at a point where users of ‘smartphones’ and similar devices can access the internet almost as if they were using a desktop-browser. But screen-size, text-input, data transfer (bandwidth and price) and context remain very different from normal browsing, so don’t believe the “one web”-hype just yet. But still; these sure are great web times for building mobile(-ready) websites and -applications!

New: cross-document messaging

With new versions of our trusted browsers coming out, web developers who like living on the edge can start  using some of the new features that are becoming available. One such goody is cross-document messaging, which is part of the HTML5 draft spec.
Cross-document messaging allows children of a window (think iframes, popups, …) to communicate using JavaScript, even if they originate from a different domain. This means that Instead of just iframing an external application, without being able to integrate further, your page can send and receive messages to/ from it. PostMessage could even be used to do cross-domain XHR (a hidden iframe on the same domain as a a remote datasource can be used as a proxy to perform XmlHttpRequests on that remote domain) untill the real thing hits the streets as well.
The two additions that allow you to perform such messaging, are window.postMessage and an eventlistener for events of the “message” type to handle the message. A pretty straightforward example of this can be found on JQuery’s John Resig’s site (see also his lastest blog entry about postMessage). As cross-domain javascript can be a potential big security risk, taking into account some precautions is really really really really really necessary. Really!
On the downside (as if security is not a problem); this brand new feature is only available in Firefox 3 for now. My own little test (a copy of John Resig’s example with some minor tweaks) worked in Opera 9.2x (and 9.5b) as well, but postMessage seems to have been dropped from the final Opera 9.5, as the tests on Opera Labs don’t seem to work any more either. Support for postMessage is also available in Webkit (Safari‘s backbone) nightly builds and in Microsoft’s IE 8 BETA (with the event being ‘onmessage’ instead of ‘message’ and some other quirks but hey, this is beta, no?).
So expect postMessage to be available in all major browsers by the end of the year. But why wait if you know that Facebook is already using postMessage in their chat application. I wonder what they fall back to if it is not available though …

About:blazingbetabrowsers

zeer snelle vosDat er precies iets (heel snel) beweegt in browserland:

Safari3 vreet geen wiki meer!

webkit logoGroot nieuws: Safari3 is de smaak van mijn wiki eindelijk beu en vreet er geen tekst in de textarea’s meer! De webkit nightly build van 26-8-2007 (werkt enkel als je Safari3 voor Windows al geïnstalleerd hebt staan) heeft deze lelijkaard immers de wereld uit geholpen.
Als ik de uitleg in de webkit-bugtracker goed begrijp, werd de bug veroorzaakt door toetsaanslagen die onterecht als tekstinput werden beschouwd en daardoor als ‘null character’ werden ingevoegd. Die null characters en/of control characters (die ondingen gooien ook roet in het eten, snap niet waar die vandaan komen maar soit) zorgden er dan voor dat de rest van de textarea werd “opgegeten”. Ofzo?
Alleszins; groot feest gister in Eksaarde, mijn vrouw, dochterken en ik dansten de polonaise en de buren hosten enthousiast mee. Terug in de echte wereld besefte ik wel dat ik nog wel enkele probleempjes met Safari3 voor Windows heb; ik krijg nog regelmatig de foutmelding “Safari can’t open the page” met detail “unknown error” ((null):10053)”, maar misschien moet ik Safari 3.0.3 eens installeren om ook dat te hertesten? Mijn vertrouwen in de Apple-bughunters staat alleszins in het zenit, dat wordt me daar een fantastische browser mensen! 🙂

Safari3 for Windows still sucks, but getting better at it

catching safari bugsOmdat ik in het diepst van mijn gedachten een Steve Jobs-fanboy ben en omdat ik zo graag met browsers speel, heb ik na mijn rant van vorige week vlijtig verder geëxperimenteerd met Safari3 voor Windows en speurde ik het wilde wereld web verder af naar informatie over mijn kleine probleempjes. En ik mag misschien nog niet jubelen, maar ik kan wel al aankondigen dat er toch al enige vooruitgang is:

Read more

Safari ate my wiki! (updated)

unknown error en geen toegang tot proxy instellingenSafari Beta3 voor Windows is uit, dit kon U al uitgebreid lezen in de pers en natuurlijk ook in blogland. Als wannebe-mac-user met een boontje voor alles wat niet MSIE6 (yuck) is, ben ik verplicht Safari te downloaden, installeren en testen.
En ik zal maar direct met de deur in huis vallen: blijf er zo ver mogelijk van weg, Safari3 beta voor Windows is een slecht vermomde alpha release!

Read more