středa 5. listopadu 2008

JSF nemá mou důvěru

K tomuto zamyšlení mě vyburcovalo přečtení článku JSF vs. Tapestry - jak jednoduché je dělání komponent a letmé nahlídnutí do JSF specky 2.0 (zdroj JavaServer Faces 2.0 Composite Components). Nevím jestli se tomu dá říkat předpojatost, možná ano, možná ne, ale technologie JSF ve mě prostě nebudí důvěru. A mám k tomu několik pádných důvodů.

JSF byly od počátku přesně tím typem specifikace v Jave, který jasně ukazuje, jak se to nemá dělat. Není možné si říci, my teď potřebujeme komponentovou technologii pro vývoj web aplikací, tak si něco vymyslíme. To už ukázaly jiné specifikace v JEE, že tohle prostě nefunguje, protože lidé ve skutečnosti chtějí trochu něco jiného. Příklad JSF jasně ukazuje, že ve verzi 1.0 jsou uživatelé dané technologie spíše v roli pokusných králíků.

Mluvím o tom v každé své prezentaci otírající se o JEE, základním nepochopením lidí, kteří JEE tvořili (doufám už v minulém čase), bylo to, že je potřeba, aby technologie byla jednoduchá a použitelná. Většina všech webových aplikací, neřkuli všechny, řeší ty samé problémy. Proto musí být základní charakteristikou každého web frameworku to, že umožní tyto problémy řešit jednoduše.

K čemu je webový framework řešící problémy třetího světa (nadneseně řečeno), když v něm nejde jednoduše udělat vlastní komponenta. Přijde mi jako utopie spoléhat na nástroje, které by nás měly od této komplexnosti odstínit. Vývojáři neradi spoléhají na magické skříňky, které jim pod rukami generují tuny kódu. Je to vcelku pochopitelné a vychází to z dobře známých důvodů.

Další věcí k zamyšlení je, jestli opravdu odstínění od principu webové aplikace požadavek/odpověď je to co při vývoji webových aplikací potřebujeme. Opravdu nám vyšší abstrakce přinese tolik výhod oproti tomu, o co přijdeme? Má smysl zakrývat základní paradigma webu a tvářit se, že webovou aplikaci lze stavět podle podobných principů jako tu desktopovou? Osobně tuhle víru ztrácím. Položme si otázku, mají něco podobného technologie jako PHP či Ruby on Rails. Pokud ne, proč asi...

Poslední, ale rozhodně ne nejméně důležitý fakt představuje faktor inovace či agilnosti. JSF 2.0 po jejich finálním vydání zůstanou zakonzervované nějaký ten pátek. Oproti tomu jakýkoliv proprietární (nestandardizovaný) framework může relativně pružně reagovat na aktuální potřeby. Přidávání nových vlastností do čehokoliv standardizovaného je prakticky nemožné a pokud je to vůbec možné, tak ve většině případů ztrácíme přenositelnost. U proprietárních frameworků tohle prostě a jednoduše nehrozí.