מאחורי הקלעים של חלונות 8 – WinRT וטכנולוגיות הפיתוח החדשות

21 בנובמבר 2011

תגיות: , , , , ,
3 תגובות

פוסט זה הוא חלק מסדרת הפוסטים “תכנות לחלונות 8 בHTML5”.

הרבה דובר על ממשק המשתמש החדש של חלונות 8 – מטרו – אבל חלונות 8 מביאה הפתעות מתחת לקלעים לא פחות מאשר מעל. החידוש הכי משמעותי הוא כמובן WinRT, הAPI שמחליף את Win32, ומאפשר  3 דרכים שונות לכתיבת אפליקציות, כל אחת עם הפלוסים ועם המינוסים שלה;

  1. 1. C# + XAML.

  2. 2. C++ + XAML

  3. 3. JavaScript + HTML5

 

המודל התכנותי הישן של חלונות 7 עדיין נמצא כאן (כל אפליקציה של חלונות 7 עדיין תעבוד בחלונות 8), אבל בממשק הישן (Legacy).
בממשק החדש, מטרו, תתאפשר עבודה עם הפלטפורמות החדשות. לכולן יש גישה מלאה ל API של חלונות החדש, שנקרא WinRT.
סביבת דוט נט סבלה מנחיתות ביחס לC++ בעשר שנים האחרונות, היות והAPI הישן Win32 לא היה דוט נטי (ואפילו לא C++ לגמרי. הממשק הוא ממשק Com-י שנראה הרבה יותר כמו C).
לא עוד. לדוט נט יש גישה לAPI באותה רמה שיש לC++, ואלה חדשות מאוד טובות למתכנתי דוט נט. WinRT עדיין כתוב בC++, אך עכשיו הוא כתוב כך שמבחינת מתכנתי הדוט נט זה שקוף לחלוטין.

הבשורה המשמעותית יותר היא לHTML. בניגוד למה שחשבתי בפעם הראשונה ששמעתי את המושג Native HTML בכנס מיקס 2011 – שזה סה”כ עוד דרך של מיקרוסופט להגיד שהפלטפורמות שלהם יתמכו בHTML5 בצורה הטובה ביותר – מיקרוסופט הבטיחו וקיימו הרבה מעבר למה שיכולתי לחלום. HTML5/JS מקבל גישה ישירה לWinRT בדיוק כמו הפלטפורמות האחרות, ויכול לעשות (כמעט) כל מה שהפלטפורמות האחרות יודעות לעשות. ביוני 2011 כבר רשמתי שחלונות 8 היא רעידת אדמה למפתחים, ועכשיו אפשר לראות את זה קורה. חלונות 8 הינה מערכת ההפעלה המשמעותית הראשונה שמאפשרת פיתוח אמיתי בHTML5, והאפשרויות העומדות בפני מפתחי HTML5 גדולות מתמיד.

הדיאגרמה שלעיל פורסמה במהלך הרצאת המליאה הראשית בכנס בילד, וזכתה כמעט מיד לביקורת על היותה לא מדויקת. מהדיאגרמה לא ברור האם הCLR עדיין כאן. DirectX נעלם לגמרי התמונה ולא ברור לאיזו טכנולוגיה יש גישה לDirectX. להוסיף עוד חטא על פשע סילברלייט בכלל לא מופיע אפילו בצד הלגאסי… (Haven’t the Silverlight people suffered enough?! Smile )

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

 

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

C# + XAML

השם המוזר הזה (לא WPF, ולא סילברלייט. זאמל!) בא בשביל לאפשר למיקרוסופט בצורה אלגנטית לא לדבר על איזו טכנולוגיה החליפה איזו טכנולוגיה. המודל התכנותי (לעבוד מעל מערכת הפעלה ולא בתוך פלאגין של דפדפן) הוא של WPF, אבל הקוד מבוסס דוקא על סילברלייט (או כפי שכבר שמעתי מישהו סרקסטי מתבטא – הרגו את סילברלייט, ביתרו את הגופה, ומחלקי הגופה יצרו את C# + XAML Smile ).
במובן מסויים יש כאן את המינוסים של WPF (רק לחלונות) ואת המינוסים של סילברלייט (לא מבוסס על קוד דוט נטי מלא) ביחד, ואלו החדשות הרעות. יחד עם זאת, יש בזה לא מעט הגיון.
חשוב לציין כי הקוד לא תואם לWPF או לסילברלייט, אך שינוי קוד קיים והתאמתו (Porting) לא מורכב במיוחד, ויש כבר בלוגים המתארים את התהליך.

הפלוסים:
1. מתכנתי WPF וסילברלייט ירגישו בבית.
2. הדרך הקלה והפרודקטיבית ביותר לכתוב לחלונות 8 (וזה לא ישתנה בזמן הקרוב). לכל מי שהספיד את דוט נט – זה היה טיפה מוקדם מדי Smile

 

C++ + XAML

C++ מקבלת עדנה מחודשת. יחד עם שחרור C++11, השפה הישנה והטובה מקבלת כאן חיזוק משמעותי. C++ היא מהירה, אבל עד היום במידה והיינו רוצים תמיכה ביכולות גראפיקה, שפה דקלרטיבית לUI, ויכולות Layout מודרניות – ++C הייתה בעייתית (למרות ש QT סיפק לא מעט). הרבה מאוד חברות שעברו מ++C לWPF בשנים האחרונות עשו את המעבר הקשה בעיקר בשל כך. 
החל מחלונות 8 ++C מקבלת יכולות מודרניות לחלוטין, ואם C# מיישרת קו עם C++ בכל מה שקשור לגישה למערכת ההפעלה, C++ מיישרת קו עם C# בכל מה שקשור לגראפיקה ולגישה מודרנית ל UI.

יחד עם זאת, C++ היא עדיין שפה לא מנוהלת והרבה יותר קשה לכתוב בה. אני רגיל שהGarbage Collector מנקה אחרי, ואין לי כל כך רצון לחזור לכאב ראש הזה..
אז למה כן לכתוב ב++C?

הפלוסים:
1. היחידה עם גישה לDirectX, ולפיכך משחקים עם ביצועים מקסימליים יכתבו כמעט אך ורק בC++. קוד לא מנוהל עדיין מאפשר שליטה מלאה יותר על מה שקורה מאחורי הקלעים, וזה כנראה אף פעם לא ישתנה. מה עם XNA אתם שואלים? בינתיים אין תוכניות כאלו…

 

JavaScript + HTML5

אין ספק כי זו הפלטפורמה המדוברת והמעניינת ביותר. HTML5 מקבל גישה בפעם הראשונה אי פעם למערכת הפעלה סטנדרטית (ולא, ChromeOS לא נחשב). החלום של “כתוב פעם אחת, הרץ בכל מקום” מעולם לא היה קרוב יותר להתממש. HTML5 בחלונות 8 יכול לרוץ בשני מודלים שונים. דרך הדפדפן, וישירות מעל מערכת ההפעלה כאפליקציית מטרו בדיוק כמו C# ו++C.
שתי הדרכים דומות למדי. (אותו מנוע של IE10 מאחורי הקלעים), אם כי הדרך השניה היא החידוש הגדול. כאשר HTML5 רץ כאפליקציה, יש לו גישה מלאה לWinRT ולכל היכולות המיוחדות של מערכת ההפעלה. למיטב הבנתי כל דבר שאפשר לכתוב בC# יהיה אפשר לכתוב גם בHTML5, וזו אפשרות מדהימה.

יחד עם זאת, לכתוב בJavaScript עדיין הרבה יותר קשה מC#. שפת JavaScript היא שפה דינאמית ולא מקומפלת, מה שאומר בין השאר שהרבה יותר קשה לכתוב לה תמיכה טובה בכלי פיתוח – אינטליסנס, ריפקטורינג, וכו’ (Intelisense, Refactoring). זו שפה ללא יכולות שכבר התרגלנו לראות בשפות מודרניות כגון Generics, Interfaces וכו’ ולכתוב אפליקציות מלאות וגדולות בJavaScript עדיין הרבה יותר קשה מאשר בC#.
גם כאן, מיקרוסופט מציעה לא מעט. כלי הפיתוח החדשים – Visual Studio 11, ו Expression Blend 5 מהווים קפיצת מדרגה משמעותית בכל מה שקשור לתכנות בHTML5.
ממה שראיתי עד עכשיו כלי הפיתוח החדשים מספקים אפשרויות אינטליסנס וריפקטורינג מרשימים למדי, והרבה פיצ’רים שהתרגלנו אליהם בC# סוף סוף מגיעים לJS.

הפלוסים:
1. לכתוב פעם אחת ולהריץ בכל מקום. (עם התאמות, לא גדולות במיוחד)
2. לשפות לא מקומפלות יש גם פלוסים. אחד הפלוסים המשמעותיים ביותר מגיע עם Blend5 שיאפשר לעצב אפליקציה תוך כדי ריצה!
היכולת הזו לא פחות ממדהימה, ולמעשה מאפשרת את היכולת הכי חזקה של MVVM – בלנדאביליות (Blendability) בלי טיפת מאמץ ועם הרבה יותר כוח. (הפיצ’ר המדהים ביותר שראיתי מזה הרבה זמן. ארחיב עליו בפוסט עתידי)
3. היות וHTML5 עובד דרך IE10, מובטחים לנו את כל הפיצ’רים של HTML5 עם סטנדרטים מלאים, אין צורך בהתאמה לאחור במידה וכותבים לחלונות 8.
4. לכתוב פעם אחת ולהריץ בכל מקום כבר אמרנו? Smile

למתכנתים יש נטייה לעיתים קרובות להתאהב בטכנולוגיה בה הם כותבים (וגם אני חוטא בזה מדי פעם), אבל חשוב לזכור שטכנולוגיה היא רק כלי. במידה ואני יכול לעשות עם שפה X מה שאני רוצה לא באמת אכפת לי איזו שפה זו.
לכל אחת מהטכנולוגיות יש פלוסים ומינוסים ברורים, ואני מניח שיצא לי לפתח לא מעט לשלושתן.
יחד עם זאת, HTML5 נראה לי מרתק במיוחד, היות וזה הפתח היחידי לטכנלוגיה שהיא באמת Cross-Platfrom בסופו של יום, ולכן בסדרת הפוסטים הנוכחית נתרכז בטכנולוגיה הזו.

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

3 תגובות

  1. ניר25 בנובמבר 2011 ב 22:42

    האם אפליקציות HTML באמת יהיו Cross Platform?
    נניח שאני כותב אפליקצית HTML שכותבת לקובץ בדיסק או עושה פעולת API כלשהי – איך זה ירוץ על windows 7? או בכלל על פלטפורמות אחרות?

    הגב
  2. eladkatz26 בנובמבר 2011 ב 1:06

    ניר – אפשר לחלק את השאלה לשני חלקים, כל גישה לWinRT ליכולות מיוחדות לחלונות, וגישה לWinRT שהיא סטנדרטית וקיימת גם בHTML5 כגון גישה לדיסק.

    כמובן שאם נשתמש ביכולות שהן אך ורק לחלונות אז למעשה נכתוב אפליקציה שהיא לא CrossPlatform (אם כי יהיה קל להפוך אותה לאפליקציה שהיא כן במידה ונרצה). במידה ולא נשתמש ביכולות מיוחדות, הAPI של WinRT וה API של HTML5 לא בהכרח חופפים, אבל יהיה מאוד קל לבדוק אם רצים תחת מטרו – ואז להתשמש בAPI של חלונות, ובמידה ולא להשתמש בAPI של HTML5. מן הסתם ספריות שיבצעו את הבדיקה הזו כבר נכתבות כרגע, ויש כאלו כבר ספריות בשביל פלאפונים (PhoneGap לדוגמא)

    השורה התחתונה היא החשובה – מתבצע כרגע קפיצת דרך משמעותית בדרך לחלום של CrossPlatform אמיתי. אנחנו עדיין לא שם ב100% אבל זה כבר *מאוד* קרוב.

    אני יכול להגיד לך שאני מפתח כרגע אפליקציה בHTML5, ובשביל לגרום לה להיות אפליקציית Win8 (שמרגישה ונראית כמו אפליקציית Native) העבודה תהייה יחסית פשוטה.

    הגב
  3. יוני10 בדצמבר 2011 ב 19:17

    משהו קטן על XAML: מסוג הדברים שעדיף אולי להסתכל עליהם בראיה רחבה שכוללת גם את מה שמחוץ לקופסה של מיקרוסופט. זו היתה התפתחות טבעית במקביל (או קצת אחרי?) למודל של XUL שלצערי פשוט נתקע כי למוזילה לא היה מספיק כוח לדחוף ולשכלל את מה שצריך.
    ושתי השפות, אגב, איתנו כבר הרבה מאוד שנים (נדמה לי שלפחות 7-8 אבל לא בדקתי). בעיני זה מצער.

    הבשורה הטובה ב-HTML5 בעיני היא שהסטנדרט יעשה סדר אחרי 5-7 שנים רעות שבהן מיקרוסופט החליפה רעיונות כמו גרביים. הסלט שמיקרוסופט עשתה מדברים כמו Silverlight ו-WPF לא איפשרו לדעתי בשלות ראויה של מתודולוגיות פיתוח מלאות.

    הגב