Nejprve bych chtěl potěšit všechny zájemce čekající na Nette. Dočkali se. Tedy… na tomto místě už měl být úvodní článek ze série věnované Nette. Leč mé zděšení z ASP.NET nesneslo odkladu.

Nejprve – toto není kritika jazyka nebo technologie .NET. Toto je kritika způsobu, jakým se vypořádává s webovým rozhraním a HTTP protokolem. Tedy toho, co je z výsledné aplikace vidět. A co úzce souvisí s kvalitou odvedené práce a spokojeností klienta.

Dost řečí, podívejme se na dvě z nejoblíbenějších standardních komponent v praxi.

Calendar Control

ASP.NET Calendar Control

Jde o tento roztomilý kalendáříček, který najdete na celé řadě blogů psaných v ASP.NET. Podstatné je, že navigace je kompletně závislá na JavaScriptu (podívejte se, kam směřují odkazy). Bez něj ani ránu. Takže, zapomeňte na přístupnost, zapomeňte na roboty indexující váš web.

Taktéž je nemožné si uložit aktuální stav do bookmarků, URL zůstává během práce stejné (obdobný problém jako v případě AJAXu).

Na Intervalu.cz jsem našel návod, jak zprovoznit kalendář i bez JavaScriptu. Dovolím si citovat autora:

Ovládací prvek Calendar umožňuje uživateli velmi komfortní volbu data v aplikaci. Bohužel, jako u většiny webových ovládacích prvků, je tento komfort vázán na JavaScript. V článku si ukážeme, jak v aplikaci doplnit kalendář o podobnou funkčnost i u klientů bez JavaScriptu, byť ne tolik komfortní.

O pár řádků dále se dozvídáme princip celého triku:

Datum, které uživatel s podporou JavaScriptu zvolí prostě klepnutím myši v kalendáři, necháme ostatní uživatele zadat v alternativním textovém poli.

Inu proč ne 😁

DataGrid Control a stránkování

ASP.NET DataGrid Control

Další velmi populární ovládací prvek, jenž slouží k rozbrazování tabulkových dat, často databázových tabulek. Disponuje celou řadou užitečných funkcí, nicméně v ubohosti výsledného projevu předčí i Calendar.

Podívejte se nejprve na demo. JavaScriptová navigace už nepřekvapí. Zajímavý je však pohled do zdrojového kódu, jemuž vévodí formulářové políčko __VIEWSTATE o velikosti 3kB! Tak to je prosím režie. Navíc v čistém základu, s doplňováním funkcionality nadále vesele roste. Velikost 50–150kB není nic neobvyklého.

Zajímalo by vás, co tak zajímavého si ASP.NET sám sobě posílá? Odpověď mi dal Peter van Ooijen, který píše:

Špatné na viewstate DataGridu je to, že se může stát šíleně veliká. Má v sobě celý obsah tabulky. V tomto případě (pozn. tedy v situaci, kterou řeší pisatel) mě zajímají pouze dvě čísla, zvolený řádek a datakey. Obsah tabulky je vždy znovu načítán z databáze.

Děsivé, že? Ještě děsivější, když si uvědomíte, že s těmito komponentami pracuje většina vývojářů. Jen minimum se zajímá o postupy, jak ViewState minimalizovat či dokonce obejít JavaScript.

Jak pracuje ASP.NET

Abych trošku vysvětlit, kde je zakopán pes, pokusím se stručně a zjednodušeně popsat, jak pracuje ASP.NET.

Webová stránka je v podstatě jeden velký formulář POST. Ten obsahuje skryté políčko __VIEWSTATE, ve kterém je serializovaná aplikace v aktuálním stavu. Dále jsou tu ovládací prvky, třeba tlačítka, která tento formulář odešlou zpět na server. Z __VIEWSTATE server obnoví aplikaci a vykoná událost aktivovanou stiskem onoho tlačítka. Tak se aplikace dostane do nového stavu a koloběh se opakuje. Opět se vytvoří stránka, velký formulář, do políčka __VIEWSTATE se serializuje aplikace, vygenerují tlačítka atd.

První problém vzniká, pokud akci nemá aktivovat tlačítko, nýbrž odkaz <a href. Takovému odkazu je v href přiřazen JavaScript odesílající formulář. To způsobuje nepřístupnost a celkovou závislost na JavaScriptu.

Další problém se týká URL, které se odesíláním formuláře nezmění a není tedy možné uložit aktuální stav do bookmarků nebo někomu poslat e-mailem. Také se obávám, že tlačítko Zpět v prohlížeči bude způsobovat varovné otázky, zda znovu odeslat formulář (neověřeno).

Pak jsou tu problémy se samotným __VIEWSTATE. Jeho velikost se špatně kontroluje a může snadno dosáhnout desítek kilobajtů (viz příklad s DataGrid, kdy se zbytečně ukládá celý obsah tabulky). Také tu vidím až nedozírné možnosti injektovat podvržený obsah (neověřeno).

Jsem naprosto přesvědčen, že tento způsob práce se v žádném případě neshoduje s principem HTML & HTTP (jeho současným moderním pojetím) a jde jen o násilné naroubování cizorodých postupů na web. Vývojáři Microsoftu si tím značně zjednodušili práci, protože implementace této techniky je vcelku snadná a přináší spoustu výhod pro programátory. Snadno vytvoří robustní aplikace. Je jen otázkou, jestli si uvědomují, za jakou je to cenu?

Závěrem

Nechci vytvářet půdu pro flamewar. Znovu opakuji, že tato kritika se netýká programátorského pohodlí v ASP.NET, ale úrovně běžně dosažitelných výsledků. Ta je prachbídná. Čest každému programátorovi, co hledá cesty, jak ten Microsoftí omyl vylepšit. Ale na otázky, k čemu je PHP, když daleko vhodnější platformou je .NET, je třeba pohlížet s velkým odstupem.


Související: