ASP.NET מרגילה מתכנתים לעבוד בצורה בזבזנית ומחפירה בכל הקשור ל-UI. כאחד שעוסק שנים רבות בפיתוח ל-Web בשלל טכנולוגיות, כל הזמן היה דגש כמה שפחות להטריד את השרת. לא רק ש-ASP.NET WebForms לא עושה את זה, היא אפילו מעודדת להטריד כמה שיותר. וזה פשוט רע.

כמה פעמים ראיתי קוד כמו

void btn_Click(object sender,EventArgs e) {
        Response.Redirect("Page.aspx?Param=Value");
}

יש למישהו מושג איזה תהליך קורה כשלוחצים על הכפתור עד שמגיעים ללינק?

אז תיאור קצרצר:

1. לחיצה על הכפתור מפעילה רוטינות JS לבדוק שהטופס ואלידי בהקשר של אותו Validation Group של הכפתור (אם יש), ובנוסף שמה את הכפתור כ-EventTarget
2. אם הכל כשורה – הטופס נשלח לשרת יחד עם כל ערכי הפקדים הקיימים על העמוד וכמובן ה-ViewState
3. מגיעה בקשת HTTP לשרת, כל הרוטינות הרגילות, הפניות, יצירת HttpContext, הרצת כל ה-HttpModules – טעינת Session, Cache וכו'
4. העמוד המכיל את הכפתור רץ: נוצר מופע מהמחלקה של העמוד
5. כל שרשרת האירועים רצה, אתחול culture, קונטרולים, init, load, render וכמובן שרשרת האירועים של קונטרולים מקוננים בעמוד שלנו
6. אירוע ה-Click ששמנו לכפתור, בין אם ב-aspx בעזרת asp:Button OnClick=btn_Click או בין אם בקוד בעזרת btn.Click+=btn_Click, מחווט ונרשם לכפתור
7. השרת עכשיו בודק מי ה EventTarget שלו ומגלה שזה הכפתור. עכשיו הוא יורה את אירוע ה-Click של הכפתור ומגיע לנחלה – מבצע Response.Redirect.

עכשיו שלבים 3-5 רצים שוב עבור העמוד אליו הפנינו.

נשמע הגיוני? לי ממש לא.

<a href="Page.aspx?Param=Value">click</a>
<button onclick="location.href='Page.aspx?Param=Value';">click</button>

זה הרבה יותר טוב.

אז נכון, לא כולם עושים את זה. אבל לשם דוט נט מובילה אנשים שלא מכירים את התחום. ובמלוא מובן המילה – זה רע.

חושבים שזה לא משפיע? המשתמשים/לקוחות שלכם כבר יודעים לזהות אתר עם סיומת aspx כאתר שהולך להיות איטי לגלוש בו. כל האינטראקציה הלוך ושוב בין הקליינט לסרבר כל כך מיותרת ומכבידה על הגלישה עצמה. חוויית משתמש נוראית.
התדמית של ASP.NET כל כך יורדת בגלל היישום התמוה שמיקרוסופט עשו, גם בעיני משתמשים ובטח בעיני מתכנתים אחרים.

תחשבו על הסיטואציה הבאה: אתם מטיילים עם העכבר שלכם על המסך. בכל תזוזה של פיקסל – כל הפיקסלים על המסך מתרנדרים מחדש. הופכים להיות שחורים לעשירית שנייה ומקבלים צבע.
עכשיו תשוו את זה ל-ASP.NET WebForms

נכתב במקור כתגובה לשאלתה של רותם בפורום .net בתפוז. ואם השקעתי כל כך הרבה, אז יאללה, שיהיה גם חומר לבלוג

שורה תחתונה – טכנולוגית WebForms היא אחד הדברים הכי גרועים שמיקרוסופט אי פעם הוציאה. הטכנולוגיה הזו לעולם תיחשב כקיצור דרך של מיקרוסופט למתכנתי VB6 לעולם ה-Web. להבדיל, שימו לב, מ-ASP.NET שהיא פלטפורמה נהדרת אם לא הטובה מכולן.

מיקרוסופט ניסו לחשוב בצורה עסקית – איך אנחנו נותנים למתכנתי ה-VB שלנו גישה מהירה לעולם ה-Web המתפתח עד מאוד? כמובן – ניצור לו את הכלים שאותם הוא מכיר, באותה צורה ובאותה סביבה! Drag & Drop של אובייקטים, מחלקה שמייצגת את הטופס הנוכחי, לחיצה כפולה מובילה לאירוע לכתיבת קוד עבור אירוע ברירת המחדל. אחד לאחד. זה באמת מעורר הערצה.

מכיוון שלא באפשרות מיקרוסופט להטמיע דפדפן חדש שבעצם ירנדר אפליקציה ב-100% מהמחשבים בעולם, הם היו חייבים להישאר באותו רעיון של הדפדפן הרגיל ותקשורת HTTP – רינדור של HTML, טפסים, שרת staeless.

אז אחד אחד, הפתרונות שלהם:

• את כל העמוד שלנו נעטוף ב-form אחד בלבד, נוסיף לו מספר שדות שישמרו את המצב הנוכחי של הפקדים שלנו (להלן – ViewState). מטרת הטופס היא לגרום לאינטראקציה עם השרת בכל שינוי/לחיצת כפתור. בשרת אנחנו הרי יכולים לעשות מה-בא לנו (דברי מיקרוסופט) ולהחזיר חזרה לקליינט דברים אחרים מאלה שהיו על העמוד. בלי ליצור אותם בצד לקוח. רק לעבד בצד שרת ולהחזיר את כל המידע מחדש בצורה העדכנית, עם ViewState חדש שתואם את מצב הפקדים החדש שלנו.
• לא ממש חייבים לדעת HTML מאחר ויש Drag & Drop לפקדים שנראה זהה לעבודה מול WinForms. ואם בכל זאת רוצים – שמות הפקדים זהים לשל WinForms.
• כל קונטרול, הוא עטיפה בגודל הר למשהו פיצפון. כך הפך לו </"input type="text" name="a> ומקבילו ה-Serverי ["Request.Form["a למשהו מפלצתי, שבמבט ראשון נראה חמוד – </"asp:TextBox runat="server" ID="a> ומקבילו ה-Serverי a.Text (סוג של גרמלין) אך מאחוריו יושב מנוע רב מימדים. מי שלא חושב כך – שיפתח בבקשה את Reflector ויעבור על System.Web.UI (בהצלחה) . מעבר לזה – כל כפתור שנלחץ, כל DropDown ששונה וכו' גורמים לשרשרת תהליכים מטורפת. לחצת כפתור? שרפת קלוריה. לא שלך, של השרת. *כל* הנתונים שעל העמוד נשלחים לשרת. כל ערכי פקדי ה-TextBox שרונדרו ל-input ושאר חבריו, וכל ה-ViewState. עמוד ארוך? לא נורא, 50K upload של נתונים זה.. 7 שניות בממוצע? ה bandwidth גדל כל הזמן, למי אכפת ?:)
  עוד קצת בנוגע ל-ViewState: יש לך GridView בעמוד? כל הנתונים שבו מקומפרסים Base64 לתוך ה-ViewState ונשארים שם. מעתה, כל שינוי סדר, לחיצה על כפתור שבכלל יושב במקום אחר בעמוד וכו' ישלחו את כל הנתונים האלה חזרה לשרת, גם אם ה-GridView הזה לא צריך להיות שם אחרי הלחיצה (השרת לא יודע מזה). היוזר סה"כ רצה לבצע login, וכל נתוני העמוד נשלחו. 50K במקום 50 bytes (כולל headers).
• עיצוב (CSS) מיושם ע"י הפרופרטיז המוכרים – BackColor, BorderStyle.
• ב-JS בכלל לא צריך לגעת כי הכל כבר מיושם מאחורי הקלעים. ולידאציות, שליחת הטופס, יישום TreeView וכו'
• קונטרולים של Data כמו SqlDataSource כדי שנעשה את חיי המתכנתים כ"כ קלים.

ואז הגיע הבאזוורד – AJAX

פה מיקרוסופט נכנסה ללחץ. "מה נעשה מה נעשה" שאלה. הרי כל הקטע ב-AJAX זה JS שעושה דברים מגניבים, וחוצמזה פונה לשרת בדרך מינימלית ויודע לשלוח ולקבל חזרה מהשרת רק מה שצריך.
אז בא הפקד UpdatePanel – סוג של Panel שמכיל בתוכו פקדים. רוצה שהוא יתרפרש לבד בלי שכל העמוד יתרפרש? אין בעיה, זה אכן קורה. ועובד. נהדר, לא?
חה. לא. הרעיון ה*גרוע* מאחורי UpdatePanel הוא כזה: קח את כל ערכי הפקדים, את ה-ViewState, שלח לשרת, לא דרך form כי זה ירפרש את העמוד אלא דרך xmlhttp. בשרת תעשה כאילו קיבלת את הנתונים מתוך טופס אמיתי, תפעיל מחדש את כל ה PostBack מכניזם, צור את העמוד מחדש, תפעיל את שרשרת האירועים שלו ובסופו של דבר, תרנדר אותו ותגזור רק את המקטע שבתוך ה-UpdatePanel שלנו, ושלח אותו חזרה לקליינט, כמובן עם ViewState חדש.
כך, עטיפה של כל האתר ב UpdatePanel שקולה בדיוק ל-PostBack.
רציתם דברים מגניבים ב-JS? יש פקדי אנימציה (איטית בהשוואה לכל ספריית אפקטים אחרת ברשת).
גם ה-Extenderים של הפקדים הרגילים מורכבים ממכניזם די רחב (מדי), ועל אף שאני אוהב את יוזמת ה-Toolkit, הסירבול בהרחבה של פקדים שנכתבו שם הוא פשוט אבסורד (באף אפליקציה שהמחלקה שלי או אני כתבנו לא יכולנו להשתמש בפקד out of the box).

אני חייב לציין – אין לי שום דבר נגד מתכנתי VB או WinForms ויוזמה ברוכה של מיקרוסופט לקרבם לעולם ה-Web, אך המחיר שמשלמים בכך שהמנגנון המקורי של asp.net הוא מנגנון כבד ובזבזני הוא גדול.
ואני לא מדבר רק על ביצועים. אלא על זמן. זמן תסכול, זמן מחקר ב-Reflector מה-לעזאזל-הם-התכוונו, זמן קליטה ש-UpdatePanel עושה בעצם Full PostBack וש Partial PostBack זה FRAUD (תוך כדי חקירה ב-fiddler).

אוקיי, אחרי החפירה הארוכה הזו, אז מה עושים?

• מיקרוסופט מצידם עובדים סוף סוף על תחליף ל-WebForms שנקרא MVC – כרגע בבטא. זהו קונספט שבעיקרון קיים ב-PHP ו-Ruby On Rails, וגם קיים בפרוייקט castle עבור ASP.NET בשם monorail. מהבלוג של סקוט גו זה נראה טוב (יחי ה inline scripting)
• אפשר להפסיק לכתוב עם form runat=server. לעבוד פשוט מול הנדלרים (ashx) או web services.
• לא כל GridView או Repeater חייבים להיות כאלה. הם יכולים להיות inline code חמוד. זו לא עבירה. זה העתיד.
• AJAX – אין יותר פשוט מזה בצורה הטבעית שלו. עבודה מול web services עם ScriptService כדי לחשוף גם לפניות AJAX שלא מבוססות UpdatePanel או סתם לתוך ashx. אפשר לשלוח פניייה עם כל פריימוורק JS בסיסי כמו MooTools, jQuery, Prototype (אין טעם לכתוב לבד).
• בנוגע לשכפול לוגיקות — כותבים/מורידים פעם אחת בודק טפסים גנרי (יש כאלה שעובדים לפי class של input כמו input class=required) ויש לנו ולידאציות. בשרת נמשיך לעשות ולידאציות בשכבת הלוגיקה.

אחרי צעד כזה, פתאום מרגישים חופשיים ולא כבולים לכלום. וזמן הפיתוח מתקצר. באמת.
יש מאות אפליקציות web עשירות עם AJAX ו-JS מגניב מבוססות ROR או PHP. מישהו יכול למנות לי 10 בולטות מבוססות ASP.NET AJAX שגם מתקפדת טוב וגם נראית טוב?

הודעה זו נכתבה בשל תסכול יתר של שנים רבות מטכנולוגית ה-WebForms המיותרת להפליא. בזמן שמבזבזים על חקירת הקרביים של ה-WebForms, או מתחבטים בשאלות של "למה ה-ViewState לא נטען לי בפקדים דינמיים היררכיים" או יותר מזה – "למה הכל עובד נורא לאט?!" אפשר להשלים שעות שינה של שנתיים