Hlavní navigace

Názor k článku Accelerated Mobile Pages (AMP): Proč vlastně vznikly a jaké mají háčky od unplugged - "CSS nesmí být v externím souboru" To znemožňuje sdílet...

  • Článek je starý, nové názory již nelze přidávat.
  • 16. 9. 2018 20:46

    unplugged (neregistrovaný) ---.net.upcbroadband.cz

    "CSS nesmí být v externím souboru"

    To znemožňuje sdílet CSS mezi stránkami. Společné části CSS se tak budou načítat pokaždé znovu


    "Žádný vlastní JavaScript"

    Deklarativní programování má svá omezení a některé věci v tom elegantně neuděláte.
    U složitějších stránek vás čeká programování založené na řetězcích, kterými je celý "kód" propojen.
    Magické formulky, prefixy, vlastní podjazyk JavasScriptu, to vše musí zákonitě přijít:

    <input id="name-input"
    on="input-throttled:AMP­.setState({na­me: event.value})">

    input-throttled - to si musim proste asi zapamatovat, co vsechno tam vlastne muzu naplacat?
    setState vypada skoro jako volani funkce v JavaScriptu, ale:

    Expressions: These are JavaScript-like expressions that can reference the state. The example above has a single expression, 'Hello ' + foo, which concatenates the string literal 'Hello ' and the state variable foo.
    There is a limit of 100 operands what can be used in an expression.
    Expressions do not have access to globals like window or document.
    Only white-listed functions and operators may be used.
    Undefined variables and array-index-out-of-bounds return null instead of undefined or throwing errors.

    a tak dále.

    AMP si s sebou táhne od začátku podobný smrádek jako Angular 2, 3, 4 ... mno to by bylo na delsi povidani


    "Autor se na argument „obejití W3C“ dívá pohledem člověka, který Google „věří“:"

    V historii si prohlížeče tvořily svůj vlastní standard. Kam jsme se tím tehdy dostali?


    "Umístění na serverech Googlu. To je samozřejmě nepříjemné, hlavně třeba pro sdílení stránky a jakoukoliv další práci s ní. Nebo pro vnímání značky.
    Ale troufnu si tvrdit, že bychom si na to měli zvyknout. "

    Ne, neměli. Tvrzení opaku je naivní, zcestné a dokonce nebezpečné.
    Má si snad uživatel zvyknout, že je jedno, odkud obsah stránky pochází?
    Má tedy zadávat heslo ke svému emailu, internetovému bankovnictví, číslo karty a tak dále kamkoliv?
    Tohle chceme uživatele naučit?

    AMP tuším hodlá tohle nějakým pochybným způsobem řešit, ale to bude pouze náplast na problém, který bez něj neexistuje


    "Některé AMP stránky vypadají podobně, protože jsou odfláklé."

    Zakážeme vlastní komponenty, javascript, externí CSS a divíme se, že weby vypadají podobně?


    "A tak to autoři Accelerated Mobile Pages udělali se vším.
    Prostě vzali komponenty, které weby používají, a snaží se je vymyslet znovu a lépe.
    Uživatelsky přívětivě. Aby je nezkazili designéři, vývojáři, marketéři"

    Kde je napsáno, že to co autoři AMP vytvoří je správně. Material Design má taky řadu kritiků a myslím, že oprávněných.
    Když vidím některá grafická rozhraní v Google produktech, nejsem si jejich kvalifikací úplně jistý.
    Z hlediska programátora to ale určitě lépe nedopadlo. Kód rozesetý kde se dá pospojovaný řetězci, vlastní podjazyk ...


    "Občas zaslechnu, jak je pitomé, že musíme dělat další verzi webu.
    Jak už jste určitě z předchozích vět pochopili, chyba úvahy je v té „další verzi webu“.
    AMP a ne-AMP verze mají být totožná věc s občasnými výjimkami v kódu ve prospěch AMP."

    Pokud mám existující stránky tak prostě zcela nové stránky vytvořit musím. Dokonce i s novými CSS,
    protože výsledné html nemám v AMPu pod kontrolou a tak bude mít jistě jinou strukturu.


    "Pokud byste začínali stavět nový statický nebo obsahový web a byli mými klienty,
    doporučoval bych vám stavět jej jako „AMP-first“, tedy s maximálním využitím designérských a technických komponent frameworku."

    To je jako uzavřít manželství bez předmanželské smlouvy.


    "Zní to hezky. Jenže přemýšlejme o JavaScriptu. Jak jsem psal, do AMP není možné žádný vlastní vkládat.
    To je pro Google velká výhoda, protože kromě jiného může předvyrobené javascriptové knihovny
    skladovat na vlastních serverech a sdílet mezi AMP stránkami"

    To si může udělat se svými knihovnami každý. JQuery mohu tahat klidně také z CDN a sdílet ho.


    "Kdyby měl nějaký prohlížeč chybu v izolaci iframe nebo by ten problém byl v AMP vieweru,
    měl by útočník přístup na obsah na google.com (cookies nebo localStorage).
    Ochrana soukromí by mohla být problém, protože AMP stránka je ve výsledcích vyhledávání načtená, i když se na ni neklikne."

    Za to může ale jedině AMP, protože on sám vás natáhnul do svého origin. AMP si sám vyrobil bezpečnostní problém, který
    musí řešit na každém místě, kde se zpracovává výraz - tedy například v "bind"
    Zrušili jsme si tím localStorage a další API.
    Pokud se objeví v AMP chyba, její následky mohou být nedozírné (stejný origin)


    "To opravdové kouzlo ovšem přichází až s dalším krokem. Přednačtení ve výsledcích vyhledávání"

    To opravdové kouzlo tedy znamená, že už mi chrome sežral pár kB z mého tarifu a možná i nějaký procesorový čas i
    když jsem na danou stránku ani nechtěl jít?
    To není kouzlo, to je spíš pěkná sviňárna.
    Pokud se tváříme, že velký problém jsou vlastně pomalé sítě, tak ony nejsou mnohdy ani levné.