לפני כ-15 שנה עבדתי בחברה שבה בנינו אפליקציות לסוכני נסיעות, עובדי שדות תעופה וחברות תעופה. כמו כן בנינו מסגרת פנימית משלנו עבור רכיבי ממשק משתמש ויכולות אפליקציה של עמוד בודד. היו לנו רכיבים לכל דבר: שדות, כפתורים, כרטיסיות, טווחים, טבלאות נתונים, תפריטים, בוררים תאריכים, בחירה ובחירה מרובה. אפילו היה לנו רכיב div. אגב, רכיב ה-div שלנו היה מעולה, הוא איפשר לנו לעשות פינות מעוגלות בכל הדפדפנים, מה שלא היה קל לעשות באותו זמן, תאמינו או לא.
העבודה שלנו התרחשה בנקודה בהיסטוריה שלנו שבה JS, Ajax ו-HTML דינמי נתפסו כמהפכה שהביאה אותנו לעתיד. לפתע, יכולנו לעדכן עמוד באופן דינמי, לקבל נתונים משרת, ולהימנע מהצורך לנווט לדפים אחרים, אשר נתפסו כאיטיים והבהב מלבן לבן גדול על המסך בין שני הדפים. היה משפט, שהפך פופולרי על ידי ג'ף אטווד (מייסד StackOverflow), שקרא: "כל יישום שניתן לכתוב ב-JavaScript ייכתב בסופו של דבר ב-JavaScript." - ג'ף אטווד
לנו בזמנו זה הרגיש כמו העז ללכת וליצור את האפליקציות האלה. זה הרגיש כמו אישור גורף לעשות הכל עם JS. אז עשינו הכל עם JS, ולא ממש הקדשנו את הזמן לחקור דרכים אחרות לעשות דברים. לא ממש הרגשנו את התמריץ ללמוד כראוי מה HTML ו-CSS יכולים לעשות. לא ממש תפסנו את האינטרנט כפלטפורמת אפליקציות מתפתחת בשלמותה. בעיקר ראינו בזה משהו שאנחנו צריכים לעקוף אותו, במיוחד כשזה הגיע לתמיכה בדפדפן. אנחנו יכולים פשוט לזרוק על זה יותר JS כדי לעשות דברים. האם לקחת את הזמן כדי ללמוד עוד על איך האינטרנט עובד ומה היה זמין בפלטפורמה יעזור לי? בטח, כנראה יכולתי לגלח חבורה של קוד שלא באמת היה נחוץ. אבל, בזמנו, אולי לא כל כך. אתה מבין, ההבדלים בדפדפן היו די משמעותיים אז. זו הייתה תקופה שבה אינטרנט אקספלורר עדיין היה הדפדפן הדומיננטי, כאשר פיירפוקס היה השני הקרוב, אך החל לאבד נתח שוק בגלל ש-Chrome צובר פופולריות במהירות. למרות ש-Chrome ו-Firefox היו די טובים בהסכמה על תקני אינטרנט, הסביבות שבהן האפליקציות שלנו פעלו הביאו לכך שנאלצנו לתמוך ב-IE6 במשך זמן רב. גם כשהורשה לנו לתמוך ב-IE8, עדיין היינו צריכים להתמודד עם הרבה הבדלים בין דפדפנים. לא רק זה, אלא שלרשת של אז פשוט לא היו כל כך הרבה יכולות מובנות ישירות בפלטפורמה.
מהר קדימה להיום. דברים השתנו מאוד. לא רק שיש לנו יותר מהיכולות האלה מאי פעם, אלא שהקצב שבו הן הופכות לזמינות גדל גם כן. הרשו לי לשאול את השאלה שוב, אם כן: האם לקחת את הזמן כדי ללמוד עוד על איך האינטרנט עובד ומה זמין בפלטפורמה יעזור לכם היום? בהחלט כן. ללמוד להבין ולהשתמש בפלטפורמת האינטרנט כיום מעמיד אותך ביתרון עצום על פני מפתחים אחרים. בין אם אתה עובד על ביצועים, נגישות, היענות, כולם ביחד, או סתם משלוח תכונות ממשק משתמש, אם אתה רוצה לעשות זאת כמהנדס אחראי, הכרת הכלים שעומדים לרשותך עוזרת לך להגיע ליעדים שלך מהר יותר וטוב יותר. כמה דברים שאולי כבר לא צריך ספרייה בשבילם אם אנו יודעים במה תומכים הדפדפנים כיום, השאלה היא אם כן: מה נוכל לוותר עליו? האם אנחנו צריכים רכיב div כדי לעשות פינות מעוגלות ב-2025? כמובן, אנחנו לא. המאפיין border-radius נתמך על ידי כל הדפדפנים הנמצאים בשימוש כיום במשך יותר מ-15 שנים בשלב זה. ו-corn-shape גם בקרוב, עבור פינות מפוארות עוד יותר. הבה נסתכל על תכונות עדכניות יחסית שזמינות כעת בכל הדפדפנים הגדולים, ובהן תוכל להשתמש כדי להחליף תלות קיימות בבסיס הקוד שלך. הנקודה היא לא לבטל מיד את כל הספריות האהובות שלך ולשכתב את בסיס הקוד שלך. לגבי כל השאר, תצטרך לקחת בחשבון תחילה את תמיכת הדפדפן ולהחליט על סמך גורמים אחרים ספציפיים לפרויקט שלך. התכונות הבאות מיושמות בשלושת מנועי הדפדפן הראשיים (Chromium, WebKit ו- Gecko), אך ייתכן שיש לך דרישות תמיכה שונות בדפדפן שמונעות ממך להשתמש בהן באופן מיידי. עכשיו זה עדיין זמן טוב ללמוד על התכונות האלה, ואולי לתכנן להשתמש בהן בשלב מסוים. פופ-אוברים ודיאלוגים ה-Popover API, אלמנט ה-HTML
בטח, כנראה שגם מהירות חיבור האינטרנט שלך עלתה, אבל זה לא המקרה עבור כולם. וגם לא לכולם יש את אותן יכולות מכשיר. משיכת קוד של צד שלישי לדברים שאתה יכול לעשות עם הפלטפורמה, במקום זאת, כנראה אומר שאתה שולח יותר קוד, ולכן מגיע לפחות לקוחות ממה שאתה רגיל. באינטרנט, ביצועי טעינה גרועים מובילים לשיעורי נטישה גדולים ופוגעים במוניטין של המותג. הפעלת פחות קוד במכשירים יתר על כן, סביר להניח שהקוד שאתה שולח במכשירים של הלקוחות שלך פועל מהר יותר אם הוא משתמש בפחות הפשטות JavaScript על גבי הפלטפורמה. זה גם כנראה מגיב יותר ונגיש יותר כברירת מחדל. כל זה מוביל ללקוחות נוספים ומרוצים יותר. בדוק את הבלוג השנתי של עמיתי אלכס ראסל על פערי אי השוויון בביצועים, שמראה שמכשירי פרימיום נעדרים במידה רבה משווקים עם מיליארדי משתמשים בגלל אי שוויון בעושר. והפער הזה רק הולך וגדל עם הזמן.
פריסת בנייה מובנית תכונה אחת של פלטפורמת אינטרנט שתגיע בקרוב ושאני מאוד מתרגשת ממנה היא CSS Masonry.
הרשו לי להתחיל בהסבר מהי בנייה. מהי בנייה בנייה היא סוג של פריסה שנעשתה פופולרית על ידי Pinterest לפני שנים. זה יוצר מסלולים עצמאיים של תוכן שבתוכם פריטים אורזים את עצמם קרוב לתחילת המסלול ככל שהם יכולים.
אנשים רבים רואים בבנייה כאופציה מצוינת לתיקים וגלריות תמונות, מה שהיא בהחלט יכולה לעשות. אבל בנייה גמישה יותר ממה שאתה רואה בפינטרסט, והיא לא מוגבלת רק לפריסות דמויות מפל. בפריסת בנייה:
רצועות יכולות להיות עמודות או שורות:
רצועות התוכן לא חייבות להיות באותו גודל:
פריטים יכולים להשתרע על מספר מסלולים:
ניתן למקם פריטים על מסלולים ספציפיים; הם לא חייבים תמיד לעקוב אחר אלגוריתם המיקום האוטומטי:
הדגמות הנה כמה הדגמות פשוטות שהכנתי באמצעות היישום הקרוב של CSS Masonry ב-Chromium. הדגמה של גלריית תמונות, המראה כיצד פריטים (הכותרת במקרה זה) יכולים להשתרע על מספר רצועות:
גלריית תמונות נוספת המציגה מסלולים בגדלים שונים:
פריסת אתר חדשות עם כמה רצועות רחבות יותר מאחרות, וכמה פריטים משתרעים על כל רוחב הפריסה:
לוח קנבן המראה שניתן למקם פריטים על מסלולים ספציפיים:
הערה: ההדגמות קודמות נעשו עם גרסה של Chromium שעדיין לא זמינה לרוב משתמשי האינטרנט, מכיוון ש-CSS Masonry רק מתחיל להיות מיושם בדפדפנים. עם זאת, מפתחי אינטרנט משתמשים בשמחה בספריות ליצירת פריסות בנייה כבר שנים. אתרים המשתמשים בבנייה כיום ואכן, בנייה די נפוצה באינטרנט כיום. הנה כמה דוגמאות שמצאתי מלבד Pinterest:
ועוד כמה דוגמאות פחות ברורות:
אז איך נוצרו הפריסות האלה? דרכים לעקיפת הבעיה טריק אחד שראיתי בשימוש הוא להשתמש בפריסת Flexbox במקום זאת, לשנות את הכיוון שלה לעמודה ולהגדיר אותה לגלישה. בדרך זו, אתה יכול למקם פריטים בגבהים שונים במספר עמודות עצמאיות, וליצור רושם של פריסת בנייה:
עם זאת, ישנן שתי מגבלות לפתרון זה:
סדר הפריטים שונה ממה שהוא יהיה עם פריסת בנייה אמיתית. עם Flexbox, פריטים ממלאים תחילה את העמודה הראשונה ולאחר מכן, כאשר היא מלאה, לאחר מכן עבור לעמודה הבאה. עם בנייה, פריטים ייערמו בכל מסלול (או עמודה במקרה זה) שיש יותר מקום פנוי. אבל גם, ואולי יותר חשוב, הדרך לעקיפת הבעיה מחייבת שתגדיר גובה קבוע למיכל Flexbox; אחרת, לא תתרחש עטיפה.
ספריות בנייה של צד שלישי למקרים מתקדמים יותר, מפתחים השתמשו בספריות. הספרייה המוכרת והפופולרית ביותר עבור זה נקראת בפשטות מאsonry, והיא יורדת כ-200,000 פעמים בשבוע לפי NPM. Squarespace מספקת גם רכיב פריסה המציג פריסת בנייה, לחלופה ללא קוד, ואתרים רבים משתמשים בה. שתי האפשרויות הללו משתמשות בקוד JavaScript כדי למקם פריטים בפריסה. בנייה מובנית אני ממש מתרגש מכך ש-Masonry מתחילה להופיע כעת בדפדפנים כתכונת CSS מובנית. עם הזמן, תוכל להשתמש ב-Masonry בדיוק כמו שאתה עושה ב-Grid או ב-Flexbox, כלומר, ללא צורך בכל דרך לעקיפת הבעיה או בקוד של צד שלישי. הצוות שלי ב-Microsoft הטמיע תמיכה מובנית ב-Masonry בפרויקט הקוד הפתוח Chromium, שעליו מבוססים Edge, Chrome ודפדפנים רבים אחרים. Mozilla הייתה למעשה ספקית הדפדפן הראשונה שהציעה יישום ניסיוני של Masonry כבר בשנת 2020. ואפל גם התעניינה מאוד להפוך את פריסת האינטרנט החדשה הזו לפרימיטיבית. העבודה לסטנדרטיזציה של התכונה מתקדמת גם היא, עם הסכמה בתוך קבוצת העבודה של CSS לגבי הכיוון הכללי ואפילו תצוגה מסוג חדש: גריד-lanes. אם אתה רוצה ללמוד עוד על בנייה ולעקוב אחר התקדמות, עיין בדף המשאבים שלי לבנייה ב-CSS. עם הזמן, כאשר בנייה תהפוך לתכונת Baseline, בדיוק כמו Grid או Flexbox, נוכל פשוט להשתמש בה ולהפיק תועלת מ:
ביצועים טובים יותר, היענות טובה יותר, קלות שימוש וקוד פשוט יותר.
בואו נסתכל מקרוב על אלה. ביצועים טובים יותר יצירת מערכת פריסה משלך דמוי בנייה, או שימוש בספריית צד שלישי במקום זאת, פירושה שתצטרך להפעיל קוד JavaScript כדי למקם פריטים על המסך. זה גם אומר שהקוד הזה יחסום. אכן, או ששום דבר לא יופיע, או שהדברים לא יהיו במקומות הנכונים או בגדלים הנכונים, עד שקוד ה-JavaScript ירוץ. פריסת בנייה משמשת לעתים קרובות עבור החלק העיקרי של דף אינטרנט, מה שאומר שהקוד יגרום לתוכן הראשי שלך להופיע מאוחר יותר ממה שהיה יכול להופיע אחרת, ובכך משפיל את ה-LCP שלך, או המדד Largest Contentful Paint, אשר משחק תפקיד גדול בביצועים הנתפסים ובאופטימיזציה למנועי חיפוש. בדקתי את ספריית Masonry JS עם פריסה פשוטה ועל ידי הדמיית חיבור 4G איטי ב-DevTools. הספרייה לא מאוד גדולה (24KB, 7.8KB gzipped), אבל לקח 600ms לטעון בתנאי הבדיקה שלי. הנה הקלטת ביצועים שמראה שזמן טעינה ארוך של 600 אלפיות השנייה עבור ספריית ה-Masonry, וששום פעילות רינדור אחרת לא התרחשה בזמן שזה קרה:
בנוסף, לאחר זמן הטעינה הראשוני, היה צורך לנתח את הסקריפט שהורד, להידור ולאחר מכן להפעיל אותו. כל אלה, כאמור, חסמו את העיבוד של הדף. עם הטמעת בנייה מובנית בדפדפן, לא יהיה לנו סקריפט לטעינה ולהפעיל. מנוע הדפדפן פשוט יעשה את שלו במהלך שלב עיבוד העמודים הראשוני. היענות טובה יותר בדומה לרגע שבו דף נטען לראשונה, שינוי גודל חלון הדפדפן מוביל לעיבוד הפריסה בדף זה שוב. עם זאת, בשלב זה, אם הדף משתמש בספריית Masonry JS, אין צורך לטעון את הסקריפט שוב, כי הוא כברכָּאן. עם זאת, הקוד שמזיז פריטים במקומות הנכונים צריך לפעול. כעת נראה שהספרייה הספציפית הזו די מהירה לעשות זאת כאשר הדף נטען. עם זאת, הוא מפעיל הנפשה של הפריטים כאשר הם צריכים לעבור למקום אחר בשינוי גודל החלון, וזה עושה הבדל גדול. כמובן, משתמשים לא מבלים זמן בשינוי גודל חלונות הדפדפן שלהם כמו שאנחנו המפתחים. אבל חוויית שינוי הגודל המונפשת הזו יכולה להיות די צורמת ומוסיפה לזמן הנתפס שלוקח לדף להסתגל לגודלו החדש. קלות שימוש וקוד פשוט יותר כמה קל להשתמש בתכונת אינטרנט וכמה פשוט הקוד נראה הם גורמים חשובים שיכולים לעשות הבדל גדול עבור הצוות שלך. הם לעולם לא יכולים להיות חשובים כמו חווית המשתמש הסופית, כמובן, אבל חווית מפתחים משפיעה על התחזוקה. שימוש בתכונת אינטרנט מובנית מגיע עם יתרונות חשובים בחזית זו:
מפתחים שכבר יודעים HTML, CSS ו-JS יוכלו ככל הנראה להשתמש בתכונה זו בקלות מכיוון שהיא תוכננה להשתלב היטב ולהיות עקבית עם שאר פלטפורמת האינטרנט. אין סיכון של שבירה שיוצגו בשימוש בתכונה. יש כמעט אפס סיכון שתכונה זו תצא משימוש או לא תישמר.
במקרה של בנייה מובנית, מכיוון שזה פרימיטיבי פרימיטיבי, אתה משתמש בו מ-CSS, בדיוק כמו Grid או Flexbox, ללא JS מעורב. כמו כן, מאפייני CSS אחרים הקשורים לפריסה, כגון פער, עובדים כפי שהיית מצפה מהם. אין טריקים או דרכים לעקיפת הבעיה, והדברים שאתה כן לומד מתועדים ב-MDN. עבור Masonry JS lib, האתחול מעט מורכב: הוא דורש תכונת נתונים עם תחביר ספציפי, יחד עם רכיבי HTML מוסתרים כדי להגדיר את גודל העמודות והפערים. בנוסף, אם ברצונך להרחיב עמודות, עליך לכלול את גודל הפער בעצמך כדי למנוע בעיות:
<סגנון> .track-sizer, .item { רוחב: 20%; } .gutter-sizer { רוחב: 1rem; } .item { גובה: 100 פיקסלים; margin-block-end: 1rem; } .item:nth-child(odd) { גובה: 200 פיקסלים; } .item--width2 { רוחב: calc(40% + 1rem); }
הבה נשווה את זה לאיך ייראה יישום בנייה מובנה: <סגנון> .container { תצוגה: גריד-נתיבים; גריד-lanes: repeat(4, 20%); פער: 1rem; } .item { גובה: 100 פיקסלים; } .item:nth-child(odd) { גובה: 200 פיקסלים; } .item--width2 { עמודת רשת: span 2; }
קוד פשוט יותר וקומפקטי יותר שיכול פשוט להשתמש בדברים כמו פער והיכן מסלולי מתח מתבצע עם span 2, בדיוק כמו ברשת, ואינו מחייב אותך לחשב את הרוחב הנכון הכולל את גודל הפער. איך לדעת מה זמין ומתי זה זמין? בסך הכל, השאלה היא לא באמת אם אתה צריך להשתמש בבנייה מובנית על פני ספריית JS, אלא מתי. ספריית Masonry JS מדהימה וממלאת פער בפלטפורמת האינטרנט כבר שנים רבות, ולהרבה מפתחים ומשתמשים מאושרים. יש לו כמה חסרונות אם אתה משווה אותו למימוש בנייה מובנה, כמובן, אבל אלה לא חשובים אם היישום הזה לא מוכן. קל לי לרשום את תכונות פלטפורמת האינטרנט החדשות והמגניבות האלה מכיוון שאני עובד אצל ספק דפדפן, ולכן אני נוטה לדעת מה צפוי. אבל לעתים קרובות מפתחים משתפים, סקר אחר סקר, שקשה לעקוב אחר דברים חדשים. קשה להישאר מעודכן, וממילא חברות לא תמיד נותנות עדיפות ללמידה. כדי לעזור בכך, הנה כמה משאבים המספקים עדכונים בדרכים פשוטות וקומפקטיות כדי שתוכל לקבל את המידע הדרוש לך במהירות:
פלטפורמת האינטרנט כוללת אתר סייר: ייתכן שתתעניין בדף הערות השחרור שלו. ואם אתה אוהב RSS, בדוק את עדכון הערות השחרור, כמו גם את העדכונים הבסיסיים החדשים הזמינים והזמינים נרחבים.
הרשתלוח המחוונים של סטטוס הפלטפורמה: ייתכן שתאהב את דפי שנת הבסיס השונים שלו.
דף מפת הדרכים של Chrome Platform Status.
אם יש לך קצת יותר זמן, ייתכן שתתעניין גם בהערות השחרור של ספקי דפדפן:
כרום קצה פיירפוקס ספארי
למשאבים נוספים עוד יותר, בדוק את גיליון הצ'יטים שלי לניווט בפלטפורמת האינטרנט. הדבר שלי עדיין לא מיושם זה הצד השני של הבעיה. גם אם אתה מוצא את הזמן, האנרגיה והדרכים לעקוב, עדיין יש תסכול עם השמעת קולך ויישום התכונות האהובות עליך. אולי חיכית כבר שנים לפתרונה של באג ספציפי, או פיצ'ר ספציפי שיישלח בדפדפן שבו הוא עדיין חסר. מה שאני אגיד זה שספקי דפדפנים כן מקשיבים. אני חלק מכמה צוותים חוצי ארגון שבהם אנו דנים באותות ומשוב למפתחים כל הזמן. אנו מסתכלים על מקורות משוב רבים ושונים, הן פנימיים אצל כל ספקי דפדפן והן חיצוניים/ציבוריים בפורומים, פרויקטי קוד פתוח, בלוגים וסקרים. בנוסף, אנחנו תמיד מנסים ליצור דרכים טובות יותר עבור מפתחים לשתף את הצרכים הספציפיים שלהם ומקרי שימוש. אז אם אתה יכול, אנא דרש יותר מספקי דפדפנים ולחץ עלינו ליישם את התכונות שאתה צריך. אני מבין שזה לוקח זמן, וגם יכול להיות מאיים (שלא לדבר על מחסום כניסה גבוה), אבל זה גם עובד. הנה כמה דרכים שבהן תוכל להשמיע את הקול שלך (או של החברה שלך): קח את הסקרים השנתיים של State of JS, State of CSS ו-State of HTML. הם ממלאים תפקיד גדול באופן שבו ספקי דפדפנים מתעדפים את עבודתם. אם אתה צריך ממשק API מבוסס סטנדרטי ספציפי שייושם באופן עקבי בדפדפנים, שקול להגיש הצעה באיטרציה הבאה של פרויקט Interop. זה דורש יותר זמן, אבל שקול כיצד Shopify ו- RUMvision שיתפו את רשימות המשאלות שלהם עבור Interop 2026. מידע מפורט כמו זה יכול להיות מאוד שימושי עבור ספקי דפדפן לתעדוף. לקישורים שימושיים נוספים להשפעה על ספקי דפדפנים, בדוק את גיליון הצ'יטים שלי לניווט בפלטפורמת האינטרנט. מסקנה לסיום, אני מקווה שהמאמר הזה השאיר אותך עם כמה דברים למחשבה:
התרגשות לקראת בנייה ותכונות אינטרנט נוספות. כמה תכונות אינטרנט שאולי תרצה להתחיל להשתמש בהן. כמה פיסות קוד מותאם אישית או של צד שלישי אולי תוכל להסיר לטובת תכונות מובנות. כמה דרכים לעקוב אחר מה שמגיע ולהשפיע על ספקי דפדפנים.
חשוב מכך, אני מקווה ששכנעתי אותך ביתרונות השימוש בפלטפורמת האינטרנט במלוא הפוטנציאל שלה.
