Už před delší dobou jsem chtěl napsat nějaké menší srovnání Zend Frameworku a Nette Frameworku, ale pořád jsem to odkládal a odkládal, až už z toho Zend Frameworku pomalu nic neznám 
. U Nette jsem mnohem častěji, protože ho používáme v práci (když jsem nastoupil, už tam bylo a nedalo se s tím nic dělat 
). Bude to také samozřejmě subjektivní a nějakou moc velkou obhajobu Nette nečekejte. Do velké míry je to tím, že Nette jsem byl nucen používat od jeho velmi rané fáze, ještě někdy před verzí 0.8. Zaměřím se hlavně na MVC, protože to je to nejdůležitější, co dělá framework frameworkem.
MVC je základ
V Zendu se jede podle klasiky MVC s front controllerem, view helpery a spoustou nachystaných pluginů a bohaté plugin architektury. Pluginy mohou být jak pro action (v Zendu se tomu říká action helpery, základem je Zend_Controller_Action_Helper), tak pro celý proces, kterým odbavení požadavku prochází - Zend_Controller_Plugin_Abstract. Současně framework už v základu poskytuje velké množství helperů, které zajišťují redirectování, inicializaci view, context switching a další. Je to velmi propracovaný a přitom poměrně volně vázaný systém.
Nette je založeno na MVP, P není tedy Controller, ale Presenter, který může obsluhovat více stránek. Proces dispatchnutí požadavku je jednodušší než v Zendu, ale co je horší, není zajištěna dobrá separace jednotlivých částí procesu odbavení požadavku a velmi špatná možnost pluginování. Nette obsahuje podivnou třídu Application, která umožňuje pověsit se na nějaké události, ale o přehlednosti plugin architektury jako je v ZF se nedá vůbec hovořit. Ono by se na první pohled mohlo zdát, že koncept Presenteru a Controlleru je v podstatě stejný, zejména proto, že presentery v Nette mohou být multiaction, ale opak je pravdou. Existuje zásadní rozdíl v práci s Controllery v Zendu a Presentery v Nette. Presenter je totiž od toho aby se dědil - viz. doporučení od autora frameworku, ale Controller, se naopak dědit nemá (může, ale nedoporučuje se to), společné prvky controllerů v aplikaci se zajišťují přes pluginy. Taková architektura je mnohem flexibilnější, na dědičnosti závislém presenteru se tak rozsáhlý systém v podstatě nedá postavit.
Presenter architektura v Nette naopak poskytuje jednu velmi pěknou vlastnost, kterou zřejmě nikde jinde nenajdete - komponenty. Funguje to velice pěkně, navíc s built-in podporou ajaxu a factory metod na komponenty. U Zendu se komponenty dají nahradit částečně view helpery, ale tak efektní to není, "widgetizovaný" web se tak dá s podporou presenterů postavit mnohem lépe. S odstupem času mi ta "ajaxovost" komponent už tak pěkná nepřijde, myslím si, že éra posílání a substituce kousků html je překonaná záležitost, i když pro oživení klasické webové presentace je to pořád asi nejčastější způsob.
Nette také obsahuje poměrně bohatý šablonovací systém, který je v podstatě nutné používat zejména kvůli komponentám a snippetům, bez nich by to nebylo ono. Naopak v Zendu jsou šablony klasické PHP soubory, kde velkou roli hrají view helpery, které umožňují tvořit znovupoužitelné části pro view a zjednodušit tvorbu šablon. Opět je poskytováno obrovské množství view helperů na všechno možné. Klasické PHP v šablonách velmi pěkně zapadá do MVC architektury a potřeba nějakého složitějšího šablonování tak v Zendu není.
Routing je Nette a v ZF dost podobný, v Nette je možná malinko propracovanější, ale na 90% věcí vám vyhoví oba zhruba stejně. ZF má podporu RESTu, Nette zatím ne.
Nezmínil jsem třeba takové věci jako formuláře, které jsou např. v Nette díky komponentové podpoře pěkně řešené a používají se lépe než v Zendu, ale jak jsem napsal, soustředil jsem se hlavně na MVC.
Komunita, koncepce vývoje
Tady už je to v podstatě nesrovnatelné i když autor se to snaží vyvracet. Je pravda, že Zend Framework je tažen především třemi full time vývojáři (spíše dvěma, že by Alex kromě Zend_Pdf nějak zásadně do frameworku přispíval …), ale pořád je o 100% více než Nette, kde ač se po různu vynořují magická spojení jako Nette Foundation, je to celé v podstatě na D. Grudlovi. No, spíše o 200% až 300% více, protože Zend vývojáři se opravdu věnují programování frameworku a nepatlají se tolik s věcmi okolo (design, wiki, bugtracker, školení, webcasty, manuál …), v tom jim firma poskytuje zázemí.
Na ZF je krásně vidět, jak do projektu zatáhl komunitu. Od začátku jasná pravidla pro komunitní vývoj komponent a jejich pravidelné zařazování do frameworku. Pak se přidaly pravidelné bug hunt days - to je naprostá bomba a klasická ukázka komunitního vývoje, dále delegování odpovědností za vývoj jednotlivých komponent a výbor expertů z řad komunity, která posuzuje framework jako celek je další nová věc. Nic takového v Nette není, všechno jede pod diktátem autora a bez něj v podstatě všechno stojí. Minimálně bug hunts by potřebovalo Nette jako koza drbání, ale je tu problém s testy, viz. dále.
Další velké koncepční problémy byly učiněny hned na začátku vývoje Nette. První byla neexistence testovaní a druhá nesmyslná "cool" podpora php 5.3 v době, kdy ani php 5.3 nebylo reálně použitelné. To vedlo k tomu, že Nette mělo naprosto strašné zdrojové kódy nutné pro generování 5.3 verze a doteď se tam vyskytují třídy pro kompatibilitu s 5.2. Navíc od začátku se poskytovala a preferovala neprefixovaná verze frameworku pro 5.2, což je z pohledu pojmenování a kolizí naprostá hrůza.
Zend od začátku zvolil klasiku PHPUnit a s 5.3 si hlavu nelámal. Prefixoval třídy klasicky ve stylu PEARu. Když nastala doba, učinil se stávající framework v pohodě kompatibilní s 5.3 a začalo se pracovat na nové major verzi. Naprostá pohoda, bez konfliktů a hromady ušetřené práce.
Ohledně testování v Nette se snad ledy hnuly a konečně i Nette bude mít testy pro PHPUnit, což by snad nakonec mohlo dospět i k tomu, že by mohlo dojít na ty bug hunt days . Sice se autor pokoušel o nějaký svůj koncept testů, ale jedině dobře, že mu to nakonec snad zametli pod stůl.
Přitom komunita je to, co by z Nette mohlo udělat přednost, je totiž pravda, že se kolem něj nabalila velká skupina především mladých a velmi schopných PHPčkařů a zapojit je více do vývoje frameworku by do frameworku přineslo naprosto novou kvalitu, spolu se standardním testováním by to neměl být problém. Jako příklad můžeme vzít šablonovací systém. Jak jsem již uvedl, Nette má svůj, je poměrně propracovaný a docela dobře se používá. Nicméně pod povrchem je to makroprocesor okolo reg. výrazů. Jakub Kulhan, jeden z těch, kteří se okolo Nette motají, má velmi dobré znalosti ohledně kompilátorů, lexerů, parserů, … a chuť něco takového udělat i pro Nette šablony. To by byl naprosto revoluční počin a posunul Nette šablony na naprosto jinou dimenzi. Minimálně za pokus by to stálo a takových lidí se motá okolo Nette více.
Další věc je verzování. U Zendu máte jistotu že pokud nepřijde major verze, tak se BC breaky nedělají a všechno jede jak má. Má to jasnou koncepci, která je možná trochu rigidní, ale pro udržování rozsáhlejších projektů nutná.
Naproti tomu Nette si klidně i do údajně stabilní větvě 0.9 švihá i zpětně nekompatibilní změny v API a to dost často velmi zásadní. Sice se to autor snaží vylepšovat tím, že do fóra napíše BC break, ale i tak se to s pojetím ZF nedá srovnat a pro reálné nasazení je tak každá taková "stabilní" verze dost velká komplikace.
Další věc je magičnost a WTF faktor. Ten je u Nette kupodivu mnohem větší než u Zendu a není to jen šablonami. Troufnu si tvrdit, že tenhle rozdíl se bude s příchodem ZF 2.0 a Nette 1.0 zvětšovat. Nette si dost zakládá na magických konstrukcích a různých nápravách a vylepšeních PHP jako jazyka, Zend se o nic takového nesnaží a naopak se magičnosti bude snažit zbavit. S tím souvisí i poněkud zavádějící slogan "Nette Framework is designed with simplicity in mind". Nenechte si mýlit rozsahem ZF, podle mých zkušeností je zvládnutí základu Zend Frameworku pro začátečníka jednodušší než Nette.
Závěr
Ačkoli už tu Nette nějaký ten pátek je, pořád bych se při rozhodování, co zvolit jako zásadní firemní framework, pro něj nerozhodl. Naopak jako framework pro nějakého člověka, který dělá zakázkové weby, se Nette hodí velmi dobře. Počkejme si, co přinese verze 1.0 a jestli se Nette opravdu otevře více komunitě. Uvidíme také, jak se frameworky vypořádají s integrací nějakého ORM řešení, které by přidalo alespoň nějakou podporu modelů.
Komentáře (17)
Díky za pěkné srovnání. Výše zmíněné mě asi donutí opustit Nette a přejít na jiný framework. Co jste nezmínil a co se mi na Nette, či spíše to, jakým směrem jde, nelíbí - vlastní syntaxe a defakto nulový re-use již existujícího. Příkladem budiž diskuze k syntaxi anotací a konfigurace, kdy se bohužel prostě nevezme již existující řešení, ale vymýšlí se něco jiného.
A co se týče změn v API: Šlo by to překousnout, kdyby občas nemizeli celé třídy jen proto, že někdo usoudí, že se nepoužívají (i kdyby proto, že na ně nebyla dokumentace) nebo depracted metody byly označeny jako deprecated jinak (anotace) než vytvořením warningu.
Zajímalo by mě, jak by v tomhle obstál Symfony2.
* nemizely, deprecated; fuj :)
V diskuzi X vs. Y je vždy nutné vymezit kategorii priorit. Jde o to, "kdo" chce "vyvinout co". A popravdě - daleko škaredší, objektově nesprávnější CakePHP mnohdy umožní vyvinout rychlejší a udržovatelnější web, než by by bylo v čemkoliv, co by z Nette a ZF vybralo jen to nejlepší.
Prioritou Zendu je čistota a ne produktivita práce. Do vzniku Zend_Tool byla produktivita práce v ZF docela tragická. To je docela smutné, například Josefem zmiňované Symfony2 nebo Flow3 mají řádově lepší, objektovější, udržovatelnější zdrojový kód a třeba v tom Symfony jde vyvíjet mnohem rychleji, než v ZF.
Prioritou Nette je zase jiný workflow, který nebude vynucovat použití a chápání návrhových vzorů a bude bližší těm, kteří mají radši komponentový přístup, na který si zvykli třeba v Delphi, Webforms, PRADO.
Neříkám ani tak ani tak, ve skutečnosti má jak Nette, tak ZF ještě velmi dlouhou cestu, než budou za něco stát v komplexnějším pohledu, který je ale viditelný zas jen někomu, kdo si prošel a zkusil třeba několik desítek frameworků.
Díky za srovnání!
V prvé řadě oba frameworky, Zend i Nette, se ubírají dosti odlišným směrem. Dalo by se to připodobnit k rozdílu mezi Windows a Mac OSX. Kdo oba systémy vyzkouší, může vypíchnout, co se mu na kterém víc nebo méně líbilo - což je status quo. Zajímavější je to vidět v pohybu a dokázat odhadnout, jak vše bude vypadat třeba za rok, za dva. (A zcela souhlasím s Jirkou Kneslem, že oba frameworky mají ještě dlouho cestu před sebou, sám se cítím teprve na startu a hlavou plnou plánů).
Rysem Nette Frameworku je, že byl vždy inovativní. Píšeš třeba, že routování mají oba frameworky cca stejné (neumím posoudit), nicméně Nette je měl v roce 2007. Netuším, jaké (zda-li vůbec) má Zend debuggovací nástroje, Nette\Laděnka doprovází PHP programátory since 2008 a je to killer srovnatelný s Firebugem. A tak by se dalo pokračovat, přes podporu AJAXu, šablon, rychlost, takřka dokonalé odstínění od bezpečnostních děr, autoloadingu atd.
Nepíšu to proto, abych trumfovat featurama; naopak zcela otevřeně přiznávám, že chceš-li inovovat, občas narazíš na slepé cesty. Osobně vidím velký prostor právě v tom, co označuješ ?MVC? a také nástrojích produktivity. Do verze 1.0 dojde k zásadnímu posunu v MVC+komponenty+AJAX. Programovat AJAXové aplikace v Nette 1.x bude úplně fantastické.
Jestli v něčem nemohu souhlasit, tak to je část "Komunita, koncepce vývoje". Dobrý framework se nedá psát od stolu, musíš ho sám používat, být v kontaktu s komunitou a školit. Na Nette bez testů si vážně nepamatuju, díky "cool podpoře PHP 5.3" není potřeba dělat žádnou tlustou čáru jako v případě Zend 2.0, u šablonovacího systému si nejsem vědom WTF faktorů a pod kapotou funguje skvěle, proč by ho měla změna motoru posunula na jinou úroveň?
Ale asi rozumím, kam míříš: využití komunity je něco, kde cítím největší resty a chci se snažit zlepšovat.
[4] - nette bez testů - ano, "něco jako testy" tam bylo vždycky, bohužel to ale nikdy nebylo a pořád není integrální součástí frameworku jako je Zend_Test a jeho unit testy, nemluvě o dokumentaci jak to používat a co s tím dělat.
- podpora 5.3 hned z kraje je z mého uživatelského pohledu ukvapenost, která zbytečně natahuje a komplikuje vývoj a nepřinesla mi zhola nic, kromě nepoužitelných zdrojáků. Ten kdo jede teď na 5.2 a 0.9 bude muset přejít na 5.3 a 1.0, zůstat u 5.2 je nesmysl, a to bude stejně tlustá čára jako přejít na ZF 2, možná tlustší.
- šablony - každý šablonovací systém je z kraje WTF pro toho, kdo je zvyklý na použítí PHP jako šablonovacího jazyka (a to je téměř každý). Nový kompilovací motor umožní větší optimalizaci výsledného PHP a větší prostor pro zavedení debugu do šablon. Chyba v generovaném php šablony je totiž další šablonové WTF.
[5] Ale Mirku, vždyť pamatuješ, jak to bylo http://mirin.cz/en/blog/jmenne-prostory-namespaces-v-php-53 ?verze PHP 5.3, která ... bude vypuštěna někdy začátkem roku 2008.? Ve stejné době byl vypuštěn Nette Framework a tak ji plně podporoval.
PHP 5.3 bylo vypuštěno před více než rokem a ptám se: kdo dnes může programovat v plnohodnotném 5.3 frameworku s namespaces, programátoři s Nette nebo Zendem? A samozřejmě všechny verze Nette fungují pod PHP 5.2 a ještě cca rok budou.
(otazníky jsou uvozovky, zaměňuje se to samo)
Chtěl bych se zeptat přítomných PHPčkarů, jestli třeba neuvažovali o přechodu na Ruby on Rails, případně Django nebo jiné Ruby a Python frameworky? (no flame prosím).
Nejsem znalec PHP frameworků, ale z toho co o nich čtu mi přijde, že se často řeší věci, které jsou v Rails většinou už uspokojivě vyřešeny a většinou hluboce propracovány (samozřejmě důsledné MVC, několik propracovaných ORM, šablonování, debugging, testy, vše kolem AJAX, atd.), Prakticky na cokoliv se dá najít solidní gem (něco jako plugin/knihovna) - na http://rubygems.org/ je teď kolem 15 tisíc gemů. Taky komunita je zdá se nesrovnatelně větší (taky proto, že není roztříštěna mezi tolik frameworků). V core teamu je tuším 8 lidí, kteří na tom makají intenzivně, seznam kontributorů je taky docela dlouhej: http://contributors.rubyonrails.org/, existuje spousta kvalitní dokumentace, včetně knih, na google groups se dá najít odpověď prakticky na cokoliv a když ji nenajdu, tak na českým railsovým IRC kanálu je kdykoliv cca 10-20 lidí a na anglickým kolem 500 lidí.
Co Vás odrazuje od toho, abyste to zkusili? (znovu, no flame prosím)
Dík
Zkusil jsem Rails i Django a neměnil bych zpět, obojí mi přijde pro mé potřeby lepší než PHP... jen bohužel některé větší projekty se nepřepíšou ze dne na den, některé vůbec, a když má člověk takovéto pohrobky, které musí dál udržovat, ani se neohlídne a už je bohužel zpět u PHP... Druhá věc je nedostatečná poptávka a nedostatečný počet vývojářů, kteří by tyto frameworky ovládali.
Na to proč PHPčkaři (nechci křivdit všem, ale týká se to naprosté většiny) raději vymyslí kolo, než aby se porozhlédli jinde mám svoji teorii :)
[9] A ta teorie zní? Zajímalo by mě to.
Díky za článek. V hodně věcech s ním souhlasím.
Nicméně si nemyslím, že je naučení Zendu jednodušší než naučení Nette. Myslím, že v tomhle ohledu je na tom Nette lépe. Samozřejmě, že to platí pouze pro Čecha. Při hlubším zkoumání člověk ale naráží na dost magie, což je na škodu. Jak sledují vývoj různých nástrojů v PHP, tak tendence je spíše opačná. Dělat toho méně, ale dělat to transparentně. Stejně jako to dělají programy v Linuxu, když už David použil přirovnání k operačním systémům.
Nette je kvalitní framework, o tom žádná, klobou dolů před Davidem. Chce to ale, aby komunita dostala větší prostor. V jednom člověku se to dělat nedá.
To mazání tříd se mi taky nelíbí, taky si myslím, že je v Nette potřeba být na BC breaky opatrnější. Pokud jde o něco jako "chcete-li staré chování, upravte jen trošku BasePresenter", tak snad. I když i tady bych byl pro to, aby defaultní nastavení zůstalo staré a upravil se skeleton.
Deprecated je, bohužel, v dynamicky typovaném jazyku problematické kontrolovat. (V Javě označím třeba metodu jako @Deprecated a hned vidím, jestli/kde ji používám. A, pokud to nebylo vypuštěno ven jako nějaké API, hned vím, zda, popř. kdy to mohu smáznout.) V production je blbost warningy vypisovat a v logu nebo development módu se IMHO hodí.
K šablonám a chybám v nich: Tady jsem navrhoval řešení, bohužel, s minimální odezvou.
* Tady je diskuze: http://forum.nette.org/cs/3682-generovane-prekladane-zdrojaky-a-cisla-radku-typicky-sablony?pid=27015#p27015
* Tady je obecný popis problému (mnohem obecnější, než je pro PHP potřeba): http://v6ak.profitux.cz/clanky/proc-negenerovat-zdrojovy-kod.php
K ne-PHP řešením: Jako zastánce statického typování se dívám do světa Javy, trošku experimentuji, líbí se mi hlavně Play framework. Jazyk bych taky chtěl vyměnit, přecejen je Java trošku ukecanější, než by musela být (zhruba jako PHP). Dívám se třeba po Scale nebo Mirah, ještě uvidím. U PHP mě drží hlavně práce. Může student najít práci v JEE?
proč ne rails apod? protože je v nich mnohem složitější sehnat práci. navíc pokud již vnich práce je často se jedná o dost velké a náročné projekty, což pro někoho kdo z rails nědělá dost dlouho je problém. v php naproti tomu máš mnohem více i jednodušších projektů které jsou pro začátek ideální. ono je něco jiného když se tím bavítenebo když vás to má živit.
v php jsem zkusl kde co. v žádném frameworku nejsem guru ale kdybych měl volit rozhodoval bych se mezi nette/kohana/cakePHP zend ani symphony mě svým přístupem absolutně nezaujaly. každému vyhovuje něco jiného.
[12] v6sak - v článku popisuješ manipulaci s AST a právě tu by navrhovaný kompilátor šablon mohl zprostředkovat.
Na RoR bych přešel v práci velmi rád, ale rozhodnutí není na mě, moc reálně to nevidím. Ve volnu se mě v tom rýpat moc nechce. Django by bylo až za RoR. Mimochodem, první verze Perlu6 už jakž takž funguje :-).
Zajímavé je, že mnoho projektů má svého benevolentního diktátora, který je středem vesmíru a bez něj by to prostě nešlo.
Tak třeba:
Linux - Linus
Perl - Larry Wall
Ruby - Matz
Python - Guido van Rossum
Nette - Davídek
Jenom říkám.
PS: Jazyk budoucnosti je Scala - funkcionální a objektový - 2 za cenu jednoho.
[14] No, mohl. Ale zde to neřeší runtime chyby, kde by čísla řádků byla špatně. Třeba Lombok (pro Javu) manipuluje s AST, ale AST mu dovolí ponechat (nebo jakkoli upravit) čísla řádků. Takže anotací vygenerované gettery, settery a další metody (konstruktory, equals, hashCode) jsou jakoby na řádku, kde je daná anotace. A ostatní je na svém původním řádku. Takto to prostě nemůžeme udělat pomocí skutečných řádků, třeba u @Data by to bylo nemožné. V Javě je to řešeno právě pomocí zmíněného mapování offsetů bytecode na čísla řádků v kódu.
[15] Jo, Scala je pěkná. Ale někdy je problém ji pochopit. A plugin pro Eclipse, bohužel, nic moc. S Javovým pluginem pro Eclipse se to nedá srovnávat.
Ahoj, nejsem zadne php eso, ale nette se mi libilo diky tomu ze jsem jsem si mohl vse poskladat jak jsem potreboval, takze co uvadis jako vyhodu zend, tak ja vidim jako nevyhodu, zend mi prisel moc ukecanej nezlob se na me. Podle me je to jen tim ze jsi v zendu delal dele a ze jsi si ho vic navykl a vyhovuje ti, ale to neznamena ze je to lepsi framework, spis mi prijde obcas jako kladivo na vrabce v pripade mensich veci.
Komentáře jsou uzavřeny.