#על טעם ועל ריח – GWT

השבוע הייתי עד לדיון בנושא לGWT. לא לקחתי צד מכיוון שמהר מאוד העסק הפך לויכות דתי כמו שמקובל בתחום שלנו.

אין לי ספק שGWT היא טכנולוגיה בשלה מבית טוב ועם תומכים נלהבים שניתן לבסס עליה אפליקציות רציניות. בכל אופן הנה 2 הסנט שלי למה אני לא בוחר בה (כאשר הבחירה בידי).

Action based vs. component based

בגדול, ניתן לחלק את מסגרות הפיתוח לרשת לשני סוגים:

Action based frameworks

זהו הסגנון הנפוץ בו משתמשים בדרך כלל בטכנולוגית template כלשהי (או תחליפי view אחרים) כדי לייצר את התשובה הנשלחת לדפדפן. תשובה זו כוללת גם אלמנטים כמו לינקים, תפריטים וכפתורים אשר ישמשו לפניות נוספות. באופן טבעי, סגנון זה מעודד יצור של לינקים בסגנון ?action=deleteRow&roweId=33 אשר מתארים את הפעולה המבוקשת, ומגיעים לרכיב המתאים.

Component based frameworks

כאן הגישה היא לנסות לעבוד בצורה פרוגרמטית (למשל לייצר מחלקה שמייצגת view מסויים, ואז להוסיף כפתורים על ידי משהו כמו add new Button('click me') בסגנון swing, mfc וכו'). הרעיון הוא שהתשתית דואגת לתרגום האובייקטים שיצרנו לאלמנטים של html, קושרת אותם לאירועי JS מתאימים וכו'. גם האינטראקציה עם השרת נעשת בצורה שהיא אנלוגית לטיפול באירועים בכל אפליקצית GUI, למשל נטפל באירוע בסגנון   deleteButton33Clicked() במקרה של הדוגמא הקודמת (כמובן שהכל פושט לצורך המחשה).

אז מה עדיף?

קודם כל שתי הגישות עובדות, ולכל אחת יש חסידים ומתנגדים. הרושם שלי הוא שהראשונה קצת יותר נפוצה והשניה קצת יותר איזוטרית (למשל טכנולוגיות חמות כמו RoR הן Action Based) אבל זה לא כל כך חוכמה כיוון שהם קרובות יותר לצורה ה"מקורית" שבה עובדות הפלטפורמות. הנטייה שלי היא גם לסוג הראשון ומעבר לסיבות הטכניות יש שני דברים עקרוניים:

מחולליה מות יומת

אולי קצת הגזמתי עם הפראפרזה, אבל אני שונא טכנולוגיות שמחוללות קוד בזמן ריצה. זה טוב ויפה כשהכל עובד ועושה בשבילך את העבודה באופן אוטומטי, וזה נורא כשמגיע הרגע (והנסיון מראה שהוא כמעט תמיד מגיע) שבו צריך "לצלול" פנימה כדי לתקן משהו ואז מחזירים ליקום את כל הזמן שנחסך + ריבית.

חלוקת אחריות

הסיבה העיקרית היא שלדעתי יש פה הנצחה של מצב לא תקין – ערבוב אחריות בין רכיבי client וserver. למעשה, כל קובץ jsp (או asp ובוודאי php) מפר בהגדרה את עקרון separation of concerns שכן הוא מכיל רכיבי תוכנה ששייכים לשני מקומות שונים. הדבר הזה יוצר בעיות של הנדסת תוכנה, בעיות של skill set וחלוקת צוותים וכו'. מובן שניתן להתגבר על זה וכך עושה באופן יומיומי כל מי שמפתח jsp למשל, אבל ברמת העקרון זהו מודל בעייתי.

בזמן שבו התפתחו הפרדיגמות של פיתוח לאינטרנט הקיימות כיום, היה ברור שהלקוח הוא דפדפן ששולח בקשות וטפסים, ומקבל חזרה דפי רשת בקוד html. המצב הזה שונה היום: יש לנו דפדפנים, לקוחות wap, אפליקציות פלאש ובעיקר iOS ואנדרואיד. גם html5 מדגיש לנו את המעבר (ולמעשה החזרה) למצב שבו יש אפליקציה אצל הלקוח והתקשורת עם השרת מעבירה מידע בלבד, ללא markup. באפליקציות כאלה הלקוח מפותח באופן עצמאי, בטכנולוגיות, בכלים ובפרקטיקות שמיועדים רק לו, והצדדים לא צריכים לדעת כלום אחד על השני פרט לפרוטוקול האפליקטיבי ביניהם. אז אני לא טוען שמעכשיו צריך לכתוב רק בסגנון הזה של הפרדה מלאה, אבל צריך תמיד לזכור שערבוב של רכיבי לקוח בצד השרת הוא סוג של פשרה, ולא סגנון שאנחנו רוצים לאמץ ולהעמיק.

כתיבת תגובה

הזינו את פרטיכם בטופס, או לחצו על אחד מהאייקונים כדי להשתמש בחשבון קיים:

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s