הבלוג של ינון פרק

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

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

אין ספק שאנחנו פותרים יותר טיקטים, אבל כמה מהם נפתחו רק בגלל שטויות שה AI פספס?

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

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

לפני החפירות על הסילבוס זה הלינק לדף הקורס:

https://www.tocode.co.il/genai_course

תוכלו למצוא שם בצד שמאל למטה סוכנת AI ששילבתי ממש לכבוד הקורס הזה ושתעשה כמיטב יכולתה לענות על כל שאלה.

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

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

I fixed both issues. The service is running, and all 183 tests pass.

ובאמת הנושא תוקן והפיצ'ר החדש עובד.

אך יש עדיין שני פערים מורגשים בתהליך:

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

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

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

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

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

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

שופיפיי הודיעו על מיגרציה של אפליקציות המובייל שלהם מריאקט נייטיב לאפליקציות נייטיב רגילות, סוויפט וקוטלין

https://shopify.engineering/back-to-native

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

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

עם React Native אפליקציית האייפון ואפליקציית האנדרואיד מפותחות על ידי אותו צוות ולכן שומרות על אחידות בחוויה ובפיצ'רים.

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

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

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

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

ואני מאמין לקטע של החצי שנה כתיבה ושיפור קובץ CLAUDE.md. אבל השאלה האם זה היה הדבר היחיד שהשפיע?

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

אלה מספר טכניקות שראינו בוובינר היום כדי לנקות תוספים ישנים, לחסוך טוקנים ואולי לשפר את התוצאות.

1. קונטקסט ריק - הפקודה /context בקלוד קוד מראה את כל התוספים שתופסים מקום בקונטקסט. כשמפעילים את קלוד קוד במצב בטוח עם claude --safe-mode קלוד קוד לא טוען תוספים כלל ומתעלם מקובץ CLAUDE.md. נסו להפעיל את קלוד קוד במצב בטוח לאותה משימה שקודם הפעלתם במצב הרגיל ושימו לב לטוקנים. האם קיבלתם תוצאה דומה במחיר יותר נמוך? אם כן אולי שווה לנקות.

2. פקודת /plugins בקלוד קוד מראה את כל הפלאגינים שמותקנים. לכו לטאב Installed ותוכלו לראות איזה תוספים לא היו בשימוש בזמן האחרון. אלה מועמדים טובים להסרה.

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

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

5. שרתי MCP לא רק תופסים מקום בקונטקסט הם גם מכתיבים התנהגות. מספיק שיש לי את שרת ה MCP של כלי הפיתוח של כרום והסוכן ישתמש בו כדי לוודא בדפדפן כל שינוי, גם כשלא ממש צריך. נסו למחוק שרתי MCP ולהחליף אותם בכלי שורת פקודה שמותקנים על המכונה והוראה ספציפית להשתמש בכלים, בדוגמה של הדפדפן ראינו איך כשמתקינים agent-browser במקום devtools mcp הסוכן עובר להפעיל דפדפן רק לפי דרישה.

6. קובץ CLAUDE.md שהשקעתם חצי שנה של עבודה בכתיבה שלו יכול להיות חוב טכני. בוריס צ'רני, היוצר של קלוד קוד, המליץ למחוק את הקובץ פעם בחצי שנה בגלל התקדמות של המודל. אפילו אם אתם חושבים שהקובץ כולל פרטים חשובים על שיטת העבודה האהובה עליכם אולי אחרי שתמחקו אותו תגלו שהסוכן ממילא מצליח לזהות את שיטת העבודה על בסיס הקוד הקיים.

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

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

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

שלוש תשובות לדעתי שלושתן חשובות:

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

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

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

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

קלוד החליט לגוון בסקריפט פייתון שביקשתי וסיים את הסקריפט עם הקטע הבא שקצת הפתיע אותי:

if __name__ == "__main__":
    raise SystemExit(main())

למה לסיים קוד עם raise? מי זה SystemExit? ומה ההגיון בשיטת הכתיבה הזו?

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

if rm demo
then
    echo "yes"
else
    echo "no"
fi

מנסה להריץ את פקודת המחיקה, אם הצליחה למחוק אז היא תדפיס yes ואם לא הצליחה למחוק תדפיס no.

איך אנחנו יודעים אם תוכנית "הצליחה" או "לא הצליחה"? כל תוכנית יוניקס מחזירה ערך למערכת ההפעלה. ערך 0 מעיד על הצלחה וכל ערך שאינו 0 מעיד על כשלון. בפייתון אפשר להשתמש ב sys.exit כדי להחזיר ערך למערכת ההפעלה לדוגמה תוכנית הפייתון הבאה תמיד תכשל:

import sys

sys.exit(1)

ותוכנית הפייתון הבאה תמיד תצליח:

import sys

sys.exit(0)

מי שרוצה להעביר את ההחלטה אם להצליח או להכשל לפונקציה בשם main יכול לכתוב קוד כזה:

import sys

result = main()
sys.exit(result)

או צעד לכיוון הקוד מתחילת הפוסט:

import sys

sys.exit(main())

ומה עושה sys.exit? שימו לב למימוש מתוך sysmodule.c:

static PyObject *
sys_exit_impl(PyObject *module, PyObject *status)
/*[clinic end generated code: output=13870986c1ab2ec0 input=b86ca9497baa94f2]*/
{
    /* Raise SystemExit so callers may catch it or clean up. */
    PyErr_SetObject(PyExc_SystemExit, status);
    return NULL;
}

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

raise SystemExit(main())

ולחסוך את ה import sys.

אני לא אוהב את שיטת הכתיבה הזו. אני חושב שהיא מסתירה את החלק הכי חשוב בשורה, כלומר הפעלת main, בתוך סוגריים בתוך פרמטר ל raise, אבל בכל מקרה תמיד נחמד להכיר מבנים חדשים בשפה.

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

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

לנגלטס היא הניסיון שלי להפוך את התיאוריה הזאת למציאות. נכנסים בקישור he.langlets.app

עקרון העבודה הוא פשוט:

1. מוצאים סרטים מעניינים ביוטיוב או טיקטוק.

2. מדביקים ל Langlets או משתפים בלחיצת כפתור מאפליקציית יוטיוב או טיקטוק לאפליקציית לנגלטס.

3. מחכים שתי דקות שה AI יארגן את התוכן ומתחילים לתרגל.

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

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

מבנה כל שיעור שהסוכן יוצר מתאים לאיך שאני רגיל לתרגל שפה:

1. מסך ראשון הוא פשוט הטקסט בעברית של אותו קטע.

2. מסך שני פותח את הסרט ומציג רק את הקטע אותו אנחנו מתרגלים (בערך 20-30 שניות מהסרט). מתחת לסרט יש את הטקסט המלא שלו באנגלית ואפשר ללחוץ על כל מילה כדי לראות את התרגום שלה.

3. מסך שלישי נכנס לתרגול משפטים ספציפיים - מראה לכם משפט באנגלית מתוך הסרט ואתם צריכים לבחור את התרגום שלו לעברית מתוך 4 אפשרויות.

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

בסרט מיוטיוב של 8 דקות יש כ 17 שיעורים. בטיקטוק הסרטים יותר קצרים ושם לכל סרט יהיו 3-4 שיעורים.

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

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

כשלמדתי next.js לקח לי זמן להבין שכשאני כותב use client בתחילת קובץ הכוונה שלהם היא שהקוד ירוץ גם ב client וגם ב server, ולא רק ב client כמו שאולי היה אפשר להבין מהשם.

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

'use client';

import { useEffect, useState } from 'react';

export default function StoredValue({ storageKey = 'username', fallback = 'Not set' }) {
  // null means "haven't read storage yet" — distinct from an empty stored value
  const [value, setValue] = useState(null);

  useEffect(() => {
    try {
      setValue(localStorage.getItem(storageKey) ?? fallback);
    } catch {
      // Storage can throw in private mode or when disabled
      setValue(fallback);
    }
  }, [storageKey, fallback]);

  if (value === null) return <p>Loading…</p>;

  return <p>{value}</p>;
}

בשביל לקרוא מ local storage ריאקט היה צריך להחביא את הקוד שקורא מקוד צד השרת שיריץ אותו, כי על השרת ה local storage אולי לא זמין ובטוח מכיל ערכים אחרים.

לאחרונה next הוסיפו מנגנון חמוד בשם browser: https://react.dev/reference/react-dom/browser

המטרה שלו לאפשר לסמן קוד שירוץ רק בדפדפן ולא על השרת. כן, כאילו הוא מוסתר באפקט רק בלי כל הטקס. הנה הגרסה המודרנית של אותו קוד:

'use client';

import { use, useState } from 'react';
import { browser } from 'react-dom';

export default function StoredValue({ storageKey = 'username', fallback = 'Not set' }) {
  use(browser('The value is stored in localStorage.'));

  const [value] = useState(() => localStorage.getItem(storageKey) ?? fallback);

  return <p>{value}</p>;
}

המלכודת היחידה בעדכון היא לכתוב את הקומפוננטה רק בתוך Suspense Boundary כלומר:

import { Suspense } from 'react';
import StoredValue from './StoredValue';

export default function Page() {
  return (
    <Suspense fallback={<p>Loading…</p>}>
      <StoredValue />
    </Suspense>
  );
}

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

מקס לייטר מקלוד קוד הרגיש שהאתר שלו כבר יותר ממה שצריך וידע שהוא משתמש רק בחלק קטן מהיכולות של next.js. במקום לשכתב את האתר מאפס הוא ביקש מקלוד לבנות לו תחליף ל next.js שיתאים רק לאתר שלו. שמונה שעות ו 669$ מאוחר יותר האתר נטען עם הפריימוורק החדש.

זה הפוסט שהוא כתב לסכם את הניסוי: https://maxleiter.com/blog/thank-u-next

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

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

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

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

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