Chrome משתף פעולה עם frameworks של קוד פתוח כדי לשפר את האינטרנט
Chrome תורם באופן פעיל לסביבה העסקית של מסגרת האינטרנט ומנהל את השיחה שלנו בכנס Chrome למפתחים שנת 2019 עוסקת בדברים שעבדנו עליהם בשנה האחרונה.
בהמשך תוכלו לקרוא סיכום מורחב של השיחה, עם פרטים ומקורות מידע נוספים.
איך אנחנו משפרים את האינטרנט?
המטרה של כל החברים בצוות Chrome היא לשפר את האינטרנט. אנחנו עובדים על שיפור ממשקי API לדפדפנים ו-V8 – מנוע הליבה של JavaScript ו-WebAssembly שמפעיל את Chrome – כדי שמפתחים מצויד בתכונות שעוזרות לו ליצור דפי אינטרנט מעולים. אנחנו מנסים גם לשפר אתרים כבר נמצאים בייצור היום, כי הם תורמים ליצירת כלים בקוד פתוח בדרכים רבות.
רוב האתרים מפתחים מסתמכים ככל האפשר על כלים בקוד פתוח והם מעדיפים לא ליצור . מסגרות JavaScript וספריות ממשק משתמש בצד הלקוח הן חלק הולך וגדל של בשימוש בקוד פתוח. נתונים לגבי שלוש הספריות והמסגרות הכי פופולריות בצד הלקוח, React , Angular ו-Vue, תוכניות ש:
- 72% מהמשתתפים מפתח/ת האינטרנט השנתי הראשון של MDN סקר מעצבים להשתמש לפחות באחת מהספריות והמסגרות האלה.
- אובר 320,000 אתרים ב- 5 מיליון כתובות ה-URL המובילות שנותחו על ידי ארכיון HTTP משתמשות לפחות באחת מה-frameworks והספריות האלה.
- כשמקבצים לפי זמן ההוצאה, 30 מתוך 100 כתובות ה-URL המובילות משתמשות לפחות באחת מהמסגרות האלה של הספריות. (המחקר בוצע על נתונים פנימיים).
המשמעות היא שכלים טובים יותר בקוד פתוח יכולים להוביל באופן ישיר לשיפור חוויית האינטרנט, ולכן מהנדסי Chrome התחילו לעבוד ישירות עם כותבים של framework חיצוני וספריות.
תכנים שנוספו ל-frameworks באינטרנט
המסגרות הנפוצות לבניית דפי אינטרנט ולבנייה שלהן מתחלקות לשתי קטגוריות:
- UI frameworks (או ספריות), כמו Preact, React או Vue, שמספקות שליטה בשכבת התצוגה של אפליקציה (לדוגמה, באמצעות מודל רכיב).
- מסגרות אינטרנט, כמו Next.js, Nuxt.js ו-Gatsby, שמספקות מערכת מקצה לקצה עם תכונות מקובעות באופן מובנה, כמו רינדור בצד השרת. בדרך כלל המסגרות האלה להשתמש במסגרת של ממשק משתמש או בספרייה לשכבת התצוגה.
מפתחים יכולים לבחור שלא להשתמש ב-frameworks אלא על ידי חיבור ספריית שכבות תצוגה, נתב, באמצעות מערכות עיצוב, כלי לרינדור שרתים וכו', פעמים רבות הם יוצרים בעצמם . למרות שהן מקובעות, מסגרות אינטרנט מטפלות בהרבה מהחששות האלה כברירת מחדל.
בהמשך הפוסט הזה מודגשים שיפורים רבים שהגיעו לאחרונה למסגרות שונות. וכלים, כולל תוספות מצוות Chrome.
Angular
צוות Angular שלח כמה שיפורים לגרסה 8 של ה-framework:
- טעינה דיפרנציאלית לפי כברירת מחדל, לצמצום שדות polyfill שאינם נחוצים בדפדפנים חדשים יותר.
- תמיכה בתחביר סטנדרטי של ייבוא דינמי למסלולים לטעינה מדורגת.
- תמיכה ב-Web Worker להרצת פעולות בשרשור ברקע בנפרד מה-thread הראשי.
- Ivy, המשחק החדש של Angular מנוע רינדור שמספק ביצועים טובים יותר של הידור מחדש ולהפחית את כמות החבילה גדלים, זמינים במצב תצוגה מקדימה בפרויקטים קיימים.
מידע נוסף על השיפורים האלה זמין בכתובת "גרסה 8 של Angular" וצוות Chrome ישמח לעבוד איתם בשיתוף פעולה הדוק בשנה הבאה כדי להוסיף תכונות אדמה.
Next.js
Next.js היא framework באינטרנט שמשתמשת ב-React כשכבת תצוגה. בנוסף מודל של רכיבי ממשק משתמש שמפתחים רבים מצפים לקבל מ-framework בצד הלקוח, Next.js מספק מספר תכונות ברירת המחדל המובנות:
- ניתוב עם פיצול קוד שמוגדר כברירת מחדל
- הידור וקיבוץ (באמצעות Babel ו- webpack)
- רינדור בצד השרת
- מנגנונים לאחזור נתונים ברמת דף
- עיצוב משולב (עם styled-jsx)
חברת Next.js מבצעת אופטימיזציה לחבילות קטנות יותר, וצוות Chrome עזר לזהות תחומים שבהם ניתן כדי לשפר את הביצועים עוד יותר. לקבלת מידע נוסף על כל אחד מהסוגים האלה, אפשר לעיין בבקשות שלהם לתגובות (RFCs) ולבקשות משיכה (PRs):
- אסטרטגיה משופרת של קיבוץ חבילות אינטרנט שמפיקה חבילות מפורטות יותר, וכך מצמצמת את כמות של קוד כפול שאוחזרה דרך כמה מסלולים (RFC, PR).
- טעינה דיפרנציאלית עם Module/noModule template שיכול להפחית את הכמות הכוללת של JavaScript באפליקציות Next.js בשיעור של עד 20% ללא צורך בקוד שינויים (RFC, PR).
- מעקב משופר אחרי מדדי ביצועים שמבוססים על User Timing API PR.
אנחנו גם בוחנים תכונות אחרות לשיפור חוויית המשתמש והמפתחים של השימוש Next.js, כמו:
- הפעלת מצב בו-זמנית כדי לאפשר התייבשות חלקית או הדרגתית של רכיבים.
- מערכת תאימות מבוססת-Webpack שמנתחת את כל קובצי המקור והנכסים שנוצרו כדי להציג שגיאות ואזהרות טובות יותר (RFC).
Nuxt.js
Nuxt.js היא מסגרת אינטרנט שמשלבת את Vue.js עם ספריות שונות של לספק הגדרה מקובצת. בדומה ל-Next.js, הוא כולל תכונות רבות ייחודיות:
- ניתוב עם פיצול קוד שמוגדר כברירת מחדל
- הידור וקיבוץ (באמצעות Babel ו webpack)
- רינדור בצד השרת
- אחזור נתונים אסינכרוני לכל דף
- מאגר הנתונים שמוגדר כברירת מחדל (Vuex)
לצד שיפור הביצועים של כלים שונים, הרחבנו את framework קרן כדי לספק תמיכה כספית ליותר קוד פתוח frameworks וספריות. עם העדכונים האחרונים שלנו תמיכה ל-Nuxt.js, התכונות אמורות להגיע בעתיד הקרוב, כולל עיבוד חכם יותר של שרת ותמונות ואופטימיזציות.
Babel
בנוסף, התקדמנו בשיפור הביצועים של כלי בסיסי חשוב כמעט בכל של המסגרות שהוזכרו--Babel.
ב-Babel הידורת קוד שיש בו תחביר חדש יותר לקוד שדפדפנים שונים יכולים להבין.
פעמים רבות משתמשים ב-@babel/preset-env כדי לטרגט
דפדפנים מודרניים שבהם ניתן לציין יעדים שונים של דפדפנים כדי לספק מספיק מילוי פוליגונים
שנדרש עבור כל הסביבות שנבחרו. דרך אחת לציין את היעדים היא להשתמש ב-<script
type="module"> כדי לטרגט את כל הדפדפנים שתומכים ב-ES
מודולים
כדי לבצע אופטימיזציה במקרה הזה, השקנו הגדרה קבועה מראש חדשה לגמרי.
@babel/preset-modules. במקום להמיר תחביר מודרני
לתחביר ישן יותר כדי להימנע מבאגים בדפדפן, preset-modules מתקן כל באג ספציפי על ידי טרנספורמציה
התחביר המודרני הקרוב ביותר שאפשר לא מנותק. התוצאה היא קוד מודרני שניתן לשלוח כמעט באותו זמן
ללא שינוי ברוב הדפדפנים.
גם מפתחים שכבר משתמשים ב-preset-env יפיקו תועלת מהאופטימיזציות האלה בלי שהם יצטרכו
לעשות משהו, כי בקרוב הם ישולבו גם ב-preset-env.
מה השלב הבא?
עבודה הדוקה עם frameworks וספריות של קוד פתוח כדי לספק חוויות טובות יותר עוזרת צוות Chrome מבין מה חשוב באופן מהותי גם למשתמשים וגם למפתחים.
אם אתם עובדים על framework של אינטרנט, ספריית ממשק משתמש או כל צורה של כלי אינטרנט (bundler, compiler, linter), להגיש בקשה לקרן המסגרת!