15 komentáře “Zrychlete svoji webovou aplikaci pomocí Partial Update

  1. Zpětný odkaz: Myšlenky dne otce Fura » Blog Archive » GeeCON 2011

  2. Zpětný odkaz: Myšlenky dne otce Fura » Blog Archive » Čtvrtý rok Myšlenek Otce Fura

  3. @David @Peter … přesně tak. Pro GoogleBot a další je non-javascript verze plnohodnotně funkční. Partial-update je v podstatě add-on pro klienty, kteří ho umějí interpretovat (což je většina).

  4. Neni „partial update“ trosku kontraproduktivni z hlediska pageranku stranky ?
    GoogleBot je schopny parsovat i URL, ktere je v ramci javascriptoveho bloku, ale
    jakym zpusobem, pak vyhodnoti takovy fragment stranky ?

  5. @Grails Ano, proti non-javascriptové verzi by to bylo mírně (nebo spíš „nepatrně“) složitější.

    Na příkladu se seznamem poptávek – stránka by se rozdělila na template celé stránky, který by „includoval“ template pro seznam poptávek. Takže soubor celaStranka.gsp by obsahoval následující fragment:

    Samotnému seznamu poptávek by odpovídal druhý soubor – _poptavky.gsp. Tohle ještě nic nestojí.

    Controller pro práci se stránkou by pak vedle metody pro získání dat celé stránky obsahoval ještě speciální metodu navíc pro obsoužení AJAX requestu na obnovu seznamu. Něco v tomto stylu:

    class PoptavkyController {
    def refreshList = {
    …získání seznamu…
    render(template: „/poptavky“, model: [list: list])
    }
    }
    To už je práce navíc, ale pořád je to dobře zvladatelné.

    Nechci tu vystupovat jako skalní zastánce Grails (teprve se je učím). Zmínil jsem Grails jako příklad ne-komponentního frameworku, ve kterém se dá partial update taky dobře implementovat.

  6. @optik Právě nad tím jsem přemýšlek, když jsem na letošním WebExpo slyšel o novém AJAXu v Nette vyprávět vývojáře okolo mě. Vzhledem k tomu, že jsem Javista, jsem PHPkové přednášky programově vynechával, ale řada rysů AJAXových aktualizací mi přišla hodně podobná.

    K té tvé vizi. Osobně si nemyslím, že partial update vymizí. Možná bude na webu čím dál více „desktop like“ aplikací, ale pro naprostou většinu webových aplikací se tento styl nehodí. Navíc i když se o RIA stále mluví, nějaká masivní adopce stále nikde. Dosud, myslím, není vyřešena indexace obsahu vyhledávači, přístupnost aplikací je diskutabilní, tlustí klienti (Flash, Silverlight, JavaFX) mají každý celou řadu svých vlastních problémů atd. atd.

    JavaScriptové knihovny (ExtJS, GWT a jim podobné) se zase velmi špatně customizují a mají tendenci vypadat na každé implementaci stejně – což je něco, co většina zákazníků na internetu nechce (pokud se jen nesnaží portovat své stávající desktop aplikace na web).

    Webů, které by vypadaly jako klasické „old school“ weby, bude sice pořád dost, ale zdá se mi, že stále narůstá podíl webu s velkým podílem dynamického obsahu. A právě partial update je pro tyto weby jako dělaný. Masivně se podle mého nepoužívá proto, že pro vývojáře není jednoduše uchopitelný nebo znamená navýšení pracnosti na projekt.

    Uvidíme kam bude vývoj v budoucnosti směřovat, ale implementace partial update na takových aplikacích jako je Twitter (i když zde probíhá komunikace přes JSON) nebo Facebook mě zatím naplňují optimismem.

    P.S.: komunikace přes JSON, kterou zmiňuješ je samozřejmě validní varianta – nicméně vyžaduje mít aktualizační rutiny obnovující DOM napsané v JavaScriptu a to je zase práce navíc, které jsem se chtěli vyhnout. Současné řešení má pro nás minimální náklady na implementaci, proti klasické non-javascriptové verzi. V tom právě vidím velkou výhodu, která nám i interně pomůže tuto techniku posadit na víc webů, které realizujeme.

  7. partial update dost pěkně implementuje pomocí komponent v Čechách populární php framework Nette, včetně funkce bez javascriptu, podpory zajaxovatění a snippetů – možnost označit jen část komponenty, která se bude ajaxovat. Je to v podstatě implementované stejně jak to popisuje článek.

    Osobně ale nejsem zastánce tohoto přístupu, spíš poslat ajaxem json (třeba seznam článků na dané stránce) a js na klientovi updatne dané elementy, na serveru se to automaticky pozná a zavolá se jiná obslužná action. Obsluha a podpora non-js řešení je ale o trochu pracnější.

    Já trochu doufám, že takovýchto webu s ajax komponentami bude ubývat a weby se začnou více dělit na desktop like, které budou komplet v js a web like, které zas budou jako klasická webová stránka a tam pak pro partial update bude čím dál méně uplatnění.

  8. @Martin Beránek: jestli je to tak, pak se mi zdá, že na serveru se zbytečně plýtvá výkonem na vyrenderování celé stránky, když je klientovi servírovaná pouze část – to mě u JSF docela překvapuje, protože tam by měli poměrně přesně vědět, co je pro jakou komponentu třeba (JSF je postavené nad patternem ViewHelper pokud vím)

    @Tomáš Piňos: jestli si to vysvětluji správně, tak v případě Grails, musím na serveru počítat s tím, že klient může požadovat pouze „partial update“ odpověď a renderovat mu v takovém případě jen šablonu odpovídající danému „DIVu“? Tím jsou sice veškeré kvality partial update zachovány, ale vynakládá to náklady na vývoj, kdy musím specielně AJAX režim opečovat. Pochopil jsem to tak správně?

  9. Co se týká toho JSF: v JSF2 se partial update standarne pouziva pro vsechny AJAXove stranky. Podle toho co jsem četl, se na serveru vždy vyrendruje kompletní stránka s odpovědí (ať už to je normální request nebo ajaxový). Pokud je to ajax request, tak se z toho vyřízne ta správná část domu a pošle se na klienta jenom ta.

  10. Statistiky browserů s vypnutým JavaScriptem se dost různí a prý nejsou ani moc přesné (díky proxy serverům, indexovacím robotům atd.). Různí se, ale většina hovoří o 2-4%. Sehnal jsem pár statistik, které jsou alespoň trochu aktuální:

    http://www.w3schools.com/browsers/browsers_stats.asp
    http://www.woopra.com/forums/topic/track-users-with-javascript-disabled
    http://statcounter.com/project/standard/system.php?account_id=397157&login_id=1&code=ba7c7043e25ecfacd62fc4d67fc2f508&guest_login=1&project_id=2368090

    Obecně řečeno – tím, že stránky jsou „JavaScript only“ komplikuješ práci:

    – indexovacím robotům (ty JS pokud vím neinterpretují)
    – uživatelům s nestandardními (starými nebo specifickými browsery)
    – uživatelům přistupujících pomocí specifických zařízení (screen readerům, některým mobilním zařízením atd.)

    Otázka je, jestli si to můžeš u svých web stránek dovolit. Na intranetu asi ano, u e-shopu rozhodně ne.

    Velmi mne oslovila reakce AdrianH v na této stránce: http://uxexchange.com/questions/3360/should-we-really-be-concerned-with-javascript-being-disabled-anymore-disregardin – s ní se naprosto ztotožňuji. Na internetu není žádné procento dost malé – pořád tím vylučujete tisíce potenciálních uživatelů / zákazníků vašich stránek.

  11. Moc pěkný článek +1!

    Nutí mě přemýšlet nad tím, jak velký problém je, když web nefunguje při vypnutém Javascriptu v browseru. Píšeš, že se to týká asi 2-3% uživatelů, to je jen odhad nebo máte nějaké měření? Zkusil jsem si vypnout Javascript (v Chrome) a vůbec mě nepřekvapilo, že „New Twitter“ vůbec nenaběhne. Je to #fail nebo ne, když stránka v dnešní době vůbec nepočítá s tím, že Javascript může být vypnutý?

    Pokud si třeba Twitter (ať už úmysleně nebo omylem) dovolí ignorovat část uživateů, kteří Javascript nemaji (a v jejich případě i ty 2-3% bude velké číslo), tak se mi zdá, že by možná bylo lepší vůbec se renderováním HTML na serveru nezabývat a posílat klientovi (browseru) jen JSON, ať si s ním udělá co chce (třeba z něj vyrobí HTML), jedna z výhod takového přístupu je, že data lze snadno konzumovat i jinými JSON friendly klienty. Pokdu jsem to dobře pochopil, tak přesně touto cestou se vývojáři, kteří pracovali na „New Twitter“ vydali: http://engineering.twitter.com/2010/09/tech-behind-new-twittercom.html