مجموعة أدوات GWT: إنشاء واجهات JavaScript أمامية قوية باستخدام Java

مجموعة أدوات الويب GWT ، المعروفة سابقًا باسم Google Web Toolkit ، هي مجموعة من أدوات التطوير لبناء وتحسين التطبيقات المعقدة القائمة على المستعرض باستخدام لغة برمجة Java.

ما يجعل GWT ليست "أداة Java أخرى لكتابة تطبيقات الويب" ، هو حقيقة أن قلب مجموعة الأدوات عبارة عن مترجم يحول Java إلى JavaScript (بالإضافة إلى HTML و CSS) ، مما يتيح للمطورين كتابة تطبيقات الويب الأمامية مع الاستفادة من جميع نقاط القوة في Java.

من السهل أيضًا استخدام مزيج من Java و JavaScript ، حيث تتضمن GWT بنية قوية للتشغيل البيني للتفاعل مع نظام الويب الأساسي. تشبه إلى حد كبير واجهة Java الأصلية (JNI) تسمح لـ Java Virtual Machine (JVM) باستدعاء إجراءات خاصة بالنظام الأساسي (على سبيل المثال ، للوصول إلى ميزات أجهزة معينة ، أو استخدام مكتبات خارجية من لغات أخرى) ، تتيح لنا GWT كتابة معظم في Java ثم ، إذا لزم الأمر ، لاستخدام واجهة برمجة تطبيقات ويب معينة ، أو الاستفادة من مكتبات JavaScript الموجودة ، "للانتقال إلى اللغة الأصلية" والانتقال إلى JavaScript.

وُلدت GWT كمنتج من منتجات Google ولكنها تخرجت لفتح المصدر في أواخر عام 2011 ويتم إصدارها حاليًا بموجب ترخيص Apache (الإصدار 2) تحت اسم GWT Open Source Project . تدار من قبل لجنة توجيهية تضم ممثلين من العديد من الشركات ، بما في ذلك Google و RedHat و ArcBees و Vaadin و Sencha ، بالإضافة إلى مطورين مستقلين من المجتمع.

GWT في الماضي والمستقبل

تم إصدار Google Web Toolkit لأول مرة في عام 2006. وقد تم إنشاؤه كأداة لمساعدة مهندسي Google على تطوير تطبيقاتهم المعقدة القائمة على المتصفح ، مثل AdWords و Google Wallet و Google Flights ، ومؤخراً ، يتم استخدامها في قلب جداول بيانات Google وتطبيقات Inbox.

في عام 2006 ، كانت المتصفحات (ومترجمات جافا سكريبت) بعيدة كل البعد عن أن تكون موحدة. كان رمز الواجهة الأمامية بطيئًا وعربات التي تجرها الدواب ويصعب استخدامها بشكل موثوق. كان هناك نقص شبه كامل في المكتبات عالية الجودة وأطر تطوير الويب. على سبيل المثال ، لم يكن jQuery موجودًا حتى هذا العام. لذلك ، لكي يتمكن المهندسون في Google من تطوير تطبيقات ويب واسعة النطاق ، قرروا الاستفادة من الأدوات والكفاءات الحالية. كانت Java هي اللغة الأنسب لاحتياجاتهم ، كونها معروفة جيدًا ومتكاملة تمامًا في IDEs ، مثل Eclipse ، وهكذا بدأت Google Web Toolkit حياتها.

كان الهدف هو إخفاء الاختلافات بين المتصفحات ، وتغليف الحيل اللازمة لكتابة JavaScript فعال داخل مترجم Java ، مما يترك المطورين بعيدًا عن طغيان تقنيات المتصفح.

بالطبع ، خلال العقد الماضي ، تغيرت شبكة الإنترنت. أصبحت المتصفحات أسرع وتلاقت مع معايير التنفيذ ، وتم تطوير الكثير من أطر العمل والمكتبات الرائعة للواجهة الأمامية ، بما في ذلك jQuery و Angular و Polymer و React. لذا فإن السؤال الأول الذي قد تطرحه بطبيعة الحال هو ، "هل ما زالت تقنية GWT مفيدة؟"

باختصار: نعم .

في سياق تطوير الويب الحديث ، لا مفر من استهداف المتصفحات وأصبحت JavaScript لغة مشتركة لتطبيقات الواجهة الأمامية. لكن بالطبع ، الأدوات واللغات المختلفة هي الأنسب للمهام المختلفة. تهدف GWT ، إلى جانب عدد قليل من المشاريع المماثلة ، إلى استهداف المتصفحات دون حصر المطورين في استخدام JavaScript.

في المستقبل القريب ، سيتم تسهيل تطوير وتوظيف أدوات "التحويل البرمجي إلى الويب" مثل GWT من قبل ما يسمى بمجموعة WebAssembly التابعة لاتحاد شبكة الويب العالمية. لا توجد مساحة شاسعة للأدوات التي تترجم إلى JavaScript فحسب ، ولكن هذا النهج قد يلبي حاجة حقيقية في السياقات التي تتراوح من إلغاء تحميل جزء من الحساب إلى المتصفحات ، وإعادة استخدام التعليمات البرمجية والمكتبات الحالية ، ومشاركة التعليمات البرمجية بين النهاية الخلفية والواجهة الأمامية ، باستخدام الكفاءات الحالية وسير العمل والاستفادة من ميزات اللغات المختلفة (على سبيل المثال ، الكتابة الثابتة في حالة GWT).

من المتوقع أن يصدر مشروع GWT الإصدار 2.8 قريبًا ، والإصدار 3.0 قيد التطوير ، مع تحسينات كبيرة في الأعمال:

• إعادة اختراع إمكانية التشغيل البيني مع JavaScript
• مترجم محسن (معاد كتابته بالكامل تقريبًا)
• أحدث دعم لجافا (مثل لامدا)

في الواقع ، تتوفر معظم ميزات GWT 3.0 بالفعل في مستودع Git العام. فقط قم بفحص الجذع هنا وقم بتجميع GWT باتباع التوثيق هنا.

مجتمع GWT

منذ أن أصبحت GWT مفتوحة المصدر في عام 2011 ، اضطلع المجتمع بدور محوري في تطور المشروع.

تحدث جميع عمليات التطوير في مستودع Git المستضاف على gwt.googlesource.com ، وتتم جميع مراجعات الكود على gwt-review.googlesource.com. في هذه الصفحات ، يمكن لأي شخص مهتم بتطوير مجموعة الأدوات المساهمة ومعرفة ما يعمل عليه المجتمع. خلال السنوات القليلة الماضية ، ارتفعت نسبة التصحيحات الجديدة من غير موظفي Google من حوالي 5 بالمائة في عام 2012 إلى حوالي 25 بالمائة في العام الماضي ، مما يؤكد المشاركة المتزايدة.

اجتمع المجتمع هذا العام في عدد قليل من الاجتماعات الكبيرة في الولايات المتحدة وأوروبا. تم عقد GWT.create ، الذي نظمته Vaadin ، في كل من ميونيخ ، ألمانيا و Mountain View ، كاليفورنيا في يناير ، وحضر أكثر من 600 مشارك من عشرات البلدان. في 11 تشرين الثاني (نوفمبر) ، في فلورنسا بإيطاليا ، سنعقد النسخة الثانية من GWTcon ، وهو مؤتمر GWT يحركه المجتمع والذي أساعد في تنظيمه.

ما هو GWT المناسب؟

يناقش استطلاع سنوي حول مجموعة أدوات GWT ، صادر عن Vaadin ، تطور تطوير GWT ، وكيف يشعر المطورون تجاه مجموعة الأدوات ، والجيدة ، والسيئة ، وما إلى ذلك. يتيح لنا هذا الاستطلاع أيضًا فهم الغرض من استخدام مجموعة الأدوات ، وكيف يتغير مجتمع المستخدمين ، وتوقعات المطورين لمستقبل مجموعة الأدوات.

يمكن الاطلاع على تقرير مستقبل GWT لعام 2015 هنا ، وهو يوضح أن GWT تحظى بشعبية كبيرة في بناء تطبيقات الويب واسعة النطاق. على سبيل المثال ، في الصفحة 14 ، تنص على أن "معظم التطبيقات هي تطبيقات أعمال ثقيلة البيانات ويتم العمل معها لساعات عديدة في اليوم."

كما هو متوقع ، من السهل استنتاج أن البيئة الطبيعية لـ GWT هي مجال تطبيقات الويب واسعة النطاق ، حيث تكون قابلية صيانة الشفرة مهمة ، وتستفيد الفرق الكبيرة من بنية لغة Java.

من ناحية أخرى ، بالنظر إلى معايير الكود التي تم إنشاؤها بواسطة GWT (على سبيل المثال ، في الخطاب الرئيسي لمؤتمر GWT.create العام الماضي ، على الصفحات 7 و 8 و 11) من السهل رؤية ذلك ، من حيث الأداء و حجم الشفرة ، فإن JavaScript المترجمة رائعة بشكل مذهل. إذا تم استخدامه بشكل صحيح ، فإن الأداء الذي تم الحصول عليه يمكن مقارنته بأفضل جافا سكريبت مكتوبة بخط اليد. نتيجة لذلك ، من الممكن بالفعل استخدام GWT لنقل مكتبات Java إلى الويب.

هذا ينير سيناريو مثالي آخر لـ GWT. نظام Java البيئي مليء بالمكتبات عالية الجودة التي ليس لها نظير جاهز للاستخدام في JavaScript. يمكن استخدام مترجم GWT لتكييف مثل هذه المكتبات للويب. بمعنى آخر ، يتيح لنا GWT مزج المكتبات المتوفرة في كل من Java و JavaScript ، وتشغيلها في المتصفح.

يمكن رؤية هذا النهج في تطوير PicShare ، حيث نوضح كيف يمكن نقل العديد من مكتبات Java التي لا تعتبر عامة للويب (NyARToolkit على سبيل المثال) إلى المتصفح باستخدام GWT ، ودمجها مع واجهات برمجة تطبيقات الويب ، بما في ذلك WebRTC و WebGL ، الحصول على أداة الواقع المعزز على شبكة الإنترنت بالكامل. كنت فخورًا بتقديم PicShare في مؤتمر GWT.create لعام 2015 في يناير الماضي.

تحت الغطاء: تحويل Java إلى JavaScript

مجموعة أدوات GWT عبارة عن مجموعة معقدة من الأدوات بشكل معتدل ، ولكن يمكن لأي شخص البدء في استخدامها في لمح البصر ، بفضل التكامل السهل الاستخدام بشكل مدهش مع Eclipse.

يعد إنشاء تطبيق بسيط باستخدام GWT أمرًا سهلاً نسبيًا لأي شخص لديه خلفية في مشروعات تطوير Java. ولكن لفهم ما "يحدث بالفعل" ، يجدر تحليل المكونات الرئيسية لمجموعة الأدوات:

• جافا لجافا سكريبت Transpiler
• تمت محاكاة بيئة وقت تشغيل Java
• طبقة التشغيل البيني

مترجم أمثلية GWT

يصبح الوصف المتعمق لكيفية عمل المترجم تقنيًا للغاية في وقت مبكر جدًا ، ولا نحتاج إلى التعمق في هذا الأمر ، لكن بعض المفاهيم العامة تستحق النظر فيها.

أول شيء يجب فهمه هو أن GWT تقوم بترجمة Java إلى JavaScript عن طريق الترجمة على مستوى كود المصدر. بمعنى ، يتم ترجمة مصدر Java ( التحويل هو المصطلح التقني) إلى JavaScript. هذا على عكس وجود نوع من Java Virtual Machine مكتوب في JavaScript ، والذي ينفذ Java bytecode. (هذا ممكن بالفعل ، وهو النهج الذي يستخدمه Doppio ، لكنه ليس طريقة عمل GWT.)

بدلاً من ذلك ، يتم تقسيم كود Java إلى شجرة بناء جملة مجردة (AST) تمثل العناصر النحوية للشفرة. ثم يتم تعيينه إلى مكافئ (ومحسن) Javascript AST ، والذي يتم تحويله أخيرًا مرة أخرى إلى كود JavaScript الفعلي.

إن تقييم مزايا وعيوب الترجمة بعيدًا عن موضوع هذا المنشور ، لكن دعني ألاحظ أنه باستخدام هذه الطريقة ، يمكن لـ GWT الاستفادة بشكل مباشر من خدمات جمع البيانات المهملة لمترجم JavaScript ، إلى جانب أي ميزات أخرى أصلية في المتصفح.

هناك بعض الأجزاء الصعبة بالطبع. على سبيل المثال ، تحتوي JavaScript على نوع رقمي واحد فقط ، والذي لا يمكن أن يحتوي على نوع عدد صحيح long يبلغ 64 بت في Java ، لذلك تتطلب الأنواع long معاملة خاصة من قبل المترجم. بالإضافة إلى ذلك ، الكتابة الثابتة في Java ليس لها معنى مباشر في JavaScript ، لذلك يجب توخي الحذر بشكل خاص للحفاظ ، على سبيل المثال ، على تكافؤ عمليات الطباعة بعد التحويل.

من ناحية أخرى ، فإن ميزة النقل السريع التي يمكن تقديرها بسهولة هي أن GWT يمكنها إجراء تحسينات (لكل من الحجم والأداء) على مستوى Java وعلى مستوى JavaScript. يمكن معالجة شفرة JavaScript القياسية الناتجة بشكل أكبر في خط أنابيب النشر الخاص بك. على سبيل المثال ، تتضمن إحدى الممارسات الشائعة التي تم دمجها الآن في توزيع GWT القياسي تحسين إخراج JavaScript بواسطة المحول باستخدام مترجم JavaScript عالي التخصص إلى JavaScript Closure Compiler (هدية أخرى من آلهة Google).

يمكن العثور على الوصف الأكثر عمقًا لمترجم GWT الذي أعرفه في مجموعة الشرائح هذه ، والحديث الأصلي الذي أتى منه. هنا ، يمكنك العثور على تفاصيل حول الميزات الرائعة الأخرى لعملية التجميع ، مثل قدرة GWT على القيام بتقسيم الكود ، وإنشاء عدة ملفات نصية منفصلة ليتم تحميلها بشكل مستقل بواسطة المتصفح.

تمت محاكاة JRE

سيكون مترجم Java-to-JavaScript أكثر من مجرد حداثة إذا لم يتم استكماله بتطبيق Java Runtime Environment (JRE) ، والذي يوفر المكتبات الأساسية التي يعتمد عليها أي تطبيق Java تقريبًا. بشكل تقريبي ، العمل في Java بدون ، على سبيل المثال ، المجموعات ، أو أساليب String ، سيكون أمرًا محبطًا ، وبالطبع ، يعد نقل هذه المكتبات مهمة عملاقة. تملأ GWT هذه الفتحة بما يسمى بـ Emulated JRE.

لا يعد Emulated JRE بأي حال من الأحوال إعادة تنفيذ كاملة لـ Java JRE ، ولكنه نوع من اختيار الفئات والطرق التي يمكن أن تكون مفيدة (وقابلة للاستخدام) من جانب العميل. تنقسم الوظائف الموجودة في Java JRE والتي لن تجدها داخل Emulated JRE إلى ثلاث فئات:

• الأشياء التي لا يمكن نقلها من جانب العميل. على سبيل المثال ، لا يمكن تنفيذ java.lang.Thread أو java.io.File في متصفح له نفس دلالات Java. صفحة المستعرض ذات سلسلة محادثات فردية وليس لها وصول مباشر إلى نظام الملفات.

• الأشياء التي يمكن تنفيذها ولكنها "تكلف الكثير" من حيث حجم الكود أو الأداء أو التبعيات ، والتي يفضل المجتمع بالتالي عدم وجودها داخل GWT. تشتمل هذه الفئة ، على سبيل المثال ، على انعكاس جافا ( java.lang.reflect ) والذي يتطلب من الناقل الاحتفاظ بمعلومات الفئة لكل نوع ، وهذا من شأنه أن يتسبب في تضخم حجم JavaScript المترجم.

• أشياء لم يكن أحد يهتم بها وبالتالي لم يتم تنفيذها.

إذا حدث أن محاكاة JRE لا تناسب احتياجاتك (على سبيل المثال ، تحتاج إلى فئة غير متوفرة) ، فإن GWT تسمح لك بكتابة التنفيذ الخاص بك. هذه الآلية القوية ، المتاحة من خلال العلامة <super-source> ، تجعل من الممكن التحايل على المشاكل عند تكييف مكتبات خارجية جديدة تستخدم أجزاء من JRE لم تتم محاكاتها.

قد يكون من المعقد للغاية ، أو حتى المستحيل ، توفير التنفيذ الكامل لبعض أجزاء JRE ، لذلك بالنسبة لمهام محددة ، قد لا تتبع تطبيقاتك بدقة دلالات Java JRE ، على الرغم من أنها تعمل في حالتك المحددة. في الواقع ، إذا كنت تفكر في إعادة فصولك الدراسية إلى المشروع ، فتذكر أنه من الأهمية بمكان بالنسبة لـ Emulated JRE أن كل فئة مضمنة تتبع نفس دلالات Java JRE الأصلية. هذا يضمن أن أي شخص يمكنه إعادة ترجمة كود Java إلى JavaScript ويثق في أنه سيحصل على النتائج المتوقعة. تأكد دائمًا من اختبار الكود الخاص بك جيدًا قبل إعادته إلى المجتمع.

طبقة التشغيل البيني

لكي تكون أداة فعالة لإنتاج تطبيقات الويب الواقعية ، يجب أن تسمح GWT للمطورين بالتفاعل بسهولة مع النظام الأساسي الأساسي. هذا هو المتصفح و DOM.

منذ البداية ، تم إنشاء GWT لدعم مثل هذا التفاعل من خلال واجهة JavaScript الأصلية (JSNI) ، مما يجعل الوصول إلى واجهات برمجة التطبيقات في المتصفح أمرًا سهلاً. على سبيل المثال ، باستخدام ميزات بناء الجملة الفريدة لمترجم GWT ، يمكنك كتابة كود Java التالي:

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

وأنت حر في تنفيذ جسم الطريقة في JavaScript. يمكنك حتى التفاف كائنات JavaScript في JavaScriptObject (JSO) وإتاحتها في كود Java الخاص بك.

يمكن العثور على مثال على مكان تشغيل هذه الطبقة في سياق تكوين واجهة المستخدم. لطالما استخدمت Java الرئيسية مجموعة أدوات Widgets القياسية لبناء عناصر واجهة المستخدم ، والاستفادة من واجهة Java Native Interface للوصول إلى أنظمة النوافذ والإدخال الأساسية لنظام التشغيل. تقوم طبقة إمكانية التشغيل التفاعلي الخاصة بـ GWT بنفس الشيء ، بحيث تعمل الأدوات التقليدية بسلاسة داخل المتصفح. الاختلاف الوحيد في هذه الحالة هو أن النظام الأساسي هو المتصفح و DOM.

ومع ذلك ، فقد تحسنت الأطر الأمامية الأصلية بسرعة في السنوات الأخيرة ، وتقدم في الوقت الحاضر مزايا كبيرة على أدوات GWT. نظرًا لتطور هذه الأطر في التطور ، كشفت محاولات تنفيذها في JSNI عن أوجه القصور في بنية طبقة التشغيل البيني. بدءًا من الإصدار 2.7 ، قدمت GWT JsInterop ، وهي طريقة جديدة تعتمد على تعليقات Java التوضيحية ، والتي تتيح لك دمج فئات GWT الخاصة بك مع JavaScript بسرعة وسهولة. لم يعد من الضروري كتابة طرق JSNI أو فئات JSO. بدلاً من ذلك ، يمكنك ببساطة استخدام التعليقات التوضيحية مثل @JSType أو @JSProperty ، مما يتيح لك العمل مع فئات JavaScript الأصلية كما لو كانت Java.

لا تزال المواصفات الكاملة لـ JsInterop قيد التقدم ، ولا يمكن تجربة آخر التحديثات إلا من خلال تجميع المصدر من مستودع GWT. ولكن من الواضح بالفعل أن هذا هو الاتجاه الجديد الذي سيسمح لـ GWT بمواكبة منصات الويب المتطورة.

أحد المشاريع الجارية التي تستفيد من JsInterop هو عنصر البوليمر الذي تم إصداره مؤخرًا ، والذي يجعل جميع عناصر الحديد والورق من البوليمر متاحة لشركة GWT. المثير للاهتمام في هذه المكتبة هو أن المطورين لا يحتاجون إلى إنشاء Java API يدويًا. يستخدم المشروع gwt-api-generator لإنشاء معظم الواجهات مباشرةً عن طريق تحليل مكتبة Polymer وتعليقات JSDoc التوضيحية. هذا يجعل من السهل تحديث الروابط.

الكلمات الأخيرة

من خلال التحسينات التي تم إدخالها على المترجم وطبقة التشغيل البيني وأداء وحجم الشفرة التي تم إنشاؤها على مدار العامين الماضيين ، من الواضح أن GWT ليست مجرد "أداة أخرى لتطوير الويب" ، ولكنها في طريقها لتصبح مجموعة أدوات مرجعية رئيسية لـ تطوير تطبيقات ويب معقدة وواسعة النطاق ، ويمكن أن يكون خيارًا ممتازًا لجعل التطبيقات الأبسط رائعة.

أستخدم GWT يوميًا في عملي كمطور واستشاري ، لكن في الغالب أحب GWT لأنه يتيح لي دفع حدود إمكانيات المتصفح وإظهار أن تطبيقات الويب الحديثة يمكن أن تكون قوية مثل تطبيقات سطح المكتب.

مجتمع مشروع GWT نشط حقًا ، ويتم باستمرار اقتراح مكتبات ومشروعات وتطبيقات جديدة تعتمد على GWT. في فلورنسا ، سيجتمع GWTcon2015 الذي يحركه المجتمع في 11 نوفمبر. إذا كنت في المنطقة ، آمل أن تأتي وتلتقي ببعض المطورين الأساسيين ، وتتعرف على جميع الفرص لتكون جزءًا من تطور مجموعة الأدوات المذهلة هذه.