You won't choose Solid.js for your next project
Solid.js נראה כמו React, אבל מוותר על Virtual DOM לטובת signals. ניר קאופמן מסביר מה מרוויחים, מה לא נפתר, ולמה framework הוא לא זהות מקצועית.
צפו בהרצאה
הסיפור שמאחורי ההרצאה
- Solid.js מאמצת JSX וסגנון קומפוננטות מוכר ל-React developers, לכן ניר טוען שה-learning curve קטן בהרבה ממה שנדמה.
- במקום Virtual DOM ו-re-render של קומפוננטות, Solid.js מקמפלת bindings ישירות ל-DOM ומעדכנת רק את החלק שתלוי ב-signal שהשתנה.
- Show, For ו-Switch מציעים control flow דקלרטיבי בתוך JSX, בלי להמציא שפת template חדשה.
- createEffect ו-createResource מציגים מודל קטן של primitives מבוססי signals עבור side effects, fetching ו-state management.
- המסר של ניר אינו שכל פרויקט צריך Solid.js. הוא מבקש ממפתחי frontend להפסיק להפוך React או Angular לזהות שאסור לגעת בה.
Solid.js לא מנסה לנצח את React במיתוג. היא נכנסת לאותו מרחב, נראית מוכרת, ואז משנה החלטה אחת שמפתחי frontend מרגישים בכל אפליקציה גדולה: מה קורה כשה-state משתנה. בהרצאה הזו ניר קאופמן משתמש בהומור כדי לפרק את הפחד מספרייה קטנה יותר, אבל מתחת לבדיחות יש טענה רצינית על reactivity, על performance, ועל זהות מקצועית.
הכותרת אומרת שלא תבחרו ב-Solid.js לפרויקט הבא. ניר לא מנסה להוכיח שכל צוות צריך לעשות migration. הוא שואל למה ההחלטה שלנו מתחילה ונגמרת ב”כולם כבר יודעים React”, גם כשהבעיה שאנחנו רוצים לפתור היא רינדור, state או מורכבות של קוד.
הפופולריות של React היא סיבה, לא תשובה
ניר פותח בעובדה שרוב מפתחי ה-frontend עובדים עם React. היא פופולרית, יש לה אקוסיסטם עצום, ומגייסים יודעים למצוא אנשים שכבר עבדו איתה. מול זה, Solid.js קטנה יותר, צעירה יותר, ואין מאחוריה חברה אחת שכולם מכירים. אלה שיקולים אמיתיים, במיוחד לפרויקט שאמור לחיות שנים.
אבל הם לא אומרים שהטכנולוגיה לא ראויה לבדיקה. ניר מצביע על המתח המוכר: אנחנו אוהבים frameworks חדשים, ובאותו זמן מפחדים לבחור משהו שאינו ברירת המחדל. גם בנצ’מרקים שבהם Solid מהירה מאוד לא מחליפים בדיקת התאמה למוצר. הם רק מונעים מאיתנו לשלול אותה לפי שם.
הוא מכיר את הדילמה גם מהצד של גיוס. אם כל מודעת דרושים דורשת React, מפתח עלול להתייחס לכל framework אחר כאל סיכון לקריירה. זה המנגנון שמנציח את עצמו. ובדיוק עליו ההרצאה מתעקשת: שוק העבודה אינו סיבה להפסיק להיות סקרנים לגבי הדרך שבה ה-DOM, state והקומפוננטות באמת עובדים.
JSX נשאר, רק ה-control flow נהיה מפורש
הדבר הראשון שניר מדגים הוא שהכניסה ל-Solid אינה מתחילה בשפה חדשה. קומפוננטה היא פונקציה, היא מחזירה JSX, ו-props ו-event handlers נראים מוכרים. הוא מציג React ו-Solid זו לצד זו כדי להוריד את ההתנגדות הנפוצה של learning curve.
אתם יודעים React חברים, בחרתם את Solid, אתם יודעים React.
Solid מוסיפה סביב JSX רכיבים כמו Show לתנאי, For לרשימה, ו-Switch עם Match ו-fallback. אפשר לבצע תנאים גם ב-JavaScript הרגיל. הטענה כאן אינה שיש דרך אחת נכונה. ניר מעדיף את הגרסה הדקלרטיבית כי היא מספרת מה מוצג ומתי, בלי לפזר תנאים ורינדורים לאורך הקומפוננטה.
למי שמגיע מ-React, זה חשוב יותר מהתחביר עצמו. ספרייה חלופית לא חייבת לזרוק את כל מה שהצוות יודע כדי לתת מודל אחר לבעיית עדכון ה-UI. זו גם הסיבה שההרצאה של ניר על front-end פשוט יותר משלימה את המסר: לא כל שכבת abstraction נוספת הופכת את הקוד לטוב יותר.
בלי Virtual DOM, עם dependency מדויקת
הסיבה הטכנית המרכזית לבחור ב-Solid היא לא JSX אלא המודל reactive שלה. ניר מתאר את React כאפליקציה שבה שינוי state קורא שוב לפונקציית קומפוננטה, ואז React בודקת מה צריך לעדכן. באפליקציה גדולה, הדיון הזה הופך ל-useMemo, useEffect והבנה מתמדת של re-renderים.
Solid הולכת למסלול אחר. היא מקמפלת את הקוד ל-DOM methods ול-bindings ישירים. signal מחזיק ערך reactive, ו-setter משנה אותו. כשמשנים signal, רק המקומות שקראו אותו מתעדכנים. אין צורך לקרוא שוב את כל הקומפוננטה רק כדי למצוא את הטקסט או ה-element שהשתנו.
אין Virtual DOM, אין Re-Render, אין קריאה מחדש לפונקציה.
זו fine-grained reactivity. ניר מדגים signal שיכול לשמש קומפוננטה אחת או כמה קומפוננטות, בלי להפוך מיד ל-context או store כבד. זה לא אומר שאין state management. זה אומר שהיחידה הבסיסית של dependency קטנה יותר, והמערכת יודעת בדיוק למה להגיב.
כמו תמיד, performance אינו פטור מחשיבה. אם המודל קטן יותר אבל הצוות לא מבין ownership, lifecycle או flow של data, הקוד עדיין יכול להסתבך. Solid משנה את ברירת המחדל של העדכון. היא לא מחליפה design.
Signals, side effects ו-fetching בלי ערימת hooks
ניר מחבר את המודל הזה ל-createEffect: פונקציה שמופעלת שוב כש-signal שהיא קראה משתנה. מבחינתו זה מודל קטן וברור יותר מערימה של hooks עם dependency arrays. הוא מציין שגם Angular, Vue ו-Qwik משתמשים ברעיונות של signals, כך שהכיוון אינו תכונה אקזוטית של ספרייה אחת.
ב-data fetching הוא מציג createResource. נותנים לה פונקציה שמחזירה promise, ומקבלים resource reactive שאפשר לבדוק מולו loading, error ו-data. הדוגמה אינה טענה ש-React Query מיותרת או ש-fetching תמיד פשוט. היא מראה שהמודל של data וסטטוסים יכול להתחבר ישירות ל-reactivity, בלי להתחיל מספרייה נוספת רק כדי לקבל את הבסיס.
היתרון שניר מדגיש הוא לא “פחות APIs” בכל מחיר. הוא פחות דברים שצריך לזכור כדי לדעת מי מתעדכן בגלל מה. באפליקציות שבהן צוות נלחם ב-rendering לא צפוי, זו סיבה מספקת לבדוק את המודל על מסך אמיתי ולא רק לקרוא עליו.
Framework הוא כלי, לא הטייטל שלך
בסיום ניר חוזר מהמכניקה של Solid להחלטה המקצועית. React developer או Angular developer הם קיצורי דרך שימושיים, אבל הם לא אמורים להיות גבול היכולת. היכולת לעבור בין frameworks היא חלק מעבודת frontend, בעיקר כשהטכנולוגיות עצמן מתחלפות מהר.
תישארו קודם כל מפתחים, אחר כך כל השאר.
זה לא זלזול ב-expertise. יש ערך לניסיון עמוק ב-React ויש שיקולים לגיטימיים של גיוס, קהילה ותחזוקה. המסר הוא לא להינעל על ברירת המחדל מתוך פחד. בדקו את Solid.js, הבינו signals, והחזירו את ההחלטה לבעיה של המוצר ושל הצוות.
מה לקחת לפרויקט הבא
- בדקו אם הבעיה שלכם היא באמת framework, או שמדובר ב-data flow, state וגבולות קומפוננטות לא ברורים.
- אל תניחו ש-learning curve גבוה רק כי שם הספרייה חדש. JSX ומודל קומפוננטות מוכר יכולים לקצר מאוד את הכניסה.
- מדדו performance במוצר שלכם. בנצ’מרק הוא כיוון, לא design document.
- אם בוחנים signals, עקבו אחרי ה-dependencies: איזה חלק קורא איזה ערך, ומתי side effect באמת צריך לרוץ.
- תנו לשיקולי גיוס משקל, אבל אל תתנו להם להפוך את React לשם נרדף ל-frontend.
Solid.js אינה בחירה אוטומטית. היא תזכורת שימושית לכך שאפשר לקחת תחביר מוכר, להחליף מודל רינדור, ולשאול מחדש מה באמת צריך להיות פשוט יותר בקוד שלנו. צוות שמכיר את ה-tradeoffs יכול לבחור גם בברירת המחדל, אבל לבחור בה במודע.
"אתם יודעים React חברים, בחרתם את Solid, אתם יודעים React."
- ניר קאופמן
"אין Virtual DOM, אין Re-Render, אין קריאה מחדש לפונקציה."
- ניר קאופמן
"תישארו קודם כל מפתחים, אחר כך כל השאר."
- ניר קאופמן
- 03:50 למה לבחור ספרייה שאף אחד לא בוחרניר מציג את Solid.js דרך הטיעונים נגדה: קהילה קטנה יותר, בלי חברת ענק מאחוריה, ושוק שממשיך להעדיף React.
- 07:06 JSX מוכר, learning curve קטןהדוגמה של React מול Solid מראה קומפוננטות ופונקציות שנראות דומות, לצד רכיבי Show, For ו-Switch שמחליפים תנאים ולולאות בתוך JSX.
- 13:51 הבעיה שרואים אחרי שנים עם Reactניר עובר מדוגמת useState לעלות של re-render ומסביר למה memoization והבנת מסלול הרינדור הופכים לעבודה שוטפת באפליקציה גדולה.
- 17:24 Signals ו-fine-grained reactivitySolid מעדכנת binding שנשען על signal במקום לקרוא מחדש לכל הקומפוננטה, וה-signal יכול להישאר משותף גם בין קומפוננטות.
- 24:14 ארבעה primitives במקום ערימת hookscreateEffect מדגים side effect שמגיב רק ל-signals שבהם השתמש, וניר משווה את המודל לגישות reactive ב-Angular, Vue ו-Qwik.
- 29:39 Data fetching כ-resource reactivecreateResource עוטף promise ומחזיר state reactive של loading, error ו-data, בלי לבנות את כל הדוגמה סביב ספריית fetching חיצונית.
- 35:04 לא להתחתן עם frameworkניר חוזר לשיקולי גיוס ולפחד מניסיון לא-React, ומציע לראות בעצמנו מפתחי frontend שיודעים JavaScript ולא אנשי framework אחד.
מה כוסה בהרצאה
ניר קאופמן
ניר קאופמן
מנהל גילדת הפרונטאנד ב-Next Insurance, Google Developer Expert ומרצה בינלאומי. לשעבר יועץ שנגע בקרוב ל-250 פרויקטים, מנטור ומנהל קהילות.
שאלות מההרצאה
האם Solid.js משתמשת ב-Virtual DOM?
לפי ההרצאה, לא. הקוד של Solid מתקמפל ל-DOM methods ול-bindings ישירים. כש-signal משתנה, מתעדכן ה-binding שתלוי בו במקום להפעיל מחדש את פונקציית הקומפוננטה כולה.
האם מפתחי React צריכים ללמוד תחביר חדש כדי לעבוד עם Solid.js?
ניר מציג JSX, פונקציות וקומפוננטות שנראים מוכרים למפתחי React. יש רכיבים כמו Show, For ו-Switch ו-primitives מבוססי signals, אבל הוא טוען שהכניסה הבסיסית לפרויקט קצרה.
מה זה signal ב-Solid.js?
signal הוא מקור ערך reactive. קוראים אותו במקום שבו רוצים binding, ומשנים אותו דרך setter. החלקים שתלויים בו מגיבים לשינוי בלי re-render רחב של כל הקומפוננטה.
האם ההרצאה ממליצה לבחור Solid.js לכל פרויקט?
לא. ניר מכיר בשיקולי גיוס ובפופולריות של React. המסקנה שלו היא לא לבחור ספרייה אחת כברירת מחדל זהותית, אלא לשמור על היכולת להבין ולבחון frameworks שונים.