Toolkit GWT: Membangun Ujung Depan JavaScript yang Kuat Menggunakan Java

Diterbitkan: 2022-03-11

GWT Web Toolkit, sebelumnya dikenal sebagai Google Web Toolkit, adalah seperangkat alat pengembangan untuk membangun dan mengoptimalkan aplikasi berbasis browser yang kompleks menggunakan bahasa pemrograman Java.

Apa yang membuat GWT bukan “alat Java lain untuk menulis aplikasi web,” adalah kenyataan bahwa inti dari toolkit ini adalah kompiler yang mengubah Java menjadi JavaScript (serta HTML dan CSS), memungkinkan pengembang untuk menulis aplikasi web front-end sambil memanfaatkan semua kekuatan Java.

GWT mengubah Java menjadi kode JavaScript, HTML, dan CSS yang indah.

Bahkan mudah untuk menggunakan campuran Java dan JavaScript, karena GWT menyertakan arsitektur interoperabilitas yang kuat untuk berinteraksi dengan platform web. Sama seperti Java Native Interface (JNI) yang memungkinkan Java Virtual Machine (JVM) untuk memanggil rutinitas khusus platform (misalnya, untuk mengakses fitur perangkat keras tertentu, atau menggunakan perpustakaan eksternal dari bahasa lain), GWT memungkinkan kita untuk menulis sebagian besar aplikasi di Java dan kemudian, jika perlu menggunakan API web tertentu, atau, memanfaatkan pustaka JavaScript yang ada, untuk "menjadi asli" dan melompat ke JavaScript.

GWT lahir sebagai produk Google tetapi lulus ke open source pada akhir 2011 dan saat ini dirilis di bawah Lisensi Apache (Versi 2) dengan nama Proyek Sumber Terbuka GWT . Ini dikelola oleh komite pengarah dengan perwakilan dari beberapa perusahaan, termasuk Google, RedHat, ArcBees, Vaadin, dan Sencha, serta pengembang independen dari komunitas.

GWT di Masa Lalu dan Masa Depan

Google Web Toolkit pertama kali dirilis pada tahun 2006. Dibuat sebagai alat untuk membantu insinyur Google mengembangkan aplikasi berbasis browser yang kompleks, seperti AdWords, Google Wallet, dan Google Flights, dan, baru-baru ini, digunakan di jantung Aplikasi Google Spreadsheet dan Kotak Masuk.

Kembali pada tahun 2006, browser (dan penerjemah JavaScript) masih jauh dari standar. Kode front-end lambat, bermasalah, dan sulit digunakan dengan andal. Hampir tidak ada perpustakaan dan kerangka kerja berkualitas tinggi untuk pengembangan web. Misalnya, jQuery bahkan tidak ada sampai tahun ini. Jadi, untuk dapat mengembangkan aplikasi web skala besar, para insinyur di Google memutuskan untuk memanfaatkan alat dan kompetensi yang ada. Java adalah bahasa yang paling sesuai untuk kebutuhan mereka, yang terkenal dan terintegrasi sempurna ke dalam IDE, seperti Eclipse, dan Google Web Toolkit memulai hidupnya.

Tujuannya kurang lebih untuk menyembunyikan perbedaan antara browser, dan merangkum trik yang diperlukan untuk menulis JavaScript yang efisien di dalam kompiler Java, membuat pengembang bebas dari tirani teknis browser.

Tentu saja, selama dekade terakhir, web telah berubah; browser menjadi lebih cepat dan telah menyatu pada standar implementasi, dan banyak kerangka kerja dan perpustakaan front-end yang mengagumkan telah dikembangkan, termasuk jQuery, Angular, Polymer, dan React. Jadi pertanyaan pertama yang mungkin Anda tanyakan adalah, “Apakah GWT masih berguna?”

Singkatnya: Ya .

Dalam konteks pengembangan web modern, penargetan browser tidak dapat dihindari dan JavaScript telah menjadi lingua franca aplikasi front-end. Tapi tentu saja, alat dan bahasa yang berbeda lebih cocok untuk tugas yang berbeda. GWT, bersama dengan beberapa proyek serupa bertujuan untuk menargetkan browser tanpa membatasi pengembang untuk menggunakan JavaScript.

Pengembangan dan penggunaan alat “kompilasi-ke-web” seperti GWT, dalam waktu dekat, akan difasilitasi oleh apa yang disebut kelompok WebAssembly dari World Wide Web Consortium. Tidak hanya ruang yang luas untuk alat yang dikompilasi ke JavaScript, tetapi pendekatan ini dapat memenuhi kebutuhan nyata dalam konteks yang berkisar dari membongkar bagian komputasi ke browser, menggunakan kembali kode dan pustaka yang ada, berbagi kode antara back-end dan front-end , menggunakan kompetensi dan alur kerja yang ada dan memanfaatkan fitur bahasa yang berbeda (misalnya, pengetikan statis dalam kasus GWT).

Proyek GWT diharapkan segera merilis versi 2.8, dan versi 3.0 sedang dalam pengembangan, dengan peningkatan besar dalam pengerjaan:

  • interoperabilitas yang diciptakan kembali dengan JavaScript
  • kompiler yang ditingkatkan (hampir sepenuhnya ditulis ulang)
  • dukungan Java yang canggih (misalnya lambdas)

Sebenarnya, sebagian besar fitur GWT 3.0 sudah tersedia di repositori Git publik. Cukup periksa bagasi, di sini dan kompilasi GWT mengikuti dokumentasi di sini.

Komunitas GWT

Sejak GWT menjadi open source pada tahun 2011, komunitas telah mengambil peran penting dalam evolusi proyek.

Semua pengembangan terjadi di repositori Git yang dihosting di gwt.googlesource.com, dan semua tinjauan kode dilakukan di gwt-review.googlesource.com. Di halaman ini, siapa pun yang tertarik dengan pengembangan Toolkit ini dapat berkontribusi dan melihat apa yang sedang dikerjakan komunitas. Selama beberapa tahun terakhir, persentase patch baru dari non-Googler telah meningkat dari sekitar 5 persen pada tahun 2012, menjadi sekitar 25 persen pada tahun lalu, yang menegaskan keterlibatan yang meningkat.

Tahun ini, komunitas telah berkumpul untuk beberapa pertemuan besar di AS dan Eropa. GWT.create, yang diselenggarakan oleh Vaadin, diadakan di Munich, Jerman dan Mountain View, California pada bulan Januari, dan melibatkan lebih dari 600 peserta dari puluhan negara. Pada tanggal 11 November, di Florence, Italia, kami akan mengadakan GWTcon edisi kedua, konferensi GWT berbasis komunitas yang saya bantu atur.

GWTcon 2015 di Florence, Italia

Untuk Apa GWT Cocok?

Sebuah survei tahunan pada toolkit GWT, dirilis oleh Vaadin, membahas evolusi pengembangan GWT, bagaimana perasaan pengembang tentang toolkit, yang baik, yang buruk, dan sebagainya. Survei ini juga memungkinkan kami memahami untuk apa Toolkit ini digunakan, bagaimana komunitas pengguna berubah, dan harapan yang dimiliki pengembang untuk masa depan toolkit.

Laporan GWT Masa Depan 2015 dapat ditemukan di sini, dan memperjelas bahwa GWT sangat populer untuk membangun aplikasi web skala besar. Misalnya, di halaman 14, dinyatakan, “Sebagian besar aplikasi adalah aplikasi bisnis yang membutuhkan banyak data dan bekerja berjam-jam setiap hari.”

Seperti yang diharapkan, mudah untuk menyimpulkan bahwa lingkungan alami untuk GWT adalah bidang aplikasi web skala besar, di mana pemeliharaan kode itu penting, dan tim besar mendapat manfaat dari struktur bahasa Java.

GWT sangat bagus untuk membangun aplikasi web berskala besar yang kuat.

Di sisi lain, melihat tolok ukur untuk kode yang dihasilkan oleh GWT (misalnya, dalam keynote konferensi GWT.create tahun lalu, di halaman 7, 8, dan 11) mudah untuk melihat bahwa, dalam hal kinerja dan ukuran kode, JavaScript yang dikompilasi sangat mengagumkan. Jika digunakan dengan benar, kinerja yang diperoleh sebanding dengan JavaScript tulisan tangan terbaik. Akibatnya, sebenarnya layak untuk menggunakan GWT untuk mem-port library Java ke web.

Ini menjelaskan skenario ideal lainnya untuk GWT. Ekosistem Java penuh dengan pustaka berkualitas tinggi yang tidak memiliki rekanan siap pakai dalam JavaScript. Kompiler GWT dapat digunakan untuk mengadaptasi pustaka semacam itu untuk web. Dengan kata lain, GWT memungkinkan kita mencampur perpustakaan yang tersedia di Java dan JavaScript, dan menjalankannya di browser.

Pendekatan ini dapat dilihat dalam pengembangan PicShare, di mana kami menunjukkan bagaimana beberapa perpustakaan Java yang umumnya tidak dipertimbangkan untuk web (misalnya NyARToolkit) dapat di-porting ke browser menggunakan GWT, dan digabungkan dengan API web, termasuk WebRTC dan WebGL, untuk dapatkan alat Augmented Reality berbasis web sepenuhnya. Saya bangga mempersembahkan PicShare di konferensi GWT.create 2015 Januari lalu.

JavaScript front-end dengan kekuatan aplikasi Java? Ya, Anda juga dapat memiliki semuanya, dengan GWT!
Menciak

Di Balik Terpal: Mengubah Java menjadi JavaScript

GWT Toolkit adalah seperangkat alat yang cukup rumit, tetapi siapa pun dapat mulai menggunakannya dalam sekejap, berkat integrasi yang sangat mudah digunakan dengan Eclipse.

Membuat aplikasi sederhana dengan GWT relatif mudah bagi siapa saja yang memiliki latar belakang proyek pengembangan Java. Namun untuk memahami apa yang "benar-benar terjadi", ada baiknya menganalisis komponen utama dari toolkit ini:

  • Transpiler Java ke JavaScript
  • Lingkungan Runtime Java yang Diemulasi
  • Lapisan Interoperabilitas

Kompilator Pengoptimalan GWT

Deskripsi mendalam tentang cara kerja kompiler menjadi sangat teknis cukup awal, dan kita tidak perlu menggali sedalam itu, tetapi beberapa konsep umum layak untuk dilihat.

Hal pertama yang harus dipahami adalah bahwa GWT mengkompilasi Java ke dalam JavaScript dengan terjemahan di tingkat kode sumber. Artinya, sumber Java diterjemahkan ( ditranspilasikan adalah istilah teknisnya) ke dalam JavaScript. Ini berbeda dengan memiliki semacam Mesin Virtual Java yang ditulis dalam JavaScript, yang mengeksekusi bytecode Java. (Ini sebenarnya mungkin, dan merupakan pendekatan yang digunakan oleh Doppio, tetapi bukan cara kerja GWT.)

Sebagai gantinya, kode Java dipecah menjadi pohon sintaksis abstrak (AST) yang mewakili elemen sintaksis kode. Ini kemudian dipetakan ke AST Javascript yang setara (dan dioptimalkan), yang akhirnya dikonversi kembali ke kode JavaScript yang sebenarnya.

Transpilasi GWT dari kode sumber Java ke kode sumber JavaScript menggunakan pohon sintaksis abstrak.

Menimbang pro dan kontra transpilasi jauh dari objek posting ini, tetapi izinkan saya mengamati bahwa dengan metode ini, GWT dapat secara langsung memanfaatkan layanan pengumpulan sampah dari juru JavaScript, bersama dengan fitur lain yang asli dari browser.

Ada beberapa bagian yang rumit, tentu saja. Misalnya, JavaScript hanya memiliki satu tipe numerik, yang tidak dapat berisi tipe integer long 64-bit Java, sehingga tipe long memerlukan beberapa perlakuan khusus oleh kompiler. Selain itu, pengetikan statis Java tidak memiliki arti langsung dalam JavaScript, jadi perhatian khusus harus diberikan untuk menjaga, misalnya, operasi pengetikan yang setara setelah transpilasi.

Di sisi lain, keuntungan transpilasi yang mudah dihargai adalah bahwa GWT dapat melakukan optimasi (baik untuk ukuran dan kinerja) di tingkat Java dan di tingkat JavaScript. Kode JavaScript standar yang dihasilkan bahkan dapat diproses lebih lanjut dalam alur penerapan Anda. Misalnya, praktik umum yang kini telah diintegrasikan ke dalam distribusi GWT standar melibatkan pengoptimalan keluaran JavaScript oleh transpiler menggunakan Kompilator Penutupan JavaScript-ke-JavaScript yang sangat khusus (hadiah lain dari dewa Google).

Deskripsi paling mendalam tentang kompiler GWT yang saya tahu dapat ditemukan di dek slide ini, dan pembicaraan asli dari mana asalnya. Di sini, Anda dapat menemukan detail tentang fitur keren lainnya dari proses kompilasi, seperti kemampuan GWT untuk melakukan pemecahan kode, menghasilkan beberapa file skrip terpisah untuk dimuat secara independen oleh browser.

JRE yang Dicontohkan

Kompiler Java-ke-JavaScript akan menjadi sedikit lebih baru jika tidak dilengkapi dengan implementasi Java Runtime Environment (JRE), yang menyediakan pustaka inti yang diandalkan oleh hampir semua aplikasi Java. Secara kasar, bekerja di Java tanpa, misalnya, Collections, atau metode String, akan membuat frustrasi, dan tentu saja, mem-porting library ini adalah pekerjaan yang luar biasa. GWT mengisi lubang ini dengan apa yang disebut Emulated JRE.

Emulated JRE sama sekali bukan implementasi ulang penuh dari Java JRE, melainkan semacam pilihan kelas dan metode yang dapat berguna (dan dapat digunakan) di sisi klien. Fungsionalitas yang ada di Java JRE tetapi tidak akan Anda temukan di dalam Emulated JRE terbagi dalam tiga kategori:

  • Hal-hal yang tidak dapat di-porting di sisi klien. Misalnya, java.lang.Thread atau java.io.File tidak dapat diimplementasikan di browser dengan semantik Java yang sama. Halaman browser berulir tunggal dan tidak memiliki akses langsung ke sistem file.

  • Hal-hal yang dapat diimplementasikan tetapi akan "berbiaya terlalu banyak" dalam hal ukuran kode, kinerja, atau dependensi, dan yang oleh komunitas lebih suka tidak ada di dalam GWT. Termasuk dalam kategori ini, misalnya, adalah refleksi Java ( java.lang.reflect ) yang akan membutuhkan transpiler untuk menyimpan informasi kelas untuk setiap jenis, dan itu akan menyebabkan ukuran JavaScript yang dikompilasi membengkak.

  • Hal-hal yang tidak diminati oleh siapa pun dan oleh karena itu belum diimplementasikan.

Jika terjadi bahwa Emulated JRE tidak sesuai dengan kebutuhan Anda (misalnya, Anda memerlukan beberapa kelas yang tidak disediakan), GWT memungkinkan Anda untuk menulis implementasi Anda sendiri. Mekanisme yang kuat ini, tersedia melalui tag <super-source> , memungkinkan untuk menghindari masalah saat mengadaptasi perpustakaan eksternal baru yang menggunakan bagian dari JRE yang tidak ditiru.

Mungkin terlalu rumit, atau bahkan tidak mungkin, untuk menyediakan implementasi penuh dari beberapa bagian JRE, jadi untuk tugas-tugas tertentu, implementasi Anda sendiri mungkin tidak secara ketat mengikuti semantik JRE Java, meskipun mereka bekerja dalam kasus spesifik Anda. Memang, jika Anda mempertimbangkan untuk mengembalikan kelas Anda ke proyek, ingatlah bahwa sangat penting untuk Emulated JRE bahwa setiap kelas yang disertakan mengikuti semantik yang sama dari Java JRE asli. Ini memastikan bahwa siapa pun dapat mengkompilasi ulang kode Java ke dalam JavaScript dan percaya bahwa mereka akan mendapatkan hasil yang diharapkan. Selalu pastikan kode Anda diuji secara menyeluruh sebelum memberikannya kembali ke komunitas.

Lapisan Interoperabilitas

Untuk menjadi alat yang efektif untuk produksi aplikasi web dunia nyata, GWT harus memungkinkan pengembang untuk berinteraksi dengan mudah dengan platform yang mendasarinya. Yaitu, browser dan DOM.

Sejak awal, GWT dibangun untuk mendukung interaksi semacam itu melalui JavaScript Native Interface (JSNI), yang membuat akses API dalam browser menjadi mudah. Misalnya, menggunakan fitur sintaks yang unik untuk kompiler GWT, Anda dapat menulis kode Java berikut:

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

dan Anda bebas mengimplementasikan isi metode dalam JavaScript. Anda bahkan dapat membungkus objek JavaScript dalam JavaScriptObject (JSO) dan membuatnya dapat diakses dalam kode Java Anda.

Contoh di mana lapisan ini berperan dapat ditemukan dalam konteks komposisi UI. Mainstream Java selalu menggunakan toolkit Widget standar untuk membangun elemen UI, memanfaatkan Java Native Interface untuk mengakses windowing dan sistem input sistem operasi yang mendasarinya. Lapisan interoperabilitas GWT melakukan hal yang sama, sehingga Widget tradisional bekerja dengan mulus di dalam browser. Satu-satunya perbedaan adalah, dalam hal ini, sistem yang mendasarinya adalah browser dan DOM.

Namun, kerangka kerja front-end asli telah meningkat pesat dalam beberapa tahun terakhir, dan saat ini menawarkan keuntungan yang signifikan dibandingkan Widget GWT. Karena kerangka kerja ini telah berkembang dalam kecanggihan, upaya untuk mengimplementasikannya dalam JSNI telah mengungkap kekurangan dalam arsitektur lapisan interoperabilitas. Dimulai dengan versi 2.7, GWT memperkenalkan JsInterop, pendekatan baru berdasarkan anotasi Java, yang memungkinkan Anda mengintegrasikan kelas GWT dengan JavaScript dengan cepat dan mudah. Tidak perlu lagi menulis metode JSNI atau kelas JSO. Sebagai gantinya, Anda cukup menggunakan anotasi seperti @JSType atau @JSProperty , yang memungkinkan Anda bekerja dengan kelas JavaScript asli seolah-olah itu adalah Java.

Spesifikasi lengkap JsInterop masih dalam proses, dan pembaruan terbaru hanya dapat dicoba dengan mengkompilasi sumber dari repositori GWT. Tetapi sudah jelas bahwa ini adalah arah baru yang memungkinkan GWT mengikuti platform web yang berkembang.

Salah satu proyek yang sedang berlangsung yang memanfaatkan JsInterop adalah elemen gwt-polimer yang baru dirilis, yang membuat semua elemen Besi dan Kertas dari Polimer tersedia untuk GWT. Yang menarik dari library ini adalah para developer tidak perlu melakukan generate Java API secara manual. Proyek ini menggunakan gwt-api-generator untuk menghasilkan sebagian besar antarmuka secara langsung dengan mem-parsing pustaka Polymer dan anotasi JSDoc. Hal ini memudahkan untuk menjaga agar binding tetap up to date.

Kata-kata Terakhir

Dengan peningkatan pada kompiler, lapisan interoperabilitas, dan kinerja serta ukuran kode yang dihasilkan selama dua tahun terakhir, jelas bahwa GWT bukan hanya “alat pengembangan web lain”, tetapi juga siap menjadi alat referensi utama untuk pengembangan skala besar, aplikasi web yang kompleks, dan bahkan bisa menjadi pilihan yang sangat baik untuk membuat aplikasi yang lebih sederhana menjadi luar biasa.

Saya menggunakan GWT setiap hari dalam pekerjaan saya sebagai pengembang dan konsultan, tetapi kebanyakan saya menyukai GWT karena memungkinkan saya mendorong batas kemampuan browser dan menunjukkan bahwa aplikasi web modern dapat sekuat aplikasi desktop.

Komunitas Proyek GWT sangat aktif, dan perpustakaan, proyek, dan aplikasi baru berdasarkan GWT terus diusulkan. Di Florence, GWTcon2015 berbasis komunitas akan bertemu pada 11 November. Jika Anda berada di wilayah tersebut, saya harap Anda akan datang dan bertemu dengan beberapa pengembang inti, dan belajar tentang semua peluang untuk menjadi bagian dari evolusi perangkat yang luar biasa ini.