ik sprak onlangs met een vriend over UI ontwikkeling. Hij is ook een programmeur sinds programmeren werd beschouwd als een geheimzinnige kunst (toen degenen onder ons die het deden werden beschouwd als Gandalf de grijze tegenover de Balrog). Of misschien zagen we onszelf zo. Hoe dan ook, beiden van ons zijn Java programmeurs voor een groot deel van die tijd.
we klaagden beiden over het feit dat het een context switch was om te gaan van het coderen van de meeste van onze projecten in Java, en vervolgens over te schakelen naar JavaScript voor de front-end.
op basis van gesprekken die ik online heb gezien, zijn verschillende lezers hun toetsenborden aan het opwarmen om mij te berispen voor het klagen over het moeten coderen in JavaScript. Houd uw sleutels koel, zowel van ons als onze medewerkers zijn ervaren in, en blij om te schrijven in, JavaScript en een van de frameworks voor onze klanten. Maar het gebruik van JavaScript is niet altijd de beste aanpak.
in dit bericht introduceren we twee frameworks waarmee je je gebruikersinterface in Java kunt coderen: GWT en Vaadin.
wanneer Java gebruiken voor uw gebruikersinterface?
het gesprek kwam bij me terug toen ik sprak met een cliënt — een kleine winkel van slechts een paar programmeurs en een software-architect die ook programmeerde. Ze hadden besloten dat ze hun projecten niet in twee verschillende talen wilden onderhouden. Hun bedrijf was gestandaardiseerd op Java en ze wilden dezelfde tools en mindset gebruiken om krachtige en moderne gebruikersinterfaces voor hun webapplicaties te creëren.
bij grotere teams heb ik gemerkt dat het team zich lijkt te scheiden, sommigen concentreren zich liever op de front-end, en anderen werken meestal op de back-end of server-side code. Wanneer het werk wordt goedgekeurd voor ontwikkeling, vaak zie ik dezelfde programmeurs ofwel nemen of krijgen de meerderheid van de JavaScript front-end werk, en anderen nemen op de back-end.
Ik zeg niet dat dit een slechte zaak is; eigenlijk lijkt het juist het tegenovergestelde te zijn. Iedereen lijkt productiever te zijn in zijn comfortzone, maar iedereen is zich ook bewust van wat iedereen doet en kan in die zone stappen als of wanneer dat nodig is. Voor kleinere winkels is dit geen optie. Vaak schrijft dezelfde programmeur de code een heel project van de gebruikersinterface naar het model.
gelukkig zijn er keuzes als u uw gebruikersinterface in dezelfde taal wilt houden als uw back-end als die taal Java is. Laten we het nu over een paar van hen hebben.
GWT
Google Web Toolkit, of GWT, is een uitstekende optie.
ik heb veel succes gehad met GWT op een project dat ik ongeveer 8 jaar geleden begon en nog steeds onderhoud. GWT liet me toe om de view logica voor een enkele pagina applicatie volledig in standaard Java-code te bouwen. Het wordt geleverd met een Eclipse plugin. Ik heb het niet gebruikt omdat ik Netbeans gebruikte voor mijn ontwikkelomgeving, maar aangezien Eclipse de standaard is voor de meeste teams, kan dit erg handig zijn.
ik was in staat om de logica voor widgets (zoals een aangepast tekstvak) op te splitsen in klassen of hulpmethoden, net zoals Ik business logic op een server-side project zou doen. Door overerving, ik was in staat om verschillende widgets die soortgelijke eisen gemakkelijk had creëren. Over het enige echte concept van verandering die ik had te maken met was dat de UI is veel meer event-driven dan de meeste webservices of andere server-side code.
er zijn twee primaire nadelen zie ik GWT. Een daarvan is de compilatietijd. GWT voegt een compilatiestap toe aan het proces dat wel enige tijd in beslag neemt. De GWT klassen die zijn gebouwd in Java moeten worden gecompileerd in JavaScript bibliotheken. Ik heb verschillende klachten gezien over de tijd die dit kost.
de tweede is dat het al een tijdje geleden is dat GWT een belangrijke update heeft gezien. Vanaf dit schrijven, 2.8.2 werd uitgebracht meer dan een jaar geleden in oktober 2017. Drie jaar eerder werd 2.7.0 uitgebracht, dus vier jaar na dit schrijven. Ik zie berichten en opmerkingen over 3.0 coming out, waaronder een aantal van twee jaar geleden met de vraag of de poster moet wachten op 3.0 om uit te komen voor de uitvoering van een grote verandering (Ik hoop dat de poster is niet nog steeds te wachten), maar ik kan geen tijdlijnen over wanneer die release zou kunnen worden uit.
hoewel ik een grote fan ben van het framework en het als volwassen genoeg beschouw, Weet ik dat deze vaagheid in de mogelijkheid van toekomstige releases sommige projectmanagers nogal nerveus maakt. Niemand wil gebonden zijn aan een raamwerk dat op hen doodloopt.
GWT is een bibliotheek die Ik zal blijven gebruiken en aan andere teams zal voorstellen om te gebruiken als het aan hun behoeften voldoet.
Vaadin
Vaadin is een andere geweldige optie.
oorspronkelijk dacht ik dat de GWT mijn enige keuze was voor het schrijven van gebruikersinterfaces in standaard Java-code. Maar toen ik met die kleine winkel sprak die ik hierboven noemde, vertelden ze me dat ze besloten hadden om Vaadin te gebruiken voor hun projecten. Dus, natuurlijk, moest ik gaan kijken. En ik ben onder de indruk.
Ik zal eerlijk zijn, op dit moment heb ik Vaadin nog niet gebruikt om een project aan te maken. Maar ik ben ramping up een paar persoonlijke projecten die ik front-ends voor nodig en van plan om dit te gebruiken. Als Vaadin zijn beloften waarmaakt, zal het een perfect kader zijn voor deze projecten.
Vaadin belooft talen te ondersteunen die in de JVM draaien, zoals Kotlin en Scala. Ik hoop dat dat ook Groovy is. Als je veel van mijn vorige berichten leest, weet je dat ik een fan ben van die taal, omdat je snel code kunt maken die gemakkelijk kan worden onderhouden. Dit zijn belangrijke eisen voor mij, vooral onderhoudbaarheid. Niets vernietigt een project op de weg meer dan het niet gemakkelijk kunnen onderhouden van de code die al is geschreven.
Final Thoughts
u hebt veel keuzes bij het ontwerpen van uw webapplicatie als het gaat om de technologie van de gebruikersinterface. Of u nu een project of een productieomgeving ontwerpt, u moet zoveel eisen in gedachten houden.
twee vereisten die u in gedachten moet houden zijn het gemak van ontwikkeling en onderhoudbaarheid.
- een ontwikkelomgeving die moeilijk is om in te werken, zal leiden tot veel kostenoverschrijdingen en het zeer moeilijk maken om nieuwe programmeurs aan te zetten.
- een moeilijk te onderhouden project zal in de toekomst frustraties veroorzaken en meer geld verspillen.
op basis van de behoeften en vereisten van uw team is een volledige Java-oplossing, van de gebruikersinterface tot het model, niet alleen mogelijk, maar ook een geweldige keuze voor zowel snelle ontwikkeling als onderhoudsgemak.
geloof in goede code.