פוסט זה נכתב בשיתוף פעולה של
ניר בנימין,
איתמר שגב ושלי.
הוא מסכם ניסיון של 3 ימים בכתיבה בראקט, שהתרחשה במסגרת "האקתון" במעבדות SAP.
הפוסט
פורסם לראשונה ב geektime, אך ללא הפיסקה "כמה נושאים מעט יותר מתקדמים" (בעצתו של ניר - בכדי להקל מעט על הקוראים). אני רוצה להאמין שקוראי בלוג זה הם בעלי קיבולת גבוהה יותר מ
1600 מלים / 7 דקות קריאה - המומלצות לבלוגים.
אמרו לי אם לא. אני לא מזלזל בטענה "זה קצת ארוך מדי בשבילי". אנחנו בני-אדם.
----
Angular.js, ספריית ה MVC מבית גוגל לצד-הלקוח, הופכת לבחירה יותר ויותר מקובלת בקרב מפתחים. כיום, היא אחד הנושאים המדוברים ביותר בטכנולוגיות צד-לקוח.
בצד ההגמוניה ההולכת ונבנית ע"י אנגולר בצד-הלקוח, נשמעים בד בדד, גם קולות הטוענים שאנגולר מורכבת מדי - שאפשר לעשות את הדברים בצורה פשוטה יותר. פשטות היא ערך משמעותי בעולם הקוד הפתוח ובצד הלקוח בפרט. אחד הקולות הללו מגיע מצד Facebook ו Instagram. הפתרון שלהם: ספרייה ששוחררה לפני כשנה בשם
react.js.
React.js (להלן "ראקט"), לא תתחרה באנגולר ראש-בראש בעתיד הנראה לעין: אנגולר היא מקיפה הרבה יותר (הן פונקציונלית והן תהליכית), ומתאימה הרבה יותר ל mainstream.
ראקט פותרת רק חלק קטן ממה שאנגולר פותרת - ועושה זו בצורה לא שגרתית, מה שעלול להרחיק ממנה מפתחים רבים מה mainstream. היא אנדרדוג. כמה מהרעיונות שלה מקוממים במבט ראשון. אולי גם במבט שני :).
יש כבר כמה דוגמאות לשימושים ב React.js במוצרים מרכזיים[א]: פייסבוק (חלקים), אינסטגרם (עם ה router של backbone) ו Khan Academy (עם Backbone). ניתן למצוא עליה דיונים ב
StackOverflow ואפילו יש 4 גרסאות שונות שלה לשימוש ב
jsFiddle.
אפילו אם ראקט לא "תתפוס" - הרעיונות שלה הם מעניינים מספיק בכדי שיהיה שווה להכיר אותם ולחשוב עליהם. האם היא באה להעיר את תשומת לבנו לאבדן הדרך שהולך ומתרחש? או אולי סתם להציג עוד נקודת מבט אפשרית?
יצאנו לבדוק במה מדובר...
מה ראקט מציעה?
הדבר הראשון הניכר משימוש בראקט הוא מ
Client Side Rendering מהיר ביותר! ראקט יכולה לשמש לכתיבת אפליקציות שמרגישות מאוד "חלקות" ולא נתקעות. היא מתאימה לאפליקציות בעלות רינדור אינטנסיבי.
עד כמה שזה מרשים - זה עדיין לא פיצ'ר שמצדיק שימוש בספרייה עבור רוב המשתמשים. היכולות הללו בעיקר קוסמות למי שנמצא ב extreme optimization של אפליקציות ווב (כמו חברי "מועדון ה sub-second") ומחפש דרך לאופטימיזציה גבוהה מאוד, מבלי לחרב את הקוד.
האלמנט השני שמאפיין את ראקט הוא
פישוט צד-הלקוח בכל הנוגע לעדכונים של ה DOM.
בד"כ באפליקציה נראה 2 סוגי עבודה עם ה DOM: בנייה ראשונית של האפליקציה (על בסיס state מסוים) ועדכון ה DOM הקיים בנתונים חדשים. באפליקציות
SPA, עדכון ה DOM הוא חלק משמעותי מהאפליקציה.
ראקט מציעה לנו לבטל את עדכון ה DOM: כאשר יש צורך בעדכון כלשהו, פשוט נהרוס את ה DOM של האפליקציה כולו - ונבנה את כולו מחדש בעזרת לוגיקת "הבנייה הראשונית".
פשוט, לא?
מבחינת ביצועים, רעיון זה הוא חסר היגיון: כתיבה ל DOM היא יקרה מאוד.
ראקט מנהלת DOM וירטואלי אותו ניתן לעדכן במהירות רבה. המהירות מאפשרת סגנון כתיבה פשוט יותר - כתיבת ה DOM ללא התחשבות במצבו הקודם.
רעיון שלישי ואחרון של ראקט הוא
חלוקה מחדש של ה concerns בצד הלקוח: במקום הפרדה בין UI, לוגיקה, נתונים ואולי שליטה (וריאציות שונות של MVC) - ראקט מציעה הפרדה לרכיבים המחולקים ע"פ "יכולות עסקיות", כאשר כל רכיב אחראי על הנתונים, הלוגיקה וה UI שלו בעצמו.
חלוקה זו מזכירה במידה רבה טרנד עכשווי אחר בעולם צד-השרת, ובענן:
microservices.
שווה לציין שאת הרעיון הזה ראקט בעיקר מציגה כפי כחזון / הצעה - ללא סט כלים מלא לממשו. ה Components של ראקט הם אכן נקודת התחלה - אולם מנקודה זו ואילך על המפתח להתוות את הדרך בעצמו.
רבים ממשתמשי ראקט לא מאמצים / מאמצים חלקית בלבד את הרעיון השלישי, ומשתמשים בראקט בתור שכבת UI (קרי View) לארכיטקטורת MVC סטנדרטית. MVC היא אולי לא מושלמת - אך היא מוכרת ומובנת (כלומר: כל קבוצה מכירה אותה בדרך משלה).
שימוש בראקט עם Angular או Ember אפשרי, אך הוא לא נפוץ. השימוש בראקט מייתר חלק מיכולות Angular/Ember ומחליש את הסדר המובנה שהן מציעות. שימוש ב
ראקט עם Backbone.js, הוא דווקא טבעי בהרבה - כאשר ראקט מחליפה את ספריית ה Template ליצירת Views.
יש כאלו הממליצים להתחיל לעבוד עם ראקט כ View של Backbone, ורק לאחר שמשיגים בצורה זו שליטה - להמשיך הלאה.
סיכום ביניים:
- ראקט לא מציעה MVC, או תחליף ישיר ל MVC.
- ראקט מהווה סוג של תחליף ל Templates (וקצת יותר מכך). במקום שפת template "מנוונת" - ראקט מאפשרת להשתמש (פחות או יותר) בג'אווהסקריפט לבניית ה markup.
- ראקט מערבבת בין ג'אווהסקריפט לבין "HTML) Markup)", אך מפרידה בין רכיבים על הדף - כל אחד אחראי על הפונקציונליות שלו.
- ראקט יעילה מאוד ברינדור, ומתאימה לאפליקציות אינטנסיביות ברינדור (בעיקר כאלו שעובדות על ה DOM).
אציין שגם Ember יעילה למדי בתחום זה (בעזרת Handlebars) - אולם נראה שהקוד יהיה פחות קריא.
כיצד ראקט עובדת
React.js היא ספרייה פשוטה, יחסית, בעלת אלמנטים ספורים.
הגדרת רכיבים (Components) נעשית ע"י המבנה הבא:
var <myComponentName> = React.createClass({
method1: function(...){..};
method2: function(...){..};
});
לא שונה בהרבה מ Backbone, Angular, או ספריות נפוצות אחרות.
בראקט ישנה הבחנה בין 2 סוגי רכיבים:
- רכיבים שהם Immutable
- רכיבים בעלי state
שני הרכיבים נוצרים ע"י createClass, אך הם שונים בשימוש שלהם ב State: האם כותבים משהו על ה state של הרכיב או לא. ראקט מעודדת לנסות ולכתוב כמה שיותר רכיבים Immutable - עבור יתרון בביצועים. כדי לחסוך ב Garbage Collections ראקט מבצעת pooling של אובייקטים (כגון Events) ועושה בהם שימוש-חוזר.
הרכיבים מושפעים בעת הרינדור שלהם מ2 מקורות: ה properties - שנקבעים בעת יצירת המופע של הרכיב (ולא ניתן לשנותם מרגע זה) וה state - שנשמר על הרכיב, וניתן לשנותו בכל רגע. בד"כ ה properties ישמשו גורם חיצוני לקבוע את התנהגות הרכיב, בעוד ה state הוא פנימי לשימושו של הרכיב.
אפליקציית ראקט טיפוסית מתחילה בקריאת:
React.RenderComponent(<root component name>);
היוצרת את רכיב האב וקוראת ל ()render שלו. הוא מצידו יקרא ייצור מופעים של רכיבים בנים (משולבים ב HTML markup) - ויקרא ל render שלהם וכך חוזר חלילה לעומק עץ של רכיבים ו markup.
כאשר יש שינוי ב state של אחד הרכיבים - פונקציית ה ()render של אותו רכיב תקרא ותגרום לעדכון של תת העץ שלו.
הרכיבים בראקט מגדירים את המראה שלהם בעזרת Markup ורכיבים בנים, כאשר הם לא כותבים ישירות ל DOM של הדפדפן לא רק ל React.DOM - ה DOM הוירטואלי שראקט מנהלת.
כפי שציינו, כתיבה ל DOM היא פעולה יקרה. יתרה מכך: הדפדפן מחזיק Buffer קטן של כתיבות ל DOM אותן הוא מנסה לאגד לאצווה, אולם כל קריאה מה DOM עשויה להכריח אותו לכתוב ל DOM בנקודת זמן לא רצויה (מדוע?
הסבר בפוסט זה, "ההשפעה של פעולות DOM מתוך קוד ג'אווהסקריפט").
מכיוון שראקט מנהלת עותק שלה של ה DOM, היא יכולה לקרוא ולכתוב ל DOM הווירטואלי שלה מבלי לעדכן את ה DOM של הדפדפן. כמו כן היא יכולה לסדר פעולות ל DOM בצורה אופטימלית מבחינת ביצועים (סדרות של קריאות וסדרות של כתיבות).
כאשר היא רוצה לעדכן את ה DOM של הדפדפן, היא עושה diff יעיל (
להלן הסבר האלגוריתם) של ה DOM הווירטואלי וה DOM האמיתי ומעדכנת ב DOM האמיתי רק אלמנטים שבאמת השתנו. כמובן, שכדי שזה יעבוד, אין לערבב על אותו אזור ב DOM את ראקט עם ספריה אחרת שכותבת ל DOM ישירות.
 |
ראקט מחלקת את הטקסט לרכיבים אטומיים קטנים, כך שיהיה אפשר לעדכן רק את ה nodes של הערכים (בירוק), מבלי לעדכן את הערכים של ה Labels (בצהוב).
שימו לב למספור שראקט מייצרת על ה DOM (תכונת data-reactid) - בעזרתו היא מבצעת השאוות יעילות של ה DOM. |
הרעיון של Virtual DOM אינו חדש, אגב:
Backbase הציגה מין Virtual DOM משלה לפני שנים (היא כנראה לא היחידה), וטכניקה דומה נמצאת בשימוש במנועים גרפיים של משחקי מחשב.
הניתוק מה DOM מאפשר לראקט גם ל
רוץ בצד השרת (עבור מכשירים חלשים / sub-second load time) - ממש כמו
rendr עבור Backbone.js.
 |
השוואה לא מדוייקת בין האתר Hacker News (שורה עליונה) ו clone שלו שכתבנו בראקט (שורה תחתונה). אדום - טעינה ראשונית. בכחול - פעולת דפדפוף בין הכתבות (האתר שלנו היה הרבה-הרבה יותר מהיר).
פרופיל ה timeline שקבלנו מקוד הראקט מאוד לא אופייני לאתר / אפליקציה שלא עברה עדיין שום אופטימיזציית ביצועים. |
דוגמת קוד
אין כמו לראות קצת קוד.
הנה אפליקציה פשוטה למדי עם 2 כפתורים (++X ו ++Y) המעלים את הערכים של ה counters המתאימים במרכז המסך.
 |
| התוצאה הסופית של האפליקציה |
קוד ב react ניתן לכתוב באחד מ2 סגננונות: JSX ו"ג'אווהסקריפט נקי".
JSX הוא הרחבה לג'אווהסקריפט עם XML (מבוסס
E4X?), המאפשרת לכתוב snippets של XML בתוך הג'אווהסקריפט ע"פ חוקים מסויימים.
JSX אמור להיות פשוט יותר ונקי יותר לכתיבה - ועל כן מועדף ע"י החלק הגדול של מפתחי ראקט. ה JSX מקומפל לג'אווהסקריפט רגיל לפני שהוא מורץ על הדפדפן. ניתן לקמפל אותו בתוך הדפדפן ע"י הוספת קובץ ג'אווהסקריפט בשם
JSXTransformer (לפיתוח מהיר יותר) או בצד השרת ע"י
רכיב מתאים של Node (לביצועים טובים יותר).
אנו עבדנו ב IDE בשם WebStorm (מומלץ) שקיבל יפה מאוד את הרחבות ה XML בתוך קובצי ה javaScript, והמשיך לתפקד היטב עם קוד הג'אווהסקריפט (hinting, ניווט, וכו').
עוד וריאציה נפוצה יחסית לשימוש בראקט היא
כתיבה ב CoffeeScript על מנת לכתוב קוד מינימליסטי של ראקט ללא JSX.
בדוגמה זו נראה כתיבה בצורת JSX ולאחר מכן, את הגרסה המקומפלת שלה ל"ג'אווהסקריפט נקי".
- כאשר משתמשים ב JSX Transformer בכדי לקמפל JSX "תוך כדי שימוש" ("on the fly") - חייבים לכלות הערה זו בתחילת הקובץ.
- אנו מגדירים רכיב (component) פשוט של ראקט, בשם Simple.
- את הרצת התוכנה בראקט מבצעים בעזרת פקודת renderCompoent על הרכיב הראשי. שימו לב לתגים ה Simple - שאיננה סטנדרטית ב HTML, אלא מבטאת את הרכיב שלנו. אנו שולחים לרכיב ה Simple שלנו Property (בלתי ניתן לשינוי immutable) - בשם message ואומרים לראקט להוסיף את הרכיב בתוך document.body (קרי InnerHTML).
- אחד השלבים הראשונים במחזור החיים של רכיב react הוא קריאה למתודה ()getInitialState המאתחלת את ה state של הרכיב. בשלב זה, ניתן להבין שזהו stateful component.
- שלב מעט מאוחר יותר במחזור החיים של הרכיב, הוא הקריאה למתודה ()render המייצרת את ה markup של הרכיב - ומחזירה אותו לרכיב האב (במקרה זה - זהו רכיב האב).
- יצירת ה markup נעשית על ידי כתיבה inline של markup ב JSX. עטפנו הכל בסוגריים כדי שנוכל למקם את ה div הראשון בשורה חדשה (אחרת JavaScript יחשוב שרצינו לכתוב ;return, ואח"כ אולי עוד משהו לא רלוונטי).
- סוגריים מסולסלות הוא ה escaping לשילוב ביטויי ג'אווהסקריפט בתוך ה XML (חייב לחזור ערך). במקרה זה אנו קוראים לאובייקט ה properties של הרכיב (שהוא immutable - בלתי ניתן לשינוי). את הערך של התכונה message קבענו בשלב 3.
- באופן דומה אנו רושמים מטפלים לאירועים (incX, incY).
- כאשר האירועים נקראים (בעקבות לחיצה של העכבר על אחד הכפתורים), מספיק שנשנה את ה state של הרכיב - כדי ש react ידאג לקרוא ל render, ובצורה יעילה (למשל: לא יותר מפעם אחת ב Animation Frame של הדפדפן).
- לתחביר ה XML יש כמה תכונות מיוחדות - למשל הטיפול ב inline style attribute.
כפי שאפשר להבחין, ה markup שאנו כותבים ב JSX הוא איננו HTML. זהו XML שרק דומה ל HTML. הסיבה לשימוש ב XML הוא הצורך ב markup קל לפענוח - HTML הוא מאוד סלחן ובעייתי לפענוח.
הדרך הכי בולטת לשים לב להבדל בין ה JSX XML ו HTML היא לקחת דוגמת HTML מהאינטרנט (שעובדת!) ולהדביק אותה לתוך האפליקציה. כמה הבדלים מרכזיים הם:
- אלמנטים חייבים להסגר. לא עוד <br> אלא רק </ br >.
- מכיוון שה markup מקומפל לג'אווהסקריפט, לא ניתן להשתמש במלים שמורות של שפת ג'אווהסקריפט. למשל, במקום תכונת class משתמשים ב className.
- inline style attribute לא נכתב כמו ב HTML, אלא כאובייקט - כמו בדוגמת הקוד למעלה. אפשר גם לכתוב אותה inline בעזרת סוגריים מסולסלים כפולים {{...}}=style.
בסה"כ, בניגוד לציפיותנו, התרגלנו לכתיבת ה XML דיי מהר - והיא לא היוותה מטרד מיוחד.
מעניין לציין ש react עושה escaping ל markup בכדי להגן בפני חולשות
XSS.
הנה הקוד לאחר שקומפל ל JavaScript בעזרת ה JSX Transformer:
הודאה קטנה: זה לא בדיוק הקוד. הקוד שנוצר הוא מעט "עמוס" בגלל השימוש ב "React.DOM" בכל מקום - ולכן עשינו לביטוי זה extract למשתנה שפחות תופס את העין: קו תחתון (בירוק).
הכנסנו את הביטוי במקום שורת רווח כדי לא "לקלקל" את מספרי השורות. ה JSX Transformer דואג לשמר את מספרי השורות בין ה source JSX לתוצר ה javaScript שנוצר.
כמה נושאים מעט יותר מתקדמים
דוגמת הקוד למעלה היא דיי בסיסית, אבל במערכות אמיתיות - דיי מהר נזדקק לקצת יותר מזה. הנה כמה פרטים על השימוש בראקט במצבים מעט יותר מורכבים / ריאליסטיים.
רשימות
פעמים רבות אפליקצית מכילות רשימה מסוג כזה או אחר. בד"כ טבעי למדל זאת כאובייקט שמנהל את הרשימה כולה ואובייקט שמנהל כל אחת מהרשומות.
אפשר לנהל את מודל כזה בצורה הקלאסי (חיבור למודל backbone, למשל) או לתת לרכיב להביא את המידע לו הוא זקוק ישירות מהשרת בעזרת קריאת Ajax (גישה של micro-services - כל רכיב דואג לעצמו מא' ועד ת').
על מנת ליצר רשימה כזו בראקט הגדרנו שני רכיבים:
- List רכיב שמיצג את הרשימה כולה – רכיב זה ייצור ListItem עבור כל אחת מהרשומות במודל שלנו, וגם ינהל את הרשימה במידה ויש צורך.
- ListItem רכיב שמייצג כל רשומה – רכיב זה יצטרך להכיר את המאפיינים של כל רשומה וידע להציג אותם כראוי.
כזכור, בראקט כל אחד מהרכיבים מחזיר בפונקציות ה () renderאת מבנה ה DOM שעליו הוא אחראי.
בדוגמה שלפנינו, כל רשומה היא בעצם DIV שמכיל את מבנה ה DOM של הרשומה. רכיב ה ListItem יחזיר אך ורק את ה DOM שנדרש בשביל להציג את הרשומה הבודדת.
רכיב ה List שאמור להציג את כלל הרשומות, יחזיר רק את העטיפה הנדרשת לכלל הרשומות, במקרה שלנו רק DIV עוטף אחד.
 |
| (לחצו להגדלה) |
- זוהי הגדרת רכיב האב, ה List. בעת יצירתו הרכיב מקבל startIndex - מאיזה מספר רשומה להציג את ה listItems ו data - הנתונים עצמם המגיעים מהשרת מבנה json.
- דרך יעילה לרנדר רשימה של אברים היא היא לעבור על נתוני המקור (this.props.data) בעזרת פונקציית map (של מערך בג'אווהסקריפט) וליצור מכל פריט נתונים - מופע של הרכיב (ListItem).
לא הייתה מניעה, אגב ש ListItem יהיה מורכב גם הוא מתתי-רכיבים. במקרה שלנו הפרדנו רק אלמנט אחד לרכיב-בן: Comment (האלמנט האחרון).
- הרכיב ListItem הוא עצמאי ואינו מודע ל List. אחד הרעיונות בראקט הוא לייצר רכיבים הניתנים לשימוש חוזר.
- ניתן לראות כיצד ListItem משתמש בטבעיות כ properties שהושמו לו ביצירה (שלב 2) - אלו בעצם הנתונים כפי שקיבלנו אותם מהשרת.
- שראקט יודע לטפל ב markup (למשל: אלמנט div), רכיבים (למשל <List>) או במערך של רכיבים / אלמנטי markup - כמו במקרה זה.
בעקבות שלב 5 בקוד, ראקט יוציא לנו הערה ב console של הדפדפן בזמן ריצה:
לא כדאי להתעלם מהערות אלו (ואחרות שהוא מוציא): כאשר יש רשימה, ראקט מבקש מאתנו מפתח ייחודי שבעזרתו יזהה שינוי state באובייקטי הרשימה. אחרת, האופטימיזציות של ראקט עלולות לגרום לו לדלג על שינויים שנעשו באובייקט - מבלי לעדכן אותם על המסך.
הנה דוגמה ל key כזה שהוספנו לאובייקט הרשימה בפרויקט שלנו:
האינדקס ממנו מתחילה הצגת הרשימה ברגע הנתון - הוא מזהה טוב לצורך זה.
יש עוד כמה נושאים ששווים ציון, אך היריעה קצרה להכיל. הנה מספר נקודות התייחסות אליהם:
מחזור החיים של הרכיב
כשתכתבו רכיבים מורכבים יותר - כנראה שתוכלו להיעזר בשלבים שונים ב lifecycle.
ממשק חיצוני של רכיב
כפי שאמרנו, רכיבים נבנו לשימוש חוזר / תחוף. ראקט מספקת מספר כלים כדי לכתוב רכיבים עמידים (robust):
- default props - ערכי default במידה והמשתמש לא הגדיר את Property נדרש.
- propTypes - מנגנון אימות על properties: האם יש property שחייבים להגדיר (isRequired), האם יש Property שסט הערכים התקניים שלו הוא סגור ( ([...])isRequired, ) וכו'.
שימוש חוזר בקוד בין רכיבים
במקום להסתבך עם prototype chains, ראקט מציעה מנגנון נוח יותר של
mixins, לשיתוף התנהגות בין כמה components שונים.
שינויים נקודתיים
על רכיב ניתן לשמור קישורים (תכונת refs) לאובייקטים מסוימים ב DOM בכדי לבדוק / לעדכן אותם בצורה נקודתית.
סיכום ורשמים אישיים
ראקט דורשת קצת זמן הסתגלות: אנו ניסינו אותה במהלך סוג של "האקתון" שערך שלושה ימי כתיבה, במסגרת מקום העבודה. רק ביום השלישי התחלנו להתרגל לסגנון הכתיבה בראקט (וגם אז - לא כולנו☺).
התיעוד שלה - לא טוב. את רוב התשובות מצאנו ב stackoverflow וכמעט לא בתיעוד הרשמי. נציין שכל נושא שלא עניין אותנו, דווקא היה מתועד בצורה מופתית! ("חוק מרפי של התיעוד").
נתקענו כמה פעמים על בעיות, לזמן לא קצר - אך בסוף הצלחנו לפתור את הבעיות ולהבין את מקורן. למשל גילינו, בדרך הקשה, שקביעת ערך לאובייקט ה state (כלומר
(...)setState) לא מתרחשת מיידית, אלא היא מנוהלת בתור ומבוצעת רק לפני ציור ה Activation Frame (כלומר האירוע בו הדפדפן מעדכן את תצוגת המסך, שאמור להתרחש 60 פעמים בשנייה). קביעת ערך בפונציה א' לא מבטיח שזה הערך שיקרא מאובייקט ה state בפונקציה ב' שמתרחשת מיד לאחר מכן. עדיף להעביר את הערך כפרטמר לפונקציה ולא להסתמך על ה state שיהיה מעודכן.
האפליקציה שכתבנו התרנדרה בצורה מהירה מאוד, גם ללא מאמץ שהושקע מצדנו. החלוקה לרכיבים הסתדרה בצורה טובה, אם כי זו אפליקציה קטנה. סה"כ הקוד בדיעבד נראה סביר ומסודר.
עוד נושא שלא בדקנו ונשאר כשאלה פתוחה היא הקלות לכתוב בדיקות יחידה: המצאותו של ה Virtual DOM עשויה בהחלט לעזור - אך לא ניסינו זאת עדיין.
היינו מנסים את react.js בעתיד באפליקציות לא-גדולות ו
עתירות רינדור (הייתה לנו אחת כזו לפני מספר חודשים).
מכיוון שרקאט היא לא כ"כ דומה ל frameworks אחרים, כדאי כנראה להשתמש בה רק בצוות שירגיש נוח איתה - לרוב מפתחי client-side hardcore הרגילים לכתוב קרוב ל DOM.
שאר המפתחים - יוכלו להמתין שראקט תתבגר עוד קצת ותגיע לגרסה...נאמר, 0.5.
---
כותבים שותפים:
ניר בנימין החל את לימודי ההנדסה שלו בגיל 3 - כאשר פירק את המערכת הסטריאו של הוריו. מאז הוא ממוקד בהנדסת תוכנה, טכנולוגיה, ושיפור תהליכים.
איתמר שגב הוא מפתח Client-Side ב SAP מאוד אוהב טכנולוגיות חדשות ובעיקר את כל מה שגוגל עושה.
---
קישורים
---
[א] בהשוואה לאנגולר. ניתן להזכיר שגוגל לא משתמשת באנגולר במוצרים המרכזיים שלה.
