am vorbit recent cu un prieten despre dezvoltarea UI. El a fost, de asemenea, un programator, deoarece programarea a fost considerată o artă arcane (când aceia dintre noi care au făcut-o au fost considerate ca Gandalf Grey cu care se confruntă Balrog). Sau poate, ne-am văzut așa. Indiferent, amândoi am fost programatori Java pentru o mare parte din acea vreme.
amândoi ne-am plâns de faptul că a fost un comutator de context pentru a trece de la codarea majorității proiectelor noastre în Java, apoi a trebuit să trecem la JavaScript pentru front-end.
pe baza conversațiilor pe care le-am văzut online, mai mulți cititori își încălzesc tastaturile pentru a mă mustra că mă plâng că trebuie să codific în JavaScript. Păstrați-vă cheile la rece, atât noi, cât și colegii noștri avem experiență și suntem bucuroși să scriem JavaScript și oricare dintre cadrele sale pentru clienții noștri. Dar utilizarea JavaScript nu este întotdeauna cea mai bună abordare.
în această postare, introducem două cadre care vă permit să codificați interfața dvs. de utilizator în Java: GWT și Vaadin.
când să utilizați Java pentru UI?
conversația mi — a revenit în timp ce vorbeam cu un client-un mic magazin de doar câțiva programatori și un arhitect software care a programat și el. Ei au decis că nu vor să-și mențină proiectele în două limbi separate. Compania lor a standardizat pe Java și au vrut să folosească aceleași instrumente și mentalitate pentru a crea interfețe de utilizator puternice și moderne pentru aplicațiile lor web.
am observat la echipele mai mari că echipa pare să se separe, unii preferând să se concentreze pe front-end, iar alții lucrează mai ales pe codul back-end sau pe server. Când munca este aprobată pentru dezvoltare, adesea văd aceiași programatori fie luând, fie primind majoritatea lucrărilor JavaScript front-end, iar alții luând back-end-ul.
nu spun că acesta este un lucru rău; de fapt, pare a fi exact opusul. Toată lumea pare să fie mai productivă în zona lor de confort, dar toată lumea este, de asemenea, conștientă de ceea ce fac toți ceilalți și poate păși în acea zonă dacă sau când este nevoie. Pentru magazinele mai mici, aceasta nu este o opțiune. Adesea, același programator va scrie codul unui întreg proiect de la interfața cu utilizatorul la model.
din fericire, există opțiuni dacă doriți să păstrați interfața de utilizator în aceeași limbă ca back-end-ul dvs. dacă limba respectivă este Java. Să vorbim despre câteva dintre ele acum.
GWT
Google Web Toolkit, sau GWT, este o opțiune excelentă.
am avut mult succes cu GWT într-un proiect pe care l-am început acum 8 ani și încă îl mențin. GWT mi-a permis să construiesc logica de vizualizare pentru o aplicație cu o singură pagină complet în codul Java Standard. Acesta este dotat cu un plugin Eclipse. Nu l-am folosit pentru că am folosit Netbeans pentru mediul meu de dezvoltare, dar, deoarece Eclipse este standardul pentru majoritatea echipelor, acest lucru ar putea fi foarte util.
am reușit să descompun logica pentru widget-uri (cum ar fi o casetă de text personalizată), în clase sau metode de ajutor, la fel cum aș face logica de afaceri pe un proiect de pe server. Prin moștenire, am reușit să creez cu ușurință mai multe widget-uri care aveau cerințe similare. Despre singurul concept real de schimbare cu care am avut de-a face a fost că UI este mult mai condus de evenimente decât majoritatea serviciilor web sau alt cod de pe server.
există două dezavantaje principale pe care le văd la GWT. Unul este timpul de compilare. GWT adaugă un pas de compilare a procesului care nu ia ceva timp. Clasele GWT care au fost construite în Java trebuie compilate în bibliotecile JavaScript. Am văzut mai multe plângeri cu privire la timpul necesar.
al doilea este că a trecut ceva timp de când GWT a văzut o actualizare semnificativă. Începând cu această scriere, 2.8.2 a fost lansat acum un an în octombrie 2017. Cu trei ani înainte, 2.7.0 a fost lansat, ceea ce a făcut patru ani de la momentul scrierii acestui articol. Văd postări și comentarii despre 3.0 care ies, inclusiv unele de acum doi ani întrebând dacă afișul ar trebui să aștepte ca 3.0 să iasă înainte de a implementa o mare schimbare (sper că afișul nu mai așteaptă), dar nu găsesc niciun calendar cu privire la momentul în care ar putea fi lansată.
deși sunt un mare fan al cadrului și consider că este suficient de matur așa cum este, știu că această vagă în posibilitatea lansărilor viitoare îi face pe unii manageri de proiect destul de nervoși. Nimeni nu vrea să fie legat de un cadru care se termină pe ele.
GWT este o bibliotecă pe care voi continua să o folosesc și să o sugerez altor Echipe să o folosească dacă le satisface nevoile.
Vaadin
Vaadin este o altă opțiune excelentă.
am crezut inițial că GWT a fost singura mea alegere pentru scrierea interfețelor de utilizator în codul Java Standard. Dar când am vorbit cu acel mic magazin pe care l-am menționat mai sus, mi-au spus că au decis să folosească Vaadin pentru proiectele lor. Deci, desigur, a trebuit să mă duc să arunc o privire. Și sunt impresionat.
voi fi sincer, începând cu această scriere, nu am folosit încă Vaadin pentru a crea un proiect. Dar eu sunt ramping un cuplu de proiecte personale am nevoie de front-end pentru și intenționează să folosească acest lucru. Dacă Vaadin își respectă promisiunile, va fi un cadru perfect pentru aceste proiecte.
Vaadin promite să sprijine limbile care rulează în JVM, cum ar fi Kotlin și Scala. Sper că asta include Groovy. Dacă citiți multe dintre postările mele anterioare, veți ști că sunt un fan al acelei limbi, deoarece puteți crea rapid cod care poate fi ușor întreținut. Acestea sunt cerințe importante pentru mine, în special mentenabilitatea. Nimic nu distruge un proiect pe drum mai mult decât a nu fi capabil să mențină cu ușurință codul care a fost deja scris.
Gânduri finale
aveți multe opțiuni atunci când vă arhitectați aplicația web atunci când vine vorba de tehnologia interfeței cu utilizatorul. Indiferent dacă proiectați un proiect sau un mediu de producție, aveți atât de multe cerințe de reținut.
două cerințe trebuie să păstreze în minte sunt ușurința de dezvoltare și mentenabilitate.
- un mediu de dezvoltare care este dificil de a lucra în va duce la multe depășiri de costuri și de a face aduce noi programatori pe foarte dificil.
- un proiect dificil de întreținut va provoca frustrări și va risipi mai mulți bani în viitor.
pe baza nevoilor și cerințelor echipei dvs., o soluție Java completă, de la interfața cu utilizatorul la model, nu este doar posibilă, ci o alegere excelentă atât pentru dezvoltarea rapidă, cât și pentru ușurința întreținerii.
crede în codul bun.