פלטפורמת Web: החלק החסר

לפני מספר ימים קיבלתי כ”טובה” מחשב עבודה (Workstation) מאוד עוצמתי למספר ימים. המחשב כלל 2 מעבדים של AMD (סה”כ 32 ליבות), 32 ג’יגה זכרון, 5 דיסקים של 2 טרה ב-RAID חומרה. הסיבה שהמחשב הגיע אליי? לבדוק תאימות שלו מול גירסת פדורה. (לצערי אני צריך להיפרד מהמחשב הזה מחר).

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

כמעט.

אחד הדברים המוזרים ששמתי לב היה עניין חשוד שמדי פעם המחשב פתאום נהיה איטי ולאחר מכן חזר לפעול לאט לאט למהירות הרגילה. מכיוון שביטלתי את כל עניין שינוי מהירות שעון, תמהתי מה זה ובזבזתי כמה שעות טובות כדי למצוא מה הבעיה. מה היתה הבעיה בסוף? דף של YNET ודף של וואלה (ללא חוסמי פרסומות) שמטעינים טונות של פרסומות ועושים לעצמם Refresh – מפעילים כמה קבצי Flash כל אחד, ו-Flash יודע להאיט גם מכונה מפלצת כזו. ביטלתי את הפלאש והפלא ופלא – המכונה טסה!

את הבעיה של פלאש אפשר למצוא גם במק ובמקרים רבים גם ב-Windows. זה לא סוד שפלאש עושה המון צרות ויודע לחנוק משאבים של כל מחשב, בין אם נייד חלש או נייח עצבני, ומאז שאפל החליטו שפלאש הוא פרסונה נון גראטה במכשירים הניידים שלה (במחשבים הניידים של אפל הוא אינו מגיע מותקן), חברות רבות אימצו בחום יותר ויותר טכנולוגיות HTML-5 כתחליף לפלאש, וגם אדובי הבינו לאן הרוח נושבת וכיום הם משקיעים הרבה יותר בפיתוח כלים לכתיבת HTML-5, אנימציה ב-HTML-5 ועוד והרבה פחות בפלאש, גם אדובי יודעים שפלאש בקרוב יסיים את חייו.

וכאן נפתח “חור” שיצרני הדפדפנים חלוקים לגביו.

כיום מקובל בד”כ כשמפתחים אתר, שאת העבודה שמצריכה משאבים יבצעו השרתים של בעלי האתר, והדפדפן יקבל את הפלט, ויבצע עבודות קטנות פה ושם עם Javascript. יש כל מיני אתרים שדווקא משתמשים המון ב-JS כדי לעשות דברים שונים, כמו לדוגמא כל האפליקציות שנותנות אפשרות לעשות מניפולציה בסיסית לתמונות, אפליקציות כמו מפות, IM ועוד ועוד.

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

עם פלאש כיום אפשר לכתוב אפליקציות שלמות שמשתמשות בציוד של המחשב שלך (מצלמה, מיקרופון), להשתמש בהאצה הגרפית של הצ’יפ הגרפי, לכתוב אפליקציות שפותחות פורטים שונים (TCP, UDP) ועוד דברים רבים שאין להם כרגע פתרון ברמת ה-JS או HTML-5. כך לדוגמא, אפליקציה שאני מאוד אוהב לערוך איתה תמונות כמו Pixlr תהיה בעייתית ומסובכת מאוד לכתיבה ב-JS. קחו, תטעינו תמונה ל-Pixlr (התמונה בין כה לא עולה לשרתים שלהם) ותשחקו עם הפונקציונאליות. האפליקציה הזו שוקלת בערך כ-300K ותראו איזה דברים מטריפים אפשר לעשות איתה. כל ה”מתחרים” שלה שנכתבו ב-JS וב-HTML-5 לא נותנים אפילו עשירית ממה ש-Pixlr נותנת.

גוגל מבינה את הדברים האלו. היא מבינה שאנשים מעוניינים בפתרון שאפשר להשתמש במלוא הכח של המעבד והצ’יפ הגרפי, הסאונד וכו’ והם פיתחו את Native Client (או Nacl כפי שהוא נקרא). עם Nacl אפשר להשתמש ביכולות של המחשב שלך תוך הגבלות שונות (כמו Sandbox) לשם האבטחה, והביצועים יהיו מאוד גבוהים. קחו לדוגמא את NaclBox, זה אתר שלקח את האמולטור DOS Box והמיר אותו לעבוד עם Native Client. התוצאה? עשרות משחקים שנכתבו ל-DOS רצים במהירות מלאה עם תמיכה של מסך מלא, צליל וכו’. לא צריך להתקין תוספים כדי להשתמש בזה בכרום, פשוט מפעילים Flag שמאפשר את Native Client ומשתמשים באפליקציה.

יש עוד עשרות הדגמות ל-Native Client ואי אפשר לאמר שגוגל מזניחה את ה-JS: כרום הוא הדפדפן עם מימוש JS הכי מהיר  שיש, אבל גוגל מספיק מציאותית להכיר את המגבלות שיש ל-JS.

אבל מוזילה ומיקרוסופט לא אוהבים את הפתרון של גוגל. למיקרוסופט יש את ה-ActiveX (וכולנו מכירים כמה הפתרון הזה בטוח), ומוזילה בטוחים שעם JS אפשר להגיע לביצועים של Native Client ושאפשר לעשות איתו את הכל, למרות שעד היום הם לא הוכיחו זאת (והאפליקציה שהם הדגימו לשינוי דינמי של צבעי תמונה לא ממש מדגימה יכולות כמו Native Client).

מדוע לדעתי הפתרון של Native Client יכול לעזור? כי ישנם המון אפליקציות ודברים שאפשר וצריך לעשות בצד המשתמש מבלי להעמיס את זה על שרת, והעמסה רק תיצור בחזרה “עומס” בדמות הורדות ארוכות.

אתן דוגמא למשהו שנתקלתי בו היום: Xiph.org הארגון שמפתח את OGG ועוד כמה דברים, מפתח מקודד אודיו חדש בשם CELT. היתרון של CELT על פני מקודדים אחרים הוא בכך שהוא מאוד מתאים למימוש אודיו דו-כיווני (תחשבו על סקייפ), יש לו Latency מאוד נמוך ויש לו איכות אודיו מאוד גבוהה.

אם כיום אני רוצה לכתוב אפליקציה שתנגן קבצים כאלו, אני לא יכול לכתוב אותה עם JS כי אין ב-JS תמיכה ישירה לאיזה “ערוץ אודיו” כמו שיש בפלאש. אני יכול לכתוב את זה כ-Java Applet ואז אצטרך לחייב את המשתמשים להתקין Java במחשב שלהם כך שזהו אינו פתרון טוב. לעומת זאת, אם אכתוב אפליקציה קטנה כ-Native Client, זה י
עבוד מעולה בכרום (כולל כרום החדש לאנדרואיד), אבל בגלל ההתעקשות של מיקרוסופט ומוזילה, זה לא יעבוד בדפדפנים שם.

לסיכום: בגלל ויכוחים אין כיום שום אפשרות ריאלית לכתוב ולהריץ אפליקציות שיתמשו במלוא הכח של המעבד הגרפי והרגיל שיש במחשב, ופתרון כמו JS אינו מתאים לכך עדיין. הפתרון של מיקרוסופט אינו מתאים כמעט לכלום (חוץ מאקספלורר על Windows וגם זה לא נתמך תמיד ב-64 ביט), ולמוזילה אין פתרון כלל וכלל והם לא רוצים להכניס פתרון כמו Nacl לדפדפן. מה יוצא מזה? פרגמנטציה בדפדפנים.

Comments

comments

5 תגובות בנושא “פלטפורמת Web: החלק החסר

  1. אני לא יודע אם אתה זוכר, אבל בשנות התשעים מישהו חשב על פלטפורמה של Write once, run everywhere וקרא לה Java. הסביבה הנ"ל היוותה מכונה וירטואלית ובמשך מספר שנים הייתה בחוד החנית של יישומי הרשת המתקדמים. במקביל התפתחה שפה קטנה בשם JavaScript שלא התיימרה לתת את כל היכולות של Java, אבל גם הייתה יותר מחוברת לאירועים בדפדפן מאשר יישום Java שרץ בתוך מסגרת מוגדרת.

    Native Client נכנס בדיוק באותה מסגרת בה נכנסים גם Java,‏ ActiveX,‏ SilverLight נגני אודיו ווידאו למיניהם וכו' – הם לא רצים ברשת באופן טבעי, והגישה שלהם לתוכן הדף מוגבלת. תמיד יהיו כל מיני אנשים שיתאהבו בטכנולוגיות אלו ויבנו אתרים שלמים באותן טכנולוגיות, אבל חשוב לזכור שהן לא מיועדות לרשת באופן בלעדי ולכן משתמשים רבים יחזו בכל מיני תופעות מעצבנות כמו איטיות, תקיעות, קריסות, מחרוזות בעברית שמופיעות הפוך וכדומה. כאשר אתה מפתח מערכת תוך שימוש ביכולות של הדפדפנים אתה בעצם לא צריך לדאוג מהרבה בעיות שונות ומשונות כי מפתחי הדפדפנים יכולים לבנות עבורך סביבת ריצה אופטימלית ליישום שלך.

  2. נראה שכרגע אין באמת פתרון:
    אחת התכונות הבולטות של NaCl היא שקוד שאמור לרוץ עליו צריך להיות מקומפל עבור כל סוג ארכיטקטורת יעד (ARM, x86-32, x86-64 וכו'). זה עושה אותו הרבה פחות פורטבילי (או בכלל לא) לעומת קוד שמיועד לרוץ על מכונה וירטואלית, כמו ג'אווה סקריפט או ג'אווה.
    מתוכננת גרסת NaCl שתריץ LLVM bytecode כדי לאפשר פורטביליות, ושמה PNaCal, אבל כרגע היא רק בתכנון.
    בינתיים, בעולם ה-HTML מתפתחים סטנדרטים והרחבות לסטנדרטים שאמורים להתגבר על המגבלות שצויינו בפוסט: File API, WebGL, Audio API… דרך אגב, ג'אווה סקריפט כשפה והמהירות שלה הן לא באמת מגבלות: ע"פ [1] היא בהחלט בסדרי הגודל של C, C++ וג'אווה, והיא רק משתפרת עם הזמן.

    [1] http://shootout.alioth.debian.org/u32/performance.php?test=nbody

סגור לתגובות.