הרשת גועשת סביב המעבר של OpenAI מ next ל remix. כולם משתפים חוויות ומסבירים כמה גם להם היה קשה לעבוד עם next ואיך ה App Router החדש מסובך מדי. אנסה לעשות קצת סדר:

1. אפליקציות עמוד-יחיד (SPA) זה מסובך. זה תמיד היה. ספריות לפיתוח SPA כמו react-router קיימות בדיוק בגלל שזה מסובך ושלאף אחד אין כח לטפל בלחיצות על כפתור "אחורה" וסימניות בדפדפן. אנחנו בונים SPA כי לפעמים זה נותן חווית שימוש טובה יותר.

2. רינדור בצד שרת (SSR) זה אפילו עוד יותר מסובך, כי יש לנו את כל הסיבוך של SPA ובנוסף צריכים להתמודד עם ניהול Cache בצד שרת ולוודא שהקוד של הקומפוננטות לא מפעיל דברים שצריכים את window כשהוא רץ בשרת. אנחנו מרנדרים בצד שרת כי מנועי חיפוש, קוראי מסך ועוד כלים רבים אחרים אוהבים לקבל את ה HTML מוכן גם אם הם לא מריצים JavaScript.

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

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

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