פרק מספר 499 של רברס עם פלטפורמה, שהוקלט ב-27 ביולי 2025 - אמצע הקיץ, סחוניה דל מות, עדיין בלי רעיונות לפרק 500 (יש זמן, אין לחץ*), ואורי ורן מארחים את הדר וקרן מחברת Myop כדי לדבר על חדשות מעניינות מעולם ה-Frontend.
(רן) אז תיכף נצלול פנימה ונבין את הצורך ואת הפתרונות - אבל לפני זה קצת היכרות. קרן, בבקשה:
- (קרן) אז נעים מאוד, קוראים לי קרן פנאן, מייסדת-שותפה והמנכ״לית של Myop.
- אני מגיעה מרקע לא-טכני: בעברי VP Product בחברה שנקראת Moon Active, פלטפורמה לפיתוח משחקים.
- אני הדר גבע - CTO ו-Co-Founder ב-Myop.
- ל-Myop אני מגיע מ-Wix
- אם Gett זה GetTaxi, אז Wix זה Wix.com . . . גם לא יודע למה מוסיפים את זה תמיד, אבל Wix.com.
- (רן) עכשיו אני מתבלבל עם Wix-נקודה-Whatever-אחר . . .
- (הדר) כן . . .
- (רן) . . . למרות שהם בטח קנו את כל הדומיינים, אני מנחש, את כל ה-”dots”. זה מה שאני הייתי עושה . . .
- (הדר) היו כמה, לא את כולם.
- בשנים האחרונות שם ניהלתי את גילדת ה-Frontend - הקבוצה הטכנית שאחראית על פיתוח ה-Front.
- גם בהקשרים של Soft Skill - גיוסים, הכשרות, הרצאות שאנחנו נותנים החוצה ומביאים פנימה.
- וגם ממש בליווי הטכני של ארכיטקטים בתוך Wix’ בתוך הקבוצות השונות.
- לפני זה הייתי ארכיטקט בעצמי ב-Wix כמה שנים.
- ולפני זה, לפני Wix, עבדתי בחברה שנקראת Jive Software - חברה אמריקאית.
- (הדר) ב-Wix בשיא היו 720, בשיא שלי, אולי משהו יותר, אולי פחות . . . 700 ומשהו Frontend
- (רן) Frontend, לא בסך הכל . . .
- (הדר) כן, סה”כ 1500-1600 בפיתוח זה, כולל את ה-QA, Mobile, Backend, כל ה...
(רן) כן. עכשיו, עובדים על מוצרים שונים - אבל ה-Stack הטכנולוגי הוא משותף או שדומה לפחות, ואתה בין השאר היית אחראי גם על לפתח אותם ולדאוג שיעבדו בצורה דומה, כל אותם 700.
(רן) כן, רק רציתי להזכיר.
- (הדר) כן, הייתי אומר ב-Wix’ שבעצם ה-Companies השונים או הקבוצות השונות אומרות את ה-”מה”, והגילדה אומרת את ה-”איך”.
- זה בעצם מה שעשינו שם.
- לגילדה גם היה גוף טכני, שתיכף נרחיב ונדבר - תשתיות וכל הדברים האלו.
(אורי) רגע, אז אה, “שאלה של סבתא” - איך נפגשתם?
(רן) . . . איך הכרתם? ראיתי את זה מתבשל . . .
- (הדר) אז רגע, בשביל זה אני צריך לסיים את ה... לפני Jive הייתי ברפא”ל ו-8200
- זה גם השירות הצבאי שלי וגם קצת אחרי.
- תפקידי ניהול ופיתוח - זה בגדול.
- ואז זה מגיע לאיך הכרנו - אני, קצת אחרי השביעי לאוקטובר, בעצם הגעתי למילואים ביחידה, לאיזה ארבעה חודשים ברצף, משהו כזה.
- אני עושה מילואים כל התקופה - 13-14 שנה - כמה ימים בחודש, פחות או יותר.
- מלווה שם קבוצות פיתוח ועוזר להם.
- ואז בעצם השותף השלישי שלנו . . .
- (קרן) כן - אז אנחנו בעצם שלושה שותפים, ואמיר ואני ככה התחלנו לגלגל את הרעיון שמאחורי Myop, והבנו שאנחנו צריכים צלע לשלישית, שתוביל את הטכנולוגיות.
05:09 מה זה Myop?
- (קרן) אז מה זה Myop? קודם כל, הדר ואני באים לשנות את העולם.
- זה מה שפאונדרים באים לעשות - לערער את הקיים עם פתרון שאנחנו מאמינים שהוא יותר טוב.
- בעצם, Myop היא מערכת UI או מערכת Frontend פלאגבילית (Plug-able).
- מה זה בעצם אומר? זה אומר שאנחנו מאפשרים לחברות טכנולוגיה לחבר לתוך המוצר הקיים שלהן חתיכות UI חיצוניות, בשיטה שאותה אנחנו פיתחנו, בשיטה שאנחנו קוראים לה “השיטה הפלאגבילית”.
- כלומר, אנחנו לא מכניסים את החתיכות קוד החיצוניות האלה לתוך ה-Stack, אלא מאפשרים איזושהי תקשורת עם החתיכה הזו ב-Runtime, ועל ידי זה מאפשרים גם עוד כל מיני יכולות סביב זה
- של ניהול ב-Production, היכולת לעשות שינויים, היכולת גם להריץ A-B Testing, סגמנטציות (Segmentations) . . .
- ולתוך כל זה - כי אי אפשר שלא - הבנו שיש לנו פה גם חלק מאוד מאוד משמעותי בכל “מהפכת ה-AI” נקרא לה.
- כי דווקא השיטה הפלאגבילית הזו שאנחנו מציעים, היא שיטה שהיא לדעתנו הרבה יותר נכונה - לקחת חתיכות קוד חיצוניות שה-AI כותב
- אולי אפילו גם על ידי Non-Developers או בשמם החדש, אני לא יודעת אם שמעתם את זה, “Citizen Developers”, שזה בעצם אנשים שהם עובדים עם הפיתוח אבל לא יודעים לכתוב קוד, כמו Product Managers ו-Designers.
- מאפשרים להם בעצם לייצר Feature-ים או קומפוננטות (Components) או whatever שהם החליטו, ולקחת אותם all the way ל-Production.
- כשאנחנו בעצם אומרים “לא - לא עשינו פה שום Risk, כי לא דחפנו את זה לתוך הקוד”.
07:02 פריטת החזון וההבדל מול מה שכבר היה קיים
(רן) אוקיי, אז בואו נפרוט את החזון הגדול הזה לחזונות קטנים יותר, או לחוזים קטנים יותר.
אז בעצם, בשיחת ההכנה, אחד הדברים שסיפרתם לי זה שכשנמצאים וכשעובדים בקבוצה שיש בה הרבה מאוד מפתחי Frontend, הרבה מאוד דברים קורים כל הזמן, בו זמנית. זאת אומרת, הרבה צוותים רוצים לשחרר רכיבים.
המוצר עצמו, ה-Frontend עצמו, זה לא מקשה אחת - יש בו הרבה מאוד רכיבים.
אפשר לחשוב על זה כמו על Microservice ב-Backend, אז Micro-Frontend - מונח שהוא כבר מוכר בתעשייה, Micro-Frontend ב-Frontend. ואני נתתי את האנלוגיה, שאני לא יודע עד כמה היא מדוייקת, שאתם למעשה בונים Docker ל-Frontend - איזושהי יכולת לעשות קונטיינריזציה (Containerization). התאמנתי על המילה, כן . . . - (קרן) מילה מורכבת . . - (רן) . . . להכיל רכיבים של Frontend, כדי לאפשר מודולריות, כדי לאפשר רובסטיות, כדי לאפשר Deployment יותר בטוח.
אבל אתם גם מוסיפים לזה עוד משהו - כלומר, היכולת לטעון רכיב מרחוק בצורה שהיא דינמית. הזכרתם A-B Testing וכל זה.
אז עד כמה מה שתיארתי הוא מדויק ואיך פורטים את זה למעשה לפעולות? זאת אומרת, איך קורה כל “הקסם” הזה?
- (הדר) כן, אז תראה - אמרת הרבה דברים, באמת בוא נפרוט אותם שלב-שלב.
- קודם כל, אני חושב שלפני שאנחנו עושים איזושהי עטיפה או איך קראת לזה? אני לא התאמנתי . . .
(רן) אני חייב להגיד את זה שוב? “מעטפת” נקרא לזה [Containerization . . . .]
- (הדר) כן, אז אני אומר שאנחנו עושים קודם כל ג'נרליזציה (Generalize) למה זה קומפוננטה (Component).
- ואני אוהב להציג את זה שאנחנו לוקחים כל חתיכת UI קיימת מכל טכנולוגיה ובכל צורת פיתוח - והופכים אותה לקומפוננטה.
- היום, כשאנחנו מסתכלים על חתיכות UI - בטח קיימות, בטח Legacy - אנחנו אומרים “אוקיי, זה מסך, זה מערכת, זה קומפוננטה”.
- ו-Myop באה ואומרת “אנחנו יכולים להפוך כל דבר לקומפוננטה”.
- אנחנו יכולים לקחת, ובהינתן חוזה נכון - ואנחנו כבר היום מפתחים בחוזים האלה Prop-ים, Ref-ים, הגדרות של מה קומפוננטה מקבלת ומה היא מחזירה.
- בהינתן שנדע לעשות את זה בצורה אחידה לכל חתיכת UI, נדע לקחת כל חתיכת UI ולרנדר (Render) אותה בכל מקום.
(רן) אבל אוקיי, אתה אומר שזה כבר היה קיים לפני זה . . . זאת אומרת, כל מי שאי פעם כתב ב-React או במערכות דומות מכיר את החוזים האלה - יש תכונות, יש מתודות . . . זאת אומרת, זה כן היה קיים.
אבל מה ההבדל בין מה שהיה קיים לבין החזון שלכם?
- (הדר) אז מה שהיה קיים זה הרעיון - הרעיון שאפשר לקחת חתיכת UI, ואותה לארוז עם חוזה מסוים.
- וגם, מה זה “היה קיים תמיד”? React לא היה קיים תמיד.
- נכון, React זה כן היה משהו מאוד מאוד חדשני - הקונספט של קומפוננטות.
- אז זה משהו שאנחנו לקחנו ומינפנו אותו למטרייה הרחבה יותר של לבוא ולהפוך כל חתיכה לדבר הזה.
- על זה, מה שאנחנו מוסיפים זה את היכולת לבוא ולהתעלם בעצם מבאיזה Stack זה מומש.
- בגלל זה אני אומר - “מכל תשתית לכל תשתית”.
- אז את זה אנחנו עושים - ואנחנו לא עושים את זה רק ברמת ארגון קוד או ניהול קוד. יש כל מיני חברות וכל מיני מוצרים שעושים את זה.
- אנחנו עושים את זה באמת ברמת הקוד שרץ לך באפליקציה ב-Production.
- זאת אומרת, תן לי חתיכת UI שנכתבה בכל דבר, בהנחה שהיא עובדת ואתה עומד בחוזה שלה - מעביר את הדאטה פנימה, מקבל את הדאטה החוצה - תוכל לרנדר (Render) אותה ולעשות לה Reuse בכל מערכת.
(אורי) אז הפרוטוקול שמדבר עם הקומפוננטה (Component) הוא רשתי? הוא מתעלם מה-Stack?
- (הדר) לא, זה יותר פשוט מזה - הפרוטוקול, כביכול- זה בסוף Prop-ים, כן.
- אנחנו מכירים את זה מ-React מאוד מאוד טוב - i PropTypes אם נחשוב על זה.
- בסוף, אתה יודע - גם כשאתה מרנדר (Render) קומפוננטת (Component) React, אתה תקבל את ה-Error בזמן כתיבת הקוד, נכון?
- אבל מה זה ה-Error הזה? זה TypeScript, כן? אני יכול להעביר יותר Prop-ים - והקומפוננטה תתעלם; אני יכול להעביר פחות Prop-ים, והקומפוננטה תתייחס לזה כ-Undefined או כ-NULL - אולי תתפקד, אולי לא.
- מה המנגנון הגנה שלי? TypeScript.
- מה אנחנו עשינו ב-Myop? מג'נרתים (Generate) לך את ה-TypeScript, את אותו TypeScript.
(אורי) אוקיי . . .
אבל סבבה, אז הבנו. לא הבנו את הפרטים, אבל הבנו בגדול מה קורה שם. עכשיו השאלה היא למה צריך את זה? כלומר, למה שתרצה לטעון דברים בצורה דינמית? כלומר, אנשי Frontend - יש להם איזשהו Spec, יש להם איזשהו Design, הם עובדים לפי ה-Spec, וברגע שהגיעו למשהו שהם אוהבים, הם עושים Deploy ויאללה. כאילו, למה צריך את הדינמיות הזאת? איפה רואים את הצורך הזה?
- (הדר) אז אני אתחיל דווקא ממה שאתה אמרת - הגיעו לאיזשהו ”Spec”. אז זו נקודה מעולה - אבל הם הגיעו לאיזשהו Spec בטכנולוגיה ספציפית.
- אם אנחנו בארגון קטן - מהניסיון שלי, כן? - כנראה שיש לנו רק Stack אחד או שינויים קלים בין לבין, וקל לנו מאוד לקחת את אותה Component או את אותה חתיכת UI שאיתה הגענו, פשוט לממש אותה ולרוץ קדימה.
- מה לגבי ארגונים, מערכות, גופים - שאת אותו Spec צריכים עכשיו לממש בכמה וכמה מקומות, אולי בכמה Stack-ים שונים? אולי בכמה Environments שונים?
- אז קודם כל’ מהזווית של “הגעתי כבר למשהו קיים”, עכשיו עם Myop אתה יכול לקחת ולעשות לו Reuse בעוד מקומות.
- תחשוב על מוצרים, תחשוב על חברות שיש להן . . .
(רן) כשאתה אומר “מקומות”, אתה מתכוון ל-Multi-Platform? תן דוגמא של מקומות כאלה . . .
- (הדר) כן, התחלנו, אתה יודע - יש לנו חברה, אנחנו רצים מ-15 שנה, כנראה שאנחנו ב-Angular, ועכשיו אנחנו רוצים להתחיל לכתוב ב-React.
- או כשעכשיו רכשנו חברה, או שעכשיו קנינו או לקחנו או רכשנו איזשהו מוצר.
- אז זה Scenario אחד - ה-Scenario של לקחת חתיכה שכבר יצרנו אותה ולהשתמש בה במקומות אחרים.
- הרבה פעמים, אגב, הבעיה היא הפוכה - איך אנחנו מגיעים בצורה המהירה ביותר ל-Spec שקיבלנו?
- ופה זה מתחיל להיות מעניין . . . .
- אם אני היום באיזשהו Stack Legacy, אולי אני בכלל כתוב על Builder . . .
- אולי איזה בית-תוכנה כתב לי את המערכת שלי - כי הייתי סטארטאפ קטן, כי הייתי ארגון לא מאוד טכנולוגי.
- ופתאום היום יש לי דרישות שעולות, והקומפוננטות הן מורכבות, נהיות מורכבות יותר ויותר.
- באים המפתחים שלי אומרים לי “תקשיב, היום כבר לא כותבים ב-PHP היום כבר לא כותבים ב-ASP - אני רוצה לכתוב ב-React אני רוצה לכתוב ב-Vue”.
- לרוב זה מגיע מאוד מהר ל”אוקיי בוא נעשה Re-write ובוא נשלם את כל מחיר ה-Re-write הזה”.
- (קרן) אני חושבת שיש לזה גם דרישה עסקית - שבסוף, ניהול ב-Runtime הוא מקצר Time to Market.
- וגם אם בפעם הראשונה שאתה לוקח את זה ל-Production אז נניח לא קיצרנו הרבה - אנחנו מאמינים שגם פה זה מקצר - אבל זה בוודאות מקצר לך כשאתה רוצה לעשות שינויים.
- ואנחנו חיים בעולם שעושים בו שינויים - Feature מגיע ל-Production הוא . . . אוספים Feedback, רואים מה עובד רוצים לעשות שינויים, רוצים לעשות דיוקים . . .
- כל דבר כזה זה עוד משימה לפיתוח - זה עובר את אותו Cycle של R&D - ואנחנו טוענים למה?
- בעצם, אני יכולה עכשיו לקחת - כ-Product-ית, כ-Designer-ית, כמי שאחראית על Revenues - בכוונה אני כזה לוקחת את הצד העסקי - ולקחת שינויים ל-Production, בצורה שהיא הרבה יותר מהירה ולא עושה לי עכשיו Disruption לראות מה פה לFeature-ים חשובים שיש לי ב-Sprint.
(רן) כלומר, את מדברת על . . . את, נניח, לא מפתחת, ואת הולכת ומפתחת קומפוננטה (Component) - נגיד איזשהו רכיב שלא יודע, “סופר קליקים שנותן לאנשים לקנות משהו”, בלי צורך בעזרה מהפיתוח - “כי AI”, אוקיי, עוד מעט
נגיע לשם - אבל את גם יכולה לפרוש את זה בעצמך. זאת אומרת, את לא צריכה שום עזרה - גם לא של ה-Frontend וגם לא של ה-Deployment וגם לא של ה-DevOps ולא של אף אחד - אלא פשוט ללחוץ על כפתור או לקרוא לאיזשהו API - והנה זה שם מול לקוח.
- (קרן) כן, אז תראה - קודם כל, חשוב לומר שבגישה שלנו עדיין צריך מפתח בתמונה, ובטח שצריך מפתח בתמונה בשביל החוזה הראשוני.
- אבל זה לא צריך להיות תהליך אינסופי כמו שזה היום.
- אני זוכרת, בתור מי שניהלה לא מעט מוצרים - שוב, בצד העסקי - ותמיד ישבה על הפיתוח ולא הבינה “למה זה לא קורה יותר מהר”
- כי זה לא יכול לקרות יותר מהר בהרבה פעמים.
- אבל בסוף כשחושבים על זה, כשמדובר בשינויי UI קטנים
- או בדברים - גם אם הם לא קטנים, בשינוי Layout, אבל שבסוף אין לי פה עכשיו איזושהי לוגיקה חדשה או שלא עשיתי איזשהו שינוי מהותי ל-Feature ובטח שלא שיניתי שום דבר שנוגע גם ל-Backend - ועדיין אני עוברת . . .
- זו אותה משימה, אני עוברת את אותו תהליך - וזה עדיין ייקח את אותו זמן של שבוע-שבועיים-שלושה-חודש, תלוי בגודל ה-Stack ובמורכבות של החברה.
- ואת זה אנחנו מערערים - כי אנחנו אומרים “רגע, יש דרך אחרת”
- שיכולה לגרום לחברות לפגוש את Production הרבה יותר מהר - להבין מה עובד ולקבל החלטות שהן “מבוססות תכל’ס”
- וכן, כמו שאמרת - AI עושה לזה אקסלרציה (Accelerate) בטירוף, כי AI גם יאפשר לי, כלא-מפתחת.
(רן) כן אז בואו נדגיש שוב את הבעיה במילים שלי - אז ככה: אתם רואים ש“יש צוואר בקבוק”. צוואר הבקבוק הוא הרבה פעמים הפיתוח - יש Designer, יש מנהל מוצר, שרוצים לדחוף קדימה Feature-ים, והרבה פעמים יש מחסור בשעות מפתחי Frontend או Whatever. מכל סיבה שהיא, זה לא עובר מספיק מהר כמו שרוצים - ואתם למעשה מפתחים את הכלי או את הטכנולוגיה או אולי את שיטת העבודה, שתאפשר לפתוח להרחיב את צווארי-הבקבוק האלה.
כלומר, יש דברים שבשבילם כן צריך מפתח וצריך פה הנדסה וזה צריך להיות נכון ומדויק - אבל לא להכל. אם זה ניסויי A-B Testing שונים, אם זה שינויים שהם לא משמעותיים, שכן יכולים להזיז את המחט בצורה מאוד מאוד משמעותית,
אבל מבחינה הנדסית הם לא משמעותיים - אז למה לחכות לפיתוח בשביל הדבר הזה?
- (הדר) נגיד אפילו משהו שיותר קל לעיכול באזורים האלה: נניח שאנחנו, כמפתחים, לדרישת ה-Product, לדרישת ה-Design, מימשנו 2-3-4 וריאנטים (Variants) לקומפוננטה (Component) מסוימת.
- בסוף, מי שיחליט מי רואה מה וכמה ואיזה Variant ניצח - זה בכל מקרה ה-Product.
- למה לא לתת לו כלי מאוד פשוט, שבקליק הוא מחליט את זה?
- הרי בסוף אנחנו מכירים את זה - יש את הפיתוח עצמו: מורכב או לא מורכב, AI או לא AI, תכף נגיע לזה.
- אבל הרבה פעמים אנחנו מכניסים את ה-If-Else לקוד הזה, של 50/50.
- שבוע אחרי או כמה ימים אחרי, אם אין לנו איזה מערכת, בוא נשנה את זה למשהו אחר - ואז נכנסים לקוד עוד פעם ומוחקים את ה-Experiment - כי ה-Variant ניצח.
- בסוף ה-Product מחליט את זה - ואנחנו הולכים ומממשים את זה, שוב ושוב ושוב.
(אורי) אבל פה אתה מדבר ממש על יצירת התוכן, ה-Variant - לא רק על המיתוג של . . .
- (הדר) אני אומר יותר מזה - יש את היצירה עצמה, שתיכף נדבר: עם מפתח או בלי מפתח.
- את האורקסטרציה (Orchestration) של הדבר הזה, את הניהול של איזה Variant מנצח, מי רואה מה, כמה אחוזים - כל זה.
- יש הרבה כלים שעושים את זה ברמת “אני אחזיר לך את ה-Boolean, אני אחזיר לך את ה-Variant, אני אחזיר לך את המספר באחוזים”.
- אבל אנחנו, כמפתחים, הולכים ועושים את הקוד - חושבים מאיפה לטעון את הקומפוננטה, איך להעביר את ה-Prop, מה הדאטה שזה מקבל, מה הדאטה שזה נותן . . .
- ו-Myop מאפשרת לנו לעשות לזה הכללה מאוד פשוטה: יש Variant-ים, זה החוזה של הקומפוננטה (Component) - ואז זה שכבת ניהול מעל זה.
- מי רואה מה, מתי, ואיזה גרסה מנצחת.
(רן) לא משלמים על זה מחיר? זאת אומרת, אם אתה צריך לשחק לפי הפרוטוקול - לצורך העניין, אני כותב React, Vue, Angular, או Whatever, Prototype, רחמנא ליצלן - אז אני צריך להתאים את עצמי לפרוטוקול.
כלומר, אני, קודם כל - אני, שכתב את הקומפוננטה (Component), צריך להתאים את עצמי לפרוטוקול. אם לא עשיתי את זה, אז מישהו מהחברה שמשתמשת צריכה לעשות את זה. זאת אומרת, יש פה איזשהו Overhead.
גם ברמה ה-HR-ית, כאילו, מבחינת כוח אדם, אבל גם אולי מבחינת Run-time, מבחינת ביצועים על לא יודע, על Device-ים יותר קטנים. זאת אומרת, לא משלמים פה מחיר?
- הדר) אז תראה, ברגע שטוענים קומפוננטה בזמן ריצה - אנחנו מכירים את זה הרבה לפני Micro-Frontend ודברים כאלה, משלמים איזשהו מחיר.
- המחיר הזה, אם משחקים איתו נכון, יטיב איתנו עם ה-Performance
- כי אנחנו בעצם מורידים דברים מה-Bundle המלא שלנו, מאיצים את ה-initial load, את ה-initial pain, וטוענים את הדאטה הפנימי בעמוד רק מתי שצריך.
- כשאנחנו מדברים על Multi-Variant או UI שמשתנה, זה אפילו מקבל עוד חיזוק.
- כי בעצם במקום להביא שניים-שלושה-ארבעה Variant-ים ל-Client-side ולעשות את ה-If-Else בקוד.
- שבואו - זה מה שיקרה ב-React, ב-Vue, ב-Angular, אם לא נכתוב מנגנון חכם מעל - Myop יודעת לבוא ולהגיד “אוקיי, הבנתי - בגלל עץ ההחלטות, בגלל ההגדרה של הקונפיגורציה, בגלל כל הכלים שאנחנו נותנים - שה-User הזה צריך לראות את ה-Variant הזה, וזה רק ה-Variant שיגיע.
20:41 מי קם בלילה?
(אורי) יש לי גם עוד שאלה, שקשורה קצת לדינמיקה של בין פיתרון כזה לבין התרבות של הפיתוח - והשאלה היא “מי קם בלילה?”.
- (הדר) אז זו שאלה טובה, שאנחנו עכשיו בדיוק עם אחד הלקוחות שאנו מתחילים להתחבט בה.
- הטייק שכרגע נלקח שם - ואני מאוד מתחבר אליו - זה ש”מי שעשה את הקומפוננטה”.
- זאת אומרת, אם אנחנו באים ומעצימים איזשהו Citizen Developer, שהוא ה-Designer, שהוא ה-Product, והוא הלך - עם AI, לא עם AI, לא משנה איך - ויצר קומפוננטה - הוא אחראי עליה, הוא פותר בה את הבאגים.
(אורי) אז הוא נכנס ל-On-Call?
- (קרן) כן. עם הכוח באה האחריות.
- אני יכולה לשתף מעולם ה-Gaming, שבאמת יצא לי לעבוד שם כמה שנים - אני לא יודעת כמה אתם מכירים, אבל גם בעולם ה-Gaming, משחקים מוצלחים, זה משחקים שיש בהם רכיב דינמי.
- כלומר, כל החלק הוויזואלי הוא נשלט מרחוק - בעצם, אי אפשר לשחרר עכשיו גרסה ל-App Store או ל-Google Play על כל שינוי ויזואלי.
- וזו אחריות שבעצם ירדה מהפיתוח ועברה למחלקות הProduct - Product, מוניטיזציה.
- וכן, זה אומר שעם האחריות לעשות את השינויים - שזו אחריות מדהימה, זו אחריות שמאפשרת לך לתקשר עם ה-User-ים בצורה מדהימה, להעביר רעיונות מרעיון לProduction ב-No-Time.
- אז כן, אז באה גם האחריות של להיות On-Call - ואם משהו משתבש, אז כן, אז אתה חלק, אתה מתחת לאלונקה להבין מה לא עבד.
- אנחנו מאמינים שלשם העולם הולך.
- כאילו, אי אפשר לבוא ולהגיד “אני רוצה לעשות יותר” - ומצד שני לא לרצות לקחת את האחריות.
(רן) כן, אבל אני חושב שאורי מעלה פה נקודה נכונה - זה כנראה תהיה מטוטלת. כלומר, זה לא יהיה קל להעביר את הכדור הזה, או לחלוק בכדור הזה בין כולם, ויכול להיות שזה גם ידרוש מכם לפתח כלים לניטור - אבל לא למפתחים, במקרה הזה, ל-Citizen Developers, כמו שאמרתם.
אז כן, זאת אומרת - כנראה שהמטוטלת הזאת תעבור כמה פעמים עד שהיא תגיע למקום יציב, אבל סבבה, זה מובן.
23:07 מה היעד?
(רן) רציתי רגע לדבר על ה-Target Market. כלומר, אם אני סטארטאפ של מפתח Frontend אחד ואיש Backend אחד, אני מניח שבמקרה הזה אני לא צריך פתרון כמו Myop. אולי גם פה אני טועה . . . מתי כן?
זאת אומרת, מה הלקוח האידיאלי מבחינתכם?
- (קרן) נכון, אז אתה ממש צודק. אני אגיד יותר מזה - אני חושבת שהיום, סטארטאפ של מפתח אחד, או אפילו Founder לא-טכנולוגי - השוק עכשיו, שלא נאמר “מוצף”, בכלים שאמורים לתת לך את ה-Ramp-up הראשוני, ואנחנו בעד זה לגמרי.
- גם אין לנו שום רצון או כוונה להתחרות בזה.
- אני חושבת שזה כלים מדהימים, ואין ספק שגם הם ילכו וישתפרו וישתפרו.
- אנחנו דווקא פונים לחברות שכבר יש להן מוצר - כבר יש להן User-ים, כבר השקיעו שנות-Engineering, שעלו הרבה מאוד כסף.
- וזה עובד - וה-User-ים מרוצים והכל בסך הכל טוב.
- ויש יעדים וצריך לגדול וצריך לעמוד בהם - ועל הדרך צריך גם לזוז יותר מהר, וצריך גם To adopt AI, כי אי אפשר שלא.
- ושם אנחנו חושבים שיש כאב מאוד מאוד גדול, כי אני לא אזרוק את כל מה שבניתי עכשיו בשלוש-ארבע-חמש-עשר שנים האחרונות - ואבנה מאפס ב-Lovable, זה לא יקרה . . . .
- זה לא ריאלי, זה גם לא יחזיק מים.
- אבל אולי אפשר להשתמש ב-Lovable לפתח Feature או קומפוננטה (Component) או יכולת ספציפית - ושם ליהנות מה-Vibe המטורף הזה.
(רן) כן, רק למי שלא היה בכדור בחודשים האחרונים - Lovable זו פלטפורמה למה שנקרא Vibe Coding או אולי ל-Citizen Coders אם תרצו, שמאפשרת לפתח אתרים או רכיבים - באנגלית, כלומר, על ידי תיאור של מוצר. יכול להיות שמכירים את Base44 הישראלית שעושה משהו דומה. אז כן, אז יש כמה כאלה, ו-Lovable זו אחת המובילות.
אז זה מתחיל לענות -אבל אני אשאל את השאלה הזאת במפורש: למה עכשיו? כלומר, למה לדעתכם השוק עכשיו בשל לפתרון כמו שלכם וצריך אותו?
אז מן הסתם “התפזלנו” לכיוון של AI, אבל בואו תפרטו קצת, כלומר - איך זה הולך להיראות לפי החזון שלכם?
- (קרן) אז קודם כל, אני חושבת ששווה לשאול מה האלטרנטיבה?
- אם אנחנו הולכים על אותה Mature App - מה אפשר לעשות? אפשר עכשיו להשקיע בתשתית שהיא יותר מודולרית והיא מייצרת לי את ה-Micro Apps או שליטה שהיא . . .כאילו, אני יכולה להחזיק דברים בתוך הStack ומחוץ ולייצר ביניהם תקשורת.
- אני גם יכולה לשים מפתח, שיעבור על ה-Output של Gemini או Claude, על אלפי שורות קוד - ויעשה גם אינטגרציה ידנית, זה גם אני יכולה לעשות.
- אבל איך שאנחנו רואים את זה, אלה כרגע האופציות, האלטרנטיבות.
- אז בעצם אנחנו אומרים, רגע - אם עולם ה-Software עובר פה איזשהו Disruption - מרצון, לא מרצון - אנחנו שם, הרכבת הזאת יצאה, נסעה, וכולנו בתוך זה.
- אז אנחנו ננסה להקל על ה-Disruption הזה עם השיטה הפלגבילית (Plug-able) שלנו, ה-”Containerization” . . . .
- (רן) . . . חייבים להמציא מילה יותר פשוטה לזה.
- (קרן) . . . חייבים.
(רן) כן, כלומר - את אומרת . . . אם אני מבין אותך נכון, בעצם את אומרת “אוקיי, יצרתי פה איזושהי קומפוננטה, שהיא נראית לי טוב - אבל היא מכילה אלפי שורות קוד, יכול להיות”. זאת אומרת, משהו ש-Lovable פלט או Gemini כתב לי, או Claude Code או Whatever. “זה נראה לי שזה עובד בסדר, נתתי לחברים שלי לשחק, נתתי ל...” . . . .
עכשיו, אני באמת הולך לעבור על כל האלף שורות קוד האלה לפני שאני באמת יודע אם משתמשים רוצים את זה?
לא בא לי לעשות את זה . . . אז לא, אני פשוט אתן למשתמשים. קודם כל להבין אם זה בכלל נותן את הProduct הנכון, אם זה נותן את החוויה הנכונה.
יכול להיות שזה לא Robust במאה אחוז - בסדר, אני מוכן לשלם את המחיר הזה. אבל אני קודם כל רוצה לדעת אם זה הולך לעבור את הפילטר של המשתמשים - ואתם למעשה נותנים את הכלי לעשות את זה. עם סיכון מסוים, אבל שהוא Manageable.
- (קרן) כן, אנחנו מנסים למתן את הסיכון עם QA פנימי ועם כמובן יכולות ולידציה (Validation) ועם Gradual Rollout, ו”תיקח את זה ל-5%, תיקח את זה ל-10%”, עם כל הכלים האלה.
- אבל כן, בדיוק - אנחנו אומרים, לא יודעת . . . זה כמו “ה-Next level של ה-MVP”, זה “AI-MVP”
- קח את זה, תבדוק את זה - ואז תקבל החלטה מושכלת אם לשים על זה צוות פיתוח ולפתח את זה Enterprise-Grade . . .
- (רן) “לשייף את הקצוות” . . .
(רן) כלומר, בעצם אתם מייצרים את היכולת להביא Prototype - אולי לא של כל המוצר, אבל Prototype של איזשהו רכיב, נגיד איזשהו מסך בתוך המוצר או איזשהו תפריט בתוך המוצר - להביא את ה-Prototype הזה ללקוח
עם מינימום מאמץ פיתוחי, באמצעות AI-Coding או Whatever. דרך אגב, יכול להיות שכן היה שם מפתח אבל הוא לא “שייף את זה עד הסוף”, אוקיי? אז להביא את ה-Prototype הזה לפני הלקוח, להבין אם הלקוח באמת רוצה את זה - ואם כן אז לוקחים את ה-Prototype והופכים את זה למוצר רובסטי (Robust), עם Performance וכו’ - אבל לפני זה אין טעם להשקיע.
(אורי) תמיד, כן - “בזמן הכבד” אתה רוצה להשקיע אחרי הוולידציה (Validation).
- (קרן) בדיוק.
- (הדר) כן, נכון. אני גם חושב שכאילו היום בלי פתרון כזה, בעצם העולם מתחיל להתחלק לאוקיי, היו לנו את ה-”Builder-ים”, הרבה מאוד שנים, שהיו שמורים ללקוחות מסוימים, נכון? דפי נחיתה פשוטים, כל מיני e-commerce קטנים, עצמאים שבונים לעצמם אתר . . .
- והיה לנו את המערכות הגדולות שחברות כותבות - Dashboard-ים, אפליקציות, כל הדברים האלו.
- וה-AI, עם ה-Vibe Coding, Base44, Lovable, כל הכלים שדיברנו, תופס ובא להחליף את ה-Builder-ים.
- אבל בעצם אנחנו זיהינו פה פוטנציאל - רגע, למה? למה לא לשלב עכשיו בין הדברים ולבוא ולתת את כל היכולות המדהימות של ה-Vibe Coding וה-AI שהולכים ומשתפרים כל יום ב-Level של קומפוננטה (Component) ולא ב-Level של אפליקציה.
- אם אני יכול לבנות אתר שלם ב-Base44 - חנויות, מה לא ראיתי בחודשים האחרונים . . . חנות להשכרת רכבים ונדל”ן שאנשים עשו בשכונה שלהם וכל מיני דברים.
- אז אם זה עושה אתר שלם, ה-Take שלנו זה בוא נצמצם את הקונטקסט לקומפוננטות - האיכות רק תעלה.
- נפנה ל-AI במשימה קטנה יותר מדויקת יותר, ונוכל להשתמש בזה במוצרים קיימים.
(רן) כן, זאת אומרת אתה אולי רומז לכיוון שני אתגרים שבאחד מהם נגענו ובשני לא ממש.
אחד זה אתגר המיטיגציה (Mitigation). כלומר, אני לא בטוח עד כמה הקוד הזה רובסטי (Robust), אני עדיין רוצה לבדוק אותו. על זה דיברנו.
30:00 “לכתוב Prompt” זה יותר מורכב ממה שזה נשמע
(רן) אתה גם מזכיר או רומז, לפחות לדעתי, על אתגר אחר - שהכלים האלה, יש להם יכולת לכתוב פרויקטים קטנים ברמת איכות יחסית סבירה. אבל כשאתה מכניס אותנו לתוך פרויקט גדול - חי, שיש בו מורכבות - ניקח את Wix לדוגמה - מאוד קשה להם להתמודד עם כל ה-Code base הזה, מאוד קשה להם להיכנס עם כל ה-Coding Conventions. אבל אם אתה מקטין להם את ה-Scope, אתה אומר “אוקיי אתה לא צריך להכיר את כל Wix, רק תסתכל על הריבוע הקטן הזה - זה הממשק הקטן שלך בתוך ה-Sandbox הזה אתה חי”, אז פתאום החיים שלהם קלים, ואז הם נותנים עבודה טובה.
- (הדר) נכון, וזה משהו שאתה לא צריך לחכות, אתה יודע, את החצי-שנה-שנה-שנתיים-חמש, שזה יהיה במקום הזה.
- ואנחנו מדברים עם הרבה אנשים כל אחד נותן את ההערכה שלו מתי ה-Context Window יוכל להכיל יותר ויותר.
- והיום שמענו על איזה Agent שעושה את זה בכמה Thread-ים, ואז הוא יכול לעשות יותר קונטקסט וכל מיני כלים שעשו.
- אגב, יש איזה כלי מאוד מעניין עכשיו שמעתי שבתוך Wix מפתחים אותו אז זה מעניין . . .
- אנחנו באים ואומרים “אוקיי, אבל למה לחכות?”
- את הקומפוננטה ה-Scoped, החצי-מסך, הבאנר, הכמה דפים, ה-Form הזה שאני צריך, התת-אפליקציה הזאת . . . - זה עושה מעולה היום.
- ואם אני אחבר את זה ואתן כאן איזשהו פתרון רובסטי, Type-safe - עם בדיקה בין גרסאות, עם יכולת לשחרר את זה מהר ולתקן את זה מהר - זה יכול היום להיכנס לאפליקציית React ה-Production שלי, לאפליקציית Vue ה-Production שלי.
(רן) כן. דרך אגב, אני חושב שכן יש פה עוד איזה שהוא אתגר שבעיניי הוא לא מפוצח: אז גם אני, כמו הרבה אחרים, משתמש בכלים האלה, ולמדתי שאחד האתגרים הכי גדולים זה לבוא ולהגדיר את ה-Interface-ים. כלומר, לבוא ולהגדיר את דרישות המוצר, לבוא ולהגיד “הנה - תשתמש בזה, אל תשתמש בזה, תחשוף את הממשק הזה, אל תחשוף ככה” . . . לבוא ולתת פידבקים. וכדי לדעת לעשות את זה בצורה טובה, צריך איזה שהם כישורים הנדסיים.
כלומר, אני חושב שאותם אנשים, שאין להם את הרקע ההנדסי - ופה אפילו לכאלה שיש להם רקע הנדסי משמעותי, יכול להיות להם אתגר. אז אני חושב שעדיין יש פה איזשהו Scarcity של Skill של Engineering, כדי לייצר פה קומפוננטות (Components) כאלה שהן עובדות נכון.
- (הדר) אז זה ממש נכון - וזה יתחבר לנו בצורה מאוד מאוד טובה למה שהתחלנו איתו: איך אתה מגדיר חוזה מול מה שקראתי לו “כל חתיכת UI”?
- ה-Dashboard שלנו היום והפלטפורמה שלנו היום יודעת, בהינתן Output כזה שהבן אדם שכתב - יותר טכני, פחות טכני - יודעת לבוא ולבקר את החוזה הזה.
- לבוא ולהגיד “תראה, בגרסה הקודמת היה API כזה וכזה - שברת אותו”.
- “בגרסה הזאת מוצעות עכשיו עוד כמה וכמה יכולות - אתה רוצה להשתמש בהן?”
- וככה אנחנו בעצם יכולים לעשות איזושהי רמה של ולידציה (Validation) ראשונית, שלא שברת את הממשק.
- אנחנו יודעים לזהות שם את ה-Type-ים, מה שדיברנו, את ה-Prop-ים הנכנסים, היוצאים,Ref-ים.
- השלב הבא של הדבר הזה - ואז אנחנו ממש עובדים וחושבים עכשיו איך נעשה את זה - זה להיות מסוגלים לקבל Prompt פשוט, ואוטומטית ליצוק לתוכו את כל ההבנה.
- זאת אומרת, לבוא ולהגיד אנחנו מבינים שזה הולך להיטען ב-Run-time, אנחנו מבינים שזה צריך לנהל API, אנחנו מבינים שזה צריך לעמוד בסטנדרטים כאלה וכאלה וכאלה . . . .
- אולי אנחנו מכירים את ה-Pattern-ים שקורים אצלך בארגון - ונמליץ את זה למנוע, בתוך ה-Prompt שלנו.
- אז זה גם מה שאנחנו עכשיו מסתכלים עליו, בוחנים אותו - איך התוצר של זה אל מול “החופש”: פשוט לך ל-Gemini, Claude, GPT ותן לי את ה-Output.
(רן) כלומר, אתם לא רק מייצרים את ה-Framework שאליו מזריקים את הקומפוננטות, אלא אתם עוזרים - אתם ה-Mediators לייצור הקומפונטות. אתם באים ואומרים “אוקיי, אתה רוצה להשתמש ב-Lovable, Base44, Gemini או Claude Code - תשתמש”. אתה יכול לשחק חופשי, אבל אתה גם יכול לקבל את העזרה מאיתנו - ואנחנו נעזור לך לייצר קומפוננטות שעובדות יותר טוב איתנו.
- (קרן) בדיוק. האמת שזה בגלל שאחרי שדיברנו עם באמת לא מעט אנשים, הבנו שזה לא מפתיע - שהקושי הוא באמת באיך ניגשים לזה, ואיך בונים, ואיך עושים את זה נכון.
- וכאילו זה “לכתוב Prompt” - זה יותר מורכב ממה שזה נשמע . . .
(רן) “תעשה את זה יפה”, כן . . . “תעשה את זה יפה” זה לא מספיק - צריך להסביר מה זה יפה.
- (קרן) בדיוק - ותקליט לו גם, כי למי יש כוח לכתוב?
34:32 ה-ActiveX Strikes Back / אם אתה פותר בעיות שאף פעם לא ראית לפני זה, אז אתה לא עושה את האנלוגיה הנכונה
(אורי) אני יכול להגיד משהו, כנציג “שיער אפור”?
(רן) אתמול התגלחתי, אז לא רואים . . .
(אורי) כן . . . אתה זוכר, רן, את תחילת שנות האלפיים?
(רן) נניח, כן . . . זורם.
(רן) כן, כן - קראתי איזה ספר . . .
- (הדר) אפילו אני עוד מכיר . . .
(אורי) כן, אז הנה - פחות שיער . . . כל הנושא של טעינה ב-Run-time וייצור קומפוננטות וכל הדברים האלה - זה אחלה שיעור היסטוריה. אני בתחושה שהיסטוריה חוזרת בשיחה הזאת.
אז יכול להיות שיש הרבה פתרונות, שמתחבאים שם בשיעור היסטוריה.
- (הדר) אני חושב שכאילו . . . . אני מצד אחד יכול להתחבר למה שאתה אומר.
- מצד שני, אני חושב - ואנחנו מדברים על זה גם הרבה - שהפתרונות האלה, הפתרונות כמו ActiveX או היה Silverlight בזמנו, היה כל מיני דברים כאלו - הם באו לפתור כאב אחר, שאם שאלנו למה עכשיו, אז הוא כבר פתור היום - וזה המגבלות של ה-Frontend.
- אנחנו לא באים להגיד “React לא טוב”, “Vue לא טוב” או “ה-Output של Lovable לא טוב”.
- איך אני מחבר בין הדברים?
- ו-ActiveX, לצורך העניין, הוא בא ואמר “אני לא יכול לעשות הכול בזמנו ב-HTML ו-JavaScript, אז בוא ניתן לך להריץ אובייקטים מורכבים יותר, Native-יים בתוך ה-Browser”.
- אני רואה את זה כמשהו קצת אחר . . .
- זה עוד לפני ה-Browser-ים זה עוד על ה... כאילו, ממש על התכנות ה... אתה יודע, היית מראה אפליקציה, ואז מביא “מהיקב ומהגורן“ ערימות של DLL-ים - שהיו מכילים בעצם את ההשלמות.
(רן) אתה מחפש את MFC, נכון? MFC זו המילה שאתה מחפש . . . זאת אומרת, קודם כל, אני דווקא חושב שזה מעודד, שהבעיות חוזרות על עצמן - רק בטכנולוגיה אחרת. אנחנו חיים בגל-סינוס וטוב לנו ככה, אז זה בסדר. אז בוא נגיד - זה לא מה שהיה מפחיד אותי.
אבל כן - אני חושב שבוא נגיד שאם אתה מחפש פתרונות מהעבר ומנסה להפעיל אותם על ההווה או העתיד, בוא רק תוודא שעשית את האדפטציות (Adapt) הנכונות . . .
(אורי) ברור . . .
(רן) . . . אבל עצם זה שזה חוזר על עצמו - אני חושב שזה דווקא בסדר. זה “בדיקת-שפיות” כזאת. בוא נגיד, אם
אתה פותר בעיות שאף פעם לא ראית לפני זה, אז או שאתה לא עושה את האנלוגיה הנכונה או שאתה קצת הוזה. עכשיו, מדי פעם אתה אולי צודק - “אחת ל” יש המצאת iPhone . . . זה קורה. אבל רוב הזמן לא - רוב הזמן זה דברים שקרו גם לפני זה.
וואו איך גלשנו שם לפילוסופיה . . .
(אורי) לגמרי . . .
37:15 אז איך מתחילים?
(רן) טוב, קודם כל - אנחנו ככה לקראת סוף הזמן שלנו, אז רציתי לבוא ולהגיד תודה רבה, ואולי עוד כמה מילים על החברה? בעצם, אמרתם שאתם כיום שלושה, נכון? או שכבר גדלתם?
- (קרן) גדלנו. אנחנו שלושה Co-Founders, אבל כבר יש לנו - גייסנו צוות ולקוחות ראשונים ואנחנו גדלים.
- מחפשים חברות אמיצות שרוצות לקחת AI לProduction -
I dare you.
(רן) מה נדרש מהם לעשות אם הם רוצים לבוא ולהתחיל לעבוד איתכם?
- (הדר) אז זה ממש ממש פשוט - בעצם אנחנו מציעים איזושהי פגישה, שבה אנחנו פשוט לוקחים קומפוננטה, בוחרים קומפוננטה, פתוחים לכל Stack של הלקוח.
- וב-20 דקות עד 40 דקות מכניסים קומפוננטה מחוץ ל-Build שלו אל תוך המוצר ב-Production.
(רן) כן, כשאתה אומר “קומפוננטה” (Component), אתה מדבר על משהו ש”חי ב-Browser”. כלומר, לא מטפלים ב-Backend ואחרים?
- (הדר) נכון - UI, SSR גם - אפשר לדבר על זה - אבל UI כן.
(רן) לא Mobile. זאת אומרת, לא Native Mobile - ווביי (Web).
- (הדר) נכון.
(רן) בסדר גמור. נשמע כמו אתגר ראוי וכיפי - שיהיה בהצלחה!
- (הדר, קרן) תודה רבה.
38:30 פרק 500 קהילתי - שלחו את ה-Mp3 שלכם!
(רן) ושנייה לפני שאנחנו מסיימים - כהכנה לפרק 500 הממש-ממש קרוב אלינו, אנחנו רצינו לעשות משהו מיוחד.
אז מה שאנחנו מבקשים מכם, המאזינים, זה לשלוח לנו משהו קטן - ותיכף נגיד לכם מה זה - משהו קטן אלינו.
אנחנו ניקח את ה-Input שלכם ונקמפל את זה לפרק שלם, ובטוח שיהיה מעניין.
(אורי) אני רק מקווה שישלחו לנו, כן?
(רן) כן . . . אז מה אנחנו מבקשים?
(אורי) אז שלחו לנו דברים, לפי הנושאים הבאים: נגיד, אתם יודעים - אנחנו מקליטים כבר 17 שנים. זה די היסטוריה רחוקה, והרבה דברים קרו. ואנחנו יודעים שיש לנו מאזינים שמאזינים לנו הרבה זמן - אז דברים כמו למשל משהו מעניין או מצחיק שקרה לכם בעקבות פרק של רברסים.
(רן) אז דוגמא אחת - שוב אני אומר: לשלוח לנו MP3! נגיד -
- משהו מצחיק שקרה לי ו-1,2,3 - תספרו.
- 30 שניות, דקה - אפשר גם פחות.
- ותשלחו לנו לאימיילים שלנו - Ran-at-Reversim ו-Ori-at-Reversim.
(רן) אז דוגמא אחת זה משהו מעניין או מצחיק שקרה לכם בעקבות הפרק
- דוגמא אחרת - מה למדתם מאחד מהפרקים? משהו מעניין שלמדתם שלא הכרתם לפני זה
- (אורי) או למשל מה הפרק שהכי אהבתם - ולמה?
- (רן) או שאלה אחרת - מה זה רברסים בשבילכם? וזה בסדר גם לדבר על טרקטורים ופלטפורמות . . .
- (אורי) נכון . . .
- (רן) מה המשמעות? “רברסים” - מה המילה, מה השם הזה אומר לכם?
- (אורי) והשאלה הכי פרובוקטיבית פה -האם החלפתם עבודה בעקבות פרק של רברסים?
- (רן) ספרו לנו . . .
(רן) אז כן - נשמח אם פשוט תשלחו לנו קבצי mp3, הקלטה של כמה שניות עד 30 שניות. אפשר גם קצת יותר, זה בסדר.
ניקח את כל זה, נקמפל לפרק - ויהיה פרק קהילתי: הפרק הקהילתי הראשון בתולדות רברסים ובעולם, נניח . . .
(אורי) פרק מספר 500 . . .
(רן) אז תודה רבה! מצפים מאוד לשמוע מכם, להתראות.
האזנה נעימה ותודה רבה לעופר פורר על התמלול!
