Chrome משתף פעולה עם מסגרות קוד פתוח כדי לשפר את האינטרנט
Chrome תורם באופן פעיל למערכת האקולוגית של מסגרות האינטרנט, ובמהלך ההרצאה שלנו ב-Chrome Dev Summit 2019 הסברנו על מה עבדנו בשנה האחרונה.
בהמשך תמצאו סיכום מורחב של השיחה עם פרטים ומשאבים נוספים.
איך אנחנו משפרים את האינטרנט?
המטרה של כל חברי צוות Chrome היא לשפר את האינטרנט. אנחנו פועלים לשיפור ממשקי ה-API של הדפדפן ו-V8 – מנוע הליבה של JavaScript ו-WebAssembly שמפעיל את Chrome – כדי לספק למפתחים תכונות שיעזרו להם ליצור דפי אינטרנט מצוינים. אנחנו גם מנסים לשפר אתרים שכבר נמצאים בייצור היום, על ידי תרומה לכלים של קוד פתוח בדרכים רבות.
רוב מפתחי האינטרנט מסתמכים על כלים בקוד פתוח כשהדבר אפשרי, והם מעדיפים לא לבנות תשתית בהתאמה אישית מלאה. ספריות UI ו-frameworks של JavaScript בצד הלקוח מהווים חלק הולך וגדל בשימוש בקוד פתוח. נתונים על שלושת ה-frameworks והספריות הפופולריים ביותר בצד הלקוח, React, Angular ו-Vue, מראים:
- 72% מהמשתתפים בסקר השנתי הראשון של MDN למפתחי אתרים ומעצבים משתמשים לפחות באחת מהמסגרות והספריות האלה.
- יותר מ-320,000 אתרים מתוך 5 מיליון כתובות ה-URL המובילות שנותחו על ידי HTTP Archive משתמשים לפחות באחת מהמסגרות והספריות האלה.
- כשמקבצים לפי זמן שהייה, ב-30 מתוך 100 כתובות ה-URL המובילות נעשה שימוש לפחות באחת מהמסגרות ומהספריות האלה. (המחקר בוצע על נתונים פנימיים).
המשמעות היא ששימוש בכלים טובים יותר עם קוד פתוח יכול להוביל ישירות לאינטרנט טוב יותר, ולכן מהנדסי Chrome התחילו לעבוד ישירות עם יוצרים של מסגרות וספריות חיצוניות.
תרומות למסגרות אינטרנט
יש שתי קטגוריות של מסגרות שמשמשות בדרך כלל לבנייה ולארגון של דפי אינטרנט:
- מסגרות (frameworks) (או ספריות) של ממשק משתמש, כמו Preact, React או Vue, שמאפשרות שליטה בשכבת התצוגה של האפליקציה (לדוגמה, באמצעות מודל רכיבים).
- מסגרות אינטרנט, כמו Next.js, Nuxt.js ו-Gatsby, שמספקות מערכת מקצה לקצה עם תכונות מובנות, כמו עיבוד בצד השרת. בדרך כלל, המסגרות האלה מסתמכות על מסגרת או ספרייה של ממשק משתמש לשכבת התצוגה.

מפתחים יכולים לבחור שלא להשתמש במסגרות, אבל אם הם מרכיבים ספרייה של שכבת תצוגה, נתב, מערכת סגנונות, רכיב עיבוד בצד השרת וכן הלאה, הם לרוב יוצרים סוג משלהם של מסגרת. למרות שהן מבוססות על דעות מוצקות, מסגרות אינטרנט מטפלות ברבות מהבעיות האלה כברירת מחדל.
בהמשך הפוסט הזה נציג שיפורים רבים שנוספו לאחרונה למסגרות ולכלים שונים, כולל תוספות של צוות Chrome.
Angular
צוות Angular פרסם מספר שיפורים בגרסה 8 של המסגרת:
- טעינה דיפרנציאלית כברירת מחדל כדי לצמצם את השימוש בפוליפילים מיותרים בדפדפנים חדשים יותר.
- תמיכה בתחביר סטנדרטי של ייבוא דינמי לטעינה עצלה של נתיבים.
- תמיכה ב-Web worker כדי להריץ פעולות ב-thread ברקע, בנפרד מה-thread הראשי.
- Ivy, מנוע הרינדור החדש של Angular, שמאפשר ביצועים טובים יותר של קומפילציה מחדש וצמצום הגודל של חבילות, זמין במצב תצוגה מקדימה לפרויקטים קיימים.
מידע נוסף על השיפורים האלה זמין במאמר בנושא גרסה 8 של Angular. צוות Chrome מצפה לעבוד איתם בשנה הקרובה ככל שיתווספו עוד תכונות.
Next.js
Next.js הוא framework לאינטרנט שמשתמש ב-React כשכבת תצוגה. בנוסף למודל של רכיבי ממשק משתמש שרבים מהמפתחים מצפים לו ממסגרת בצד הלקוח, Next.js מספק מספר תכונות מובנות שמוגדרות כברירת מחדל:
- ניתוב עם פיצול קוד כברירת מחדל
- קומפילציה וצירוף (באמצעות Babel ו-webpack)
- רינדור בצד השרת
- מנגנונים לאחזור נתונים ברמת הדף
- סגנון מוכל (עם styled-jsx)
Next.js מבצע אופטימיזציה להקטנת גודל החבילות, והצוות של Chrome עזר לזהות תחומים שבהם אפשר לשפר עוד יותר את הביצועים. כדי לקבל מידע נוסף על כל אחת מהן, אפשר לעיין בבקשות שלהן לתגובות (RFC) ובבקשות למשיכת קוד (PR):
- שיפור באסטרטגיית חלוקת ה-webpack לחלקים, שיוצרת חבילות מפורטות יותר ומפחיתה את כמות הקוד הכפול שנשלף דרך כמה מסלולים (RFC, PR).
- טעינה דיפרנציאלית באמצעות התבנית module/nomodule, שיכולה לצמצם את הכמות הכוללת של JavaScript באפליקציות Next.js בשיעור של עד 20% ללא שינויים בקוד (RFC, PR).
- מעקב משופר אחר מדדים לבדיקת ביצועים המשתמש ב-User Timing API (PR).
אנחנו גם בודקים תכונות נוספות כדי לשפר את חוויית המשתמש והמפתח בשימוש ב-Next.js, כמו:
- הפעלת מצב בו-זמניות כדי לבצע העשרת דפי HTML מתקדמת או חלקית של רכיבים.
- מערכת תאימות מבוססת webpack שמנתחת את כל קובצי המקור והנכסים שנוצרו כדי להציג שגיאות ואזהרות טובות יותר (RFC).
Nuxt.js
Nuxt.js הוא פריימוורק לאינטרנט שמשלב בין Vue.js לספריות שונות כדי לספק הגדרה מוטה. בדומה ל-Next.js, הוא כולל הרבה תכונות מוכנות לשימוש:
- ניתוב עם פיצול קוד כברירת מחדל
- קומפילציה ואיגוד (באמצעות Babel ו-webpack)
- רינדור בצד השרת
- שליפת נתונים אסינכרונית לכל דף
- מאגר נתונים שמוגדר כברירת מחדל (Vuex)
בנוסף לעבודה ישירה על שיפור הביצועים של כלים שונים, הרחבנו את קרן המסגרות כדי לספק תמיכה כספית למסגרות ולספריות נוספות של קוד פתוח. לאחרונה התחלנו לתמוך ב-Nuxt.js, ובקרוב נשיק כמה תכונות חדשות, כולל רכיב חכם יותר של עיבוד בצד השרת ואופטימיזציה של תמונות.
Babel
בנוסף, התקדמנו בשיפור הביצועים של כלי בסיסי חשוב כמעט בכל המסגרות שצוינו – Babel.
Babel קומפייל קוד שמכיל תחביר חדש יותר לקוד שדפדפנים שונים יכולים להבין.
מקובל להשתמש ב-@babel/preset-env כדי לטרגט דפדפנים מודרניים, שבהם אפשר לציין יעדים שונים בדפדפן כדי לספק מספיק polyfilling שנדרש לכל הסביבות שנבחרו. אחת הדרכים לציין את יעדי הטירגוט היא להשתמש ב-<script
type="module"> כדי לטרגט את כל הדפדפנים שתומכים במודולים של ES.
כדי לבצע אופטימיזציה למקרה הזה, השקנו הגדרה קבועה מראש חדשה לגמרי: @babel/preset-modules. במקום להמיר תחביר מודרני לתחביר ישן יותר כדי להימנע מבדיקות באגים בדפדפן, preset-modules מתקן כל באג ספציפי על ידי המרה לתחביר מודרני שלא מכיל באגים ודומה ככל האפשר לתחביר המקורי. התוצאה היא קוד מודרני שאפשר להציג ברוב הדפדפנים כמעט ללא שינוי.

מפתחים שכבר משתמשים ב-preset-env ייהנו גם מהאופטימיזציות האלה בלי שיצטרכו לעשות כלום, כי הן ישולבו גם ב-preset-env בקרוב.
מה השלב הבא?
העבודה הצמודה עם מסגרות וספריות בקוד פתוח כדי לספק חוויות טובות יותר עוזרת לצוות Chrome להבין מה חשוב למשתמשים ולמפתחים.
אם אתם עובדים על framework לאינטרנט, על ספריית ממשק משתמש או על כל סוג של כלי אינטרנט (bundler, קומפיילר, linter), אתם יכולים להגיש בקשה למימון במסגרת תוכנית התמיכה ב-frameworks.