jag pratade nyligen med en vän om UI-utveckling. Han har också varit programmerare sedan programmering ansågs vara en svårbegriplig konst (när de av oss som gjorde det ansågs som Gandalf den grå inför Balrog). Eller kanske såg vi oss själva på det sättet. Oavsett, vi båda har varit Java programmerare för en stor del av den tiden.
vi beklagade båda det faktum att det var en kontextbrytare att gå från att koda de flesta av våra projekt i Java och sedan behöva byta till JavaScript för fronten.
baserat på konversationer som jag har sett online, värmer flera läsare upp sina tangentbord för att chide mig för att klaga på att behöva koda i JavaScript. Håll dina nycklar svala, både vi och våra medarbetare har erfarenhet av, och gärna skriva in, JavaScript och någon av dess ramar för våra kunder. Men att använda JavaScript är inte alltid det bästa sättet.
i det här inlägget introducerar vi två ramar som låter dig koda ditt användargränssnitt i Java: GWT och Vaadin.
När ska du använda Java för ditt användargränssnitt?
konversationen kom tillbaka till mig när jag pratade med en klient — en liten butik med bara ett par programmerare och en mjukvaruarkitekt som också programmerade. De hade beslutat att de inte ville behålla sina projekt på två separata språk. Deras företag hade standardiserat på Java, och de ville använda samma verktyg och tankesätt för att skapa kraftfulla och moderna användargränssnitt för sina webbapplikationer.
jag har märkt på större lag att laget verkar skilja sig, vissa föredrar att koncentrera sig på front-end, och andra arbetar mestadels på back-end eller server-side kod. När arbetet blir godkänt för utveckling ser jag ofta att samma programmerare antingen tar eller får majoriteten av JavaScript-front-end-arbetet, och andra tar på sig back-end.
jag säger inte att detta är en dålig sak; faktiskt, det verkar vara precis tvärtom. Alla verkar vara mer produktiva i sin komfortzon, men alla är också medvetna om vad alla andra gör och kan gå in i den zonen om eller när det behövs. För mindre butiker är detta inte ett alternativ. Ofta kommer samma programmerare att skriva koden ett helt projekt från användargränssnittet till modellen.
lyckligtvis finns det val om du vill behålla ditt användargränssnitt på samma språk som din back-end om det språket är Java. Låt oss prata om några av dem nu.
GWT
Google Web Toolkit, eller GWT, är ett utmärkt alternativ.
jag har haft en hel del framgång med GWT på ett projekt som jag startade om 8 år sedan och fortfarande behålla. GWT tillät mig att bygga visningslogiken för en enkelsidig applikation helt i standard Java-kod. Den levereras med en Eclipse plugin. Jag använde det inte eftersom jag använde Netbeans för min utvecklingsmiljö, men eftersom Eclipse är standarden för de flesta lag kan det vara mycket praktiskt.
jag kunde bryta ner logiken för widgets (till exempel en anpassad textruta), i klasser eller hjälpmetoder, precis som jag skulle affärslogik på ett serverprojekt. Genom arv kunde jag enkelt skapa flera widgets som hade liknande krav. Om det enda verkliga begreppet förändring jag var tvungen att ta itu med var att användargränssnittet är mycket mer händelsestyrt än de flesta webbtjänster eller annan kod på serversidan.
det finns två primära nackdelar jag ser till GWT. En är kompileringstiden. GWT lägger till ett kompileringssteg i processen som tar lite tid. GWT-klasserna som har byggts i Java måste kompileras i JavaScript-bibliotek. Jag har sett flera klagomål om den tid det tar.
den andra är att det har varit ett tag sedan GWT har sett en betydande uppdatering. När detta skrivs släpptes 2.8.2 för över ett år sedan i oktober 2017. Tre år tidigare släpptes 2.7.0, vilket gjorde det fyra år från skrivandet. Jag ser inlägg och kommentarer om 3.0 som kommer ut, inklusive några från två år sedan frågar om affischen ska vänta på 3.0 att komma ut innan man genomför en stor förändring (jag hoppas att affischen inte väntar fortfarande), men jag kan inte hitta några tidslinjer för när den utgåvan kan vara ute.
även om jag är ett stort fan av ramverket och anser att det är moget nog som det är, vet jag att denna vaghet i möjligheten till framtida utgåvor gör vissa projektledare ganska nervösa. Ingen vill vara bunden till ett ramverk som slutar på dem.
GWT är ett bibliotek som jag kommer att fortsätta använda och föreslå för andra lag att använda om det uppfyller deras behov.
Vaadin
Vaadin är ett annat bra alternativ.
jag trodde ursprungligen att GWT var mitt enda val för att skriva användargränssnitt i standard Java-kod. Men när jag pratade med den lilla butiken som jag nämnde ovan berättade de för mig att de hade bestämt sig för att använda Vaadin för sina projekt. Så, självklart, jag var tvungen att gå och titta. Och jag är imponerad.
jag ska vara ärlig, när detta skrivs har jag ännu inte använt Vaadin för att skapa ett projekt. Men jag ramp upp ett par personliga projekt jag behöver front-ends för och har för avsikt att använda detta. Om Vaadin levererar sina löften kommer det att vara en perfekt ram för dessa projekt.
Vaadin lovar att stödja språk som körs i JVM som Kotlin och Scala. Jag hoppas att det inkluderar Groovy. Om du läser många av mina tidigare inlägg vet du att jag är ett fan av det språket eftersom du snabbt kan skapa kod som enkelt kan underhållas. Det här är viktiga krav för mig, särskilt underhåll. Ingenting förstör ett projekt på vägen mer än att inte enkelt kunna behålla den kod som redan har skrivits.
slutliga tankar
du har många val när du skapar din webbapplikation när det gäller användargränssnittsteknik. Oavsett om du skapar ett projekt eller en produktionsmiljö har du så många krav att tänka på.
två krav du måste tänka på är enkel utveckling och underhåll.
- en utvecklingsmiljö som är svår att arbeta i kommer att resultera i många kostnadsöverskridanden och göra nya programmerare mycket svåra.
- ett projekt som är svårt att underhålla kommer att orsaka frustrationer och slösa mer pengar i framtiden.
baserat på ditt teams behov och krav är en fullständig Java-lösning, från användargränssnittet till modellen, inte bara möjlig utan ett utmärkt val för både snabb utveckling och enkel underhåll.
tro på bra kod.