Végre: leváltotta a Flash-t a Prezi
Hosszú éveken át tartó, zsákutcáktól sem mentes fejlesztés eredményeképp JavaScript-HTML alapokon írta újra prezentációs szoftverét a Prezi - jelentette be a cég. Első körben az új technológia a prezentációk lejátszásánál mutatkozik be.
Sikerült megoldani végre a Prezi fejlődését hosszú ideje visszafogó műszaki problémát, az Adobe Flash helyett JavaScript-HTML technológiára áll át a prezentációk lejátszása - jelentette be a Prezi, Halácsy Péter műszaki vezérigazgató csodálatosan megírt, öniróniával fűszerezett blogposztjában.
A fejlesztés többször is (tanulságos) zsákutcába futott, a sok éve húzódó projekt azonban végre a célegyenesbe fordult, a prezentációk lejátszásához már nincs szükség Flash-re, az alapértelmezett lejátszó már az új technológiát használja. Első körben csak ez, vagyis a lejátszó kapja meg a JavaScript-megjelenítést, az prezentációk összerakása továbbra is a Flash-alapú szerkesztőfelületen zajlik. Halácsy bejegyzése szerint ugyanakkor már készül a szerkesztőfelület átültetése az új motorra, egyelőre azonban nem tudni, hogy ez mikor állhat csatasorba.
A zoom volt a probléma
A Prezi már korábban is sűrűn beszélt arról, hogy az egyedi, a zoomolást előtérbe helyező prezentációs formátum portolása milyen komoly műszaki akadályokat vet fel, a natív iOS-es alkalmazás elkészítése sem volt gyerekjáték. A megvalósításhoz ugyanis olyan megjelenítő rétegre van szükség, amely a felhasználók által feltöltött anyagokból (fotók, videók) illetve a szövegekből pixelpontosan megjelenített, korlátlanul zoomolható prezentációt hoz létre, pixelesedés nélkül. Ilyen megjelenítő réteg azonban a projekt indulásakor, 2010-ben nem létezett és most is csak kezdemények, félkész megoldások állnak rendelkezésre.
A probléma megértésére Halácsy a betűk platformfüggő renderelését hozza fel egyik példaként. A különböző operációs rendszerek ugyanis egészen eltérő módon jelenítik meg az (amúgy azonos betűtípussal és -mérettel) megadott szöveget, emiatt az elforgatott, bezoomolt betűk elhelyezése, mérete nem azonos. A problémát a Prezi úgy oldotta meg, hogy saját betűrenderert épített, amely pixelpontosan ugyanazt a képet adja mobil platformokon, Windows-on és OS X-en is. A renderer C-ben íródott, ez az Emscripten segítségével fordul le JavaScriptre, így tud böngészőkben futni.
A Flash nagy erőssége a vektorgrafika volt, ezért is esett erre a platformra elsőként a Prezi választása az induláskor. A weben azonban hosszú ideig a bitmapek uralkodtak, a vektoros grafikai eszközök csak nemrég indultak fejlődésnek (például az SVG). A bejegyzés szerint a meglévő megoldások nem voltak eléggé jók a Prezi céljaira, ezért a fejlesztők fogtak egy meglévő projektet és kiegészítették saját, a megoldandó feladathoz passzoló kóddal. A választás a Mozilla Shumway vektoros rendererjére esett, amely egy független, JavaScript-HTML futtatókörnyezet Flash-alkalmazásokhoz. Ehhez készített a hazai cég egy, a levágást (clipping) megvalósító részt, amellyel a nagyon nagy méretű vásznak (canvas) is kezelhetővé váltak. A bejegyzés szerint a fejlesztés a Mozilla fejlesztőinek is megtetszett, hamarosan bekerül a Shumway kódjába.
A megjelenítés önmagában még nem sokat ér, ha az átvezető animációk nem folyékonyak. A JavaScript pedig nem sebességéről híres, ezért a felhasznált kódot két fejlesztő négy hónapon keresztül csiszolta, míg a nagyméretű vásznak animációja is elfogadható sebességűre gyorsult. Szerencsére az új technológiákban a flash-es tapasztalatok egy része újrahasznosíthatónak bizonyult, így bizonyos korábbi optimalizációk itt is működtek.
A fejlesztés ezen szakaszában a mérés és a tesztelés került fókuszba, hogy az optimalizációkról azonnal visszajelzés érkezzen a készítőkhöz. Ehhez a cég saját eszköztárat épített, amely a kódbázisból automatizáltan elkészítette a webes alkalmazást, majd 7 böngészőn tesztelte azt. A rendszerrel elérhetővé vált az apró változások hatásának követése is, különböző platformokon, különböző böngészőkben, automatikusan. Így derült ki például, hogy a kisméretű, de komplex képek gyorsítótárazása dobja meg leginkább az animáció sebességét.
Nehéz a JavaScript
Nem véletlen az sem, hogy a Prezi és partnerei örömmel hívták már kétszer Budapestre a nagyméretű JavaScript alkalmazások fejlesztőit, az Mloc.js konferencia keretében. A konferencián a millió soros kódú JavaScript-webappok fejlesztési-fenntarthatósági problémáiról beszélgettek a terület legjobb szakemberei, és történetesen ilyen problémákkal küzdött a Prezi is a készülő alkalmazás kapcsán.
Az első próbálkozás - nem lett termék belőle.
A JavaScript ugyanis nem nagy alkalmazásokhoz, hanem egyszerű scriptekhez készült eredetileg, emiatt a valóban nagy kódbázissal rendelkező alkalmazások fenntartása nehezebb, mint mondjuk C++-ban vagy Javában. A Prezi itt is elegáns (és egyedi) megoldást választott, az alkalmazást ugyanis nem JavaScriptben, hanem Haxe-ben írják, az elkészült kód pedig optimalizált, böngészőben futó JavaScriptre fordul le, így lesz kompatibilis az elterjedt böngészőkkel. A híresen soknyelvű Prezi emellett TypeScripttel és (a fent már említett) Emscriptennel is foglalkozik, nem csoda, hogy házon belül már komoly (megkockáztatható: világszínvonalú) compile-to-JS kompetenciát épített ki a cég.
Miért csak most?
-teszi fel a kérdést Halácsy. A válasz prózai, tavalyig nem ez volt a fejlesztési prioritás. Ugyan a JavaScript-megjelenítőn a munka már 2010-ben elkezdődött, csak tavaly vált valóban fontossá ez a fejlesztés. Az első zsákutca egy HTML5 és DOM+CSS3 motor fejlesztése volt. A '10-es évek elején nagyon menő technológiák azonban alapvetően alkalmatlannak bizonyultak a Prezi céljaira. Működő prototípust sikerült előállítani, de egy idő után látszott, hogy ebből kiadható termék nem lesz.
Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.
A második próbálkozás egy közös, keresztplatformos alkalmazás kialakítására irányult, a cég reményei szerint így létrejött volna egy közös kódbázis, amelyből az Android- és iOS-natív alkalmazások illetve a webes-böngészős verzió közösen származtatható le. Az ilyen közös alap hatalmas könnyebbséget hoz, csupán egy kódbázist kell fejleszteni, karban tartani, az eredmények pedig szinte azonnal jelentkeznek minden felhasználónál, platformtól függetlenül. Nem utolsó szempont, hogy az egységes megjelenítő motorral garantált lett volna a platformfüggetlenül pixelpontos megjelenítés is.
Egy év után derült ki, hogy ez az út is járhatatlan, a közös kódbázis egy "nagyon rossz ötlet". "Hosszú távon a népszerű platformok bevett folyamatait és eszköztárait használva jobb minőségű terméket és boldogabb fejlesztőket kapunk. Ne fantáziáljunk kevéssé ismert eszközökkel egyszer megírt közös kódbázisról. A fejlesztők tulajdonképpen szeretnek kódot írni." - foglalja össze idézhető formában Halácsy a tanulságot.