With all the discussions about the place of Flash on the ever-evolving web and the excitement following Google’s announcement about YouTube going HTML5, one would almost forget that YouTube is only at the very start of their “open video” endeavor. The limitations of the current implementations are numerous; there’s no OGG (damn), no ads (yeah!) and no embedding either (damn) for example.
After looking into ways to call the YouTube mp4-file from within a Video for Everybody html-block (which is not possible, Google protects raw video-files using what seems to be a session-based hash that has to be provided in the URL), I decided to take another (dirty) approach; faking it!
The solution is entirely javascript-based and is as un-elegant as it is simple; create a html-file with a script include of http://futtta.be/newTube/newTube.js and a div with “id=newTube” containing a link to a YouTube-page and the script automagically takes care of the rest. Check out http://futtta.be/newTube/ to see it in action.
The result is an embedded YouTube player which will display the HTML5-version if you’re running a browser which supports mp4/h264 playback (i.e. a recent version of Chrome or Safari) and if you enrolled in the beta. If either of these preconditions aren’t met, you’ll just see the plain old Flash-player.
Don’t get your hopes up too high, newTube is probably not as obvious as normal YouTube embeds (for reasons I’ll get into in a follow-up post, when I have some time to spare that is). You’ll have to wait for someone (YouTube, Dailymotion, Vimeo, … are you listening?) to offer real embeddable html5-video (with support for both mp4/h264 and and ogg/theora).
But I did have fun creating the very first html5-capable embedded YouTube-player 😉
javascript
Firefox 3rc1 shines in Javascript benchmark
As the official release of Firefox 3 is getting closer, with Release Candidate 1 being available since May 17th, I decided to boldly go where codinghorror has gone before and do a quick-and-dirty Javascript-performance comparison of the different browsers I’ve got installed on my Dell Latitude D620 laptop, using Webkit’s Sunspider benchmark.
Let’s start with the results for the browsers on my Windows XP SP2 installation, ordered from slowest to fastest. Each test was executed 2 times, clicking on the results will teleport you to the detailed results where you can paste the URL’s of another test to compare.
- msie 6 (6.0.2900.2180.xpsp_sp2_qfe.070227-2300): 47203.0ms +/- 16.7% and 47882.2ms +/- 4.9%
- IE 7 (standalone version, see below): 44726.2ms +/- 4.1% and 42655.2ms +/- 5.0%
- firefox 2 (2.0.0.12): 26025.4ms +/- 4.5% and 25305.0ms +/- 1.1%
- opera 9.27: 14202.0ms +/- 1.0% and 14755.6ms +/- 2.4%
- opera 9.5 (b2, build 9945) produced a number of ‘NaN’s’, but is clearly faster then it’s predecessor
- safari 3.1 (build 525.13): 6759.0ms +/- 1.2% and 6750.8ms +/- 2.0%
- firefox 3 (rc1): 5830.4ms +/- 2.2% and 5765.8ms +/- 1.0%
The MSIE7-results are probably not entirely representative, as I use Tredosoft’s standalone IE7. This is a bit of a hack to have IE7 on my otherwise MSIE6-based system. Moreover my corporate Windows-installation is infested with crapware, notably McAfee OAS and Zonealarm seem to be slowing things down enormously. The codinghorror-tests indeed show significantly better results for this browser, although IE does have serious issues with string concatenation, which should be fixed in IE8.
On the same hardware, but booting in Ubuntu 8.04 (Linux) form my external USB HD (a.k.a. my ‘disktop‘), I got the following results:
- opera 9.27: 15343.2ms +/- 1.1% and 15499.4ms +/- 1.1%
- firefox 3 (rc1, official mozilla build): 5352.6ms +/- 1.1% and 5343.8ms +/- 0.6%
- firefox 3 (b5, included in ubuntu 8.04): 5195.2ms +/- 1.6% and 5240.2ms +/- 1.4%
- konqueror 4: not tested yet,
results will follow later todaycan’t get test to completely run, any KDE-user want to give this a try?
Firefox 3 RC1 seems slightly slower then b5, but maybe the Ubuntu-b5-version is compiled with optimizations? Firefox is also faster on Ubuntu, but the anti-virus-bloat is probably messing with our heads here (although Opera is slower on Linux, go figure).
The general conclusion however; Firefox 3 is a huge step forward as far Javascript-performance is concerned. Users of javascript-heavy web-applications such as Gmail, Google Reader, Zoho Office and Zimbra should benefit enormously from this. It would however be very interesting to perform similar tests with regards to ‘normal page rendering’ (html/css). Does anyone know of such benchmarks?
Are you doing Web2.0 the wrong way?
According to Jakob Nielsen, jumping on the web2.0-bandwagon often implies adding unneeded complexity instead of getting the basics right. I tend to agree; in our quest for sexier, more responsive web-sites and -applications, we seem to easily forget boring stuff such as accessibility and sometimes even usability. How much time did it take you to find your way around the new LinkedIn-UI? Have you tried to use a web2.0-site on a PDA or smartphone? With your keyboard instead of your mouse? Using a screenreader instead of your normal display? Or with JavaScript disabled (I installed the Firefox NoScript-extension to guard against XSS and other JS-attacks)? And if you have ever tried loading Gmail on a slow connection, you’ll surely have noticed that they automatically fall back to their more accessible “Web 1.0”-version?
Lately I’ve been reading a number of interesting articles on this subject and at work we’re carefully applying some Web2.0-techniques as well. Based on that, here are a few suggestions on how to build better websites and -applications:
- Don’t use GWT or Flex unless you’re building a complex desktop-style webapp and if you’re willing to invest in a second “basic html”-version as e.g. Gmail does. Let’s face it, most websites and even -applications do not have the level of complexity that warrants the use these RIA-frameworks.
- Develop your core functionality in “web1.0”-style, using semantic HTML (structure) and CSS (presentation) only and apply your usability- and accessibility-wisdom here.
- Sprinkle JavaScript (behavior) over that static foundation using an established JavaScript-framework to define event-handlers for objects and to modify the content of divs (but test if you can already write to the object, or you’ll get those ugly “operation aborted” errors in MSIE). Give users a chance to opt out of this enhanced version, even if they do have JavaScript enabled. With this progressive enhancement (a.k.a. hijax) you add extra functionality for those people who can make use of it, without punishing users who can’t because of physical or technological impairments. Read more about progressive enhancement on London-based Christian Heilmann’s site.
- Only load your JavaScript-functions when you really need them, creating a kind of stub for methods of an object and only load the real method when it is needed. This technique is dubbed “lazy loading” and can help making your pages load & initialize much faster. To learn more about the concept of “lazy loading” on digital-web.com.
- Use <noscript>-tags if you absolutely have to use JavaScript without having a meaningful object already in place in your static version. Explain what is going on and provide a link to a normal page where the same information or functionality can be found.
Off course these tips won’t guarantee you a perfectly usable and accessible website or -application, but when done right, this will help to get 80% of the way. A good functional analysis and thorough testing, both keeping usability and accessibility in mind, will push you towards 99,99%.
MSIE: operation aborted
Op één of andere site, die misschien wel en misschien niet met mijn werkgever te maken heeft, zagen we vreemde dingen in MS Internet Explorer; tijdens het laden van sommige pagina’s kregen we een lelijke “Operation aborted” error te zien.
De oorzaak: terwijl MSIE (via een trage bedrijfsproxy) de DOM van een zwaardere pagina nog aan het inladen was, probeerde een javascriptje (dat de .update functie van Prototype aanroept) al een DIV te updaten. En blijkbaar slaat Internet Explorer (versie 6 en 7) in dat geval een beetje aan het stotteren.
De oplossing: het uitvoeren van de element.update uitstellen tot de DOM geladen is. MSIE (6 en 7) hebben daar blijkbaar geen kant-en-klare functie voor, maar op het internet vind je daar wel oplossingen voor.
Zo, nu dat achter de rug is, ga ik een huis kopen! 🙂