Čas od času weboví vývojáři povstanou a hlasitěji reptají na nedostatky W3C a ECMA ohledně způsobů, jakými se rozhodli vyvíjet (nebo nevyvíjet) technologie webu. O návrhu komisí mluvíme jako o selhání, prodejci prohlížečů by měli jednoduše implementovat a nestarat se o to...pokud to není Microsoft, nikdy by neměli dělat nic, aniž by se předtím zeptali někoho jiného...a zda existuje lepší a rychlejší způsob, jak vytvořit změnu. . Ve skutečnosti mě méně zajímá organizační struktura než nedostatek zaměření těchto skupin.
Velký problém
Mám předsudky, pokud jde o řešení problémů:jakmile je problém vyřešen, nechci ho řešit znovu. Když je problém dobře definován a řešení je pochopeno a přijato, chci, aby to bylo ten řešení a přejděte k řešení novějších problémů.
Každý výbor pro webový standard má jediný úkol, a to řešit problémy v jejich oblasti zájmu. Zdá se, že výbory mají problém definovat problémy, které chtějí řešit. Abychom byli spravedliví, úplná definice problému je často nejsložitější částí jeho řešení. Existují však dvě sady problémů, ze kterých si lze vybrat, a existuje mnoho problémů, které je třeba navzdory letité historii ještě vyřešit.
Design pro dnešek, design pro zítřek
Z rozhovorů s různými lidmi, kteří pracují na webových standardech, existují v zásadě dva typy problémů, které se snaží vyřešit:problémy dneška a problémy zítřka. Problémy dneška jsou známé entity. Celý kontext problému je dobře znám a řešení vytvořená vývojáři již existují. Problémy zítřka jsou trochu esoteričtější. S těmito problémy se vývojáři možná ještě nesetkali, ale standardy chtějí zajistit jejich eventualitu.
Je jisté, že obě sady problémů si zaslouží svůj náležitý čas a pečlivost a vše od HTML5 po ECMAScript 5 řeší některé problémy dneška a zároveň řeší některé problémy zítřka. getElementsByClassName() Metoda a Selectors API vyřešily problém vývojářů, kteří chtěli dotazovat DOM třídami CSS a používat dotazy CSS – obojí již bylo v knihovnách JavaScriptu všudypřítomné. Cross-Document Messaging API vyřešilo problém bezpečné mezirámcové komunikace, kde jinak vývojáři používali více vestavěných prvků iframe jen k předávání dat tam a zpět. ECMAScript 5 konečně zavedl oficiální způsob přiřazování getterů a nastavovačů a také řízení sčítatelnosti vlastností. Všechno to byly problémy dneška, které byly dobře pochopeny a poměrně rychle se změnily v oficiálně podporovaná API.
Problémy zítřka se často soustředí na dělání věcí na webu, které se ještě nedělají. Rád to nazývám problémem Photoshopu na webu. Zní to nějak takto:vzhledem k tomu, že jednou budu chtít napsat Photoshop jako webovou aplikaci, co bych k tomu potřeboval? Nejprve bych potřeboval nějaký způsob, jak přímo manipulovat s pixelovými daty (řešeno plátnem). Pak bych potřeboval nějaký způsob, jak zdrsnit spoustu dat bez zamrznutí uživatelského rozhraní prohlížeče (vyřešeno webovými pracovníky). Samozřejmě bych potřeboval umět číst soubory přímo z plochy (řešeno File API).
Možná si v tuto chvíli říkáte:"Ale já to chci udělat hned!" To je v pořádku, ale tato rozhraní API vznikla dříve než dnes. Je nevyhnutelné, že některé problémy zítřka se stanou problémy dneška, ale některé nemusí. Potřebujeme opravdu databáze v prohlížeči, nebo stačí jednoduché úložiště klíč-hodnota? Teprve budoucnost ukáže.
Nevyřešené problémy dneška
Jak jsem řekl, je rozhodně důležité trávit čas jak řešením problémů dneška, tak i výhledem na potenciální budoucí problémy, které lidi podrazí. Co absolutně nemohu vystát, je způsob, jakým výbory pro webové standardy často přehlížejí problémy dneška a tráví čas problémy zítřka. Pokud je problém dobře definovaný a týká se velkého počtu vývojářů, vyřešme jej, aby jej nikdo nemusel řešit znovu. Je spousta problémů, se kterými se potýkáme už dlouho a nikdo nejeví zájem je řešit. Pro mě je toto největší selhání webových standardů:neschopnost vývojářům umožnit přejít k zajímavějším problémům.
Zde je seznam aktuálních problémů, které ještě nejsou vyřešeny:
- Čtení a zápis souborů cookie v JavaScriptu – Netscape nám dal
document.cookie. Od té doby se to vůbec nezměnilo, což znamená, že kdykoli chce někdo číst ze souboru cookie nebo do něj zapisovat, musí provést veškeré formátování řetězce sám. Píšeme knihovny souborů cookie JavaScript posledních 15 let a stále je potřebujeme, protože rozhraní API se nikdy nezměnilo, aby odráželo to, co skutečně děláme. Toto je do očí bijící selhání ve vývoji webu. - Formátování řetězce JavaScript – již deset let víme, že potřebujeme mít možnost escapovat text pro HTML a regulární výrazy a že potřebujeme obecné formátování řetězců podobné
sprintf(). Proč to není vyřešený problém? Proč musíme každý znovu a znovu přepisovat takovou funkcionalitu? Příští verze ECMAScriptu bude mít zjevně funkci zvanou kvazis, která se snaží vyřešit všechny problémy pomocí stejné (nové) syntaxe. Opravdu se mi to nelíbí, protože neexistuje žádná zpětná kompatibilita pro to, co je souborem vyřešených problémů ve světě informatiky. Nerozbíjíme zde novou úroveň,htmlEscape()metoda by byla skvělým začátkem, nebo implementujteString.format(). Něco rozumného. - Formátování data v JavaScriptu – opět problém, který existuje již více než deset let. Proč nemohu snadno provést formátování data v JavaScriptu? Java má tuto schopnost již nějakou dobu a není to nic hrozného. Proč stále ještě píšeme knihovny formátování data?
- Běžná paradigmata uživatelského rozhraní – tohle mě fakt štve. Za posledních deset let jsme všichni napsali spoustu JavaScriptu, abychom vytvořili nejlepší ovládací prvky uživatelského rozhraní. Ovládací prvky se staly všudypřítomnými v knihovnách JavaScriptu a často vyžadují spoustu kódu, aby správně fungovaly. Proč zde nejsou značky HTML, které mi umožňují vytvářet tato běžná paradigmata uživatelského rozhraní:
- Karty – kolikrát ještě potřebujeme vytvořit JavaScript pro sadu karet? Existují dokonce role ARIA pro označení HTML jako karty, proč bychom nemohli mít nějaké značky, jejichž výchozí chování je používat tyto role? Už mě velmi nebaví vytvářet stále novější verze karet.
- kolotoče – velmi populární ovládací prvek, který je o něco více než
<marquee>značka, která se periodicky zastavuje a spouští na základě interakce uživatele. Existuje jen málo webů, na které můžete přejít a které nebudou mít na stránce alespoň jeden karusel. A když jsem jich pár napsal, je to vždycky bolest. Proč to nemůže být součástí HTML? - Akordeony – tady není nic magického. Velmi blízko HTML5
<details>chování prvku. Proč to nemohu mít nativně? - Stromy – další desetiletí trvající vynález, který jsme stále nestandardizovali. Ve skutečnosti byl můj druhý publikovaný článek o vytvoření rozšiřitelného stromu...to bylo v roce 2002. ARIA má také role, které reprezentují stromy, tak proč nemít HTML-nativní verzi?
- Dotykové události JavaScript – i když je technologie dotykové obrazovky relativně nová, rychle se objevily některé běžné vzory, které by bylo hezké standardizovat. Proč musím dešifrovat více
touchudálosti, abyste zjistili, co uživatel dělá? Proč zde nejsou události proswipe,flick,tapapinch? Abych mohl programovat pro dotykový web, nechci mít doktorát z informatiky.
Závěr
Jsem pro posun vpřed a nenechte se mýlit, jak TC-39, tak W3C odvedly chvályhodnou práci při řešení mnoha dnešních problémů. Jen bych rád viděl více řešení, abychom mohli v příštím desetiletí přestat opakovaně řešit stejné problémy. Za dalších deset let nechci psát JavaScript, abych analyzoval řetězec cookie, a nechci diskutovat o nejlepším způsobu, jak vytvořit ovládací prvek karty. To vše jsou známé problémy, které si nyní zaslouží pozornost, abychom mohli v budoucnu přejít k řešení zajímavějších problémů.