ToCode

אנלוגיית הלגו והבעיה שלנו עם תכנון רופא שצריך לטפל בחולה יודע להסתכל על אלפי חולים שסבלו בעבר מאותם תסמינים, לנתח את הבעיה ולבחור את הטיפול הטוב ביותר. אדריכל שצריך לתכנן גשר יודע להסתכל על אלפי גשרים שנבנו בעבר ולבחור את שיטת הבניה הטובה ביותר לגשר החדש. כן הוא יוכל לחדש בקצוות, אבל הבסיס בנוי על רעיונות שעובדים אלפי שנים. ואנחנו? אנחנו בונים בלגו ובלי חוברת הדרכה. כמתכנתים אנחנו מאוד טובים בבניית ספריות קטנות, אנחנו משתפים אותן בגיטהאב או בין פרויקטים. אנחנו גם יודעים לדבר על "עקרונות" או "רעיונות" של קוד נקי. אבל מאחר ואין שתי מערכות זהות אין לנו אוסף של מערכות שנבנו בעבר ללמוד מהן. יותר מזה, הטכנולוגיה משתנה כל כך מהר שאפילו אם אני בונה את אותו פרויקט שנה אחרי שנה הקוד יראה אחרת. אז מה הפלא שכל פרויקט תוכנה לוקח יותר זמן ועובד פחות טוב ממה שרצינו? הכניסה של ה AI מעניינת. עכשיו יש לנו פועל אוטומטי שמוכן לבנות את אבני הלגו הבסיסיות בשבילנו הרבה יותר מהר ממה שאי פעם הצלחנו. האם זה הולך להפוך את החיים שלנו לצפויים יותר? אני לא בטוח. זה לא מקרי ש AI לא מצליח להפוך "סיפור לקוח" לסידרה של משימות פשוטות עם הערכות זמנים מדויקות לכל משימה. האתגר שלו הוא עדיין גם האתגר שלנו, ופיתוח אבני לגו טובות יותר או מגוונות יותר זה לא החלק המעניין כאן.

הי חברים וחברות סקר זריז אני עובד על ריענון קורס ריאקט להתאים אותו לריאקט 19, נקסט וכל מה שקורה היום אשמח לשמוע מכם - איזה דברים בעולם של ריאקט הייתם שמחים למצוא בקורס?

ניסוי ויו: הצפנת זיגזג כתבתי פה בעבר על הספר סודות ההצפנה לילדים שכתבה סתיו אלבר כשהספר עוד היה רעיון בהדסטארט. היום הספר גמור ואני באמצע הקריאה עם הילדים הפרטיים שלי שמאוד נהנים ממנו בינתיים. בשביל המשחק ובעקבות השראה מהספר חשבתי לממש את אחת ההצפנות הפרימיטיביות מהדוגמאות של סתיו בקוד Vue. מה זה הצפנת זיגזג ההצפנה נקראת הצפנת זיגזג או באנגלית Rail fence cipher וזהו מצפין שבסך הכל משנה את סדר האותיות במילה באופן הבא: כותבים את המילה מלמטה למעלה לרוחב הדף עד לגובה מסוים שנקרא המפתח, ואז ממשיכים את הכתיבה כלפי מטה עד שמגיעים לשורת ההתחלה ואז שוב עולים למעלה. עם מספיק אותיות הצורה שמתקבלת נראית כמו זיגזג. בסוף לוקחים את הטקסט שכתוב מלמעלה למטה וזו ההודעה המוצפנת. אפשר לשחק עם ההצפנה בניסוי ויו שכתבתי כאן: <iframe src="https://railsfencecipher-vue.vercel.app" height="600" width="800" /> או אונליין בקישור: https://railsfencecipher-vue.vercel.app ובקוד הניסוי בגיטהאב: https://github.com/ynonp/railsfencecipher-vue סקירת קוד הצפנה ופיענוח הקובץ שמטפל בהצפנה ופיענוח הוא:

import _ from 'lodash';

export function encrypt(msg: string, key: number) {
  const height = key;
  const groupSize = height * 2 - 2;
  
  const positions = msg.split('').map((ch, idx) => {
    const indexInGroup = idx % groupSize;
    const rowFromBottom = (indexInGroup < height) ? (indexInGroup + 1) : height - (indexInGroup + 1 - height);
    const rowFromTop = height - (rowFromBottom - 1);

    return {
      ch,
      column: idx + 1,
      row: rowFromTop,
      style: { gridArea: \${rowFromTop} / ${idx + 1}\ }
    }
  })

  const message = _.sortBy(positions, 'row').map(p => p.ch).join('');
  return {
    positions,
    message,
  }
}

export function decrypt(msg: string, key: number) {
  const {positions} = encrypt(msg, key);
  const sortedPositions = _.sortBy(positions, 'row');
  const positionsWithEncryptedMessage = sortedPositions.map((p, index) => ({...p, ch: msg[index]}));
  return {
    positions: positionsWithEncryptedMessage,
    message: _.sortBy(positionsWithEncryptedMessage, 'column').map(p => p.ch).join('')
  }
}

בגדול לוקחים את ההודעה ורצים בלולאה על כל התווים, בכל תו מעלים ב-1 את אינדקס העמודה ומשנים את אינדקס השורה לפי הבדיקה באופרטור הטרנרי, אם הוא בחלק הראשון של הזיגזג מעלים את אינדקס השורה ואם הוא בחלק השני של הזיגזג מורידים את מספר השורה. בשביל הפיענוח אפשר להשתמש באותה פונקציית הצפנה כדי לחשב את צורת הזיגזג ואחרי זה בלולאה נוספת ממלאים את הריבועים באותיות האמיתיות. מחשבות על ניסויים ו AI צריך להגיד, נהניתי מהניסוי. הוא עזר לי להבין טוב יותר את הרעיון של צופן זיגזג. לא היה לי ספק שיש כבר אנשים שמימשו את זה לפניי באינטרנט ואכן לא צריך יותר מכמה שניות בגוגל כדי להגיע להמון מימושים והסברים על צופן זה, כמו שגוגל יודע. ברור גם שמנועי AI מסוגלים לבנות את הקוד הרבה יותר מהר ממה שאני כתבתי ואפילו לייצר תוצאה יפה יותר. הנה זו הגירסה של קלוד לאותו מצפין: https://claude.site/artifacts/6a2f527f-8bc8-43d5-b837-3996a9c6392c מתוך הפרומפט: > create an online rails fence cipher / decipher tool ואז מגיעים לשאלה - אם הכל כבר קיים בשביל מה לבנות את זה? ואם קלוד יודע לבנות את המצפין בשניה וחצי למה לא לקחת את המימוש שלו? ובכלל איך נראה העתיד שלי כמתכנת כשקלוד עושה כל דבר יותר מהר? התשובה שלי כרגע היא שהידע התיאורטי והידע המעשי קשורים אחד לשני, ואנחנו צריכים להתאמן על שניהם כדי להיות מסוגלים לבנות את המוצרים הבאים. ככל שעובר הזמן עם ה AI המגבלות שלו מתבהרות. זה לא מפריע לי לכתוב קוד שקלוד היה יכול לכתוב מהר יותר בשביל ללמוד נושא, כי ניסוי מעשי הוא עדיין הדרך הטובה ביותר ללמוד. ממילא העבודה אמיתית שאני עושה - פיתוח ותיקון מערכות אמיתיות, היא מחוץ ל Context Window של כל AI שראיתי או שאני יכול לדמיין.

חכמים מדי בזמן ששברתי את הראש כדי להבין למה המייל האוטומטי של הפוסט לא נשלח אתמול שמעתי מהצד של המוח קול מהעבר. עזוב ניסיתי להשתיק אותו, זה לא קשור, זה בטח בגלל השינוי שהוספתי ל Headers של המייל יום קודם, משהו שם לא נדחף כמו שצריך. ״אתה יודע מה הבעיה שלכם?״ אמר לי פעם מנהל חכם, ״אתם חכמים מדי. מרוב שאתם רואים בעיות אתם לא מצליחים להתקדם״. לא רציתי להסכים איתו. הייתי בטוח שאנחנו רואים בעיות אמיתיות, שקוד צריך להיות נכון לפני שהוא עובד, שרק כתיבה נכונה ומסודרת מייצרת מערכות נכונות, ורק אני יודע מה זה נכון ומסודר. אני חוזר לדבג את התקלה של המייל שלא נשלח. אצלי בפיתוח הכל עובד אז אני מנסה להריץ את התהליך ידנית ומקבל את הודעת השגיאה:

Template contains unsupported operations

רגע מה פתאום unsupported oprations? ומי בכלל דיבר על טמפלייטס? אבל מהר מאוד דברים מתחילים להתחבר. הפונקציה send_bulk_email של SES יודעת לקבל פרמטרים כדי לקסטם את האימייל לכל נמען בנפרד. פרמטרים בגוף המייל נכתבים בתוך סוגריים מסולסלים כפולים, ואצלי בפוסט היתה דוגמה בדיוק של סוגריים מסולסלים כפולים. האם SES חושב בטעות שתוכן המייל שלי דורש החלפת תבנית? האם הוא חושב שהסוגריים שבפוסט מגדירים פרמטרים? ואם זה המצב מה המשמעות של unsupported operations. ״כשאני צריך לבנות פיצ'ר אני משתמש בכלים שאני מכיר. אם צריך אני מוכן גם לסטות מהאיפיון, ובלבד להגיע למשהו שעובד בזמן עליו התחייבתי. אני לא עושה הערכות זמנים, אני קובע זמנים, והפיתוח מתאים לזמן שקבעתי. אתם נכנסים למשימה כמו לעבודת מחקר: מחפשים איך דברים צריכים לעבוד ומנסים לממש את זה. אין סיכוי לעמוד בזמנים ככה״. אני מנסה לתקן. מה הבעיה, זה רק להוסיף לוכסן הפוך לפני הסוגריים המסולסלים ההפוכים לפני ששולחים אותו לפונקציה של AWS, אבל שום דבר בתוכנה לא יכול להיות כל כך פשוט. ל AWS לא אכפת מהלוכסן ההפוך שלי והוא ממשיך להתלונן על התבנית שמכילה פעולות שאינן נתמכות. עכשיו אני כבר שומע בבירור את הקול מהעבר ומבין שהבעיה שלי הרבה יותר עמוקה. בואו נסכם: 1. יש שתי דרכים לשלוח אימייל ב AWS. אפשר לשלוח מייל בודד בפרוטוקול SMTP או לשלוח ערימה של אימיילים בקריאת פונקציה אחת דרך ה API של AWS. ברור שהקריאה האחת מהירה ויעילה יותר. יותר מזה, אני באמת צריך התאמה אישית של המייל לכל נמען כי בכל מייל יש קישור להסרה מרשימת התפוצה והקישור שונה לכל נמען. 2. הבעיה - בזמן הפיתוח לא ידעתי כלום על SES, לא הכרתי את המגבלות שלו. ערבבתי בין פרויקט מחקרי לפרויקט פיתוח, ובחרתי באפשרות שנראתה נכונה למרות שהיא לקחה זמן פיתוח ארוך בהרבה. 3. המכה - אפילו אחרי שהקוד הנכון עבד, ובגלל שלא הכרתי מספיק טוב את SES לא ידעתי שהוא רגיש לתווים שנראים כמו משתנים להחלפה אבל בעצם אינם כאלה. אני עדיין לא יודע אם ה API של SES יכול לפתור את הבעיה הזאת או איך להשתמש בו כדי להחליף משתנה במקום אחד (קישור להסרה מהרשימה) אבל להתעלם מדברים שנראים כמו משתנים במקומות אחרים. 4. מה עדיף - אחרי שראיתי את כל זה עדכנתי את הקוד כדי לשלוח את המייל דרך SMTP. כן זה לוקח יותר זמן אבל ממילא התהליך רץ ברקע. ל AWS לא אכפת לקבל אפילו אלפי מיילים ב SMTP והקוד בצד שלי יצא הרבה יותר פשוט וקצר. יותר מזה, אם בעתיד ארצה לעבור לשירות מייל מתחרה השינוי היחיד שיידרש הוא בהגדרות ולא בקוד, כי אני לא נעול על API ספציפי של SES. האם יום אחד זה יישבר? אולי. אבל זאת בהחלט בעיה שלא היה צריך לפתור מראש. מתכנתים חכמים (שאינם חכמים מדי) יודעים לבחור טכנולוגיות משעממות כשהן פותרות את הבעיה מספיק טוב.

טיפ רובי - החלפת טקסט מתוך Hash פונקציית gsub של רובי מחליפה טקסטים בתוך מחרוזות. היא פועלת על מחרוזת, מקבלת ביטוי רגולארי אותו צריך למצוא במחרוזת וטקסט להחלפה ושמה את הטקסט להחלפה במקום הביטוי הרגולארי. עד לפה לא מלהיב כלל. דברים מתחילים להיות מעניינים כשבמקום טקסט אנחנו מעבירים בתור פרמטר Hash עם מספר מפתחות להחלפה. המקרה הפשוט הפונקציה gsub יודעת לקבל ביטוי רגולארי וטקסט להחלפה ומחליפה כל מופע של הביטוי הרגולארי בטקסט. זה נראה ככה:

> 'hello big world'.gsub(/ /, '-')
 => "hello-big-world"

מעניין לגלות שברובי אפשר להעביר במקום טקסט להחלפה Hash עם מספר טקסטים להחלפה, ואז אחרי התאמה של הביטוי הרגולארי הפונקציה תחפש ב Hash מפתח עם תוכן הטקסט שהתאים לביטוי ואם היא מוצאת היא תחליף את הטקסט בערך שמופיע ב Hash, כלומר:

 > 'hello big world...'.gsub(/\W/, {' ' => '-', '.' => '!'})
 => "hello-big-world!!!"

החלפת טוקנים הפיצ'ר הזה ממש חמוד כי הוא מאפשר לכתוב בקלות מנגנון טמפלייטס, כלומר קוד שיקבל טקסט ויחליף מילים שמורות בערך שלהן מתוך ה Hash. לדוגמה שימו לב לקוד הזה:

3.1.1 :034 > text = 'name: {{name}}, email: {{email}}, phone: {{phone}}'
 => "name: {{name}}, email: {{email}}, phone: {{phone}}"
3.1.1 :035 > data = {'{{name}}' => 'ynon', '{{email}}' => 'testmail', '{{phone}}' => '0521111111' }
 => {"{{name}}"=>"ynon", "{{email}}"=>"testmail", "{{phone}}"=>"0521111111"}
3.1.1 :036 > text.gsub(/{{\w+}}/, data)
 => "name: ynon, email: testmail, phone: 0521111111"

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

data = {'name' => 'ynon', 'email' => 'testmail', 'phone' => '0521111111' }
 => {"name"=>"ynon", "email"=>"testmail", "phone"=>"0521111111"}

במצב כזה אפשר להפעיל map כדי לשנות את שמות המפתחות ואז to_h כדי לחזור ל Hash, אבל אולי יותר קל לתקן את הביטוי הרגולארי. בעזרת Lookarounds אני יכול לכתוב ביטוי שיחפש את סימני הסוגריים המסולסלים הכפולים אבל לא "יתפוס" אותם וכך ההתאמה תהיה רק מול המילה עצמה (name, email או phone):

3.1.1 :044 > text.gsub(/(?<={{)\w+(?=}})/, data)
 => "name: {{ynon}}, email: {{testmail}}, phone: {{0521111111}}"

ללמוד טכנולוגיה חדשה בשביל פרויקט? חבר שואל - יש לי פרויקט flask שמשתמש ב Psycopg ואני צריך לשכתב את רוב הקוד שעובד עם בסיס הנתונים. שווה לי ללמוד SQLAlchemy בשביל זה? קל לראות למה לא: 1. הפרויקט כאן. יש לו דדליין. אתה כבר יודע לעבוד עם Psycopg אבל אין לך מושג איך עובדים עם SQLAlchemy, ואפילו אם עשית טוטוריאל או שניים אין לך מושג איזה בעיות יהיו שם. חבל לבזבז פרויקט טוב רק בגלל שבא לך ללמוד משהו חדש. 2. המטרה בלימוד היא להבין. כשאתה צריך לבנות מערכת אין לך זמן לקרוא את כל התיעוד, להקשיב להרצאות, להיכנס לקוד הספריה ולנסות לשבור דברים כדי לראות איך זה עובד. חבל לבזבז לימוד טוב רק בגלל שעכשיו צריך לשכתב קוד ישן. כשאנחנו מפרידים בין הלימוד לפיתוח שני הצדדים מרוויחים. בצד הלימוד אנחנו לא ממהרים לסיים פרויקט ויכולים לכתוב ולמחוק ולשבור ולבנות POC-ים קטנים עד שנהיה בטוחים איך דברים עובדים. בצד הפיתוח אנחנו יכולים לתת הערכות זמנים מדויקות כי אנחנו עובדים עם טכנולוגיות שאנחנו מכירים. עבודה מקצועית אומרת שעלינו להסתכל על טובת הלקוח, ולפיתוח וללימוד יש שני לקוחות שונים: הלקוח של פרויקט הפיתוח הוא הבוס שלך בעבודה; הלקוח של הלימוד הוא אתה עצמך. שני פרויקטים. שני לקוחות. שני עולמות.

הרבה יותר משניים דן אברמוב כותב על שני ריאקטים, הריאקט שרץ על השרת והריאקט שרץ בדפדפן, ועל התפקידים השונים של כל אחד מהם. אני חושב שהוא עושה לעצמו הנחה. יש הרבה יותר משניים: 1. האם את ספריית תצוגה לצד לקוח, שנועדה לעזור לצוותים גדולים לתחזק אתרים עם יותר מדי קוד JavaScript? 2. האם את ספריית Full Stack שנועדה לעזור למפתחים להעלות מהר יותר פרויקטים לאוויר? 3. האם את מנסה לעזור לי לכתוב אתרים שעובדים מהר יותר (ההבטחה של Single Page Apps), או מנסה לגרום לי לכתוב קוד "נכון" גם אם זה עולה בזמני טעינה ופגיעה בביצועים? 4. האם את מעודדת שיתוף קוד בין פרויקטים או חדשנות ושינוי (שיבואו תמיד על חשבון היכולת להשתמש בקוד ישן שמצאתי ברשת) ? 5. האם את ספריית צד לקוח שאני יכול להכניס לכל פרויקט או ספריית Full Stack שדורשת קוד מיוחד בצד השרת על מנת לעבוד בצורה מיטבית? עמוד הבית של התיעוד של ריאקט כולל את ההבטחה: > Whether you work on your own or with thousands of other developers, using React feels the same. It is designed to let you seamlessly combine components written by independent people, teams, and organizations. ואני רוצה לקחת אותם ברצינות, אבל יודע שפרויקטי ריאקט שאני ראיתי לא "הרגישו אותו דבר". פרויקט צד-לקוח שמשתמש ב Redux ומחזיק את הלוגיקה והפעולות מחוץ לריאקט, ירגיש מאוד שונה מפרויקט שמעביר את כל עומס העבודה לקומפוננטות וישתמש ב react-query כדי למשוך מידע מהשרת ולשמור אותו בקונטקסט, ושני אלה ירגישו שונה מפרויקט שמשתמש ב Zustand, Valtio או Jotai. פרויקט שמשתמש ב Shadcn ו Tailwind ירגיש מאוד שונה מפרויקט שמשתמש ב Styled Components. ועוד לא דיברנו על next לעומת remix לעומת redwood לעומת tanstack start. עכשיו שקורס Vue מאחוריי התחלתי לארגן מחדש את קורס ריאקט. האקוסיסטם של ריאקט תמיד היה מבולגן ובשנים האחרונות זה רק מחמיר. זה לא מה שיהרוג את ריאקט, אבל זה כן משהו שצריך להיות מאוד מודעים אליו כשלומדים ריאקט או כשנכנסים לעבוד על פרויקט.

הרבה יותר משניים דן אברמוב כותב על שני ריאקטים, הריאקט שרץ על השרת והריאקט שרץ בדפדפן, ועל התפקידים השונים של כל אחד מהם. אני חושב שהוא עושה לעצמו הנחה. יש הרבה יותר משניים: 1. האם את ספריית תצוגה לצד לקוח, שנועדה לעזור לצוותים גדולים לתחזק אתרים עם יותר מדי קוד JavaScript? 2. האם את ספריית Full Stack שנועדה לעזור למפתחים להעלות מהר יותר פרויקטים לאוויר? 3. האם את מנסה לעזור לי לכתוב אתרים שעובדים מהר יותר (ההבטחה של Single Page Apps), או מנסה לגרום לי לכתוב קוד "נכון" גם אם זה עולה בזמני טעינה ופגיעה בביצועים? 4. האם את מעודדת שיתוף קוד בין פרויקטים או חדשנות ושינוי (שיבואו תמיד על חשבון היכולת להשתמש בקוד ישן שמצאתי ברשת) ? 5. האם את ספריית צד לקוח שאני יכול להכניס לכל פרויקט או ספריית Full Stack שדורשת קוד מיוחד בצד השרת על מנת לעבוד בצורה מיטבית? עמוד הבית של התיעוד של ריאקט כולל את ההבטחה: > Whether you work on your own or with thousands of other developers, using React feels the same. It is designed to let you seamlessly combine components written by independent people, teams, and organizations. ואני רוצה לקחת אותם ברצינות, אבל יודע שפרויקטי ריאקט שאני ראיתי לא "הרגישו אותו דבר". פרויקט צד-לקוח שמשתמש ב Redux ומחזיק את הלוגיקה והפעולות מחוץ לריאקט, ירגיש מאוד שונה מפרויקט שמעביר את כל עומס העבודה לקומפוננטות וישתמש ב react-query כדי למשוך מידע מהשרת ולשמור אותו בקונטקסט, ושני אלה ירגישו שונה מפרויקט שמשתמש ב Zustand, Valtio או Jotai. פרויקט שמשתמש ב Shadcn ו Tailwind ירגיש מאוד שונה מפרויקט שמשתמש ב Styled Components. ועוד לא דיברנו על next לעומת remix לעומת redwood לעומת tanstack start. עכשיו שקורס Vue מאחוריי התחלתי לארגן מחדש את קורס ריאקט. האקוסיסטם של ריאקט תמיד היה מבולגן ובשנים האחרונות זה רק מחמיר. זה לא מה שיהרוג את ריאקט, אבל זה כן משהו שצריך להיות מאוד מודעים אליו כשלומדים ריאקט או כשנכנסים לעבוד על פרויקט.

היום למדתי: תווים מצחיקים במשתני סביבה אנחנו יודעים להגדיר קובץ .env עם משתני הסביבה של הפרויקט בפורמט הזה:

API_KEY=abcdefg

ואחרי זה לקרוא את משתני הסביבה באמצעות:

console.log(process.env.API_KEY);

הסיפור נהיה מעניין כשאנחנו מוסיפים תווים מיוחדים לערכים של משתני הסביבה, לדוגמה:

API_KEY=abcd$e$fgh#abc123

ניסיון רגיל ב next.js לטעון קובץ env כזה ישאיר את משתנה הסביבה בלי החלק שאחרי הסולמית. ואל תדאגו שום הודעת שגיאה לא תופיע על המסך. אפשר (רצוי) להקיף את משתנה הסביבה במרכאות:

API_KEY="abcd$e$fgh#abc123"

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

API_KEY="abcd\$e\$fgh#abc123"

שימו לב ששימוש בגרש בודד לא יעזור כאן, אלא רק יזיק. ב next הגרש הבודד מפוענח כמו גרשיים והכל עדיין עובד, אבל אם תנסו לטעון את קובץ ה .env מתוך bash הגרש הבודד יגרום ללוכסן ההפוך להיכנס בעצמו לערך, כלומר הקוד הזה ב bash:

source .env

עובד עם מרכאות ו Backslash כמו שכתבתי, אבל לא עובד אם במקום מרכאות יהיה גרש בודד.

חדש באתר: קורס Vue.JS אני מודה: לא הייתי מהראשונים לעלות על הרכבת של Vue. בניגוד לריאקט, שמיד כשיצא אימצתי אותו לכל הפרויקטים שלי, ויו נראה לי "לא מספיק רציני", "לא מספיק בוגר", "מנסה לעשות יותר מדי". הריאקטיביות של ויו נראתה כמו רעיון מאוד קשה למימוש, ובאמת בגירסאות הישנות של ויו היו לא מעט מקרי קצה מוזרים. שני דברים קרו בשנים האחרונות ששינו את התמונה: בצד של ריאקט שינויים בפריימוורק קודם כל ביוזמת דן אברמוב ולאחר מכן בהובלת Vercel הפכו את ריאקט לפריימוורק הרבה יותר מסובך ממה שהיה כשאני התחלתי לעבוד איתו. לא כולם זוכרים אבל היו חיים לפני רידאקס, וכשרידאקס נכנס דברים באמת הפכו ליותר מסובכים. דן אברמוב הוביל את המעבר ל Hooks שנראה כמו שיפור מכתיב הקלאסים אבל יצר הרבה אי הבנות בעיקר סביב useEffect וכל נושא ה Memoization של useMemo ו useCallback. ואז הגיעו ורסל עם next.js והפכו את ריאקט לפריימוורק Full Stack. וכן זה נחמד אם אתם צריכים לכתוב אפליקציית Full Stack ב next.js, אבל כל מי שרוצה ספריה פשוטה לפיתוח ממשק משתמש קצת נשאר מאחור. בצד של ויו המעבר לטייפסקריפט ושינוי התחביר של Vue3, יחד עם עבודה מאומצת לכסות כל מקרה קצה ולייצר פיתרונות ידידותיים למפתחים הביא את ויו סוף סוף למקום בו 99% מהדברים שאני כותב עובדים בצורה הגיונית. המנגנון הריאקטיבי, שבעבר היה מאוד קל לשבור אותו התייצב. עד כדי כך שבמקומות שרציתי להראות איך דברים עובדים בקורס הייתי צריך מאוד להתאמץ כדי למצוא את הקוד שישבור את שכבת הנחמדות של Vue. הצטלבות אירועים זו הביאה אותי להכיר בעולם שהשתנה ולהוסיף לאתר קורס על Vue.JS. הקורס מומלץ לכל מי שמכירים פיתוח ווב ורוצים להוסיף פריימוורק לפיתוח ממשקים מתוחכמים יותר ליישומים שלכם, וגם למתכנתי ריאקט שמחפשים ספריה יותר פשוטה או עם פחות קוד, או אפילו קצת יותר מפנקת. בגלל האופי של Vue והיכולת שלו ללכת לקראתנו גם כשאנחנו עושים טעויות אני חושב שגם אנשים שמכירים ויו ילמדו הרבה מהקורס והוא יסגור לכם פינות שאולי לא שמתם לב אליהן. כרגיל הפרק הראשון בחינם ושאר הפרקים זמינים במסגרת תוכנית המנויים. לפרטים וסילבוס מלא מוזמנים להכנס לדף הקורס בקישור: קורס Vue.JS