Proč Jet nemá žádný šablonovací systém pro view?
Stručně by se dalo říct: Protože PHP samo o sobě je na to nejlepší! Přímo pro tento účel bylo PHP původně stvořeno. Tak proč používat něco jiného?
Dobře, sliboval jsem argumenty. Toto sice argument je, ale sám o sobě je chabý. Pojďme se na to mrknout jako technici a shrňme si pro a proti. Nejprve argumenty pro šablonovací systém.
Proč mít šablonovací systém
Bezpečnost
Lepší ochrana proti XSS a "zamoření" výstupu nežádoucím kódem je asi nejčastější argument. A já říkám: Dobře, to bych bral, ale ...
Nedá se to řešit jinak? A není náhodou vrstva generování výstupu až ta úplně poslední, kde by se bezpečnost měla řešit? Zlaté pravidlo přece říká, že bezpečnost začíná na vstupu a tak je nutné také opravdu začít.
Nějaká snaha o bezpečnost ve výstupu je pouze berlička a ve skutečnosti to podvědomě může vyvolávat špatné návyky - např. se na to bláhově spoléhat a nešetřit tolik vstup.
A v neposlední řadě: Není to tak trochu velkorážní houfnice na lov zajíce? Budovat celý ekosystém a novou technologii, kterou se někdo musí učit, abych měl zakódovaný výstup? To je přece šíleně drahé. Ať ten vývoj, nebo ty neopodstatněně navýšené nároky na křivku učení.
Tedy: Částečně beru, ale ... Viz dále.
Oddělení výstupu od logiky
Ale od toho máme přece MVC, ne? To se má řešit správným pochopením smyslu této architektury, protože jedině správné pochopení je cesta k dobrému výsledku.
Šablonovací systém ve skutečnosti do problematiky separace aplikace na vrstvy nic zásadního nepřináší.
Je to cool! Je tu punk! Má to hezčí syntaxi
No ... To je čistě subjektivní a neměřitelné, tedy pardon, toto jako argumenty neberu.
V termínu, v perfektní kvalitě a za slušné peníze dodávat klientům projekty co budou dlouho sloužit je cool a jít pak blbnou s kamarády do klubu je punk.
Šablonovací systém není ani jedno. Naopak ten mi dosažení daného cíle - tedy maximální efektivitu - komplikuje. Viz dále.
Proč nemít šablonovací systém
Je to drahé a neefektivní - z hlediska financí
Ano, na první místo dávám finance. Protože práci děláme profesionálně, projekty musí být finančně konkurenční a tak dále. Není to hobby, tedy o peníze jde až v první řadě. No a šablonovací systém pro mne z finančního a organizačního hlediska znamená problémy:
- Člověk který bude vyvíjet frontend musí umět daný šablonovací systém, nebo se jej musí naučit. To mi ještě víc komplikuje personální trable.
- PHP je tak rozšířená a de facto standardní technologie, že jej zná spousta lidí - alespoň základy, které jsou pro vývoj view nutné. Šablonovacích systémů je X a když udělám X+1, tak situaci moc nepomůžu a zúží mi to spektrum potenciálních kolegů na pozici front end vývojáře ...
- Určitě se najdou technická omezení šablonovacího systému, nebo nedostatek znalostí lidí, kteří se jej snaží používat. To přinese do projektu jalové hodiny - tedy neproduktivně strávený čas. A ve finále to někdo nějak ohne - sníží se kvalita projektu ... To není dobré ani krátkodobě, ani dlouhodobě.
- Reálně to může projekt prodražit - zákazník pak zaplatí za něco, co mu nic nepřináší ...
Je to technicky neefektivní
- Ať děláte co děláte, tak šablonovací systém vyvinutý v PHP a na PHP běžící nebude nikdy tak výkonný jako PHP samotné. Ano, šablony mohou být různě "kompilované" do PHP, ale i tak do nutně znamená určitou režii (spotřebu výkonu procesoru, paměti, IO), která není k ničemu opravdu užitečná. Musíte zjišťovat zda už máte šablonu přeloženou a tak dále ...
- Klade to často zbytečné omezení a překážky. Různé filtry atd. Proč? Proč si prostě nezavolat určitou metodu, když to potřebuji?
- Moderní IDE pro PHP neskutečně usnadňuje práci (mém jednoho oblíbeného favorita ve kterém vzniká i Jet). Pokud má být práce v IDE efektivní, tak musí dobře podporovat dané technologie ... A podpora PHP je dnes fakt už špičková a práce je pohodlná ... Proč si to komplikovat něčím nestandardním.
- ... a jako vrchol všeho ... Viděl jsem šablonovací systémy, který umožňují vkládat do šablony PHP kód ... Tedy po cestě kolem světa vznikl rovnák na ohýbák :-)
Suma sumárům ...
Nevidím jediný argument, který by obhájil přinesení nové ne tak úplně standardní technologie do projektů. Jak technicky, tak finančně mi to prostě nevychází ...