Amit a Prepackról tudni lehet…
Ismét a Facebook újdonságától robbant a Twitter web fejlesztőket összefogó szeglete, bemutatták a Prepack eszközüket. Az ígéretük pedig meglehetősen ambíciózus, összenyomják és számos módon optimalizálják a JavaScript kódot, így gyorsítva a futtatást. Nagyrészt legalábbis.
Miért van erre szükség?
Se vége, se hossza az elmúlt két évben azoknak az elemző cikkeknek és méréseknek, amelyek a modern web fejlesztés problémáit taglalták. Ugye a függőségek többszörösen problémásak.
Nézz csak rá egy React vagy még inkább egy Angular “Hello World” appra. Először az npm install után csodálkozol el, hogy egy teherautónyi függőség jön le. Másodszor a build folyamat végén, a bundle méretét nézve, illetve még jobban belenézve. Sokszor felmerül a kérdés, hogy mire kell ez a rengeteg minden.
Felhasználói oldalon aztán duplán problémára lehet futni, a nagy méretű kódot előbb letölteni, majd futtatni is tudni kell. Ezeken a pontokon minden varázslat és erőfeszítés ellenére is könnyen teljesítmény problémákkal találhatja magát szemben az egyszeri fejlesztő. Mobil esetében pedig könnyen lesz a bolhából elefánt, ezek a gondok hamar a többszörösükre nőhetnek. Egyáltalán nem ritka a lassúcska készülék és csiga hálózat kombinációja.
Workaround készült az évek során nem egy, sőt néhány ezek közül meglehetősen széles körben el is terjedt. Csak néhány példa ezek közül, UglifyJs, WebPack, továbbá az Angular 2 AOT fordítója majd el fog. Ezeket a build folyamatba illesztve segíthetnek összenyomni a méretet.
Nem új az ötlet…
A PrePack bizonyos szempontból sokkal ambíciózusabb célokat tűzött ki maga elé. Habár az irány nem kifejezetten új, elvét tekintve két elődöt is meg lehet jelölni.
Google Closure fordító
Nem egy új dolog, nagyon nem, már legalább 10 éve frankón működik. A legtöbb saját szolgáltatásuk esetében aktívan használják is azt, a Google Maps esetében egészen extrém, amit kihoztak belőle.
Ha nem ismered a Closure fordítót itt lehet olvasni róla. Sőt, nagyon egyszerűen ki is lehet próbálni.
Feltételezésem szerint cégen kívül a viszonylagos komplexitása miatt nem terjedt el különösebben. Egyelőre legalábbis, mert jó esély van, hogy újra reflektor fénybe kerüljön. Ugyanis az Angular csapat jó ideje aktívan kísérletezik a használatával. Az eredményeik pedig több mint meggyőzőek. Érdemes megnézni erről Martin Probst előadását a tavaly őszi AngularConnect-ről.
LLVM fordító keretrendszer
Habár ez alapvetően natív és többek C nyelvhez készült. Viszont elvében nagyon hasonló dolgokat művel a háttérben, fordítás közben.
Ismét visszatérve, feltehetőleg ezek az eredmények győzték meg a Facebook / React csapatot is az inspriálódásról. Van egy pár démon náluk is házon belül, amiket ideje lenne leküzdeni… gondolok itt a stateless componentekre, azoknak kifejezetten jót tenne egy ilyen tool bevezetése.
Hogyan működik?
De térjünk végre a lényegre, milyen trükköt tud a Closure és mit fog eltanulni tőle a PrePack? Röviden egy VM-ről van szó. Build időben futtatja a kódot, kiszűri potenciális problémákat, és számos módon optimalizál a gyorsabb és hatékonyabb futtatás érdekében.
Számos ügyes trükköt tartogat a tarsolyában:
- Nem használt függőségek eltávolítása, tree shaking módszerrel.
- Halott kód-utak elminiálása.
- Hívási láncok kilapítása.
- Függvények és kifejezések kifejtése inline.
- Optimalizálás típusok alapján.
A hivatalos oldal példái elég beszédesek:
Sőt, Jason Miller példája Twitterről még annál is inkább:
De menjünk még ennél is tovább. Mutatok még egy piszok meggyőző példát. Egy a webpack fordítás után 928 soros kódot mindössze 1 sorra nyomja össze. A részletekért klikk az alábbi postra.
Tudtuk, hogy valami készül…
Jobban belegondolva volt ennek előjele. Érdemes visszapörgetni a tavaly react-europe-ra, ott épp ennek egy kezdetlegesebb változatáról szólt Sebastian McKenzie lightning talkja.
Magyarán megy már egy ideje a kísérletezés.
Meglesznek a maga hátulütői
A Closure fordítóból kiindulva a következőkre lehet számítani:
- Jelenleg csak JavaScripttel működik. TypeScript támogatás nincs, egyelőre legalábbis.
- Viszonylag komplex a működése, ezért alaposan érteni kell hozzá, máskülönben kellemetlen meglepetéseket okozhat.
- Az is megtörténhet, hogy a bundle nem fog működni, ez pedig kellemetlen. Simán lehet, hogy nálad működik, de productionben fejre áll valami.
- Nem mindig lesz gyorsabb.
Néhány kósza gondolat…
Gondolkodjunk kicsit előre. Azért lesz ez jó dolog, sőt a Closure már most is az, mert így számos esetben másodlagos lesz a keretrendszerek mérete. Az a része marad meg, amit használunk, így az egész kevésbé lesz az téma. Gyorsabban letöltődik, gyorsabban betölt és fut. Persze továbbra is rengeteg függőség marad, nagy méretben, de ez az ügyes workaround ezt elrejti.
Kicsit tágabb kontextusban gondolkodva, kicsit átrendezheti a toolok körül a dolgokat. Abban majdnem biztos vagyok, hogy a jól megszokott uglify lépést kiváltja majd a bevezetése után. A webpack és tree-shakinggel már jobb kérdés, ott inkább közös működést látok elképzelhetőnek a váltás után.
A Facebook toolingjának szempontjából nézve pedig meglehetősen merész új távlatokat nyithat. Példának okáért a Babel idővel egy VM (is) legyen. Könnyen meglehet, hogy ez nem is olyan extrém gondolat, ha épp Sebastian Markbåge veti fel tweetjében.
Mikor használhatom production
A Google Closure compiler mögött van kb 10 év munka, idő lesz ezt beérni. A Facebook mérnökei figyelmeztetnek mindenkit, hogy ez a mostani még erősen WIP verzió.
Kísérletezni okés, bugokat jelenteni, esetleg javítani is őket, de productionben erősen ellenjavallott. Feltehetőleg valamikor jövőre, ennyi idő legalább kelleni fog rá.
