První minianketka je u konce s těmito výsledky:
- Spring MVC (36%)
- JSF (34%)
- Struts (16%)
- Něco jiného (14%)
- Samotné JSP a JSTL (8%)
- JBoss Seam (8%)
- Apache Wicket (6%)
- Spring Web Flow (6%)
- Tapestry (4%)
Hlasovalo celkem 61 lidí, takže se zrovna o velký vzorek lidí nejedná :(. Nechci z toho vyvozovat nějaké velké závěry, ale pár myšlenek si dovolím.
Pro mě osobně je Spring MVC a JSF volbou číslo jedna v současné době. Pokud potřebuji mít vše pod kontrolou, potřebuji mít rychlý web s velkou návštěvností, tak budu volit Spring MVC. Pokud si mohu dovolit JSF, tak volím JSF - tedy zejména pro intranetové aplikace, složité stránky a formuláře. Jedna volba nevylučuje druhou - JSF použiji třeba pro administrátorskou část aplikace, Spring MVC pro část prezentující data.
Struts mají silnou pozici z minulosti, takže na tom poběží pořád hodně projektů. Moc ale nepředpokládám, že by se toto řešení v nějaké větší míře používalo ještě dnes u nových projektů. Když už, tak aspoň Struts 2.
Tapestry jsou celkem staré (dnes je již beta verze páté verze) a ve své době měly několik revolučních věcí (např. provázání HTML a komponent přes speciální atribut, komponentový přístup), které ovšem v současné době jiné frameworky, které se nechaly inspirovat, řeší lépe (např. JSF Facelets, Apache Wicket). Musím se přiznat, že mě osobně nikdy moc Tapestry nezaujali.
Hodně by mě zajímalo, co se schovává pod "Něco jiného" u lidí, kteří tuto volbu zaškrtli. Možná Shale, WebWork, něco proprietárního, nevím...
Příspěvky
17 komentářů:
Tak pár oprav k Tapestry. Tapestry je již par měsíců ve verzi 5.
A co by mě zajímalo jestě víc, co řeší Wicket nebo JSF Facelets na komponentách lépe než Tapestry?
Ani jedine slovicko o Stripes...? :-(
Stripes moc neznám, tak jsem si na něj ani nevzpomněl, když jsem vybíral frameworky do ankety.
ad Tapestry: nenapadlo mě se ani podívat na jejich stránky, takže zde se omlouvám, opravím to.
Co se týče komponent, tak je to můj pocit, že Facelets provázání s HTML (přes atribut jsfc) a možnost vytváření komponent resp. částí stránek (<ui:composition/>) mají vyřešeno lépe. Mě prostě Tapestry přišly vždycky takové těžkopádné, ne úplně jednoduché.
U Wicket se mi libí objektovost a to, že se skutečně jedná o komponenty, které mohu vzít a znovu použít někde jinde. Takto jednoduché mi to v Tapestry nepřišlo.
Já jsem v Tapestry nikdy nic nedělal, jen jsem měl snahu se s nimi seznámit. Myslím, že to tehdy byla verze 2 nebo 3.
No pak musím doporučit přečíst si Tapestry - jak dělat webové aplikace konfortně, kde je pár moc zajímavých odkazů.
Co se komponent týče, já jsem nic jednoduššího než vytváření komponent v Tapestry a jejich skládání nenašel. Navíc na Wicket mě vadí to programování ala. Swing, kde vlastně vytvářím nejenom v HTML ale i v Java kódu strukturu komponent (krasně je to vidět na formuláři, jehož struktura je nadefinovaná nejenom v HTML ale i v Java kódu).
Co já vnímám jako zásadní rozdíl mezi Tapestry a Wicket je, že Tapestry má statický model komponent pro stránku a Wicket dynamický (podobně jako JSF). Jsou samozřejmě případy, kdy je to nevýhoda, ale ve většině je to velká výhoda, protože se nezaťěžuje sesion ukládáním stromu komponent a tudíž má Tapestry předpoklady pro podstatně větší škálovatelnost.
gwt?
Zaujímal by ma Váš názor na proprietárne riešenia. V poslednom čase mám pocit, že keď človek potrebuje nejaké kompaktné riešenie, v ktorom by sa rýchlejšie vyvíjalo, tak nemá inú možnosť ako si ten java framework napísať sám.
To je smutný, že jsem pro Wicket hlasoval sám samojediný :-(
Jinak já vidím jako zásadní rozdíl mezi Tapestry a Wicketem to, že Tapestry je architektonicky čisté, obsahuje plno interních speciálních jazyků, některé z nich v XML (to už možná u verze 5 neplatí?), zatímco Wicket jde čistě pragmatickou, přímočarou cestou.
Jo a s Wicketem lze taky přejít ze starší verze na novější :-)
> To je smutný, že jsem pro Wicket hlasoval sám samojediný
Ééé, prase, omlouvám se a jdu zpátky na základní školu :-)
Hmm zaujimava anketa. Ja sam pouzivam JSF framework. Kazdopadne musim povedat ze Wickety sa velmi zaujali. Rozdiel medzi JSF a wicketmi je asi vo tvorbe novych komponent resp. znovupouzitelnych casti stranok. Ten styl prace ako je to pri wicketoch mi pripomina asp.net (sorry ze to spominam) kde nemusim zbytocne oprogramovavat kopec tried aby som spravil jednoduchu komponentu a tiez spajanie jednoduchsich komponent do zlozitejsich mi pride strasne komplikovane co sposobuje aj to ze praca z JSF je podla mna dost narocna a vyskytuje sa potom aj velmi vela tazko opravitelnych chyb (tomahawk komponenty) pripadne je prakticky takmer nemozne ich upravit v rozumnom case. Preto by som bol rad keby sa v buducnosti presadil Wicket framework a urcite ho budem sledovat vo vyoji.
ad proprietární řešení: já jsem obecně proti jakémukoliv proprietárnímu řešení. Já s tímto přístupem vidím spíše samé nevýhody - údržba vlastního řešení, nemalé náklady s tím spojené, vlastní vývoj nebude nikdy na technologické špici ve srovnání s podobnými řešeními v open-source atd.
Je ale zase pravda, že hlavně teď s JSF nepoužíváme samotné JSF, ale máme kolem toho spoustu jiných knihoven, takže jsme si museli napsat nějaké vlastní rozšíření, ale vždy se jedná o rozšíření něčeho, ne vývoj vlastního řešení.
> Ten styl prace ako je to pri wicketoch mi pripomina asp.net
Nedávno jsem chtěl popsat Wicket jednou větou. A nakonec to skončilo u tvrzení Wicket je ASP.NET done right! :-)
Nestihol som sa zapojit do hlasovania. Pouzivam komponentovy Apache Cocoon. A celkom som si ho oblubil. Nie je ale moc rozsireny.jozef
Grails && Groovy
IMO Grails spada do trocha inej kategorie nez ostatne spominane frameworky, pretoze sa jedna skor o 'full stack' aplikacny framework nez o klasicky web framework. Grails na prezentacnej vrstve pouziva Spring MVC a Spring Web Flow zabalene do Groovy builderov, a tie v ankete spomenute boli.
+1 pre Tapestry 5. T5 je jednym z najrevolucnejsich web frameworkov poslednych rokov, ktory svojou jednoduchostou a flexibilitou dokaze vyrazne zvysit produktivitu vyvoja.
Taktiez by som si dovolil nesuhlasit s nazorom ze JSF je v sucasnosti vhodnym kandidatom na prakticke pouzitie. JSF v porovnani s Wicket resp. Tapestry 5 posobi skor ako predpotopne monstrum ktore je vhodne maximalne tak na premrhanie casu a frustraciu vsetkych zainteresovanych.
Osobne by som, v pripade klasickych web aplikacii, doporucoval uprednostnit uz spominane Wicket alebo Tapestry 5, podla toho ci uprednostnujete programovy (ala Swing) alebo deklarativny pristup k budovaniu uzivatelskeho rozhrania.
V pripade intranetovych aplikacii s komplexnym uzivatelsky rozhranim je v sucasnosti najlepsou volbou niektory z RIA frameworkov (Flex, Silverlight, GWT, ZK, Lazlo, Echo, a pod.).
ad JSF: nejsem vůbec velký zastánce JSF, ale jednu výhodu mají oproti jiným framworkům. Je to standard, je to součástí J2EE specifikace. To má třeba tu výhodu, že když hledáte nějaké externisty do týmu, tak spíše najdete někoho, kdo umí JSF než třeba Wicket nebo Tapestry. To je moje osobní zkušenost.
> ad JSF: nejsem vůbec velký zastánce JSF, ale jednu výhodu mají oproti jiným framworkům. Je to standard, je to součástí J2EE specifikace.
Fair enough. Uznavam ze v niektorych regionoch to moze byt problem. Na druhej strane si vsak treba spomenut ze rovnaky argument sa pred par rokmi pouzival na obhajobu EJB 2.x pred Spring Frameworkom, a staci si porovnat kde su EJB 2.x a Spring Framework dnes.
Faktom je tiez ze pri pouziti Wicket/Tapestry 5 si vystacite s mensim poctom vyvojarov nez pri pouziti JSF (vdaka vyssej produktivite). Takze urcite by som sa nebal experimentovat s novymi pokrokovymi technologiami len preto ze niesu oficialnym JEE standardom.
Okomentovat