ToCode

ליצור או לבחור? "הי קלוד תן לי בבקשה 10 רעיונות לפוסטים". "מעולה עכשיו תכתוב פוסט מלא על הרעיון השלישי" "אפשר פיסקה שניה קצת יותר מפורטת?" ... אחת הבעיות עם להשתמש ב AI בלימודים היא שאנחנו מהמרים על העתיד. יכול להיות שבעתיד בני אדם לא יצרו יותר דברים חדשים אלא רק יבחרו מתוך תפריט. שהתיאור שהתחלתי איתו את הפוסט יהיה בדיוק האופן בו אנשים יוצרים. הבינה המלאכותית היוצרת, כשמה כן היא, תהיה הכח היוצר של העולם. אנחנו נתמקד במה שאנחנו יודעים לעשות טוב, כלומר להחליט ולכוון. כשתלמיד מקבל פרויקט לבית הספר לכתוב משחק בפייתון ומחליט לתת ל AI לעשות את עבודת הכתיבה הוא מוותר על ה"ליצור". השלב הכי קשה בלימוד הוא המעבר מצפיה בסרט לכתיבת פיתרון לתרגיל. ולא משנה כמה דוגמאות ראית, הרגע הזה שאתה יושב מול דף ריק וצריך ליצור רעיון חדש יכול להקפיא. וכן זה קשה גם לאנשים שמבינים ממש טוב את החומר ויוכלו להבין את הפיתרון אם יראו אותו כתוב. "ליצור" ו"לבחור" הן שתי מיומנויות שונות. אין לי תשובות על השאלות האלה אבל הייתי רוצה שנשאיר אותן מול העיניים כשאנחנו משלבים AI בתוכנית הלימודים: 1. האם אנחנו חושבים ש"ליצור" זו מיומנות חשובה ששווה לשמר (גם לבני אדם)? 2. אם מוותרים על "ליצור" ונשארים רק עם "לבחור", איך צריך לשנות את המשימות כדי שהבחירה תהיה חלק חשוב מהעבודה? 3. מה עושים עם הזמן שנחסך? אם במקום לשבת שבוע על פרויקט אפשר לכתוב את אותו פרויקט בשלוש שעות, כי החלטנו לוותר על תרגול מיומנות מסוימת בתהליך, אולי יש דברים אחרים שנרצה ללמד בזמן שחסכנו? 4. ומה אם אנחנו טועים? אולי שווה לחכות קצת עם הכנסת AI לתוכנית הלימודים לפחות עד שנראה שבאמת אנחנו מוכנים לוותר על מיומנות היצירה? אגב אחרי שכתבתי את הפוסט נתתי לקלוד לכתוב פוסט על אותו נושא. זה מה שהוא כתב: https://claude.ai/public/artifacts/6c4cff06-9fe6-485d-80db-b69704f191b4 אולי שלו יותר טוב אני לא יודע. ובכל זאת אני שמח שהתאמצתי לארגן את המחשבות ולכתוב לבד. זאת פיסקת הסיום שלו: > What's clear is that we cannot afford to let creation become a lost art. In our rush to embrace the convenience of AI tools, we must ensure that students continue to experience the productive struggle and profound satisfaction of bringing something entirely new into the world—something that began not in an algorithm, but in their own minds. > The blank page may be intimidating, but it remains one of our most powerful teachers. אני לא כל כך בטוח שהוא צודק.

כזה ניסיתי: דיפלוימנט עם Kamal אחד הרעיונות המרכזיים בגירסאות האחרונות של ריילס הוא המעבר לדיפלוימנט על שרת במקום להשתמש בשירותי ענן, אבל בלי להתפשר על חווית המפתחים. כשאנחנו פותחים פרויקט ריילס חדש היום הוא מגיע מוכן לדיפלוימנט בעזרת קמאל שמגיע מותקן עם הפרויקט. לקחתי שרת מ Digital Ocean והלכתי לבדוק איך זה עובד. חווית הפיתוח קמאל מבצע Deployment מבוסס קונטיינרים על שרת שלנו. לכן פרויקט ריילס חדש מגיע עם Dockerfile מוכן לפרודקשן והעלאה לפרודקשן אומרת: 1. קמאל בונה את האימג'. 2. קמאל דוחף את האימג' לרג'יסטרי. 3. קמאל מתחבר לשרת ומושך את האימג' העדכני מהרג'יסטרי. 4. קמאל מפעיל את הפרויקט עם דוקר. הדיפלוימנט הוא Zero Downtime מהקופסה. קמאל מפעיל סרביס תקשורת על השרת שנקרא kamal-proxy שמחובר תמיד לפורט 80 ו 443, ובאופן אוטומטי מנתב כל הודעה שמגיעה לקונטיינר. בעת העלאת גירסה חדשה הוא ימשיך לנתב את ההודעות לקונטיינר הישן עד שהגירסה החדשה סיימה לעלות. מבחינת הרג'יסטרי קמאל שומר 5 גירסאות אחורה של הפרויקט והדוקרפייל משתמש בשכבות וב Buils Stage כך שאימג'ים חדשים לא אמורים להיות גדולים מדי. סך הכל 5 גירסאות אחרונות בפרויקט דוגמה שלי לוקחות חצי ג'יגה בריפוסיטורי שזה בדיוק הנפח ש Digital Ocean נותנים בחינם. בשביל להעלות גירסה אני צריך רק לכתוב משורת הפקודה:

kamal deploy

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

* show all app images in the registry *
kamal app images

* show application logs *
kamal app logs

הקמת הסביבה כדי להגיע לכל הטוב הזה הייתי צריך קצת לעבוד, במיוחד לקח לי זמן להבין איך עובד מנגנון ה Secrets של קמאל. בעיקרון לקמאל יש שני קבצי קונפיגורציה מרכזיים הראשון הוא config/deploy.yml שמתאר את הפרויקט והשרתים ו .kamal/secrets שמתאר איך להשיג את הסודות שקמאל צריך עבור הדיפלוימנט. נתחיל עם config/deploy.yml - תבנית בסיסית שלו יכולה להיראות כך:

service: hey
image: 37s/hey
servers:
  - 192.168.0.1
  - 192.168.0.2
registry:
  username: registry-user-name
  password:
    - KAMAL_REGISTRY_PASSWORD
builder:
  arch: amd64
env:
  secret:
    - RAILS_MASTER_KEY

הקובץ מפרט איך נקרא היישום, איך לקרוא לאימג', לאיזה שרתים להעלות את היישום, איפה ה registry ואיזה סודות היישום צריך. הקובץ השני נקרא .kamal/secrets ושם אנחנו כותבים לקמאל איך לקבל את הסודות שמפורטים ברשימת הסודות בקובץ ה deploy. הנה הדוגמה מהתיעוד שלהם:

KAMAL_REGISTRY_PASSWORD=$KAMAL_REGISTRY_PASSWORD
RAILS_MASTER_KEY=$(cat config/master.key)

עכשיו הדוגמה הזאת בלבלה אותי כי השורה השנייה בה מתיחס לקובץ master.key של סביבת הפיתוח. בשביל שזה יעבוד בסביבת פרודקשן (אם יש לכם קובץ סודות שונה לפרודקשן) יש להחליף את השורה השנייה ולהשתמש במפתח config/credentials/production.key. צריך לזכור שהסודות עצמם של יישום ריילס שמורים מוצפנים בקובץ credentials ולכן עולים לגיט וגם יישמרו בתוך האימג'. המפתח לקריאת הסודות הוא הדבר היחיד שצריך להישמר מחוץ לגיט ולכן הדבר היחיד שצריך להעביר לקמאל. מחשבות להמשך אהבתי שקמאל לקח שרת שלא היה עליו כלום והתקין כל מה שצריך כדי להריץ שם דוקר ואז התחבר לבד ל letsencrypt ולקח סרטיפיקטים לדומיין שלי. אהבתי גם שכל ההתקנה היא בקונטיינרים ולכן יהיה לי קל לשדרג את השרת כשאצטרך בלי לשבור את היישום. בניסוי שלי לקחתי בסיס נתונים מנוהל על neon אז לא יצא לי לעבוד עם accessories, שזה מנגנון של קמאל לניהול בסיסי נתונים וסרביסים אחרים בדוקר. הבנתי שיש אפשרות לחבר את קמאל שירוץ מתוך Github Action אחרי קומיט או אחרי קומיט עם tag מסוים. סך הכל אני שמח שמנגנון הדיפלוימנט הופך להיות חלק מריילס והבחירה בקונטיינרים מאוד הגיונית. הדבר היחיד שיש לקטר עליו זה הגודל של הרג'יסטרי. נקודה נוספת שהפריעה לי בקמאל היא הקפיצה מגירסה 1 לגירסה 2. לא שאכפת לי שיש גירסה ישנה אלא שכל ניסיון לקבל עזרה מ AI על קמאל גרם לו לייצר קונפיגורציה לגירסה 1 או קונפיגורציה מעורבבת שהוא המציא. למידע נוסף על קמאל שווה לבקר אצלם בתיעוד בכתובת: https://kamal-deploy.org/

אופס שברתי את next את הקוד הבא כתבתי בטעות ואני מודה שהתוצאה הפתיעה אותי:

const data = await fetch('https://api.vercel.app/blog', {
    cache: 'no-store',
    next: {
        revalidate: 60
    }
})

הקוד עבד בפיתוח אבל גרם ל build להיתקע. בואו נבין מה קורה פה. למה ה build נתקע הבעיה עם הקוד היא שהעברתי שני ערכים מתנגשים באוביקט האופציות: 1. האופציה no-store ל cache גורמת ל next לא לשמור את התוצאה של ה fetch וכך למעשה להפוך כל עמוד שמשתמש בקוד הזה לדינמי. 2. האופציה revalidate גורמת ל next להשתמש במנגנון ISR. במנגנון זה ה fetch מחושב בזמן הבנייה אבל תוצאת הבנייה תישמר רק ל 60 שניות. בקשת העמוד אחרי 60 שניות תגרום ל next לבצע את ה fetch מחדש. בדרך כלל כשיש שתי אופציות מתנגשות לאחת מהן תהיה עדיפות, אבל במקרה של נקסט (בדקתי על גירסה 15.3) שילוב שתי האופציות גרם ל build להיתקע ולהיכשל ביצירת גירסת ה ISR. לכן ההמלצה שלי בעבודה עם נקסט היא לוותר על הגדרת cache: 'no-store' באופן גורף. כשצריכים בנייה דינמית אפשר להעביר ערך 0 ל revalidate וכך מקבלים את אותה התנהגות:

const data = await fetch('https://api.vercel.app/blog', {
    // same as cache: 'no-store'
    next: {revalidate: 0}
})

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

כמה זמן צריך להשקיע ב"להבין איך זה עובד"? בהינתן AI שיכול לכתוב את כל קבצי הקונפיגורציה של העולם, כמה זמן כדאי להשקיע בלהבין איך דברים עובדים? ומאיפה נמצא את המוטיבציה? חבר היה צריך להעלות מערכת ל AWS עם טרפורם. לפני 3 שנים הוא היה צריך לשבת שבועיים בקורס טרפורם ואחרי זה לבלות עוד שבועיים בכתיבת הקונפיגורציה ותיקון תקלות (ובסוף כנראה שעדיין היו נשארות בעיות שיתגלו רק אחרי חודשים או שנים). עכשיו אותו חבר יכול לתאר ל AI מה שהוא צריך ולקבל את כל הקונפיגורציה וזה אפילו עובד בפעם הראשונה. מה זה אומר עלינו, על המוטיבציה ללמוד ועל העתיד? כמה מחשבות: 1. כל מי שלמד כלים רק בשביל "לגרום לדברים לעבוד" עובר או יעבור ל AI. 2. כשאנשים שלא מבינים את הכלי מתארים ל AI מה הם רוצים יש החלטות שהם לא לוקחים. כשה AI לוקח החלטה זה קצת לוטו, לפעמים הוא מחליט נכון ולפעמים לא (תלוי בפרומפט, נתוני האימון ואלמנט של אקראיות). 3. בשלב מסוים ה AI כבר לא עוזר ואז נצטרך להחליט - ללמוד את הכלי בעצמנו, להיעזר בייעוץ או לכתוב משהו חדש עם AI אחר. בנקודה הזאת ללמוד את הכלי לבד יהיה מאתגר כי AI כותב קוד מאוד Verbose ומנסה לטפל בכל המקרים, כלומר קוד ארוך שלא תמיד ידידותי לבני אדם. והנה הבחירה שתמיד היתה, וה AI רק הופך אותה להרבה יותר קשה - כמה זמן צריך להשקיע ב"להבין איך זה עובד" בעידן ה AI? האם אני עדיין מרשה לעצמי לשבת שבועיים ללמוד טרפורם, כשה AI יכול לגרום לכל העסק לעבוד בעשר דקות? או אולי לוותר על הכלי המתוחכם ולעבוד רק עם כלים יותר פשוטים שאני כבר מכיר, ולתת ל AI לכתוב את הקונפיגורציה שלהם, אפילו שהיא תהיה יותר ארוכה ומסורבלת? והאבסורד כאן הוא ש"ללמוד להשתמש בכלי AI" זה ברובו פייק. 90% מהיכולת "להשתמש בכלי AI" היא בסך הכל הבנה מעמיקה של עולם התוכן הרלוונטי. ככל שאנחנו "נעזרים" יותר ב AI על חשבון ההבנה שלנו כך המיומנות שלנו בשימוש ב AI נפגעת.

[Symbol.asyncDispose]: async () => {
            await fh.close();
        },
    };
};
{
    const env_1 = { stack: [], error: void 0, hasError: false };
    try {
        const file = __addDisposableResource(env_1, await getFileHandle("thefile.txt"), true);
        const { fh } = file;
        fh.write('hello world');
    }
    catch (e_1) {
        env_1.error = e_1;
        env_1.hasError = true;
    }
    finally {
        const result_1 = __disposeResources(env_1);
        if (result_1)
            await result_1;
    }
} // Automatically disposed!

ולמה אני מספר לכם את כל זה עכשיו? הסיבה פשוטה ובכותרת. הפיצ'ר הגיעה השבוע ל node.js ותוכלו להשתמש בו גם בלי טייפסקריפט עם node 24. אני חושב שיש פה מדיניות של node.js לתמוך בטייפסקריפט בלי לקמפל לטייפסקריפט - מדיניות שהתחילה עם מנגנון ה strip types שלהם וממשיכה עם טיפול בפקודות הטייפסקריפט שלא קשורות רק לטיפוסים. עכשיו נשאר לחכות ל enum.

חדש ב node - ניקוי משאבים אוטומטי עם using טייפסקריפט 5.2 הגיעה פקודה חדשה בשם using שתפקידה לאפשר לנו לנקות אוטומטית משאבים, קצת כמו with של פייתון. המנגנון בנוי בשתי שכבות: 1. מקום אחד בקוד אחראי על יצירת המשאבים. אותו מקום שמקצה את המשאבים גם מגדיר את פונקציית הניקוי שלהם. 2. מקום אחר בקוד "מפעיל" את המקום שיוצר משאבים, מקבל משאב ובאופן אוטומטי טייפסקריפט מזהה מתי המשאב שיצרנו יוצא מ scope ומנקה אותו. טכנית זה עובד עם Symbol מיוחד בשם [Symbol.dispose]. הקוד שיוצר משאבים מחזיר אוביקט שאחד המפתחות בו הוא אותו Symbol.dispose, הערך של המפתח הזה הוא פונקציית הניקוי וכשצריך למחוק את המשאב טייפסקריפט יפעיל את הפונקציה. דוגמה פשוטה לקוד שפותח קובץ נראית כך:

import { open } from "node:fs/promises";

const getFileHandle = async (path: string) => {
  const fh = await open(path, "w");

  return {
    fh,
    [Symbol.asyncDispose]: async () => {
      await fh.close();
    },
  };
};

הפונקציה פותחת קובץ ומחזירה גם את הקובץ וגם את פונקציית הסגירה באוביקט אחד, כשפונקציית הסגירה נשמרת במפתח Symbol.dispose או אם היא אסינכרונית כמו בדוגמה זה יהיה Symbol.asyncDispose. במקום אחר בקוד אנחנו יוצרים את המשאב עם המילה החדשה using:

{
  await using file = await getFileHandle("thefile.txt");
  const { fh } = file;
  fh.write('hello world');
}

וכך ביציאה מהבלוק טייפסקריפט אוטומטי יודע להפעיל את פונקציית הניקוי. קוד הטייפסקריפט בדוגמה יהפוך לקוד ה JavaScript הבא:

var __addDisposableResource = (this && this.__addDisposableResource) || function (env, value, async) {
    if (value !== null && value !== void 0) {
        if (typeof value !== "object" && typeof value !== "function") throw new TypeError("Object expected.");
        var dispose, inner;
        if (async) {
            if (!Symbol.asyncDispose) throw new TypeError("Symbol.asyncDispose is not defined.");
            dispose = value[Symbol.asyncDispose];
        }
        if (dispose === void 0) {
            if (!Symbol.dispose) throw new TypeError("Symbol.dispose is not defined.");
            dispose = value[Symbol.dispose];
            if (async) inner = dispose;
        }
        if (typeof dispose !== "function") throw new TypeError("Object not disposable.");
        if (inner) dispose = function() { try { inner.call(this); } catch (e) { return Promise.reject(e); } };
        env.stack.push({ value: value, dispose: dispose, async: async });
    }
    else if (async) {
        env.stack.push({ async: true });
    }
    return value;
};
var __disposeResources = (this && this.__disposeResources) || (function (SuppressedError) {
    return function (env) {
        function fail(e) {
            env.error = env.hasError ? new SuppressedError(e, env.error, "An error was suppressed during disposal.") : e;
            env.hasError = true;
        }
        var r, s = 0;
        function next() {
            while (r = env.stack.pop()) {
                try {
                    if (!r.async && s === 1) return s = 0, env.stack.push(r), Promise.resolve().then(next);
                    if (r.dispose) {
                        var result = r.dispose.call(r.value);
                        if (r.async) return s |= 2, Promise.resolve(result).then(next, function(e) { fail(e); return next(); });
                    }
                    else s |= 1;
                }
                catch (e) {
                    fail(e);
                }
            }
            if (s === 1) return env.hasError ? Promise.reject(env.error) : Promise.resolve();
            if (env.hasError) throw env.error;
        }
        return next();
    };
})(typeof SuppressedError === "function" ? SuppressedError : function (error, suppressed, message) {
    var e = new Error(message);
    return e.name = "SuppressedError", e.error = error, e.suppressed = suppressed, e;
});
import { open } from "node:fs/promises";
const getFileHandle = async (path) => {
    const fh = await open(path, "w");
    return {
        fh,

https://hardcover.app/blog/part-1-how-we-fell-out-of-love-with-next-js-and-back-in-love-with-ruby-on-rails-inertia-js מסתבר שאני לא היחיד בעולם 😂

על מה הלך הזמן בפרויקט Unvibing בימים האחרונים אני מארגן מחדש קוד של פרויקט קטן שכתב AI. הקוד של ה AI מכיל בערך אלף שורות, עובד עם קצת באגים אבל בנוי כמו ספגטי וכבר מתחיל להיות קשה ל AI וגם לאנשים לתקן את הבאגים. מבחינת זמנים לוקח לי בערך 4-5 שעות על כל שעה של וייב קוד. אלה הדברים המרכזיים שלוקחים זמן: 1. ארכיטקטורה - ב Vibe Code אני כמעט לא מסתכל על הקוד וממקד את הפרומפט שלי במבנה הכללי ובפיצ'רים. במעבר השני על הקוד אני קורא כל שורה שה AI כתב, מבין מה הוא ניסה לעשות שם ומארגן את הקוד במקומות נכונים כדי שאפשר יהיה לעשות שימוש חוזר מושכל בקטעים שחוזרים על עצמם. רק זה לפני שמגיעים לשנות מימושים חותך בערך 30% מהקוד שה AI כתב. 2. ניקיון ותיקון מימושים - קוד של AI עובד אבל לא תמיד משתמש ב APIs הכי חדשים, עבודה עם ספריות חיצוניות עדיין קשה לו ואין לו הבנה של מה חשוב ומה לא ולכן לפעמים הקוד יעשה יותר מדי כשלא צריך ולפעמים לא יעשה מספיק דברים שכן צריך. לא פעם מצאתי אותו שומר ערך זמני למשתנה ממנו הוא לעולם לא יקרא, או מתאמץ מאוד לארגן מחדש מבנה של מידע מבסיס הנתונים מקום לשמור מראש את המידע בצורה שתהיה יותר קלה לעיכול, או כותב המון קוד כדי שהאפליקציה תיראה נכונה אפילו שיש טעות ב Data (ואז כשמגיע Data אחר ונכון רואים את הבאג). 3. זמן לימוד - רוב הזמן אני מבין את הקוד של ה AI אבל לפעמים הוא משתמש בתבניות או יכולות שלא הכרתי, לדוגמה בקוד JavaScript היה שימוש ב Passive Event Listeners שלא הכרתי והייתי צריך להשלים פערים. סך הכל העובדה שיש את כל הקוד כתוב ואפשר להתמקד בחשיבה ובארכיטקטורה מאוד עוזרת להגיע בסוף למערכת טובה יותר. שמתי לב גם שככל שה AI משתמש בפחות ספריות ב Vibe Coding ככה יותר קל לי לעבור על הקוד שלו בסיבוב שני כי אין חשש שהוא ישתמש בספריה שאני לא מכיר וכך אני חוסך זמן לימוד של משהו שלא בטוח אצטרך.

הספריה ההיא שאף אחד לא מכיר מאפיין מרכזי של שפת תכנות או פריימוורק הוא כמה אפשר "להתאים" את הספריה לסביבה משתנה. מבחן טוב יהיה להסתכל על פרויקטים אמיתיים ולבדוק באיזה סביבות משתמשים באותה ספריה וכמה הן שונות אחת מהשנייה. ריאקט היא דוגמה לספריה שיכולה להתאים לכל חור: 1. היא רצה בצד לקוח ובונה DOM 2. היא רצה בצד שרת ובונה מחרוזת HTML 3. אפשר לחבר אותה לקומפוננטות של Mobile ולקבל אפליקציות. 4. אפשר לחבר אותה לקומפוננטות של מיילים ולקבל אימיילים ריספונסיביים. 5. אפשר לבנות איתה יישומי Text UI. 6. אפשר לבנות איתה Prompt-ים ל AI (כן הפרומפט של קרסר נבנה בצורה דינמית בכתיב JSX). בצד השני סטימולוס היא ספריית JavaScript שלכאורה מתאימה לכל מקום, אבל תכל'ס היא מתאימה כמו כפפה ליד לפרויקטי ריילס ולהם בלבד. מבחינתנו כמתכנתים יש ייתרון עצום ללימוד ספריה כמו ריאקט, כי נוכל להשתמש בה בכל מקום ובכל הזדמנות. ספריות כמו סטימולוס נראות כמו Dead End מבחינת קריירה - אתה לומד אותן לקראת עבודה על פרויקט ריילס ושוכח כשעובר לעבוד על פרויקט מסוג אחר. ובכל זאת אני חושב שמתכנתים טובים צריכים להכיר את שני סוגי הכלים, גם את הכלליים וגם את הספציפיים: 1. כלים ספציפיים נותנים לנו הבנה טובה יותר של תפיסת העולם עבורה הם נוצרו. היכרות עם סטימולוס (או htmx שמקביל לו) תלמד אתכם לעבוד טוב יותר עם מערכות Rails ו Django וקוד הפרונט אנד שלהן. 2. כלים ספציפיים נותנים לנו השראה, בגלל שהפיתרונות שלהם כל כך מדויקים ותפורים לבעיה. סטימולוס היא ספרייה הרבה יותר קטנה מריאקט וביישומי ריילס הרבה פעמים תתן ביצועים טובים יותר. אפילו אם אני כותב React ו Rails עדיין טוב שיש לי למה להשוות ולמה לשאוף מבחינת גודל קבצי ה JavaScript. 3. כלים ספציפיים מלמדים אותי עוד פרדיגמת פיתוח, מה שעוזר לי להגיע לפיתרונות יותר יצירתיים לבעיות בעתיד. בעבודה על פרויקטים גדולים עם הרבה אנשים יש ייתרון עצום לבחירה בטכנולוגיות שכולם מכירים, אבל בעבודה על פרויקטי צד אני משתדל לשלב תמיד ספריה או שתיים שלא עבדתי איתן ולא אעבוד איתן יותר שוב.