Plaxo radí jak na rychlejší JavaScript
Joseph Smarr z Plaxo (jeden z rychle se rozvíjejících sociálních serverů) měl přednášku na téma High-Performance JavaScript: Why Everything You've Been Taught is Wrong.
Je vždy zajímavé poslechnout si téma zpracované od někoho, kdo mu právě věnoval několik měsíců. Pro ukázku vybírám pár zajímavých bodů z přednášky. Některé jsou pro mne překvapující, ale předpokládám, že Joseph po té rychlostní optimalizaci celého Plaxa ví, co tvrdí:
- Minimize dependency on third-party library code
- Draw UI as late as possible
- Put CSS at the top of your page and JS at the bottom
- Load / draw your app in stages (lazy, on-demand)
- Use onmousedown instead of onclick (~100msec faster!)
- Avoid DOM manipulation; use innerHTML and array.join("")
- Do DOM manipulation off-DOM, then re-insert at the end
- Profile like crazy
- Firebug is your friend
Pokud vás téma zajímá, projděte si slidy z přednášky, vážnější zájemci mohou zhlédnout video (v první třetině se Joseph soustředí na představení webu Plaxo, tu můžete přeskočit, rychlostní optimalizace přijde na řadu hned po té).
(via mykzilla)
Vše z Blog Root.cz
Ten onmousedown místo onclick, to bude nějaká opičárna, ne? Není těch sto milisekund jen doba, než uživatel pustí tlačítko myši? Mně osobně navíc přijde maličko divný, když něco funguje už na mousedown, jsem ze všech UI zvyklý na onclick. [P.S. Zhlédnout film/video, shlédnout na někoho ze třetího patra.]
[1] Myslím, že se jedná o psychologický trik a nikoliv výkonnostní, zej. když o pár slidů dál je "Cheat when you can". Ale v případě, že tu je tah na "nejrychlejší aplikaci" (a Joseph ho evidentně má), tak to může hrát ve spojení s dalšími triky roli. Při používání Plaxa jsem si neobvyklého chování nevšiml. Aplikace je rychlejší a v tom je ten trik.
První doporučení mi přijde pro běžný vývoj nereálný. Pokud bych se rozhodl používat JavaScript bez Prototype nebo jQuery, tak okamžitě bude čas strávený vývojem řekněme 3x delší.
[3] Pamatuj, že obě tyhle knihovny jsou módní trend a jejich úkol je v zásadě jen zastřít některé rozdíly mezi prohlížeči a do pěkného pozlátka zabalit nepřítulný DOM. Na obojí zkušený JS kodér stačí.
[3] [4] Suhlasim s Metom.
Myslim si, ze niektore triky su tu s nami uz dlhsiu dobu, len sa pretavili do prostredia webu.
Misty mi ta prezentace pripada jako 101 rad, jak udelat neudrzovatelny kod.
Ale velmi trefne podotknuti je to, ze prohlizece jsou dnes tlaceny do veci, na ktere nejsou moc dobre stavene.
6> Přesně to jsem chtěl napsat. Je strašně pěkný, že JavaScript a prohlížeče umí to či ono, ale kdybych to pak měl na nějakém větším projektu všechno vyhodit oknem… brr.
[4] Samozřejmě, stejně tak zkušený programátor stačí na udělání webu v čistém Ruby (PHP, Python - doplňte dle osobních preferencí), ale pokud s tím nechce trávit moc času, tak sáhne po nějakém frameworku. Módní trend možná, to ale nic nemění na tom, že díky nim se může do zajímavějších věcí pustit i člověk, který nemá čas/peníze/zkušenosti.
[8] Ale tady se nikdo nepře o užitečnosti/neužitečnosti těchto knihoven. Jsou šikovné a na ledacos se hodí a je ostatně i móda je dnes používat. Pouze tvrdím, že věta "První doporučení mi přijde pro běžný vývoj nereálný." je neoprávněné tvrzení.
Spravne, je treba rozlisovat mezi snadnosti vyvoje, kdy se pouzije uz hotrovy, obecny, ale neoptimalni framework, nebo se udela jen to, co je opravdu potreba. Rozdil ve velikosti (a obcas i vykonu) muze byt az o rad - pamatuju, jak jsem jednu silenou Javascriptovou knihovnu zahodil, protoze byla schopna zrat nekolik sekund 100% vykonu i na dvogigahercovych strojich (je pravda, ze vykresloval sakra velkou tabulku). Moje verze to same stihla za polovinu doby, desetine velikosti kodu a vetsinou s mnohem nizsi zatezi (uzkym hrdlem bylo spis posilani XHTTPRequest dotazu serveru a cekani na zpetnou odezvu, protoze IE nezvlada prilis velka POST data najednou). Zakaznik byl nadsen, jeniom se mu nelibilo, ze uz se mu tabulka nevykresluje v prohlizeci "nazivo" :-)
[9] Říkám tomu spíš čirý pragmatismus - použití knihoven mi přináší hmatatelný výsledek, ne dobrý pocit, že jsem IN.
Bohužel všichni teď chtějí weby nejlépe zadarmo a včera bylo pozdě. Neznám moc lidí, kteří by dokázali s čistým JavaScriptem například to samé co Prototype + script.aculo.us nebo jQuery + Interface. Tedy přesněji řečeno neznám žádné, což neznamená, že neexistují, ale představovali by určitě významnou část v rozpočtu projektu. Možná jsem to měl upřesnit a zaměnit "běžný vývoj" za "vývoj malých projektů", jak jsem to myslel.
Jinak já jsem si všiml, že se tu nikdo nepře o jejich užitečnosti ;-) Jenom jsem zašel dál a tvrdím, že je dost situací, kdy nepoužití podobných knihoven je nerozum - buď tím okrádám sebe o čas, zákazníka o peníze nebo nejčastěji obojí.
[11] To my jsme zašli dokonce tak daleko, že spekulujeme nad tím zda v případě, kdy je z nějakého důvodu rychlost aplikace naší prioritou (ano, přesně a konkrétně v tomto případě) nejsou takové knihovny naším nepřítelem číslo jedna. Čistý pragmatismus 8-)
[12] Uznávám, na tomhle pragmatismu taky něco bude ;-) Dobrá otázka je jestli potom není nepřítelem číslo nula zvolený nástroj, protože HTML+JavaScript na některé věci není stavěné, jak už tu nikdo zmínil. Což už by bylo ale asi na úplně jinou debatu.
Knihovny jako jQuery hlavně ukazují rozdíl mezí tím, vyvojáři skutečně chtějí, a co jim nabízí uměle vytvořené API např. DOM API. Bylo by fajn, kdyby v duchu projektu HTML5 vzniklo i DOM5, které by implementovalo funkcionalitou podobnou JavaScriptovým frameworkům přímo do prohlížečů.
[14] DOM5 by se skutečně hodil, ale zatím na to nejsou lidi. Nicméně věřím, že na něco takového jednou taky dojde. Možná by na ledacos stačilo rozšíření E4X (i když je to taky docela složitý standard) včetně jeho používání i na prosté nevalidní HTML.