jeg snakket nylig med en venn om UI-utvikling. Han har også vært programmerer siden programmering ble ansett som en arcane kunst (da de av oss som gjorde det, ble ansett Som Gandalf The Grey vendt Mot Balrog). Eller kanskje vi bare så oss selv på den måten. Uansett, begge av Oss har Vært Java-programmerere for en god del av den tiden.
Vi beklaget begge at det var en kontekstbryter å gå fra å kode de fleste av våre prosjekter I Java, og måtte bytte Til JavaScript for frontenden.
basert på samtaler jeg har sett på nettet, oppvarmer flere lesere tastaturene sine for å chide meg for å klage på å måtte kode I JavaScript. Keep your keys cool, Både av oss og våre medarbeidere er erfarne i, Og gjerne skrive I, JavaScript og noen av sine rammer for våre kunder. Men Å Bruke JavaScript er ikke alltid den beste tilnærmingen.
i dette innlegget introduserer vi to rammer som lar deg kode brukergrensesnittet I Java: GWT Og Vaadin.
Når Skal Du Bruke Java FOR BRUKERGRENSESNITTET ditt?
samtalen kom tilbake til meg da jeg snakket med en klient — en liten butikk med bare et par programmerere og en programvarearkitekt som også programmerte. De hadde bestemt seg for at de ikke ønsket å opprettholde sine prosjekter på to separate språk. Deres firma hadde standardisert På Java, og de ønsket å bruke de samme verktøyene og tankegangen for å skape kraftige og moderne brukergrensesnitt for deres webapplikasjoner.
jeg har lagt merke til på større lag at laget ser ut til å skille seg, noen foretrekker å konsentrere seg om frontenden, og andre jobber mest på back-end eller server-side kode. Når arbeidet blir godkjent for utvikling, ser jeg ofte de samme programmererne enten å ta eller bli gitt flertallet Av JavaScript-frontend-arbeidet, og andre tar på back-end.
jeg sier ikke at dette er en dårlig ting; faktisk ser det ut til å være det motsatte. Alle ser ut til å være mer produktive i sin komfortsone, men alle er også klar over hva alle andre gjør og kan gå inn i den sonen hvis eller når det trengs. For mindre butikker er dette ikke et alternativ. Ofte vil samme programmerer skrive koden et helt prosjekt fra brukergrensesnittet til modellen.
Heldigvis er det valg hvis du ønsker å beholde brukergrensesnittet på samme språk som back-end hvis det språket Er Java. La oss snakke om noen av dem nå.
GWT
Google Web Toolkit, ELLER GWT, er et utmerket alternativ.
JEG har hatt stor suksess MED GWT på et prosjekt jeg startet for 8 år siden og fortsatt opprettholder. GWT tillot meg å bygge visningslogikken for et Enkeltsideprogram helt i standard Java-kode. Den leveres med En Eclipse plugin. Jeg brukte Det ikke fordi Jeg brukte Netbeans for utviklingsmiljøet mitt, men Som Eclipse er standarden for de fleste lag, kan dette være veldig nyttig.
jeg klarte å bryte ned logikken for widgets( for eksempel en tilpasset tekstboks), i klasser eller hjelpemetoder, akkurat som jeg ville forretningslogikk på et server-sideprosjekt. Gjennom arv var jeg i stand til å lage flere widgets som hadde lignende krav enkelt. Om det eneste virkelige konseptet om endring jeg måtte håndtere var AT BRUKERGRENSESNITTET er mye mer hendelsesdrevet enn de fleste webtjenester eller annen server-side kode.
det er to primære ulemper jeg ser TIL GWT. Den ene er kompileringstid. GWT legger til et kompileringstrinn i prosessen som tar litt tid. GWT-klassene som er bygget I Java, må kompileres i JavaScript-biblioteker. Jeg har sett flere klager om tiden dette tar.
den andre er at DET har vært en stund SIDEN GWT har sett en betydelig oppdatering. I skrivende stund ble 2.8.2 utgitt for over et år siden i oktober 2017. Tre år før, 2.7.0 ble utgitt, noe som gjør det fire år fra tidspunktet for denne skrivingen. Jeg ser innlegg og kommentarer om 3.0 kommer ut, inkludert noen fra to år siden spør om plakaten skal vente på 3.0 for å komme ut før du implementerer en stor endring (jeg håper plakaten ikke venter fortsatt), men jeg kan ikke finne noen tidslinjer for når den utgivelsen kan være ute.
Selv om jeg er en stor fan av rammen og anser det for å være modent nok som det er, vet jeg at denne vagheten i muligheten for fremtidige utgivelser gjør noen prosjektledere ganske nervøse. Ingen ønsker å være bundet til et rammeverk som døde ender på dem.
GWT ER et bibliotek som jeg vil fortsette å bruke og foreslå for andre lag å bruke hvis det oppfyller deres behov.
Vaadin
Vaadin Er et annet flott alternativ.
jeg trodde OPPRINNELIG GWT var mitt eneste valg for å skrive brukergrensesnitt i standard Java-kode. Men da jeg snakket med den lille butikken jeg nevnte ovenfor, fortalte de meg at De hadde bestemt Seg For Å bruke Vaadin til sine prosjekter. Så selvfølgelig måtte jeg ta en titt. Og jeg er imponert.
jeg skal være ærlig, fra og med denne skrivingen har Jeg ennå ikke brukt Vaadin til å lage et prosjekt. Men jeg ramper opp et par personlige prosjekter jeg trenger frontender for og har tenkt å bruke dette. Hvis Vaadin leverer på sine løfter, vil Det være et perfekt rammeverk for disse prosjektene.
Vaadin lover å støtte språk som kjører I JVM som Kotlin og Scala. Jeg håper det inkluderer Groovy. Hvis du leser mange av mine tidligere innlegg, vet du at jeg er en fan av det språket fordi du raskt kan lage kode som lett kan vedlikeholdes. Dette er viktige krav for meg, spesielt vedlikehold. Ingenting ødelegger et prosjekt nedover veien mer enn ikke å kunne enkelt vedlikeholde koden som allerede er skrevet.
Final Thoughts
du har mange valg når du designer webapplikasjonen din når det gjelder brukergrensesnittteknologi. Enten du designer et prosjekt eller et produksjonsmiljø, har du så mange krav å huske på.
To krav du må huske på er enkel utvikling og vedlikehold.
- et utviklingsmiljø som er vanskelig å jobbe i vil resultere i mange kostnadsoverskridelser og gjøre bringe nye programmerere på svært vanskelig.
- et prosjekt som er vanskelig å vedlikeholde vil føre til frustrasjoner og kaste bort mer penger i fremtiden.
basert på teamets behov og krav, er en Full Java-løsning, fra brukergrensesnitt til modell, ikke bare mulig, men et godt valg for både rask utvikling og enkelt vedlikehold.
Tro på god kode.