מחיר מסגרות JavaScript

אין דרך מהירה יותר להאט את הקצב של אתר אינטרנט (ללא משחק מילים) מאשר להריץ בו שלל קוד JavaScript. בעת שימוש ב-JavaScript, עליך לשלם עבורו בביצועי הפרויקט לפחות ארבע פעמים. הנה מה שקוד ה-JavaScript של האתר טוען עם מערכות המשתמשים:

• העלאת קובץ דרך הרשת.
• ניתוח והידור של קוד המקור שנפרק לאחר ההורדה.
• ביצוע קוד JavaScript.
• צריכת זיכרון.

השילוב הזה מסתבר שכן יקר מאוד.

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

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

הפרויקט הזה עזר לי להבין את זה. ארכיון HTTP.

נתונים

פרויקט HTTP Archive עוקב אחר סך של 4308655 קישורים לאתרי שולחן עבודה רגילים ו-5484239 קישורים לאתרים ניידים. בין האינדיקטורים הרבים הקשורים לקישורים אלו יש רשימה של טכנולוגיות שנמצאות באתרים המקבילים. זה אומר שאנחנו יכולים לדגום אלפי אתרים שמשתמשים במסגרות וספריות שונות וללמוד כמה קוד הם שולחים ללקוחות וכמה עומס הקוד הזה מעמיס על מערכות המשתמשים.

אספתי נתונים ממרץ 2020, שהם הנתונים העדכניים ביותר שהייתה לי גישה אליהם.

החלטתי להשוות את נתוני ארכיון HTTP המצטברים עבור כל האתרים עם נתונים עבור אתרים שנמצאו משתמשים ב-React, Vue ו-Angular, למרות ששקלתי להשתמש גם בחומר מקור אחר.

כדי לעשות את זה יותר מעניין, הוספתי גם אתרים המשתמשים ב-jQuery למערך נתוני המקור. ספרייה זו עדיין פופולרית מאוד. היא גם מציגה גישה לפיתוח אתרים השונה ממודל Single Page Application (SPA) המוצע על ידי React, Vue ו-Angular.

קישורים בארכיון ה-HTTP המייצגים אתרים שנמצאו משתמשים בטכנולוגיות שמעניינות אותנו

מסגרת או ספריה
קישורים לאתרי סלולר
קישורים לאתרים רגילים

jQuery
4615474
3714643

להגיב
489827
241023

Vue
85649
43691

זוויתי
19423
18088

תקוות וחלומות

לפני שנעבור לניתוח הנתונים, אני רוצה לדבר על מה שהייתי רוצה לקוות לו.

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

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

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

ניתוח הערכים החציוניים של הנתונים לא ייתן לנו את המידע שאנחנו צריכים. ולמעשה, גישה זו משאירה מעבר לתשומת לבנו הרבה דברים חשובים. במקום זאת, גזרתי ציוני אחוזון מהנתונים שהיו לי. אלו הם האחוזונים 10, 25, 50 (חציון), 75, 90.

אני מתעניין במיוחד באחוזון ה-10 וה-90. האחוזון העשירי מייצג את הביצועים הטובים ביותר (או לפחות קרובים פחות או יותר לטובים ביותר) עבור מסגרת מסוימת. במילים אחרות, זה אומר שרק 10% מהאתרים המשתמשים במסגרת מסוימת מגיעים לרמה זו, או לרמה גבוהה יותר. האחוזון ה-10, לעומת זאת, הוא הצד השני של המטבע – הוא מראה לנו כמה דברים יכולים להיות רעים. האחוזון ה-90 הוא האתרים הנגררים - אלה 90% האחרונים מהאתרים שיש להם את הכמות הגדולה ביותר של קוד JS או את הזמן הארוך ביותר הנדרש לעיבוד הקוד שלהם בשרשור הראשי.

נפחים של קוד JavaScript

ראשית, הגיוני לנתח את גודל קוד ה-JavaScript המועבר על ידי אתרים שונים ברשת.

כמות קוד JavaScript (KB) שהועברה למכשירים ניידים

אחוזים
10
25
50
75
90

כל האתרים
93.4 
196.6 
413.5 
746.8 
1201.6 

אתרי jQuery
110.3 
219.8 
430.4 
748.6 
1162.3 

אתרי Vue
244.7 
409.3 
692.1 
1065.5 
1570.7 

אתרי אינטרנט זוויתיים
445.1 
675.6 
1066.4 
1761.5 
2893.2 

מגיבים אתרי אינטרנט
345.8 
441.6 
690.3 
1238.5 
1893.6 

כמות קוד JavaScript שנשלח למכשירים ניידים

כמות קוד JavaScript (KB) שהועברה למכשירים שולחניים

אחוזים
10
25
50
75
90

כל האתרים
105.5 
226.6 
450.4 
808.8 
1267.3 

אתרי jQuery
121.7 
242.2 
458.3 
803.4 
1235.3 

אתרי Vue
248.0 
420.1 
718.0 
1122.5 
1643.1 

אתרי אינטרנט זוויתיים
468.8 
716.9 
1144.2 
1930.0 
3283.1 

מגיבים אתרי אינטרנט
308.6 
469.0 
841.9 
1472.2 
2197.8 

כמות קוד JavaScript שהועבר למכשירים שולחניים

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

מה שמעניין בנתונים האלה הוא שכמה מסגרות וספריות עשויות להיחשב לנקודות התחלה טובות יותר לפרויקט מאחרות. אתרים עם jQuery נראים הכי טוב. אתרי הדסקטופ שלהם מכילים 15% יותר JavaScript מכל האתרים, ואתרי הסלולר שלהם מכילים 18% יותר JavaScript. (אומנם, יש כאן הטיה מסוימת בנתונים. העובדה היא ש-jQuery קיים באתרים רבים, ולכן טבעי שאתרים כאלה קשורים יותר למספר האתרים הכולל מאחרים. עם זאת, זה לא משפיע על האופן שבו נתוני מקור מופקים עבור כל מסגרת.)

בעוד של 15-18% צמיחת קוד הוא נתון משמעותי, בהשוואה למסגרות וספריות אחרות, המס המוטל על ידי jQuery נמוך מאוד. אתרים זוויתיים באחוזון ה-10 שולחים 344% יותר נתונים למכשירים שולחניים מאשר כל האתרים, ו-377% יותר למכשירים ניידים. אתרי React הם הכבדים הבאים, שולחים 193% יותר קוד למכשירים שולחניים מכל האתרים, ו-270% יותר למכשירים ניידים.

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

מה שמעניין הוא שאתרי jQuery עוקבים אחר הרעיון הזה. למרות שהם, ברמת האחוזון ה-10, מעט יותר כבדים מכל האתרים (ב-15-18%), הם, ברמת האחוזון ה-90, מעט יותר קלים מכל האתרים - בכ-3% הן בגרסאות הדסקטופ והן בגרסאות המובייל. זה לא אומר שזהו יתרון מאוד משמעותי, אבל אפשר לומר שלפחות לאתרי jQuery אין גדלי קוד JavaScript ענקיים אפילו בגרסאות הגדולות ביותר שלהם.

אבל אי אפשר לומר את אותו הדבר על מסגרות אחרות.

בדיוק כמו במקרה של האחוזון ה-10, באחוזון ה-90 האתרים ב-Angular וב-React שונים מאתרים אחרים, אך הם שונים, למרבה הצער, לרעה.

באחוזון ה-90, אתרי Angular שולחים 141% יותר נתונים למכשירים ניידים מכל האתרים, ו-159% יותר למכשירים שולחניים. אתרי React שולחים 73% יותר למכשירים שולחניים מכל האתרים, ו-58% יותר למכשירים ניידים. גודל הקוד של אתרי React באחוזון ה-90 הוא 2197.8 KB. המשמעות היא שאתרים אלה שולחים 322.9 KB יותר נתונים למכשירים ניידים מאשר המתחרים הקרובים ביותר שלהם מבוססי Vue. הפער בין אתרי שולחן העבודה המבוססים על Angular ו-React לבין אתרים אחרים גדול עוד יותר. לדוגמה, אתרי React שולחניים שולחים 554.7 KB יותר קוד JS למכשירים מאשר אתרי Vue דומים.

הזמן שנדרש לעיבוד קוד JavaScript בשרשור הראשי

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

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

מסד הנתונים של HTTP Archive מכיל מידע על משך הזמן שלוקח לעבד את קוד JavaScript בשרשור הראשי של מנוע V8. זה אומר שאנחנו יכולים לאסוף את הנתונים האלה וללמוד כמה זמן לוקח לשרשור הראשי לעבד את JavaScript של אתרים שונים.

זמן מעבד (במילישניות) הקשור לעיבוד סקריפט במכשירים ניידים

אחוזים
10
25
50
75
90

כל האתרים
356.4
959.7
2372.1
5367.3
10485.8

אתרי jQuery
575.3
1147.4
2555.9
5511.0
10349.4

אתרי Vue
1130.0
2087.9
4100.4
7676.1
12849.4

אתרי אינטרנט זוויתיים
1471.3
2380.1
4118.6
7450.8
13296.4

מגיבים אתרי אינטרנט
2700.1
5090.3
9287.6
14509.6
20813.3

זמן מעבד הקשור לעיבוד סקריפט במכשירים ניידים

זמן מעבד (במילישניות) הקשור לעיבוד סקריפט במכשירים שולחניים

אחוזים
10
25
50
75
90

כל האתרים
146.0
351.8
831.0
1739.8
3236.8

אתרי jQuery
199.6
399.2
877.5
1779.9
3215.5

אתרי Vue
350.4
650.8
1280.7
2388.5
4010.8

אתרי אינטרנט זוויתיים
482.2
777.9
1365.5
2400.6
4171.8

מגיבים אתרי אינטרנט
508.0
1045.6
2121.1
4235.1
7444.3

זמן מעבד הקשור לעיבוד סקריפט במכשירים שולחניים

כאן אתה יכול לראות משהו מאוד מוכר.

בתור התחלה, אתרים עם jQuery מבזבזים פחות משמעותית בעיבוד JavaScript בשרשור הראשי מאשר אחרים. באחוזון ה-10, בהשוואה לכל האתרים, אתרי jQuery במכשירים ניידים מבלים 61% יותר זמן בעיבוד קוד JS בשרשור הראשי. במקרה של אתרי jQuery שולחניים, זמן העיבוד גדל ב-37%. באחוזון ה-90, הציונים של אתרי jQuery קרובים מאוד לציונים המצטברים. באופן ספציפי, אתרי jQuery במכשירים ניידים מבלים 1.3% פחות זמן בשרשור הראשי מאשר בכל האתרים, ובמכשירים שולחניים הם מבלים 0.7% פחות זמן בשרשור הראשי.

בצד השני של הדירוג שלנו יש מסגרות שמאופיינות בעומס הגדול ביותר על השרשור הראשי. זה, שוב, Angular and React. ההבדל היחיד ביניהם הוא שלמרות שאתרי Angular שולחים כמויות גדולות יותר של קוד לדפדפנים מאשר אתרי React, לוקח פחות זמן CPU לעבד את הקוד של אתרי Angular. הרבה פחות.

באחוזון העשירי, אתרי Angular שולחניים מבזבזים 10% יותר זמן של עיבוד קוד JS של שרשור ראשי מכל האתרים. עבור אתרי מובייל נתון זה הוא 230%. לאתרי React יש את הביצועים הגרועים ביותר. במכשירים שולחניים הם מבלים 313% יותר זמן בעיבוד קוד מכל האתרים, ובמכשירים ניידים הם מבלים 248% יותר זמן בעיבוד קוד. 658% אינם שגיאת הקלדה. באחוזון העשירי, אתרי React מבלים 658 שניות של זמן שרשור ראשי בעיבוד הקוד הקיים שלהם.

מספרי האחוזון ה-90 נראים לפחות קצת יותר טוב בהשוואה למספרים העצומים הללו. פרויקטים זוויתיים, בהשוואה לכל האתרים, מבלים 29% יותר זמן בשרשור הראשי במכשירים שולחניים, ו-27% יותר זמן במכשירים ניידים. במקרה של אתרי React, אינדיקטורים דומים נראים כמו 130% ו-98%, בהתאמה.

אחוזי הסטייה לאחוזון ה-90 נראים טוב יותר מהערכים הדומים לאחוזון ה-10. אבל כאן כדאי לזכור שהמספרים המציינים את הזמן נראים די מפחידים. נניח - 20.8 שניות בשרשור הראשי של מכשיר נייד לאתר שנבנה על React. (אני מאמין שהסיפור של מה שקורה בפועל בתקופה זו ראוי למאמר נפרד).

יש כאן סיבוך אפשרי אחד (תודה ג'רמי על הפניית תשומת ליבי לתכונה זו, ועל בחינת מדוקדקת הנתונים מנקודת מבט זו). העובדה היא שאתרים רבים משתמשים במספר כלים חזיתיים. בפרט, ראיתי הרבה אתרים משתמשים ב-jQuery לצד React או Vue כאשר אתרים אלו עוברים מ-jQuery למסגרות או ספריות אחרות. כתוצאה מכך, חזרתי למסד הנתונים, הפעם בחרתי רק את הקישורים התואמים לאתרים שהשתמשו רק ב-React, jQuery, Angular או Vue, אך לא בכל שילוב ביניהם. הנה מה שקיבלתי.

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

אחוזים
10
25
50
75
90

אתרים המשתמשים רק ב-jQuery
542.9
1062.2
2297.4
4769.7
8718.2

אתרים המשתמשים ב-Vue בלבד
944.0
1716.3
3194.7
5959.6
9843.8

אתרים המשתמשים ב-Angular בלבד
1328.9
2151.9
3695.3
6629.3
11607.7

אתרים המשתמשים רק ב-React
2443.2
4620.5
10061.4
17074.3
24956.3

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

ראשית, משהו שלא מפתיע: כאשר אתר משתמש רק במסגרת אחת או בספריה אחת, הביצועים של אתר כזה משתפרים לעתים קרובות יותר מאשר לא. הביצועים של כל מכשיר נראים טוב יותר באחוזון ה-10 וה-25. זה הגיוני. אתר שנוצר באמצעות מסגרת אחת צריך להיות מהיר יותר מאתר שנוצר באמצעות שתי מסגרות או ספריות או יותר.

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

זה קצת מוזר, אבל בכל זאת אנסה לחפש הסבר למוזרות הזו.

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

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

הפער בין מכשירים ניידים ושולחניים

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

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

עלייה בזמן (באחוזים) הקשורה לעיבוד סקריפט במכשירים ניידים בהשוואה לשולחני

אחוזים
10
25
50
75
90

כל האתרים
144.1
172.8
185.5
208.5
224.0

אתרי jQuery
188.2
187.4
191.3
209.6
221.9

אתרי Vue
222.5
220.8
220.2
221.4
220.4

אתרי אינטרנט זוויתיים
205.1
206.0
201.6
210.4
218.7

מגיבים אתרי אינטרנט
431.5
386.8
337.9
242.6
179.6

בעוד שצפוי הבדל מסוים במהירות עיבוד הקוד בין טלפון למחשב נייד, מספרים כה גדולים אומרים לי שהמסגרות המודרניות אינן ממוקדות מספיק למכשירים בעלי הספק נמוך והרצון לסגור את הפער שזוהה. אפילו באחוזון העשירי, אתרי React מבלים 10% יותר זמן בשרשור הראשי לנייד מאשר בשרשור הראשי של שולחן העבודה. ל-jQuery יש את הפער הקטן ביותר, אבל גם כאן הנתון המקביל הוא 431.5%. כשמפתחי אתרים עושים את הפרויקטים שלהם בצורה כזו שהם דורשים יותר זמן מעבד כדי לעבד אותם (וזה מה שקורה, וזה רק הולך ומחמיר עם הזמן), בעלי מכשירים עם הספק נמוך צריכים לשלם על זה.

תוצאות של

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

נראה שזה לא חל על הביצועים של פרויקטים באינטרנט (וכנראה על שלהם נְגִישׁוּת).

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

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

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

אפשר לעשות כמה פשרות במצבים מתאימים, אבל חשוב שמפתחים יבצעו פשרות כאלה במודע.

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

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

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

• בדוק את עצמך בשכל ישר. האם אתה באמת צריך להשתמש במסגרת שבחרת? JavaScript טהור יכול לעשות הרבה היום.
• האם יש אלטרנטיבה קלה יותר למסגרת שתבחרו (כמו Preact, Svelte או משהו אחר) שיכולה לתת לכם 90% מהיכולות של אותה מסגרת?
• אם אתם כבר משתמשים במסגרת, חשבו האם יש משהו שמציע אפשרויות סטנדרטיות טובות יותר, שמרניות יותר (לדוגמה, Nuxt.js במקום Vue, Next.js במקום React וכו').
• מה יהיה שלך התקציב ביצועי JavaScript?
• איך יכולת להגביל תהליך הפיתוח כדי להקשות על הכנסת יותר קוד JavaScript לפרויקט ממה שהוא הכרחי?
• אם אתה משתמש במסגרת כדי להקל על הפיתוח, שקול אתה צריך לשלוח קוד מסגרת ללקוחות. אולי תוכל לפתור את כל הבעיות בשרת?

בדרך כלל, כדאי לבחון את הרעיונות האלה מקרוב, ללא קשר למה בדיוק אתה בוחר לפתח את הקצה הקדמי. אבל הם חשובים במיוחד כאשר אתה עובד על פרויקט שאין לו ביצועים מלכתחילה.

קוראים יקרים! מה אתה רואה כמסגרת JavaScript האידיאלית?

מקור: www.habr.com