Setul de instrumente GWT: construiți front-end-uri JavaScript puternice folosind Java

GWT Web Toolkit, cunoscut anterior ca Google Web Toolkit, este un set de instrumente de dezvoltare pentru construirea și optimizarea aplicațiilor complexe bazate pe browser folosind limbajul de programare Java.

Ceea ce face ca GWT să nu „încă un instrument Java pentru a scrie aplicații web”, este faptul că inima setului de instrumente este un compilator care convertește Java în JavaScript (precum și HTML și CSS), permițând dezvoltatorilor să scrie aplicații web front-end. în timp ce valorifică toate punctele forte ale Java.

Este chiar ușor să utilizați o combinație de Java și JavaScript, deoarece GWT include o arhitectură de interoperabilitate robustă pentru interfațarea cu platforma web. La fel ca interfața nativă Java (JNI) permite mașinii virtuale Java (JVM) să apeleze rutine specifice platformei (de exemplu, pentru a accesa caracteristici hardware specifice sau pentru a folosi biblioteci externe din alte limbi), GWT ne permite să scriem cea mai mare parte a unui aplicație în Java și apoi, dacă este necesar, să utilizați un API web specific sau, să folosiți bibliotecile JavaScript existente, să „deveniți nativ” și să treceți la JavaScript.

GWT s-a născut ca produs Google, dar a devenit open source la sfârșitul anului 2011 și este lansat în prezent sub licența Apache (Versiunea 2) sub numele GWT Open Source Project . Este gestionat de un comitet de conducere cu reprezentanți ai mai multor companii, inclusiv Google, RedHat, ArcBees, Vaadin și Sencha, precum și dezvoltatori independenți din comunitate.

GWT în trecut și în viitor

Google Web Toolkit a fost lansat pentru prima dată în 2006. A fost creat ca un instrument pentru a ajuta inginerii Google să-și dezvolte aplicațiile complexe bazate pe browser, cum ar fi AdWords, Google Wallet și Google Flights și, mai recent, este folosit în centrul Aplicații Google Sheets și Inbox.

În 2006, browserele (și interpreții JavaScript) erau departe de a fi standardizate. Codul front-end a fost lent, greșit și greu de utilizat în mod fiabil. A existat o lipsă aproape totală de biblioteci și cadre de înaltă calitate pentru dezvoltarea web. De exemplu, jQuery nici măcar nu a existat până în acest an. Așadar, pentru a putea dezvolta aplicații web la scară largă, inginerii de la Google au decis să folosească instrumentele și competențele existente. Java a fost limbajul cel mai potrivit pentru nevoile lor, fiind bine cunoscut și perfect integrat în IDE-uri, precum Eclipse, și astfel și-a început viața Google Web Toolkit.

Scopul a fost mai mult sau mai puțin să ascunde diferențele dintre browsere și să încapsuleze trucurile necesare pentru a scrie JavaScript eficient într-un compilator Java, lăsând dezvoltatorii liberi de tirania tehnicilor browserului.

Desigur, în ultimul deceniu, web-ul s-a schimbat; Browserele au devenit mai rapide și au convergit către standardele de implementare și au fost dezvoltate o mulțime de cadre și biblioteci front-end minunate, inclusiv jQuery, Angular, Polymer și React. Așadar, prima întrebare pe care ați putea să o puneți este: „GWT este încă util?”

Într-un cuvânt: Da .

În contextul dezvoltării web moderne, țintirea browserelor este inevitabilă, iar JavaScript a devenit lingua franca a aplicațiilor front-end. Dar, desigur, diferite instrumente și limbi sunt mai potrivite pentru diferite sarcini. GWT, împreună cu câteva proiecte similare, urmăresc să vizeze browserele fără a limita dezvoltatorii la utilizarea JavaScript.

Dezvoltarea și folosirea instrumentelor de „compilare pe web”, precum GWT, vor fi facilitate, în viitorul apropiat, de așa-numitul grup WebAssembly al World Wide Web Consortium. Nu există doar un spațiu vast pentru instrumentele care se compilează în JavaScript, dar această abordare poate satisface o nevoie reală în contexte care variază de la descărcarea unei părți din calcul la browsere, reutilizarea codului și bibliotecile existente, partajarea codului între back-end și front-end. , utilizând competențele și fluxurile de lucru existente și valorificând caracteristicile diferitelor limbi (de exemplu, tastarea statică în cazul GWT).

Proiectul GWT este de așteptat să lanseze versiunea 2.8 în curând, iar versiunea 3.0 este în curs de dezvoltare, cu îmbunătățiri mari în lucru:

• a reinventat interoperabilitatea cu JavaScript
• compilator îmbunătățit (aproape rescris în totalitate).
• Suport Java de ultimă generație (de exemplu, lambdas)

De fapt, majoritatea caracteristicilor GWT 3.0 sunt deja disponibile în depozitul public Git. Doar verificați trunchiul, aici și compilați GWT urmând documentația de aici.

Comunitatea GWT

De când GWT a devenit open source în 2011, comunitatea și-a asumat un rol esențial în evoluția proiectului.

Toată dezvoltarea are loc în depozitul Git găzduit pe gwt.googlesource.com, iar toate revizuirile codului se fac pe gwt-review.googlesource.com. Pe aceste pagini, oricine este interesat de dezvoltarea setului de instrumente poate contribui și poate vedea la ce lucrează comunitatea. În ultimii ani, procentul de noi patch-uri de la non-Googler a crescut de la aproximativ 5 la sută în 2012, la aproximativ 25 la sută în ultimul an, confirmând implicarea în creștere.

Anul acesta, comunitatea s-a reunit pentru câteva întâlniri mari în SUA și Europa. GWT.create, organizat de Vaadin, a avut loc atât la München, Germania, cât și la Mountain View, California, în ianuarie, și a numărat peste 600 de participanți din zeci de țări. Pe 11 noiembrie, la Florența, Italia, vom organiza cea de-a doua ediție a GWTcon, o conferință GWT condusă de comunitate pe care ajut să o organizez.

Pentru ce este potrivit GWT?

Un sondaj anual despre setul de instrumente GWT, lansat de Vaadin, discută despre evoluția dezvoltării GWT, despre cum se simt dezvoltatorii despre setul de instrumente, despre ce este bun, rău și așa mai departe. Acest sondaj ne permite, de asemenea, să înțelegem pentru ce este folosit setul de instrumente, cum se schimbă comunitatea de utilizatori și așteptările pe care dezvoltatorii le au pentru viitorul setului de instrumente.

Raportul Viitorul GWT pentru 2015 poate fi găsit aici și arată clar că GWT este foarte popular pentru construirea de aplicații web la scară largă. De exemplu, la pagina 14, se afirmă: „Majoritatea aplicațiilor sunt aplicații de afaceri care au o cantitate mare de date și se lucrează cu multe ore pe zi.”

După cum era de așteptat, este ușor de concluzionat că mediul natural pentru GWT este domeniul aplicațiilor web la scară largă, unde mentenabilitatea codului este importantă, iar echipele mari beneficiază de structura limbajului Java.

Pe de altă parte, uitându-ne la benchmark-urile pentru codul generat de GWT (de exemplu, în discursul principal al conferinței GWT.create de anul trecut, la paginile 7, 8 și 11) este ușor de observat că, în ceea ce privește performanța și dimensiunea codului, JavaScript compilat este uimitor de minunat. Dacă este folosit corect, performanța obținută este comparabilă cu cel mai bun JavaScript scris de mână. Ca rezultat, este de fapt fezabil să folosiți GWT pentru a porta bibliotecile Java pe web.

Acest lucru luminează un alt scenariu ideal pentru GWT. Ecosistemul Java este plin de biblioteci de înaltă calitate, care nu au niciun corespondent gata de utilizat în JavaScript. Compilatorul GWT poate fi folosit pentru a adapta astfel de biblioteci pentru web. Cu alte cuvinte, GWT ne permite să amestecăm biblioteci disponibile atât în ​​Java, cât și în JavaScript și să le rulăm în browser.

Această abordare poate fi văzută în dezvoltarea PicShare, unde arătăm cum mai multe biblioteci Java care nu sunt considerate în general pentru web (NyARToolkit, de exemplu) pot fi portate în browser folosind GWT și combinate cu API-uri web, inclusiv WebRTC și WebGL, pentru a obțineți un instrument de realitate augmentată complet bazat pe web. Am fost mândru să prezint PicShare la conferința GWT.create din 2015 în ianuarie anul trecut.

Under the Hood: Transformarea Java în JavaScript

Setul de instrumente GWT este un set de instrumente relativ complex, dar oricine poate începe să-l folosească într-o clipă, datorită unei integrări surprinzător de ușor de utilizat cu Eclipse.

Crearea unei aplicații simple cu GWT este relativ ușoară pentru oricine cu experiență în proiecte de dezvoltare Java. Dar pentru a înțelege ce se „se întâmplă cu adevărat”, merită să analizați principalele componente ale setului de instrumente:

• Java to JavaScript Transpiler
• Mediu Java Runtime emulat
• Stratul de interoperabilitate

Compilatorul de optimizare GWT

O descriere amănunțită a modului în care funcționează compilatorul devine foarte tehnică destul de devreme și nu trebuie să săpăm atât de adânc, dar merită analizate unele dintre conceptele generale.

Primul lucru de înțeles este că GWT compilează Java în JavaScript prin traducere la nivel de cod sursă. Adică, sursa Java este tradusă ( transpiled este termenul tehnic) în JavaScript. Acest lucru este în contrast cu un fel de mașină virtuală Java scrisă în JavaScript, care execută bytecode Java. (Acesta este de fapt posibil și este abordarea folosită de Doppio, dar nu este modul în care funcționează GWT.)

În schimb, codul Java este defalcat într-un arbore de sintaxă abstractă (AST) reprezentând elementele sintactice ale codului. Este apoi mapat la un AST Javascript echivalent (și optimizat), care este în cele din urmă convertit înapoi în codul JavaScript real.

Cântărirea avantajelor și dezavantajelor transpilării este departe de obiectul acestei postări, dar permiteți-mi să observ că, cu această metodă, GWT poate folosi direct serviciile de colectare a gunoiului interpretului JavaScript, împreună cu orice alte caracteristici native ale browserului.

Există câteva părți dificile, desigur. De exemplu, JavaScript are un singur tip numeric, care nu poate conține tipul întreg long long un tratament special din partea compilatorului. În plus, tastarea statică Java nu are o semnificație directă în JavaScript, așa că trebuie avută o grijă deosebită pentru a păstra, de exemplu, operațiunile de tipar echivalente după transpilare.

Pe de altă parte, un avantaj ușor de apreciat al transpilării este că GWT poate efectua optimizări (atât pentru dimensiune, cât și pentru performanță) la nivel Java și la nivel JavaScript. Codul JavaScript standard rezultat poate fi procesat în continuare în conducta dvs. de implementare. De exemplu, o practică obișnuită care a fost acum integrată în distribuția standard GWT implică optimizarea rezultatelor JavaScript de către transpiler folosind compilatorul de închidere JavaScript-to-JavaScript extrem de specializat (un alt cadou de la zeii Google).

Cea mai aprofundată descriere a compilatorului GWT pe care o cunosc poate fi găsită în acest pachet de diapozitive și discuția originală din care provine. Aici, puteți găsi detalii despre alte caracteristici interesante ale procesului de compilare, cum ar fi capacitatea GWT de a face împărțirea codului, generând mai multe fișiere script separate pentru a fi încărcate independent de browser.

JRE emulat

Compilatorul Java-to-JavaScript ar fi puțin mai mult decât o noutate dacă nu este completat de o implementare a Java Runtime Environment (JRE), care oferă bibliotecile de bază pe care se bazează aproape orice aplicație Java. Aproximativ vorbind, lucrul în Java fără, de exemplu, colecții sau metode String, ar fi frustrant și, desigur, portarea acestor biblioteci este o treabă titanică. GWT umple această gaură cu așa-numitul JRE emulat.

JRE emulat nu este nicidecum o re-implementare completă a Java JRE, ci este mai degrabă un fel de selecție de clase și metode care pot fi utile (și utilizabile) pe partea clientului. Funcționalitățile care se află în JRE Java, dar pe care nu le veți găsi în interiorul JRE emulat se împart în trei categorii:

• Lucruri care nu pot fi portate pe partea clientului. De exemplu, java.lang.Thread sau java.io.File nu pot fi implementate într-un browser cu aceeași semantică a Java. Pagina browserului are un singur thread și nu are acces direct la sistemul de fișiere.

• Lucruri care ar putea fi implementate, dar care ar „costa prea mult” în ceea ce privește dimensiunea codului, performanța sau dependențele și pe care comunitatea preferă astfel să nu le aibă în GWT. În această categorie, de exemplu, este inclusă reflectarea Java ( java.lang.reflect ) care ar cere transpilerului să păstreze informațiile despre clasă pentru fiecare tip, ceea ce ar face ca dimensiunea JavaScript compilat să se ridice.

• Lucruri care nu au fost interesate de nimeni și, prin urmare, nu au fost implementate.

Dacă se întâmplă ca JRE emulat să nu se potrivească nevoilor dumneavoastră (de exemplu, aveți nevoie de o clasă care nu este furnizată), GWT vă permite să scrieți propria implementare. Acest mecanism puternic, disponibil prin eticheta <super-source> , face posibilă ocolirea problemelor la adaptarea noilor biblioteci externe care utilizează părți ale JRE neemulate.

Poate fi prea complex, sau chiar imposibil, să oferi o implementare completă a unor părți ale JRE, astfel încât pentru sarcini specifice propriile implementări pot să nu urmeze strict semantica JRE-ului Java, chiar dacă funcționează în cazul tău specific. Într-adevăr, dacă vă gândiți să vă întoarceți clasele proiectului, amintiți-vă că este de o importanță capitală pentru JRE emulat ca fiecare clasă inclusă să urmeze aceeași semantică a JRE-ului Java original. Acest lucru asigură că oricine poate recompila codul Java în JavaScript și are încredere că va obține rezultatele așteptate. Asigurați-vă întotdeauna că codul dvs. este testat temeinic înainte de a-l da înapoi comunității.

Stratul de interoperabilitate

Pentru a fi un instrument eficient pentru producția de aplicații web din lumea reală, GWT trebuie să permită dezvoltatorilor să interacționeze cu ușurință cu platforma de bază. Adică browserul și DOM-ul.

De la bun început, GWT a fost construit pentru a susține o astfel de interacțiune prin JavaScript Native Interface (JSNI), ceea ce face ca accesarea API-urilor din browser să fie o ușoară. De exemplu, folosind caracteristici de sintaxă unice pentru compilatorul GWT, puteți scrie următorul cod Java:

 public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{ //place your JavaScript code here }-*/;

și sunteți liber să implementați corpul metodei în JavaScript. Puteți chiar să împachetați obiecte JavaScript într-un JavaScriptObject (JSO) și să îl faceți accesibil în codul dvs. Java.

Un exemplu de unde intră în joc acest strat poate fi găsit în contextul compoziției UI. Mainstream Java a folosit întotdeauna setul de instrumente Widgets standard pentru a construi elemente de UI, utilizând interfața nativă Java pentru a accesa sistemele de ferestre și de intrare ale sistemului de operare de bază. Stratul de interoperabilitate al GWT face același lucru, astfel încât Widgeturile tradiționale să funcționeze fără probleme în browser. Singura diferență este că, în acest caz, sistemul de bază este browserul și DOM.

Cu toate acestea, cadrele native front-end s-au îmbunătățit rapid în ultimii ani, iar în prezent oferă avantaje semnificative față de Widgeturile GWT. Pe măsură ce aceste cadre au crescut în sofisticare, încercările de a le implementa în JSNI au scos la iveală deficiențe în arhitectura stratului de interoperabilitate. Începând cu versiunea 2.7, GWT a introdus JsInterop, o nouă abordare bazată pe adnotări Java, care vă permite să integrați rapid și ușor clasele dvs. GWT cu JavaScript. Nu mai este necesar să scrieți metode JSNI sau clase JSO. În schimb, puteți utiliza pur și simplu adnotări precum @JSType sau @JSProperty , permițându-vă să lucrați cu clase JavaScript native ca și cum ar fi Java.

Specificația completă a JsInterop este încă în curs, iar cele mai recente actualizări pot fi încercate doar prin compilarea sursei din depozitul GWT. Dar este deja clar că aceasta este noua direcție care va permite GWT să țină pasul cu platformele web în evoluție.

Un proiect în desfășurare care profită de JsInterop este elementele-polimer-gwt lansate recent, care pune la dispoziție pentru GWT toate elementele Fier și hârtie de la Polymer. Ceea ce este interesant în această bibliotecă este că dezvoltatorii nu trebuie să genereze manual API-ul Java. Proiectul folosește gwt-api-generator pentru a genera majoritatea interfețelor direct prin analizarea bibliotecii Polymer și a adnotărilor JSDoc. Acest lucru facilitează păstrarea legăturilor la zi.

Cuvinte finale

Odată cu îmbunătățirile aduse compilatorului, stratul de interoperabilitate și performanța și dimensiunea codului generat în ultimii doi ani, este clar că GWT nu este doar „un alt instrument de dezvoltare web”, ci pe cale să devină un set de instrumente de referință major pentru dezvoltarea de aplicații web complexe și la scară largă și ar putea fi chiar o alegere excelentă pentru a face aplicații mai simple minunate.

Folosesc GWT zilnic în munca mea de dezvoltator și consultant, dar mai ales îmi place GWT pentru că îmi permite să depășesc limitele capabilităților browserului și să arăt că aplicațiile web moderne pot fi la fel de puternice ca și aplicațiile desktop.

Comunitatea Proiectului GWT este cu adevărat activă, iar noi biblioteci, proiecte și aplicații bazate pe GWT sunt propuse în mod constant. La Florența, GWTcon2015, condus de comunitate, se va întâlni pe 11 noiembrie. Dacă vă aflați în regiune, sper că veți veni să cunoașteți unii dintre dezvoltatorii de bază și să aflați despre toate oportunitățile de a face parte din evoluția acestui uimitor set de instrumente.