keskustelin äskettäin ystäväni kanssa käyttöliittymien kehittämisestä. Hän on myös ollut ohjelmoija siitä lähtien, kun ohjelmointia pidettiin salaisena taiteena (kun niitä meistä, jotka sen tekivät, pidettiin kuin Gandalf harmaata balrogin edessä). Tai ehkä me vain näimme itsemme niin. Siitä huolimatta, molemmat meistä ovat olleet Java ohjelmoijia paljon siitä ajasta.
me molemmat valitimme sitä, että se oli asiayhteyden VAIHTO siirtyä koodaus suurin osa projekteistamme Java, sitten tarvitse siirtyä JavaScript etupää.
netissä näkemieni keskustelujen perusteella useat lukijat lämmittelevät näppäimistöjään soimatakseen minua siitä, että minun on pakko koodata Javascriptissä. Keep your keys cool, molemmat meistä ja työtovereiden ovat kokeneita, ja mielellään kirjoittaa, JavaScript ja kaikki sen puitteet asiakkaillemme. Mutta käyttämällä JavaScript ei ole aina paras lähestymistapa.
tässä viestissä esittelemme kaksi kehystä, joiden avulla voit koodata käyttöliittymääsi Java-kielellä: GWT ja Vaadin.
milloin Javaa käytetään käyttöliittymässä?
keskustelu palasi mieleeni, kun olin puhumassa erään asiakkaan kanssa — pienen puodin, jossa oli vain pari ohjelmoijaa ja ohjelmistoarkkitehti, joka myös ohjelmoi. He olivat päättäneet, etteivät he halua ylläpitää projektejaan kahdella eri kielellä. Heidän yrityksensä oli standardoitu Java, ja he halusivat käyttää samoja työkaluja ja ajattelutapa luoda tehokkaita ja moderneja käyttöliittymiä web-sovelluksia.
olen huomannut isommissa tiimeissä, että joukkue tuntuu erottautuvan toisistaan, toiset keskittyvät mieluummin etupäähän ja toiset työskentelevät enimmäkseen takapään tai palvelinpuolen koodin parissa. Kun work get ’ s hyväksytty kehittämiseen, usein näen samat ohjelmoijat joko ottaen tai annetaan suurin osa JavaScript front-end työtä, ja muut ottaen back-end.
en sano, että tämä olisi huono asia, itse asiassa asia näyttää olevan juuri päinvastoin. Jokainen tuntuu olevan tuotteliaampi mukavuusalueellaan, mutta jokainen on myös tietoinen siitä, mitä muut tekevät ja voi astua sille vyöhykkeelle, jos tai kun sitä tarvitaan. Pienemmille kaupoille tämä ei ole vaihtoehto. Usein sama ohjelmoija kirjoittaa koodille kokonaisen projektin käyttöliittymästä malliin.
onneksi on olemassa vaihtoehtoja, Jos haluat pitää käyttöliittymäsi samalla kielellä kuin taustapäätkin, jos kyseinen kieli on Java. Puhutaan nyt muutamasta.
GWT
Googlen Web Toolkit eli GWT on erinomainen vaihtoehto.
minulla on ollut paljon menestystä GWT: n kanssa projektissa, jonka aloitin noin 8 vuotta sitten ja joka jatkuu edelleen. GWT: n avulla pystyin rakentamaan yksisivuisen sovelluksen näkymälogiikan täysin tavallisella Java-koodilla. Sen mukana Eclipse plugin. En käyttänyt sitä, koska käytin Netbeans minun kehitysympäristö, mutta Eclipse on standardi useimmille joukkueille, tämä voisi olla erittäin kätevä.
pystyin pilkkomaan widgetien (kuten mukautetun tekstilaatikon) logiikan luokkiin tai auttaja-menetelmiin, aivan kuten olisin liiketoiminnan logiikka palvelinpuolen projektissa. Kautta perintö, pystyin luomaan useita widgetit, joilla oli samanlaisia vaatimuksia helposti. Tietoja ainoa todellinen käsite muutoksen jouduin käsittelemään oli, että UI on paljon enemmän tapahtuma-ajettu kuin useimmat verkkopalvelut tai muut palvelinpuolen koodi.
näen GWT: ssä kaksi ensisijaista varjopuolta. Yksi on käännösaika. GWT lisää prosessiin käännösvaiheen, joka vie jonkin aikaa. Javaan rakennetut GWT-luokat on koottava JavaScript-kirjastoihin. Olen nähnyt useita valituksia siitä, kuinka paljon aikaa tämä vie.
toinen on se, että siitä on jo aikaa, kun GWT on nähnyt merkittävän päivityksen. Tätä kirjoitettaessa 2.8.2 julkaistiin runsas vuosi sitten lokakuussa 2017. Kolme vuotta aiemmin julkaistiin 2.7.0, eli neljä vuotta tämän kirjoittamisen jälkeen. Näen viestejä ja kommentteja noin 3.0 tulossa ulos, mukaan lukien jotkut kaksi vuotta sitten pyytää, jos juliste pitäisi odottaa 3.0 tulla ulos ennen täytäntöönpanoa iso muutos (toivon juliste ei ole vielä odottaa), mutta en löydä mitään aikatauluja siitä, milloin kyseinen julkaisu voisi olla pois.
vaikka olen kehikon suuri fani ja pidän sitä riittävän kypsänä sellaisena kuin se on, tiedän, että tämä epämääräisyys tulevien julkaisujen mahdollisuudessa saa jotkut projektipäälliköt hermostumaan. Kukaan ei halua tulla sidotuksi kehykseen, joka johtaa umpikujaan.
GWT on kirjasto, jota aion edelleen käyttää ja ehdottaa muille tiimeille käytettäväksi, jos se täyttää heidän tarpeensa.
Vaadin
Vaadin on toinen hyvä vaihtoehto.
luulin alun perin, että GWT oli ainoa valintani käyttöliittymien kirjoittamiseen tavallisella Java-koodilla. Mutta kun puhuin edellä mainitsemani pienen liikkeen kanssa, he kertoivat minulle, että he olivat päättäneet käyttää Vaadinia projekteissaan. Minun piti tietysti käydä katsomassa. Olen vaikuttunut.
sanon suoraan, että tätä kirjoitettaessa en ole vielä käyttänyt Vaadin-projektia. Mutta olen ramping ylös pari henkilökohtaista projektia tarvitsen front-ends varten ja aikovat käyttää tätä. Jos Vaadin pitää lupauksensa, se on täydellinen kehys näille hankkeille.
Vaadin lupaa tukea JVM: ssä toimivia kieliä, kuten Kotlin ja Scala. Toivottavasti se sisältää svengiä. Jos olet lukenut monia minun aikaisempia viestejä, tiedät olen fani, että kieli, koska voit nopeasti luoda koodia, joka voidaan helposti ylläpitää. Nämä ovat minulle tärkeitä vaatimuksia, erityisesti ylläpidettävyys. Mikään ei tuhoa projektia tiellä enemmän kuin se, ettei jo kirjoitettua koodia pystytä helposti ylläpitämään.
Final Thoughts
sinulla on monia vaihtoehtoja, kun suunnittelet verkkosovellustasi käyttöliittymäteknologian osalta. Suunnitteletpa projektia tai tuotantoympäristöä, sinulla on niin monia vaatimuksia, jotka on pidettävä mielessä.
kaksi vaatimusta, jotka on pidettävä mielessä, ovat kehityksen helppous ja ylläpidettävyys.
- vaikeasti työstettävä kehitysympäristö johtaa moniin kustannusylityksiin ja tekee uusien ohjelmoijien tuomisesta erittäin vaikeaa.
- vaikeasti ylläpidettävä hanke aiheuttaa tulevaisuudessa turhautumista ja lisää rahan tuhlausta.
tiimisi tarpeiden ja vaatimusten perusteella Täydellinen Java-ratkaisu käyttöliittymästä malliin on paitsi mahdollinen, myös erinomainen valinta sekä nopeaan kehitykseen että helppoon huoltoon.
uskovat hyvään koodiin.