Akhir-akhir ini di waktu luang, saya sedang senang ngoprek HTML5. Kesimpulan sementara saat ini: HTML5 belum bisa memenuhi semua yang dijanjikannya terutama dalam hal portabilitas dan kecepatan. Sekarang ini lebih sering teknologi lain (misalnya Flash atau kode native) lebih cocok.
Tulisan ini berdasarkan pengalaman saya dan berlaku saat ini. Saya sendiri sudah mulai mengembangkan aplikasi dengan HTML5, bahkan sudah dijual di AppWorld (http://appworld.blackberry.com/webstore/vendor/9151/?lang=en, yang dibuat dengan HTML5 adalah MultiCounter, Four Colors, dan Baby Coloring Book), dan saya berharap dalam beberapa tahun ke depan HTML5 akan semakin baik.
HTML5 didengungkan sebagai sesuatu yang mudah, cepat dan portabel. Dalam kenyataannya, jika aplikasi kita sederhana (hanya memakai sebagian kecil fitur HTML5), maka hal itu benar, tapi jika aplikasi kita sudah mulai kompleks, maka hal-hal tersebut tidak lagi benar.
Pertama adalah masalah portabilitas: HTML5 tidak sepenuhnya portabel. Ada beberapa rendering engine (WebKit, Opera, Firefox). Setiap rendering engine memiliki keanehan (quirk) masing-masing. Andaikan kita hanya membatasi diri di mobile device, hampir semua memakai WebKit (kecuali Windows Phone yang memakai Trident). Tapi meski sama-sama webkit, featurenya bisa berbeda.
Saya tidak akan menjelaskan panjang lebar mengapa fiturnya bisa berbeda, karena sudah ada yang menulis posting blog yang akan bisa memberi penjelasan yang lebih detail, menjawab pertanyaan:
“Since browser Foo and browser Bar are using the same WebKit engine, why do I get different feature set?”.
http://ariya.blogspot.com/2011/06/your-webkit-port-is-special-just-like.html
Saya ambilkan satu contoh penting: animasi yang mulus. Untuk membuat animasi yang mulus kita bisa memakai CSS3 Animation/Transform (animasi kompleks dengan timer dan mengubah property left dan top tidak mulus, kecuali di desktop browser di komputer yang cepat). Sayangnya support CSS animation ini berbeda-beda di setiap browser, ada yang hardware accelerated dan ada yang tidak.
Hasilnya animasi yang tampak mulus ketika dicoba di browser desktop (yang hardware accelerated) jadi patah-patah. Android sebelum versi 3 tidak menggunakan hardware acceleration sama sekali. Jika dilihat di pasar, saat ini (Juni 2012) lebih dari 80 persen device masih menggunakan android sebelum 3.0.
Sumber: http://developer.android.com/about/dashboards/index.html (Diakses 24 Juni 2012)
Bahkan di platform yang mendukung hardware acceleration, transformasi yang bisa dilakukan secara konkuren juga berbeda-beda. Jadi animasi sederhana bisa sangat cepat (misalnya hanya menganimasikan posisi), tapi jika kita buat menjadi lebih kompleks (misalnya menganimasikan posisi dan warna serta rotasi sekaligus), jadi lambat
Jadi sudah jelas bahwa dalam masalah portabilitas, HTML5 ini masih jauh dari janjinya. Di desktop ada banyak sekali browser, dengan berbagai versi, masing-masing memiliki rendering engine sendiri. Di mobile device, browsernya meskti memakai webkit yang sama, tapi daftar feature yang tersedia berbeda-beda.
Dalam hal kecepatan: secara umum kecepatan JavaScript masih jauh dari Flash. Tapi pertama perlu diketahui dulu: meski rendering engine-nya sama-sama webkit, tiap device memiliki javascript engine yang berbeda . PlayBook, Nokia, dan beberapa versi Android memakai JavaScriptCore (JSC), sementara itu iOS memakai Nitro, sedangkan beberapa versi Android lain memakai V8.
JavaScript engine yang berbeda memiliki fitur yang berbeda dan kecepatan yang berbeda. Misalnya beberapa aplikasi saya banyak memanipulasi array. Jika JavaScript Typed Array didukung, maka speednya bisa sangat tinggi, sayangnya untuk saat ini itu belum banyak didukung (hanya Android 4.0 ke atas yang mendukung ini), bahkan secara umum hanya 56% browser yang mendukung fitur ini:
Sumber: http://caniuse.com/typedarrays (24 Juni 2012)
Untuk Anda yang belum pernah memakai Typed Array JavaScript, tergantung implementasinya (tergantung browser dan JavaScript enginenya), memakai typed array bisa puluhan kali lebih cepat dari array biasa (http://blog.n01se.net/blog-n01se-net-p-248.html).
Dua aplikasi yang terbit di appworld (Four Colors dan Baby Coloring Book) memakai manipulasi piksel untuk mengganti warna bagian image. Manipulasi ini dilakukan menggunakan array biasa (untyped) karena meski PlayBook mendukung typed array, tapi Canvas di Playbook belum mengembalikan Uint8ClampedArray, masih mengembalikan CanvasPixelArray (Buat yang belum tahu bedanya: http://hacks.mozilla.org/2011/12/faster-canvas-pixel-manipulation-with-typed-arrays/).
Hasilnya manipulasi image sangat lambat. Sebagai workaround, saya memotong gambar jadi beberapa bagian supaya lebih cepat dimanipulasi. Trik lain yang bisa dipakai dalam contoh aplikasi saya adalah menyimpan semua kombinasi warna untuk setiap bagian image, tapi ini akan memakan memori yang besar. Perhatikan juga bahwa saya memakai trik agar pewarnaan terlihat seperti diwarnai dengan pensil warna. Info mengenai game tersebut saya tulis di sini: http://blog.compactbyte.com/2012/06/05/aplikasi-untuk-jonathan/
Sebagai catatan: ada beberapa solusi lain untuk masalah yang saya hadapi, tapi semuanya merepotkan. Cara pertama adalah menggunakan SVG (ada metode untuk memfilter dan mengganti warna SVG), tapi karena input saya adalah PNG, maka perlu dibuatkan konverter khusus, plus tiap region harus dipisahkan manual. Cara lain adalah menulis kode pewarnaan dalam Action Script atau native code dan dilink secara khusus. Tapi karena pendekatan yang saya pakai sudah acceptable maka saya biarkan saja memakai pendekatan itu, walau sebenarnya masih belum puas 100% karena di Baby Coloring Book, gambar pertama yang diload akan butuh waktu beberapa ratus milidetik, tapi gambar berikutnya akan cepat.
Untuk Anda yang penasaran dengan kecepatan manipulasi piksel canvas, silakan coba URL ini:
http://www.html5rocks.com/en/tutorials/canvas/imagefilters/
Di Desktop, Anda akan melihat bahwa itu cukup cepat (tapi terlihat ada delay, dan jika imagenya lebih besar, delaynya akan sangat terlihat). Di kebanyakan mobile device, manipulasi bisa sampai dalam orde detik (bukan milidetik). Coba juga bedanya di berbagai browser. Anda bisa membandingkan ini dengan kecepatan manipulasi image di URL tersebut dengan editor image berbasis Flash (misalnya editor gambar yang dipakai di Google Plus).
Kesimpulan saya: untuk saat ini HTML5 masih belum cukup matang, tapi saya sudah mulai mengembangkan dengan HTML5 untuk mengetahui batasan-batasannya. Jika saya diminta membuat aplikasi yang sekedar menggunakan form dan sedikit animasi, atau aplikasi yang interaksinya terbatas, maka HTML5 ini sekarang sudah lebih dari cukup.
Aplikasi yang butuh banyak komputasi, manipulasi image, dan animasi yang bagus masih kurang cocok dikembangkan dengan HTML5, apalagi jika targetnya adalah mobile device. Bahkan Google yang punya Google Chrome (yang kecepatannya biasanya sangat bagus dibandingkan browser lain), tidak menggunakan editor image berbasis JavaScript, tapi berbasis Flash.
Jika para pembuat browser bisa sepakat untuk mengimplementasikan standar yang sama dalam waktu yang bersamaan dengan performansi yang baik, maka hal itu akan mempermudah hidup programmer.