474 Uniclient - cross platform UI with Shay Davidson, Lemonade

רברס עם פלטפורמה

[קישור לקובץ mp3]

פרק 474 של רברס עם פלטפורמה, שהוקלט ב-9 ביולי 2024. אורי ורן מארחים במזגן את שי דוידסון מחברת Lemonade כדי לדבר על פרויקט מעניין שהוא עבד עליו שנקרא UniClient - איך הוא נולד, מה עושים איתו ולמי זה עלול להתאים. השיחה היום היא סביב עולם ה-Frontend ועולם התשתיות של ה-Frontend.

00:51 קצת על שי ועל Lemonade

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

• (שי) יש שתיים . . . יש את In a galaxy far, far away [A procedural generation tale] ואת ה-Board Games Frontend Joyride, על פיתוח משחקי קופסה באמצעות טכנולוגית Web.

(אורי) זוכר באיזה שנים של הכנס? . . .

• (שי) 2019 ו-2021.

(אורי) רק אומר כמה שנים אנחנו עושים את הכנסים האלה . . . . [גם על זה יש הרצאה . . . The Reversim Story / Ran Tavory & Ori Lahav].

(רן) אז לגמרי, לגמרי . . . הרצאות שאני ממש זוכר שהייתי [בהן], לפחות בזאת עם הגלקסיות, והיה ממש כיף - אז מומלץ, לכו צפו.

אבל עכשיו, שנייה לפני זה - שי, כמה מילים עליך?

• (שי) אני בן 39, בתעשייה כבר 15 שנה - התחלתי בתור מפתח משחקים חובב, אחר כך פיתחתי משחקי-Flash בצורה מקצועית.
• אחר כך גויסתי כ-Full-Stack ב-eBay, במעבר ל-PayPal ניהלתי צוות Mobile iOS, וגם קצת Web.
• וב-2019 עברתי ל-Lemonade, שם גם הייתי מפתח Full-Stack, ניהלתי צוות, קודמתי ל-Principal Engineer והובלתי את הגילדה של ה-Frontend בשנתיים וחצי האחרונות.
• היום אני כבר לא מוביל את הגילדה, אבל עדיין מעורב בתהליכי Frontend - ובתהליכי Mentoring, למידה, פרויקטים ואכיטקטורה.

(רן) “Frontend” - זה Web ?Mobile? הכל?

• (שי) Web בעיקר.
• יש לנו גם צוותי Mobile בנפרד, שנדבר עליהם עוד מעט.

(רן) מעולה, תודה. אז Lemonade - אני בטוח שהרבה מכירים, אבל למי שלא, מה עושים שם?

• (שי) Lemonade זו חברת InsurTech, שקמה ב-2016. רוב ה-R&D נמצא בתל אביב ובאמסטרדם
• ואנחנו משווקים מוצרי-ביטוח משלל סוגים - דירה, חיות מחמד, חיים, רכב - בארצות הברית ובאירופה.
• ובעיקר, רוב החוויה שלנו היא Consumer-Facing, כלומר - איך אנחנו לוקחים את תהליך קניית הביטוח, שתמיד נשמע משעמם ומורכב, ואנחנו מנגישים אותו והופכים אותו ל”מגניב”.
• “ורוד ולבן ומלא אנימציות”, ואקססיבילי (Accessible) למשתמשים שקונים ביטוח.

(רן) כלומר, לא “Wobi” . . . תחשבו על חדי-קרן או דברים קסומים כאלה . . .

• (שי) משהו כזה . . . כלומר, אתה קונה ביטוח לכלב שלך, ופתאום קופץ לך כלב מתוך ה-Input, ומסבירים לך בצורה ממש טובה את מה שאתה קונה.

03:10 חוויית המשתמש

(רן) יפה, זאת אומרת, חוויית המשתמש היא משמעותית - אולי אפילו קריטית - להצלחת המוצר.

• (שי) כן - ועד לאחרונה, בעצם, רוב החוויה שלנו הייתה לא רק דרך ה-Web, אלא גם דרך ה-Mobile.
• היו לנו שני מוצרים שדרכם המשתמשים יכלו לקנות ביטוח - וגם להגיש תביעות - אבל הם היו שונים במהות שלהם.
• היית נכנס דרך ה-Web - היית רואה Flow מסוג אחד,
• היית נכנס דרך ה-Mobile - היית רואה Flow מסוג אחר.
• אמנם במהות, בסופו של דבר, היית יכול לקנות פוליסת ביטוח - אבל הם היו נראים שונה.
• ה-Stack שלהם היה שונה - יש לנו Stack גם IOS-י וגם Stack Android וגם Stack Web-h.
• וגם הוא דורש קצת עבודה פרודקטית נרחבת - כי כל Product Manager צריך עכשיו לחשוב שלוש פעמים איך הוא בונה את ה-Flow הזה.
• תוסיף לזה עיצוב . . . . זה נהיה קצת מורכב.

(אורי) ולפעמים זה לא אותו ה-Product Manager . . .

• (שי) בדרך כלל זה אותו ה-Product Manager, אבל בגלל שהפרדיגמת-פיתוח וגם הפרדיגמות-עיצוב וה-Design System גם היו מאוד שונות, אז בעצם כשאתה משיק מוצר חדש . . . אתה צריך לפתח אותו שלוש-ארבע פעמים.
• וזה . . . זה די מורכב - ויוצר גם חוויות לא קונסיסטנטיות (Consistent).
• למשל, פתאום מתןך צורך של השקה בזמן, אנחנו מחליטים לא להשיק חלק מהמוצר ב-Web או ב-Mobile.
• למשל, אפילו עד היום, תביעה אפשר להגיש רק דרך אפליקציות Mobile, לא דרך ה-Web - מהסיבות האלה בדיוק.

(רן) האמת שאני זוכר גם מימי . . . פעם פיתחתי כמה אפליקציות ב-Mobile, ובימים האלה היינו בוחרים את אחת הפלטפורמות להתחיל בהן - נגיד בוחרים ב-Android או בוחרים ב-iOS קודם - “ורצים עליה”, חצי שנה, לפעמים שנה - עד שמרגישים “מספיק טוב”, ואז בונים לפלטפורמה השנייה.

• (שי) נכון, וגם ברגע שאתה מרגיש “מוכן”, לבנות לפלטפורמה השנייה זה תהליך - ולא תמיד הכל הוא Streamlined ופשוט כמו לפתח ל-Web או לא תמיד הכל מהיר ונחמד כמו ב-iOS או באנדרואיד.

(אורי) אני חושב, אבל, שכשאתה מפתח - בין אם ל-Android או ל-iPhone או ל-iOS - זה לא כזאת בעיה, כי בן אדם - יש לו את אחת . . . הוא Either / Or. אבל Web או אחת הפלטפורמות - פעם אני משתמש מהמחשב, פעם אני משתמש מהטלפון, ואני רואה שתי חוויות שונות לגמרי או בכלל סט פיצ'רים אחר לגמרי - וזה כבר בעיה.

• (שי) נכון, כן.

05:44 אותו מקרר בגישה כל כך שונה

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

• (שי) בדיוק

(רן) . . . וזו בעיה שאני בטוח שהרבה חברות, שהן Consumer-Facing, מתמודדות איתה.

אוקיי, אז איך טיפלתם? היה איזשהו אירוע משמעותי ששינה את הגישה ראשון?

• (שי) אני חושב שלאורך תקופה, מאז שהצטרפתי ל-Lemonade ב-2019, תמיד ניסיתי לאתגר את הגישה הזאת של “למה אנחנו צריכים בעצם חוויה שונה?”.
• ובשנה שעברה, במאי, עשינו האקטון בחברה - ועשינו ניסוי.
• הייתי בצוות שבעצם ניסה לקחת את החוויה ה-Mobile-ית שלנו - ולפתח אותה רק באמצעות טכנולוגיית Web
• סיימנו את זה, נתתי את זה לאחד ה . . .

(רן) “טכנולוגיית Web” - כלומר WebView, React . . .

• (שי) TypeScript, React, ו-CSS בלבד - בלי Ionic, בלי React Native, לא טכנולוגיות Cross-Platform מוכרות, אלא Web בלבד.

(רן) פשוט WebView בתוך האפליקציה.

• (שי) WebView בלבד, כן.
• ונתתי ל-Founder של החברה - לשי וינינגר, אם אתם מכירים - לשחק איתה
• והוא מאוד מאתגר תמיד על עיצוב וחוויית משתמש והוא שם לב כל פרט קטן - ווואלה, הוא לא שם לב להבדל.
• מבחינתו, זו הייתה חוויית Native.
• וככה בעצם התחלנו להתניע את הפרויקט הזה, ואמרנו, אוקיי - אנחנו הגענו לאיזשהו Maturity, יש לנו ארבעה Product Lines בחוץ כבר שנים.
• איך אנחנו עכשיו מאפשרים לעצמנו להשיק מוצרים ולתמוך במוצרים בצורה הרבה יותר מהירה - בלי לתמוך בשלושה Stack-ים שונים?

(רן) דרך אגב, אני חייב להגיד הערת-אגב - ה-Maturity היא לא רק שלכם . . . זאת אומרת, בעבר, גם ה-Device-ים עצמם לא היו מספיק Mature כדי לספק כזו חוויה. זאת אומרת, אני זוכר, כשאני ניסיתי לייצר איזשהו WebView עם טכנולוגיות Web, היה Jitter והיו כל מיני אפקטים מאוד לא נעימים, שפשוט באיזשהו שלב אמרנו “אוקיי, זה לא יעבור קהל”. זאת אומרת, הטכנולוגיות לא בוגרות, לא מוכנות לזה עדיין - וזו “קריעת תחת” לנסות לעשות את זה שיהיו מוכנות, אז פשוט הולכים על Native.

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

• (שי) אני מסכים לחלוטין - ואני חושב שדווקא הקידמה הכי גדולה קרתה בתחום שאולי ישמע הכי איזוטרי, אבל זה CSS . . .
• כאילו, גם כשדיברו על טכנולוגיות Web ועל Cross-Platform בעבר, אז תמיד דברו על React Native
• ויש את המאמר המוכר והידוע-לשמצה של Airbnb מ-2018, על איך שהם “נשרפו” על React Native
• ואנשים חושבים אולי על PhoneGap, מלפני עשר שנים, ותמיד כשחושבים על חוויות Web בתוך Mobile, מדמיינים את ה-Software Keyboard קופץ וה-Header ושום דבר . . . .
• וה-Scroll מסתבך . . .
• היום, עם CSS מודרני, הדברים האלה לא קורים יותר.
• יש ממש, Properties ו-Features בתוך CSS, שאומרים “אנחנו יודעים שאתם רוצים להיות בתוך Mobile Screen, איך אנחנו מאפשרים לכם לייצר חוויה, שמרגישה Native-ית”.
• ואם זה בתמיכה בגדלי-מסך שונים, ואם זה באנימציות.
• וגם בכל מיני ספריות, כמו Framer Motion, שמאפשרות לייצר אנימציות שמרגישות הרבה יותר Native-ית וטבעיות, למשל.

(רן) כן. אז איתגרת את הגישה הזאת, ואמרת “זה לא חייב להיות ככה!”. עשית איזשהו Prototype, שי הסתכל על זה, היה בסדר . . .

• (שי) הוא לא יודע בכלל שזו חוויית-Web - ואמר “זה מרגיש כמו Native - בוא נעשה Leap of Faith וננסה לקחת הפרויקט של זה קדימה”.
• ונרים פלטפורמה, שתאפשר לנו לבנות מוצרים על גביה, בעצם ב-Stack טכנולוגי אחד.
• שהוא Web-י לחלוטין - לא React Native, כי ב-React Native עדיין צריך לתמוך בשני Stack-ים שונים.
• כי הפרדיגמת פיתוח ב-React Native, למשל היא “אוקיי, הנה האפליקציה של React Native - אמנם אנחנו מפיקים Artifact-ים עבור iOS ו-Android, אבל לא עבור Web”.
• ואמרנו שאנחנו רוצים לאתגר גם את זה - אנחנו רוצים שיהיה לנו פשוט Stack אחד, TypeScript, React . . .

(רן) כן, React Native אולי מגשר על הפערים בין iPhone ל-Android - אבל הוא לא מגשר על הפערים בין Mobile ל-Web.

• (שי) בדיוק.

10:03 מה אתה עושה כשאתה קם בבוקר? CSS.

(רן) אוקיי - אז מה? כאילו, פשוט קמת בבוקר ואמרת “אוקיי, עכשיו יש לי תפקיד חדש בחברה! זה מה שאני עושה!”.

• (שי) אז אני לא בהכרח הייתי חלק מהצוות הזה, שפיתח את הפלטפורמה - אבל הפרדיגמת-פיתוח הייתה כזאת:
• אנחנו אומרים - ה-Stack הוא Web-י לחלוטין, וכמובן שהתחלנו לעשות מחקר קודם כל.
• האם יש איזשהו Framework שיעזור לנו לפתח את זה, ושבעצם תומך בכל האפשרויות.
• כי אנחנו עדיין רצינו לשמר את האפליקציית Mobile שלנו - יש לנו אפליקציית Mobile עם הרבה Feature-ים, ועכשיו לשכתב את כולם עם ה-Stack החדש זה תהליך ארוך . . . .
• זה יכול לקחת - הערכנו את זה כשנתיים אפילו, זה מוגזם.
• אז אמרנו, אוקיי - זה פרויקט שהוא לא יכול להיות Greenfield.
• שזה משהו שהוא מאוד חשוב - כי אם היינו עושים Greenfield, אולי היינו בוחרים טכנולוגיה אחרת לגמרי.
• ואנחנו צריכים שבעצם יהיה לנו איזשהו WebView בתוך האפליקציה, שיכול לטוען את הפלטפורמה החדשה הזאת, ושהיא תרגיש Native-ית.

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

• (שי) בדיוק.

(רן) כן, אוקיי - אז בואו רגע נחזור אחורה. אמרת שיש כמה תכונות חדשות ב-CSS, שבעצם מאפשרות את השינוי הזה. אולי נדבר על כמה מהן? מה עם הדברים האלה?

• (שי) אחלה. אז קודם כל, יש Units, כש-CSS Units זה בעצם מה מאפשר לנו לדגום, למשל, 100% מגודל המסך, או 100% מרוחב המסך.
• יש Units חדשים שמאפשרים לנו להתחשב בפרמטרים של המסך - עם Header מסוים, עם Scroll board מסוים, עם דברים שמתאימים . . . . עם Software Keyboard למשל.
• דברים שלא היו אפשריים עד היום, באפליקציות Mobile - סליחה, בחוויות-Web שרצות בתוך טלפון.
• אז יש אפשרות לדגום את הדברים - ובעצם להגיב לשינויים בגודל של המסך בצורה הרבה יותר טובה.
• זה דבר אחד.

(רן) כשאתה אומר “Units”, אתה מתכוון ל-Pixel-points? אחוזים, אבל עכשיו יש קצת יותר מזה. איך קוראים להם?

• (שי) בדיוק. אני לא זוכר בדיוק את השם שלהם . . . עד עכשיו היה 100 VW, כשלמשל זה 100% מגודל המסך
• אבל יש עכשיו 100 IVW, אם אני לא טועה . . . . כנראה שאני מתבלבל, אבל לא זוכר את זה היטב, אבל בעצם הוא מאפשר לדגום חלקים אחרים בתוך המסך, שהם יותר מתאימים לגודל של מסך Mobile, למשל.

(רן) כן, הבנתי - וזה עובד Cross-Device?

• (שי) זה עובד Cross-Device, כן.
• ואם אתה נכנס ל-”Can I use”, אתה רואה שכל הדפדפנים תומכים את זה.
• כלומר, ה-Backwards Compatibility מאוד מאוד חשוב פה, מבחינת הדפדפנים - כי כאמור, אנחנו לא רק צריכים לתמוך ב-WebView בתוך Mobile, אנחנו רוצים גם לתמוך בחוויית Mobile-Web ו-Web Desktop רגילה, אז לכן אנחנו חייבים גם לתמוך בכל הדפדפנים.
• אז גם אם יש Feature חדש של CSS, אנחנו חייבים לוודא שהוא נתמך בכל הדפדפנים המודרניים.

(רן) כן . . . ולמי שלא איש Frontend - סליחה אורי - למי שלא, איש Frontend, אז Can I use זה אתר מאוד מאוד

שימושי, שמראה איזה פיצ'רים נתמכים באילו פלטפורמות, כולל דפדפנים - אז אפשר לדעת עד כמה בטוח הפיצ'ר הזה.

(אורי) והשאלה שלי היא לא רק דפדפנים - אלא גם הוורסיה (Version) של המכשיר . . .

• (שי) נכון, שזו נקודה מאוד טובה - כי בעבר, במיוחד סביב גודל המסך, מספיק ש-iOS שדרגו מ-iOS 7 ל-8
• ואז פתאום יש פיצ'רים חדשים סביב המקלדת, או שאולי הם שינו קצת את ה-Header בשלושה פיקסלים - ופתאום הכל נשבר.
• ולכן ה-CSS Properties, ה-CSS Units שדיברנו עליהם - הם יודעים להתעדכן, הם אגנוסטיים (Agnostic) לגרסת ה-iOS שאתה משתמש בה, כל עוד המערכת הפעלה יודעת להגדיר אותם היטב.

(רן) כן, אז אם אתם עושים את האבסטרקציה (Abstraction) הנכונה, אם תשתמש ב-Units האלה בצורה קונסיסטנטית (Consistent), אז אתה אמור להיות מגובה.

• (שי) כן, בדיוק.

13:54 עוד דוגמאות

(רן) אוקיי, אז Units זה דוגמה אחת - יש עוד כמה דוגמאות?

• (שי) יש עוד כמה דוגמאות, שהן אולי לא בהכרח מעולמות ה-CSS הקלאסיים, אבל אנחנו משתמשים בספרייה בשם framer/motion, שהיא עושה אבסטרקציה לאנימציות מאוד מורכבות, שמרגישות מאוד Native-יות.
• אנחנו עכשיו גם מתחילים לחקור את העולם של View Transitions, שזה בכלל Cutting Edge
• כש-View Transitions מאפשרים לעשות בעצם Rasterization לחלק מה-DOM, ואז להגיד “אה, אני טוען את המסך הבא - בוא תנסה לעשות לי Transition שמרגיש כמו Native Transitions”, למשל, שהיו לנו לפני אפילו עשר שנים.

(רן) נראה לי שדרוש פה קצת תרגום . . . אז Rasterization זה בעצם לקחת “סוג של צילום מסך”, ולהראות את ה-DOM כתמונה?

• (שי) אני אתן שנייה דוגמא אולי יותר מפורטת - נגיד שאני עובר או רוצה לעבור בין עמוד אחד, עמוד HTML אחד, לעמוד שני.
• היום ב-Web, אני לא יכול. כלומר, המסך נהיה לבן לרגע, ואז אני טוען אותו.
• (רן) כן, אתה רוצה ליצור איזושהי אנימציה של מעבר . . .
• (שי) בדיוק, כמו שכל אפליקציית iOS או Android היו מאפשרות לנו, אפילו לפני 15 שנים.
• (רן) Slide כזה ו...
• (שי) בדיוק. היום View Transitions מאפשרים לקחת מסך - נגיד שאני מייצר Snapshot שלו - לשים אותו על ה-DOM, על הדפדפן, ולהריץ עליו CSS Animations רגיל, שאנחנו מכירים כבר עשר שנים.
• (רן) כן, ולסיפור הזה אתה קורא Rasterization, כן? זאת אומרת, לקחת Snapshot, ואז להזיז אותו, לעשות לו Slide ימינה, שמאלה, ולחשוף את המסך הבא.
• (שי) נכון. וView Transitions היום נתמכים כבר ב-Chrome, וזה פשוט כמה CSS Properties ששמים על אלמנט, וזה פשוט עובד ”Magically”.
• (רן) כן. לגמרי.
• (רן) אז אני בטוח שכל מי שנגיד משתמש iOS מכיר את זה, את החוויה הזאת - וברגע שנכנסים נגיד לאיזשהו תפריט, רוצים לחזור, אז יש איזשהו Slide כזה הצידה, וזה יהיה מוזר לא לראות את זה בתוך האפליקציה.
• (שי) נכון.
• (רן) ולכן זה חשוב.

15:32 על Showstoppers ו-Milestones

(רן) כן. אוקיי. אז זאת אומרת - התחלתם באיזשהו שלב של מחקר, של לראות מה בכלל אפשר לעשות, אחרי ה-POC הראשוני הזה. נתקלתם באיזשהם Showstoppers? גיליתם משהו שאולי ככה...

• (שיי) כן. כמו שאמרתי קודם, אני חושב שהאספקט של “האם זה Greenfield או לא?” היה מאוד מהותי עבורנו.
• כי אם היינו בוחרים פרויקט Greenfield - כלומר, לשכתב את כל האפליקציה מחדש - אז זה כנראה היה Showstopper, מבחינת זמנים.
• זה היה מאוד מקל על הפיתוח שלנו, כי היינו בוחרים פרויקט כמו Capacitor, של חברה בשם Ionic, שהוא פרויקט Open Source.
• שאומר “אנחנו מנגישים עבורכם את כל היכולות שאתם רוצים לחבר בין ה-WebView שלכם לבין האפליקציה”.
• למשל, אני רוצה לפתוח Apple Pay - אז אני יכול לעשות קריאה דרך האפליקצית-Web שלי, קורה משהו בפנים, באמצעות Post Message, איזשהו Event שה-Web תומך בו, ואז אנחנו יודעים להגיד לאפליקציה “תפתחי Apple Pay!”, או אולי “תפתחו את ה-Accelerometer!” או אולי “תפתחו Photo Collection!” . . .
• בהינתן שלא בחרנו בסוף להשתמש ב-Framework שכזה, היינו צריכים לעשות את ה-Bridge הזה בעצמנו, בתוך האפליקציה.

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

• (שי) בדיוק, כן.

(רן) . . . כי בדרך כלל, Framework-ים - יש להם כל מיני הנחות-מוצא, יש להם כל מיני דרישות, והרבה פעמים קשה לספק אותם בתוך אפליקציה שכבר “חיה”.

• (שי) נכון.

(רן) אוקיי, אז עשיתם את זה, ואז פשוט התחלתם “להחליף מסכים בתוך האפליקציה”? כלומר, מה היה ה-Milestone הראשון?

• (שי) קודם כל התחלנו, הרמנו איזשהו Mono-Repo אחד גדול, שהיה בו Design System חדש והייתה פה פלטפורמה חדשה.
• והעברנו את המנגנון Chat שלנו פנימה, בעצם כדי לכתוב את כל החוויות סביב איזשהו מנגנון Chat קיים.
• והתחלנו בעצם לממש קומפוננטות (Components) ולממש את האינטגרציה (Integration) בין ה-Mobile ל-Web.
• בנינו צוות שמורכב גם ממפתחי Frontend מאוד חזקים וגם ממפתחי Mobile, שעזרו לנו לבנות את ה-Bridge הזה, בתוך Android ובתוך iOS בנפרד.

17:33 הצד האנושי של הגבינה

(רן) כן, אז בואו באמת נדבר על הצד האנושי יותר. כמה אנשים עבדו על הפרויקט הזה?

• (שי) מפתחי Frontend עבדו בהתחלה, בשלב ההקמה הראשוני, כשלושה אנשים - ועוד מפתח Mobile אחד מכל סוג.

(רן) אוקיי, ואותם מפתחי Mobile, סליחה על השאלה, לא הרגישו קצת מאוימים? כלומר, לא מרגישים כאילו אתה “מזיז להם את הגבינה” / לוקח להם את העבודה?

• (שי) האמת שזו שאלה מעולה . . . היה חשש מאוד גדול סביב זה.
• כלומר, איך אנשים יקבלו את זה.
• ואפילו עשינו שיחה - שמנו את כולם בחדר [זה נשמע מרגיע…], ועשינו שיחה סביב הדבר הזה, כי היה ברור שזה יעלה חששות.
• עדיין יש לנו צורך במפתחי Mobile בחברה, בלי שום קשר לפרויקט הזה.
• אנחנו עדיין תומכים בהרבה Flow-ים של Mobile, יש עדיין פיצ'רים שאנחנו רוצים לתמוך בהם, שנתמכים רק Native-לי ב-iOS וב-Android, ומן הסתם אנחנו רצינו לשמר את הצוות הזה.
• למרבה ההפתעה, הרבה מפתחי Mobile רצו לעשות Transition לפיתוח Frontend.
• כלומר, יש לנו היום שני מפתחי Mobile שהיו מפתחי iOS, והיום הם עוזרים בפיתוח הפלטפורמה כמפתחי Frontend לכל דבר.

(אורי) יש גם איזשהו Feature כזה של מפתחים - שהם לא אוהבים לעבוד קשה. מה בעצם הצעת להם? הצעת להם לעשות פחות עבודה . . . לא לעשות את העבודה עוד פעם ועוד פעם.

• (שי) זו נקודה טובה . . .

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

• (שי) אני לא יודע אם להגיד שהיא לא מקדמת את המוצר זה מדויק, כי בסופו של דבר כן השקענו מאוד, בתור Lemonade, בליטוש החוויה - גם ב-Mobile וגם ב-Web.
• ונכון - זה עלה בהרבה זמן של כוח אדם, וכאמור לא רק פיתוח - Product Manager-ים צריכים להגדיר את זה היטב, מעצבים צריכים לעצב את הקומפונוטות (Components) מחדש עבור כל הפלטפורמות . . .
• אני חושב שדווקא הם שמחו, בדיעבד, מאיזשהו כיוון אחר - ואני הולך להגיד אולי משהו שנוי במחלוקת בתור מישהו שגם היה Full-Stack Web בתקופה ארוכה וגם ניהל צוותי Mobile תקופה ארוכה -
• זה שפיתוח Web בעיניי הוא הרבה יותר כיף - הרבה יותר מהיר, אתה חווה אותו, אתה חווה את הפידבק בצורה הרבה יותר מהירה.
• ופתאום, כאילו . . . לפתח היום עמוד ב-React זה הרבה יותר פשוט מלפתח אותו ב-SwiftUI ולהשיג את אותה התוצאה.
• ואני חושב שאנשים התאהבו פשוט בטכנולוגיה פתאום - ורואים את זה.

(אורי) כי ה-Feedback-Loop . . .

• (שי) ה-Feedback-Loop הוא קצר, וזה פשוט . . . לפתח את אותו הדבר ב-iOS לוקח פי-שלוש זמן מאשר לפתח אותו ב-Web-י, אם לא יותר.

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

• (שי) כן.

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

• (שי) אז זו נקודה טכנית מעניינת - אנחנו דרך ה-Bridge שלנו, בעצם בכל פעם שאנחנו רוצים לקבל Permission אנחנו עושים את זה דרך ה-Bridge.
• כלומר, אנחנו “מקפיצים את זה” זה דרך האפליקציה בעצם, ולא דרך ה-Web.

(רן) כן, מה שפלטפורמות שונות עושות את זה - כלומר, Ionic שהזכרת ואחרות - הן עושות את זה, אבל אתם

עושים את זה בעצמכם.

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

אז האם עדיין צריך לעבור דרך ה-AppStores?

• (שי) לא. אנחנו לא צריכים לעדכן את ה-AppStores . . .

(אורי) זה מקדם אותך, או מקצר לך הרבה, את ה-Feedback-Loop ל-Data ב-Scale. זאת אומרת, אתה רוצה לדעת אם ה-Feature שלך, אם העדכון שלך, עובד - ועובד טוב - ב-Scale, אז זה “מיידי”.

• (שי) נכון - ולפעמים . . . חלק מהארכיטקטורה של האפליקציות-Mobile היום זה “בוא נעשה Design למערכות שיהיו Server-Driven”.
• למה? כי אם אני רוצה לשנות שדה-טקסט, אז אני אקבל אותו מהשרת ולא דרך האפליקציה.
• כי אולי ייקח לי שלושה ימים עד שאני אצליח לשחרר את התיקון הזה.
• והיום בעולם הזה של UniClient, אנחנו עושים Deploy - ותוך חמש דקות התיקון עולה.
• ואין לנו את הבעיה הזאת יותר.

(רן) אבל אני מניח שגם יש איזשהו Caching. זאת אומרת, כל פעם ה-WebView פונה ל-Server וטוען מחדש?

• (שי) אז בגלל שהאופי של האפליקציות שלנו מאוד דינמי, אז האפליקצית UniClient היא Single-Page Application, והוא מביא מידע.
• כמעט ואין צורך ב-Caching במקרה הזה.
• כלומר, ל-HTML שאתה מביא אז כן, אבל ל-Data עצמו לא.

(רן) הבנתי. אוקיי - זאת אומרת, קל לכם מאוד - אלה אם כן אתם רוצים להחליף למסך חדש, שלפני זה היה Native ועכשיו אתם רוצים Web-י - אז קל לכם מאוד לעדכן גרסאות - וזה גם יתרון מדהים.

• (שי) נכון.

(אורי) גם כל הנושא . . . עוד פעם, אני מבין שלושתינו אני ”הכי דביל” פה ב-Frontend . . .

(רן) הוא מעולה בעיצוב! מעצב על!

(אורי) כן, אבל Feature-Flags . . . גם יותר נוח בצורה הזאת.

• (שי) נכון.

(אורי) . . . אם אתה רוצה לעשות Gradual Rollout, לפתוח ל-X יוזרים (Users) . . .

• (שי) כן. גם כי אנחנו ספציפית עם Feature-Flags, אנחנו גם תומכים בהם באפליקציה גם לפני UniClient בצורה מאוד נרחבת.
• כלומר, זה מספיק שאנחנו משנים Flag ואז אנחנו יודעים לטעון את זה בצורה . . . גם באפליקציות.

(רן) כן.

23:16 אז איפה אנחנו היום?

(רן) אוקיי. אז איפה אנחנו היום? איפה אתם עומדים עם זה?

• (שי) אז היום, לקח לנו בערך חמישה-שישה חודשים להביא את הפלטפורמה ל-Maturity, שהיא Production-Ready.
• והתחלנו להמיר את כל הפרויקטים שלנו להשתמש בה.
• בהתחלה פרויקט אחד, והיו לו את ה“חבלי-לידה” מן הסתם, זה לא הרגיש . . .
• היו באגים, היו קומפונטות (Components) שחסרות . . .
• פרויקט אחד הושק - ופתאום הגענו למצב ש . . .

(רן) כשאתה אומר “פרויקט”, דרך אגב, אתה מתכוון לשלוש גרסאות - כלומר, Android ו-Web ו-iOS?

• (שי) בדיוק. למשל, את הביטוח החיים שלנו, שזה ה-Flow הקצר יותר, אמרנו שפשוט להשתמש במערכת החדשה.
• ואז בדקנו באמת שהכל עובד כמו שצריך - וראינו ש”אין מספיק באגים” והכל עובד . . .
• ופתאום “הכל התפוצץ” - כל ה-Product Managers רוצים לעבוד עם המערכת הזאת, כולם מבינים את החיסכון שזה נותן.
• ואנחנו נמצאים באיזושהי תקופה שממש אנחנו משיקים חמישה מוצרים . . . משיקים מחדש חמישה מוצרים שקיימים כבר - בשלושה חודשים. זה מטורף.

24:26 מה אפשר ללמוד מזה? WIITM?

(רן) יפה - מה חברות אחרות יכולות ללמוד מזה? זאת אומרת, האם יש פה Open Source? האם יש פה איזה שהם Best Practices שפרסמתם? מה אני, כמי שלא עובד ב-Lemonade, יכול עכשיו להרוויח מהשיחה הזאת?

• (שי) אז אני חושב שכשבאים וכותבים מוצר שהוא Consumer-Facing, צריך להסתכל האם . . . לחשוב קודם כל האם יש לי צורך באפליקציות Mobile, בכלל.
• אני Advocator של “Web-Only” - אבל בגלל איך ש . . “PWA” זה Progressive Web Apps, למי שלא מכיר, של אפליקציות Web, שפשוט אפשר לשים על המסך הראשי בטלפון, ולהתייחס אליהן כאל אפליקציה לכל דבר.
• ו-Apple לא כל כך אוהבים את זה - ולכן לא בהכרח שווה לכתוב אפליקציות כאלה.

(רן) . . . והן גם לא ב-AppStore . . . יש איזושהי “מהמורה” בדרך להגיע לשם.

• (שי) כן בדיוק. . אין Discovery.
• אבל אם יש צורך לפתח אפליקציות Mobile, צריך לשאול את השאלה קודם כל: “האם יש צורך שהחוויה תהיה שונה?”
• אני חושב שיש כל מיני סטיגמות לגבי WebViews ואפליקציות-Web בתוך Mobile.
• וכאמור - זה “מפעם”.
• אנשים חושבים PhoneGap ועל המאמר הזה נגד React Native מ-2018 - ובאופן כללי יש איזושהי “יוקרה” מסוימת סביב לפתח Native ולא לפתח Web.

(רן) “סכין בין השיניים” . . . “אני כותב קוד Assembler!”, כזה . . .

• (שי) כן . . .

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

• (שי) אני כותב בשחקים ב-TypeScript . . . [זוכרים את Board Games Frontend Joyride?]

(רן) כן. אוקיי . . . . ובכל מקרה, גם אם אתם ב-Native, אז גם שם יש פלטפורמות מצוינות, ולא צריך לכתוב

את הקוד ל-GPU בעצמכם.

• (שי) כן. יש את Three.js, אם אתה רוצה לפתח ולכתוב משחקים - זה עובד מדהים.
• אנחנו השקנו עמודי-נחיתה עם Three.js - וזה פשוט מדהים.

(רן) אוקיי, אז כלומר - קודם כל תחשבו האם אתם . . . האם דרושה לכם חוויה נפרדת ל-Web ול-Mobile.

ואם החלטתי שלא, אז?

• (שי) אם החלטת שלא, אז אני ממליץ על טכנולוגיות שהן Web-Based.
• וזה לא בהכרח חייב להיות עכשיו All-In, כמו שאנחנו עשינו.
• כי אני חושב שזה דורש צוותי Frontend מאוד חזקים - במיוחד סביב העולמות של CSS.
• היום יש איזשהו - סליחה אם אני מלכלך על אנשי ה-Tailwind, אבל אנשים אוהבים להשתמש ב-Tailwind
• וזה נותן הרבה כוח כשמשיקים אפליקציה חדשה - אבל זה לא מלמד אותך CSS . . .

(רן) כן, Tailwind זה CSS-Framework שמאוד מפשט את העבודה.

• (שי) ... וזה פשוט לא מלמד . . . ו-CSS ניהיה בשנתיים האחרונות מדהים.
• כלומר כל שבוע גם אני מגלה משהו חדש.
• ופשוט Tailwind גורם לך לפספס את זה.
• אני חושב שצריך צוותי Frontend, כאמור, שהם חזקים - שיתמכו בלהרים פלטפורמה שכזאת, ואני . . . .
• מוצר חדש - לחלוטין הייתי עושה עם Framework כמו Capacitor, ולא בונה את זה מ-0 כמונו.
• זה פשוט עושה אבסטרקציה (Abstraction) לדברים המוסבכים של ה-Bridging בין ה-Mobile Application ל-WebView, ואין צורך לכתוב את זה מחדש בעולם שהוא Greenfield.

(רן) ואם לרוב המאזינים שלנו - דווקא יש להם מוצר? סתם, אני מהמר - יש להם מוצר קיים, זאת אומרת, ברוב המקרים באמת יש איזשהו מוצר קיים והבעיה היא מאוד דומה לבעיה שלכם: רוצים לכתוב עוד פיצ'רים, מרגישים איזשהו Friction בין המוצר, בין ההנדסה - ומחפשים פתרון.

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

• (שי) אני חושב שבמקרה הזה הייתי כן שוקל React Native, ומה המשמעויות עבור צוותים שרוצים להכניס טכנולוגיות Web.
• כי בסופו של דבר, זה עוד טכנולוגיות Web - יש לך עוד Reloading, אתה יכול להשיק ל-Production תוך חמש דקות ולא תוך שלושה ימים . . .
• וכן - אתה יכול לחלוק קוד.
• אנחנו למשל, בהינתן שה-Stack המשותף הוא React-י, גם ב-React Native, אז אתה יכול לכתוב אפילו אבסטרקציות (Abstractions) ברמה של Hook-ים וקוד משותף, גם אם זה לא אותו UI.
• אז גם אתה עושה צעד אחד קדימה לכיוון הזה.

(רן) ואם אתם מחפשים דרך “למכור את זה”, בתור מפתחים - אם אתם מחפשים דרך “למכור את זה להנהלה שלכם” או לאנשי מוצר, אז אני חושב שאפשר להשתמש פה בכמה טיעונים ששי העלה.

אחד זה היכולת לעשות Reuse גם ב-Design Framework וגם בקוד עצמו; ושתיים זה היכולת לרלס (To Release), שלדעתי זה ה-Winner פה - זאת אומרת, היכולת לשחרר משהו בחמש דקות ולתקן באגים. כן, אני בטוח שלכל מפתח Mobile קרה שהוא שחרר באג ל-AppStore - ואחר כך לתקן את זה, זה במקרה הטוב שלושה ימים . . . ולפעמים זה גם הרבה יותר, והיוזרים (Users) שלו תקועים עם זה, ולפעמים צריך לשמר Backward Compatibility

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

(אורי) וגם עלויות - עלויות בכוח אדם, זה מאוד משמעותי.

• (שי) כוח אדם - והיכולת שלנו להשיק מוצרים חדשים . . . זה מדהים.
• כשאני הצרפתי ל-Lemonade, השקנו את המוצר של הביטוח חיים - והמוצר של ביטוח החיים, אז לפחות, הוא היה ארוך.
• כלומר, היית יכול במקסימום . . . היית צריך, במקסימום, אולי לענות על 70 (!) שאלות כדי לקנות ביטוח חיים.
• ופיתחנו את זה ל-Web ואז אמרנו “טוב, בואו - אנחנו צריכים להשיק עוד כמה חודשים, מה עם Mobile?”
• והיינו צריכים שני מפתחים בנפרד - וזה Flow שנראה קצת שונה, עם שאלות אחרות והתנהגויות שונות, אז זה פתאום דוחף את השקה . . .
• אין את זה יותר.

(אורי) כן.

(רן) מדהים.

29:47 קרדיטים

(רן) טוב, אז אתם עכשיו בהטמעה בתוך מוצרים נוספים, אני מניח?

• (שי) כן.

(רן) אוקיי. כתבתם משהו, פרסמתם משהו? יש דברים שאפשר לקרוא על זה?

• (שי) אנחנו רוצים - ולא הייתה לנו הזדמנות עדיין.

(רן) אוקיי, אז בקרוב?

• (שי) כן, בתקווה.

(רן) Stay Tuned! - ועד אז תאזינו לפודקאסטים שלנו . . .

תודה רבה, שי! נתראה ב-UniClient . . .

האזנה נעימה ותודה רבה לעופר פורר על התמלול!