Java web-framework kiezen

[Standeman]

Voor een nieuw project ben ik op zoek naar een (java!) web-framework om ons te helpen bij de ontwikkeling, zodat we niet zelf het wiel opnieuw uit moeten vinden. Uiteraard heb ik zitten rondneuzen over wat nu een verstandige, toekomstvaste, keuze is waarbij je applicaties redelijk snel kan ontwikkelen zonder bergen boilerplate code.

De frameworks die tegen gekomen ben in mijn zoektocht en wat nader heb bekeken zijn Wicket, Tapestry en JSF (+ richfaces of primefaces). Aangezien ik niet de tijd heb/krijg om met alle drie een kleine referentie implementatie te maken, ben ik op zoek naar advies / ervaringen met bovenstaande frameworks.

Voor zover ik heb nagelezen is heeft Tapestry de steilste learning curve, maar is verder redelijk vergelijkbaar met JSF. Wicket schijnt juist weer vrij eenvoudig te leren zijn.

Op dit moment heeft JSF mijn voorkeur, maar eigenlijk voornamelijk vanwege het feit dat het onderdeel is van de J2EE spec en omdat ik lange tijd geleden er al eens een project mee gedaan heb en dus wat ervaring heb (als is dat weer +5 jaar geleden met versie 1.2).

Verder zijn er nog andere frameworks zoals Grails en Play, maar daar ben ik nog niet dieper op in gegaan. GWT + SmartGWT is iets waar we al ervaringen mee hebben, maar niet al te blij mee zijn. Wat dat betreft valt die dus af.

[sub0kelvin]

Ik heb alleen ervaring met Wicket, wat het primaire framework bij mijn vorige werkgever was. Ik vond het altijd erg fijn werken. Het framework is erg helder, en heeft erg goede ondersteuning voor Spring en Hibernate, waardoor het allemaal heel natuurlijk in elkaar past. Als je alles een beetje door begint te krijgen kun je erg snel nieuwe dingen toevoegen zonder al te veel duplicatie.

De scheiding tussen template en code is erg groot, wat het erg makkelijk maakte om een prototype om te zetten in een werkend geheel. Ander voordeel was dat AJAX een first citizen is, waardoor je erg makkelijk modernere websites kunt maken zonder een uitgebreide javascript library te hoeven te gebruiken.

Play heb ik zelf niet gebruikt, maar oud-collega's van me wel en die waren er erg over te spreken. Aangezien ik nu ruby/rails ontwikkelaar ben kan ik me daar iets bij voorstellen, aangezien daar veel overeenkomsten zijn.

Iets anders dat je kunt overwegen, is bijv. Spring MVC. Dan ben je wel aangewezen tot een client framework zoals Batman.JS, maar kun je de backend erg schoon en simpel houden.

[HMS]

Aangezien ik best gecharmeerd ben van NancyFX op .NET, wat een Sinatra (uit Ruby) geinspireerd framework is, zou ik zoiets zoeken. Ik zie dat Spark (http://www.sparkjava.com/) daar wel bij in de buurt komt.

Disclaimer: ik heb geen ervaring met Spark .

[Hydra]

Kijk ook eens naar 't Play Framework. Heb er zelf wat mee gespeeld (niet professioneel) en ben er erg van gecharmeerd.

[majoh]

Als je ervaring met GWT hebt, maar het niet echt prettig vind, kijk dan eens naar Vaadin. Gebaseerd op GWT alleen dan 'beter'. Vind het zelf wel iets hebben.

JSF vind ik persoonlijk helemaal niets, en ga ik met een grote boog omheen.

Verder gebruik ik vaak toch Spring MVC met een los frontend framework...

[Kettrick]

Hydra schreef op vrijdag 17 januari 2014 @ 18:48:
Kijk ook eens naar 't Play Framework. Heb er zelf wat mee gespeeld (niet professioneel) en ben er erg van gecharmeerd.

Ik heb meerdere backend applicaties in elkaar gezet met behulp van play ( scala api ) en ben er erg tevreden mee.

Feedback loop is enorm goed en het feit dat je al het tomcat/ee geneuzel achter je kan laten is een verademing

[reinouts]

Ik heb goede ervaringen met Wicket. Geen doorslaggevend argument maar wel aardig is dat veel Wicket-ontwikkelaars uit Nederland komen. Goede community ook.

[pedorus]

Met dezelfde vraag ben ik ongeveer op dezelfde manier bij JPA+JSF+Primefaces uitgekomen (latest and greatest). Na wat gekke dingen rondom caching van JPA, login realms die niet standaard het juiste bieden enzo draait het vrij aardig. In zijn algemeenheid is het wel een stateful framework op stateless http, dus je moet waarschijnlijk bedenken wat je dan doet.

Ingewikkelde delen aan de frontend gebeuren deels met Jquery gebaseerde componenten, aangezien Primefaces (=JQuery gebaseerd) niet alles biedt, zoals een nuttige datetimepicker zonder gekke schuifjes of ingewikkeldere zaken. Het valt me op dat Primefaces weleens breekt bij upgrades, met dependencies of met de integratie met stukjes puur javascript.

Veel hangt natuurlijk ook af van wat voor applicatie je precies wil ontwikkelen.

HMS schreef op vrijdag 17 januari 2014 @ 17:41:
Ik zie dat Spark (http://www.sparkjava.com/) daar wel bij in de buurt komt.

Disclaimer: ik heb geen ervaring met Spark .

Lijkt me meer op iets als python/flask, perfect voor kleine dingen, maar vast minder handig met grotere apps. Voor zoiets zou ik sowieso al geen voorkeur hebben voor java..

reinouts schreef op vrijdag 17 januari 2014 @ 19:57:
Ik heb goede ervaringen met Wicket. Geen doorslaggevend argument maar wel aardig is dat veel Wicket-ontwikkelaars uit Nederland komen. Goede community ook.

Enkel die community is waarschijnlijk helaas een stuk kleiner dan jsf - http://stackoverflow.com/tags/jsf vs http://stackoverflow.com/tags/wicket is een factor ~10.

majoh schreef op vrijdag 17 januari 2014 @ 18:56:
JSF vind ik persoonlijk helemaal niets, en ga ik met een grote boog omheen.

Heb je het hier over JSF>=2 en zo ja waarom? Vooral ook leeswaardig is dit antwoord van BalusC, bekend van Tweakers: http://stackoverflow.com/a/3646940

edit:
Deze post is helaas niet openbaar

[Kwistnix]

Mijn ervaring is dat Wicket niet veel eenvoudiger is dan andere oplossingen.
De erg strikte scheiding tussen de HTML templates en de Java code heeft voordelen en nadelen. Het is een voordeel voor wat betreft testbaarheid van de Wicket componenten. Ook is het design van de componenten makkelijk bij een niet-ontwikkelaar neer te leggen, want je kan er volledig geldige HTML van maken om het ontwerp te bekijken/testen - runtime wordt alle HTML buiten de wicket tags er toch uit gestript.
Een nadeel vind ik dat de Java code heel snel nogal wollig wordt, zeker wanneer er niet veel ervaring met het framework is binnen een team. De verleiding om, bijvoorbeeld, te pas en te onpas anonieme inner classes te gebruiken is nogal groot. Ook is het gebruik / de noodzaak van verschillende Model implementaties achter de componenten niet direct heel intuïtief, maar dat went. Het is wel noodzakelijk om dat zo snel mogelijk duidelijk te krijgen, want als je een nogal zwaar domein model hebt en geen LoadableDetachableModel aanpak toepast, dan blaas je binnen no-time de sessie op met geserialiseerde versies van stateful pagina's.

Als ik zelf zou moeten kiezen zou ik op dit moment denk ik voor JSF 2 gaan, maar die voorkeur is niet heel sterk. Wicket is ook een prima framework met een actieve community en frequente updates.

[ Voor 8% gewijzigd door Kwistnix op 17-01-2014 21:39 ]

[Dricus]

JSF en Wicket verschillen qua concept niet heel veel van elkaar: Ze zijn allebei component-based, bij beide frameworks wordt viewstate op de server bijgehouden. Naar mijn mening zijn er een aantal nadelen van Wicket ten opzichte van JSF.

IDE ondersteuning
De IDE ondersteuning die ik gezien heb voor Wicket is minimaal. Dit merk je vooral bij het refactoren. De koppeling tussen je HTML en je code-behind werkt met id's die je in je Java code met strings moet linken.

Voorbeeld:

HTML:

<span wicket:id="titel"></span>

Java:

Label titel = new Label("titel");

Als je titel wil hernoemen, dan is er bij mijn weten geen IDE of plugin die daarvoor handige refactoring ondersteuning biedt. Dit wordt nog vervelender als je met (Compound)PropertyModels gaat werken om Wicket ID's automagisch te koppelen aan eigenschappen van je domeinclasses. Eerlijk is eerlijk: Dit doe je niet súper vaak, maar als je het dan toch doet, moet je goed opletten.

Wat dit betreft scoort JSF beter. Netbeans bijvoorbeeld ondersteunt bovenstaand scenario out of the box met JSF.

Unit testing
Het unit testing framework van Wicket werkt op zich wel, maar is niet altijd even gemakkelijk te gebruiken en werkt ook niet altijd fijn.

Voorbeeld: Je maakt een custom panel met eigen HTML. Gezien het gedoe met ID's zoals hierboven beschreven vind ik het wel handig om een unit test te schrijven die het spul rendert, zodat ik snel mismatches tussen Java en HTML in Wicket ID's vind. Voor hele pagina's werkt dit goed, maar als je een custom panel maakt en deze in isolatie wilt unit testen dan zal je unit test niet falen op ID mismatches.

Daarnaast zijn dit soort unit tests ook niet echt snel en dat ontmoedigt het schrijven van unit tests.

De code-behind van JSF is een Plain Old Java Object (POJO) en daardoor vanzelfsprekend erg goed te unit-testen.

Boilerplate code
Met Wicket moet je voor elke niet-triviale pagina behoorlijk veel boilerplate code schrijven om de code-behind aan je HTML te "koppelen". Voor elke tag in je HTML met een wicket:id attribuut moet je minstens één regel code schrijven om er een Wicket component aan te koppelen (zie bovenstaand voorbeeld). Alle instellingen op een component moet je in je Java code doen, dus vaak blijft het niet beperkt tot één regel. Om die code een beetje overzichtelijk te houden ga je al snel over tot het maken van factory methods om geïnitialiseerde componenten te krijgen.

Met JSF heb je dit soort boilerplate code niet.

[Standeman]

majoh schreef op vrijdag 17 januari 2014 @ 18:56:
JSF vind ik persoonlijk helemaal niets, en ga ik met een grote boog omheen.

Dat maakt me wel benieuwd naar jouw onderbouwing.. Waarom loop je er met een grote boog omheen, of is die mening gestoeld op de onvolkomenheden van JSF 1.2?

pedorus schreef op vrijdag 17 januari 2014 @ 20:47:
....

Ingewikkelde delen aan de frontend gebeuren deels met Jquery gebaseerde componenten, aangezien Primefaces (=JQuery gebaseerd) niet alles biedt, zoals een nuttige datetimepicker zonder gekke schuifjes of ingewikkeldere zaken. Het valt me op dat Primefaces weleens breekt bij upgrades, met dependencies of met de integratie met stukjes puur javascript.

Veel hangt natuurlijk ook af van wat voor applicatie je precies wil ontwikkelen.
...

De applicatie zelf wordt iig geen standaard CRUD ding. Zaken zoals KPI's (met leuke grafiekjes), locatie gegevens t.b.v tracking van devices en voertuigen (met Google Maps), planning, android apps die er mee praten, etc.
Wat dat betreft zit er genoeg uitdagingen in

Dricus schreef op vrijdag 17 januari 2014 @ 21:51:
heel goed verhaal...

Jouw antwoord en de overige commentaren op wicket (o.a. van FallenAngel666), neig ik steeds meer naar JSF met een prime / richfaces sausje er overheen.

Voor JSF geld nu:
+ grote community
+ industry standard
+ weinig boilerplate
+ eenvoudig(er) testbaar

Op de overige punten zijn de voordelen imo niet groot genoeg om een andere keuze te rechtvaardigen.

[JordyOnrust]

Ik zou zeggen Wicket.
Misschien heb je hier iets aan? https://m.facebook.com/ev...885647606497?aref=22&_ft_

[Standeman]

hmmm, jammer dat Deventer voor mij zo'n takke-eind rijden is

[Tubby]

Spring MVC i.c.m. met een clean html/jQuery frontendje erop, of Grails als je relatief snel wil starten; dat is onder de motorkap Spring MVC met wat conventies en een Groovy sausje erover heen.

Persoonlijk heb ik geen goede verhalen verhalen gehoord over JSF of Wicket maar nooit zelf direct mee gewerkt. Bovendien is de community rondom Spring behoorlijk goed.

(de eerst hit op google; maar wellicht een mooie vergelijking)
http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/

[ Voor 33% gewijzigd door Tubby op 20-01-2014 12:35 ]

[SPee]

Standeman schreef op maandag 20 januari 2014 @ 10:21:
[...]
De applicatie zelf wordt iig geen standaard CRUD ding. Zaken zoals KPI's (met leuke grafiekjes), locatie gegevens t.b.v tracking van devices en voertuigen (met Google Maps), planning, android apps die er mee praten, etc.
Wat dat betreft zit er genoeg uitdagingen in

[...]

Jouw antwoord en de overige commentaren op wicket (o.a. van FallenAngel666), neig ik steeds meer naar JSF met een prime / richfaces sausje er overheen.

Voor JSF geld nu:
+ grote community
+ industry standard
+ weinig boilerplate
+ eenvoudig(er) testbaar

Op de overige punten zijn de voordelen imo niet groot genoeg om een andere keuze te rechtvaardigen.

Ik denk dat in dit geval de grotere flexabiliteit van Wicket een voordeel is.
Bij JSF zit je veel vast aan wat het framework jouw biedt. Je kan wel zelf componenten maken, maar dat kost meer werk/ervaring dan bij Wicket.

Als de webapplicatie meer richting formulieren en simpele rapportjes blijft, dan is JSF de juiste keuze. Maar zijn hier speciale dingen nodig, dan zal (bij mij) meer de keus naar wicket gaan.
(bij services zit het verschil niet)

[majoh]

Standeman schreef op maandag 20 januari 2014 @ 10:21:
[...]

Dat maakt me wel benieuwd naar jouw onderbouwing.. Waarom loop je er met een grote boog omheen, of is die mening gestoeld op de onvolkomenheden van JSF 1.2?

Dat had ik erbij moeten vertellen, mijn mening is inderdaad gebaseerd op de oude spec... De nieuwe spec heb ik nog niet naar gekeken aangezien ik daar de noodzaak nog niet voor had/heb.

Op mijn werk houden we vast aan de beproefde formule Spring MVC met frontend lib omdat dit een bewezen onderhoudbaar en stabiele oplossing voor ons is.

Tubby schreef op maandag 20 januari 2014 @ 12:32:
[..]

(de eerst hit op google; maar wellicht een mooie vergelijking)
http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/

Het artikel wat Tubby hier aanhaald heb ik in het verleden ook al eens doorgelezen, en ze hebben daar ook een vervolg op geschreven:

http://zeroturnaround.com...o-java-web-frameworks/13/

Een goed leesbaar artikel. Waarin Vaadin (eerder aangehaald ), Play en Grails de 'winnaars' zijn. Echter ook daar aangehaald, er zijn zo veel factoren waarom je de een of de andere zou moeten of kunnen kiezen dat het moeilijk blijft om de perfecte keuze te maken.

Succes met je keuze, ik ben erg benieuwd.

[Lethalis]

Ik wil zelf java web development leren en ik kom vooral uit op jsf icm primefaces. Ook al handige tutorials en ebooks over gevonden (bijv van Packt publishing).

Het schijnt dat het ook goed te combineren met Spring is, maar ik begeef me nog op glad ijs met dit onderwerp.

Binnenkort maar eens een testproject maken

Overigens vind ik het argument dat je geen tijd krijgt wel begrijpelijk, maar erg jammer. Omdat een dergelijke keuze moeilijk terug te draaien is.

Dat gezegd hebbende, is JSF wel min of meer de standaard als ik Oracle mag geloven en dus een vrij 'veilige' keuze. Ik heb nu ook zoiets van "ik leer dit eerst en kijk daarna wel verder".

Correct me if I'm wrong Ik begin net met Java EE.. ben eigenlijk .Net ontwikkelaar met veel Asp.net ervaring en JSF lijkt daar het meeste op.

Wat ik overigens mis in het verhaal van ts: wat is de ervaring van het team? Welk framework past het beste bij hun werkervaring? Dat zal namelijk voor een groot deel het succes bepalen van de keuze.

[ Voor 17% gewijzigd door Lethalis op 23-02-2014 19:12 ]