menu

Proč nepoužívám tradiční frameworky?

Důvody, které mě vedou k nepoužívání tradičních frameworků a napsání vlastního.

Bavíme se teď o webových technologiích a nástrojích typu WordPress, Drupal, Magento a podobných z pohledu správy obsahu (CMS) a Laravel, Symfony, CodeIgniter a podobných z pohledu vývoje. Určitě bych hned v úvodu rád uvedl, že tento blog nemá být žádný hate na lidi používající frameworky, ale výčet důvodů vlastního rozhodnutí. Pokud jde o nasazení na úkol, který je zdánlivě jednoduchý, ale používá velké množství funkcí a je potřeba ho naprogramovat v krátkém čase bez ohledu na zdroje, tak lze určité frameworky doporučit.

Důležité je také to, že nepoužívání frameworku neznamená nepoužívání objektového přístupu (OOP, UML), pokročilých architektur (MVC,MVP,DDD) či verzovacích nástrojů a repozitářů pro lepší týmovou práci (GIT,SVN). Znamená to pouze používání čistého programovacího jazyka bez nástaveb pro jednodušší práci. Používání frameworku je jako když byste si objednali truhláře na nábytek do domu a on by vše koupil v IKEA a pouze složil u vás doma. Výsledek funguje a řeší zadání, dodavatel ale nemusí vědět ani jak se k cíli dopracoval. Navíc každý programátor by měl znát jazyk ve kterém píše, ale ne každý musí znát každý framework, tudíž přenositelnost čistého kódu je, na rozdíl od frameworků, stoprocentní.
A co jsou ty hlavní důvody?

Rychlost


Vývojové frameworky


Často se opakuje, že frameworky jsou rychlejší. Je ale potřeba si říci, že to platí o vývoji v nich, nikoliv jejich výstupech. Častkorát se u složitějších případů setkávám i na odborných fórech s odpověďmi typu, ať volí lidé cestu rychlejší nebo čitelnější pro programátora narozdíl od rychlejšího vykonání kódu. To je ale špatný přístup. Klient si platí, aby řešení bylo rychlé a funkční. Ne, aby řešení bylo pro vás, jako dodavatele, co nejpohodlnější. Je potřeba si uvědomit, že framework je jen další vrstvou nad programovacím jazykem a jako takový tedy vždy spotřebovává dodatečný výkon na svůj přepis do jazyka původního a přináší pouze relativní pohodlí a zjednodušení při programování.

Druhou věcí je pak zbytečná robustnost určitých funkcí. Rozsáhlé knihovny obvykle zahrnují více funkcí a kódu, než je pro daný úkol nezbytné. Navíc jsou častokrát závislé na dalších knihovnách třetích stran. Vezměme za příklad třeba knihovnu respect/validation.. ta slouží k validaci určitých vstupů. Jen všechny její funkce jsou rozloženy do 330 souborů ze celkového počtu 790 souborů na samotnou knihovnu.  Každý přístup k jednomu souboru aktivuje file system a zvyšuje režijní náklady pro exekuci kódu. Navíc většina těchto funkcí je jen přepis jednořádkové funkce z PHP.. ano, kvůli jednomu řádku a použití existující funkce se vytváří další funkce v samostatném souboru obsahující pouze tuto nativní funkci. Tato knihovna je pak například i součástí zmíněného Laravelu a implementuje se pro validaci vstupů, tedy třeba formuláře na webu.

Pro kontrolu validní emailové adresy se tak spouští celá lavina kódu v knihovnách nad frameworkem, následně proleze frameworkem a poté se přepisuje a interpretuje do PHP. Přitom stačí jednoduše napsat v čistém PHP podmínku
if(filter_var($email, FILTER_VALIDATE_EMAIL))
či lépe regulární výraz
if(preg_match("/^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$/u",$email))
Následně ještě můžeme třeba zjistit, zda daná doménu vůbec existuje pomocí příkazu checkdnsrr.
Takže kompletní test emailu provedeme snadno pomocí:
$email="mpavlik@mpavlik.co.uk";
if(preg_match("/^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$/u",$email)){
  $domain = substr($email, strpos($email, "@") + 1);
  if(checkdnsrr($domain,"MX")) {
    echo "Email OK";
  }else{
    echo "Chybný email";
  }
} else {
  echo "Chybný email";
}

To je pomocí 299 bytů včetně formátování. Tento kód si samozřejmě můžeme vložit do funkce a volat opakovaně již jen jako jednořádkový příkaz např. validuj_email($email), resp. $validator->validuj_email($email).

Pokud použijete Laravel, ten použije knihovnu respect/validation, ta pro validaci emailu potřebuje další knihovnu Egulias\EmailValidator, která má opět dalších 87 souborů a 130kB. Neřeším pak další napojené knihovny (lexer, polyfill,...), které tyto jmenované potřebují a instalují ještě pro potřebu dalších funkcí, které ani v našem příkladu nepoužijeme. Celkově se pro validaci emailu pomocí knihovny respect/validation nainstalovalo neuvěřitelných 1 347 souborů o velikosti 6.8MB
Bavíme se zde o nahrazení naší funkce.. neřeším, že dané knihovny mají více možností, ty v našem případě nevyužíváme a jsou tak pouze balastní zátěží.  To vše pro nahrazení funkce, která má 299 znaků. Navíc to rozložení do desítek složek a stovek souborů zamne způsobuje spíše chaos nežli použitelné uspořádání. To je jako když by vám někdo dal naučit se celou učebnici matematiky pro gymnázia a skipta vysokoškolské matematiky kvůli výpočtu druhé mocniny, ke kterému vám stačí základní násobení z druhé třídy ZŠ.

Základní framework (symfony, laravel) má kolem 20MB (2.000 souborů), se všemi knihovnami pak kolem 80MB (5.000 souborů)! A to ve chvíli samotné instalace.. ještě v té době nemá žádný soubor s funkcionalitou.

Pro srovnání třeba systém, který jsem dělal v čistém PHP pro společnost Propuls Solar a který obsahuje 41 modulů z toho: Správu zaměstnanců, odvodů a mezd, Adresář dodavatelů a odběratelů, Správu firemních dokumentů, Kalendáře, Výkazy práce, píchačky, docházku a nepřítomnosti, Správu vozového parku, Kompletní sklady, příjemky, výdejky, inventury, výr. čísla, ceníky, Pokladnu, Faktury, Formuláře, Stravné, Nabídky (přijaté/vydané), Objednávky (přijaté/vydané), Zakázky, Šablony emailů, Úkoly a Konfiguraci systému má celkově včetně datových pump, propojovacích můstků do Pohody, logovacích nástrojů a mého frameworku dohromady 3.2MB ve 261 souborech. Na každé stránce pak probíhá import základní knihovny funkcí o velikosti cca 50kB.

CMS frameworky


Zde je to co se týká rychlosti ještě markantnější. Web o jedné stránce, což je v reálu pár kB dat může mít i stovky MB. Na jeho tvorbu již většinou uživatelé nepoužívají ani samotný framework, ale další nástavby jako třeba DIVI (https://www.divi.cz/). Zábavným faktem je, že zrovna hlavní strana českého webu divi napsaného na divi je v času psaní toho článku rozbitá.



Načítání webů na wordpressu je značně pomalejší než čisté HTML. O pomalosti řešení svědčí i to, že existují spousty nástrojů pro následnou optimalizaci, jako např. WP Rocket, Autoptimize, Hummingbird, atd. Zde tedy pro jednoduchý web použijete robustní nástroj, nad ním další nástroj, jejichž spojení způsobí velice ošklivý a neoptimalizovaný kód, nad čímž se spustí další knihovny, které ho zkusí vyčistit a přispůsobit.. jestli toto není to pověstné drbání se levou novou za pravým uchem, tak už nevím.
Google v poslední době dává veliký důraz na rychlost načítání obsahu webu a jeho čistotu. Wordpress a podobné tak v jeho testech často propadnou a tudíž i v rámci trendu optimalizovaných webů jsou dnes v podstatě nepoužitelné.
Toto je příklad analýzy webu na WordPressu.



Kontrola nad kódem a bezpečnost


V předchozím odstavci jsme si řekli, že takový jeden pěkný framework je složen z tisíců souborů a funkcí nasazovaných i k velice triviálním úlohám. Kdo kdy tvořil něco velikého závislého na stovkách jiných elementů ví moc dobře, že to vede spíše k frustraci nežli k zjedodušení cesty k cíli. Problémem je tedy to, že programátor není schopen znát je všechny. Když by si programátor vzal na každý jeden z těch 5.000 souborů byť jen 10 minut, tak je bude studovat přes 100 pracovních dní. Pokud použiji takovéto předpřipravené kusy kódu a nevím, jak on samotný funguje, tak jak mohu ručit za jeho správnost? Navíc ne vždy musí fungovat přesně tak, jak zamýšlíte.

Doporučení vývojářů je navíc aktualizovat všechny knihovny na měsíční nebo lépe týdenní bázi.. a pak se modlit, že bude vše fungovat tak, jak jste původně zamýšleli a nic nezpůsobí nějakou kolizi. Samozřejmostí je pak provést testy aplikace. V realitě to pak může představovat i desítky tisíc v nákladech, kdy budete platit za aktualizaci, testy a opravy něčeho, co nejspíš váš systém nikdy ani nepoužil a nepoužije. V praxi tak není nic neobvyklého, že na jednoduchý web či aplikaci se použije framework místo čistého řešení, které by nepotřebovalo údržbu a klient musí platit měsíční udržovací poplatky a to vlastně jen za šlendrián dodavatelské firmy,
která toto neumí naprogramovat, tak musí použít hotové řešení a to udržovat bez jeho vnitřní znalosti.

Z důvodu neznalosti nebo neúplného vyhovování použitého kódu pak navíc vznikají uvnitř řešení různé takzvané hacky. Ty pomáhají dojít k cíli, ale výsledný kód ještě více znepřehledňují. Když takovéto obejití logiky kódu změníte přímo v knihovně, tak ho v budoucnu přepíše nejspíš někdo omylem novější verzí. Pokud ho napíšete jinde, nebude již fungovat logika modularity a navíc budete muset framework obcházet velice tvrdě a prát se s jeho ochranou. Navíc tak ještě s největší pravděpodobností vytvoříte možnou bezpečnostní díru. Nejvíce se tyto věci projevují u nestandartních vstupů. Například zpracovávání dat vkládaných z jiných systémů, špatně generovaných textových či XML vstupů, atp. Právě takovéto kličky jsou u nás častým zadáním od firem programujících na frameworcích, které se dostaly do slepé uličky a neměli jiné řešení, než použít programátory čistého jazyka, aby prostředí ohnuli.

Dalším velkým problémeme je bezpečnost, kdy stačí, že má jeden z celého toho počtu souborů bezpečností díru a zničí tak celou bezpečnostní ucelenost daného frameworku. Kdo kdy tvořil něco velikého závislého na desítkách či stovkách jiných elementů ví moc dobře, že to vede spíše k frustraci nežli k zjedodušení cesty k cíli.

Ve Wordpressu bylo jen za poslední dva měsíce (k datu 12.7.2024) odhaleno více než 10 kritických chyb, které mohly vést k získání citlivých dat a nebo k převzetí kontroly nad celou stránkou.

V Laravelu jsou známé bezpečnostní chyby uvedeny třeba zde:
https://coderscotch.com/top-six-laravel-security-vulnerabilities-and-how-to-fix-them-in-2023/

V Symfony pak naleznete jejich výčet v pravidelných release notes na jejich blogu.
https://symfony.com/blog/symfony-7-1-2-released
https://symfony.com/blog/

Je dobré ale vědět, že většina se jich zatajuje z důvodu toho, aby nebyly lehce dohledatelné a zneužítelné širokou veřejností. Symphony třeba na webu uvádí, že je nemáte nikde zveřejňovat a pouze poslat na jejich email a oni se vám ozvou.
Stejně ale jakmile se nějaká díra objeví, proběhne tato informace přes komunitu hackerů velice rychle. Pokud tedy nebudete dané frameworky aktualizovat, brzy vám je napadnou. Hezky je to vidět například v logu přístupů na serveru, který ani wordpress neobsahuje.. vidíte ty pokusy...




Nezávislosti na třetích stranách.


Poslední bod se prolíná s předchozím a to převážně v otázce častých aktualizací a změn, které nejste schopni ovlivnit.
Buď budete mít systém, který bude v budoucnu s velikou pravděpodobností zranitelný nebo budete mít systém, jehož elementární prvky se budou klidně co měsíc měnit. Na řadu také může přijít zpoplatnění či zdražení daného nástroje. Novinkou by nebylo ani nahrazení za novou verzi, na kterou může být převod velice složitý. Toto byla věc třeba frameworku Zend1 a Zend2 nebo Symfony1 a Symfony2 (nyní jen Symfony), kdy přechod byl velice složitý, jelikož novinka přinesla změnu architektury a komponent bez zpětné kompatibility a navíc s nedostatečnou dokumentací.
Některé nadějné frameworky byly dokonce úplně ukončené. Jako Radiant, Kohana či CodeIgniter.

Vlastní řešení


Definice frameworku je "nosná konstrukce, kolem které lze něco postavit". Není to žádná superschopnost, žádná magie, ani hacky procesoru či záhadné zkratky do strojového kódu. Není to žádná raketová věda, něco, co by programátor nezvládl sám vyřešit. Pouze a jenom mu pomáhají rychleji k cíli a zjednodušují práci. Jak se říká v odborné komunitě "Pokud žádný framework nepoužíváte, nakonec si vytvoříte vlastní!" případně "Pokud používáte nějaký framework dostatečně dlouho, skončíte u jeho přepisováním." Toto je nicméně i to, jak vznikly tyto tradiční frameworky. Někdo prostě pro usnadnění svého vývoje napsal vlastní framework a ten pak uvolnil do světa. Nepoužívání tradičních frameworků tedy neznamená nepoužívání žádných. Jde spíše o cestu zkušenosti a toho, že používám za roky své praxe vlastní napsané knihovny a rámce (frameworky) či produkty. Mám tedy vlastní sadu jádra pro vytváření informačních systémů, k nim sadu pro práci s obsahem a číselníky. Sadu funkcí pro validace a pro řešení práv. Databázové funkce a řešení přihlašování. V případě, že potřebuji pro určité projekty další funkce, lehce je mohu rozšířit či doplnit. Dále mám vlastní sadu modulů v čistém PHP a JS, které zapadnou do každého řešení i frameworku :). Příkladem takových modulů je třeba Captcha, Wysiwyg editor (ve kterém píšu i tento blog), Fotogalerie (aka lightbox), API rozhraní, XML a CSV parser, Upload manager, SVG kontroler, SVG editor a jiné...

Z dnešního pohledu vám může připadat daný způsob mírně zkonstnatělý. Vždyť se o frameworcích mluví všude. Nicméně osobně programuji v PHP profesionálně již od roku 2003, kdy jsem udělal první eshop. To je přes 20 let. Až následně se objevily první ze jmenovaných frameworků a jednalo se o malé komunity. Postupně jsem mohl sledovat jejich vývoj a vzestup, problémy, úpadky a třeba v roce 2011 už po osmi letech v praxi vidět, jak byl opuštěn Radiant , Symfony s problémy přecházel na novou verzi a stejně tak Zend. Spousta firem řešila problémy jak a na co migrovat, co čekat a kam směřovat. Často se mi do rukou dostaly i zprávy o bezpečnostních dírách v daných řešeních. Navíc spousta obřích projektů napsaných za tu dobu v PHP jako Facebook, Wikipedia, Flickr nebo i CMS systémy jako Wordpress či Drupal jsou napsány v čistém PHP a používají případně své frameworky.
Jen pro úplnost pak uvedu největší projekty na Laravelu, což jsou ALISON, BARCHARTS, IvoiceNinja a MyRank. V Symfony pak třeba Spotify (pouze ale správa uživatelských účtů), Blablacar, Trivago a podobné.. velice často bookovací systémy.

Závěr

Tradiční frameworky jsou velice robustní nástroje, které programátorům zlehčují jejich práci. Většinu z toho, co přináší však vyřešíte i bez nich (týmová práce, verzování, revize, testování, ...)  a rámce, kterými vám určují cestu časem začnou být omezující. Programování jako takové je velice široký pojem. Možností a variací je nekonečno a použití nástroje, který usnadňuje práci jednomu nemusí znamenat usnadnění práce zrovna i vám. Framework pro eshopy nebude vhodný na aukční portál, framework pro web nebude vhodný pro front end nějakého informačního systému, atp.. Navíc čím jsou frameworky větší, tak tím více uvolňují své směřování a nakonec v podstatě vytváří vlastní programovací prostředí, které umožňuje více a více volnosti, až se dostanou k tomu, že v podstatě jen obalí jazyk původní.

Osobně volím cestu vlastního řešení. Můj framework promne jen vytváří podpůrnou kostru, sadu nástrojů, pro mé systémy, eshopy a weby (ano, jsou to tři malé frameworky) a dělá přesně to, co potřebuji a to tím nejefektivnějším způsobem. Nic víc, nic míň.

Kam dál?


https://dev.to/francescostrazzullo/the-definition-of-framework-k70
https://patricklouys.com/professional-php/
https://kevinsmith.io/modern-php-without-a-framework/
https://www.frameworklessmovement.org/
https://en.wikipedia.org/wiki/Not_invented_here

Kontaktní informace

Ing. Matěj Pavlík
+420 603 386 632
info@unisell.eu

IČ: 87595516
DIČ: 8503100496