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

בן אדם קם בבוקר פותח את הפייסבוק לבדוק- מה חדש?

ממשיך לטוויטר, לעיתון, לאינסטוש, ללינקדאין- ותמיד אותה שאלה: מה חדש? מה קרה עכשיו?

וזה כמובן בזבוז זמן טוטאלי.

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

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

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

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

ספריית jQuery נוצרה כדי לתת לנו ממשק עבודה טוב יותר עם ה DOM. בתקופה ש jQuery התחילה כל דפדפן סיפק פונקציות שונות כדי לחבר בין קוד JavaScript לבין התוכן שאתם רואים על הדף. ג'ון רסיג כתב את jQuery ב 2005 בזמן שלמד בקולג' במטרה לתת למתכנתים (ולעצמו) כלים טובים יותר לגשת ל DOM ולחבר קוד טיפול באירועים בצורה שעובדת טוב בכל הדפדפנים.

בשנה הראשונה של jQuery היא היתה הספריה היחידה שהגיעה עם תיעוד מלא. כל שאר הספריות שלחו אתכם להסתכל בקוד המקור שלהן או להבין דברים לבד. מאפיין זה יחד עם ארכיטקטורת פלאגינים שבנויה לתוך הספריה הפכו אותה מ"עוד ספריה לגישה ל DOM" לספריה המרכזית שאנשים בוחרים בה ב 2006, ב-2012 וכן גם ב 2018.

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

שתי יכולות של תקשורת Ajax ב jQuery מחזירות את הסיפריה הוותיקה לחיים והופכות את השימוש בה להרבה יותר מהנה מכל API מקביל שיש בדפדפן. הראשונה היא השימוש ב Promises והשניה היכולת לקבוע Headers בצורה גלובאלית לכל בקשות התקשורת בעמוד.

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

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

ספריית jQuery התחילה עם רעיון פשוט וגאוני: לבנות API טוב יותר ואמין יותר עבור ה DOM. בימים שהם התחילו המצב היה הרבה יותר גרוע ממה שהוא היום והצורך ב API אמין לחיבור בין JavaScript לאלמנטים על המסך היה מאוד בולט.

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

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

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

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

אבל מהר מאוד עלתה שאלה יותר קשה- איך מתחילים? איך מתחילים ללמוד ריילס, או אנגולר, או CSS?

אז הלכתי ליודמי כדי לשמוע איך אנשים מלמדים CSS. שלושת הקורסים המובילים נראו כך: קורס אחד כלל 11 שעות במהלכן אתם צופים במישהו כותב דף HTML/CSS. קורס שני הציע 28 שעות וידאו והפעם המדריך כתב שני פרויקטים מלאים. הקורס השלישי נשמע לי הכי מעניין כיוון שלא כלל פרויקטים ובמקום נראה שהסביר מאוד לעומק על כל פיצ'ר מה המשמעות שלו ומתי נשתמש בו. הבעיה שזה לוקח 22 שעות של וידאו שבמהלך לא בונים כמעט שום דבר מעניין.

אבל האמת שאם מישהו ישאל אותי איך ללמוד CSS ההמלצה שלי היא על הקורס הזה של סקרימבה:

https://scrimba.com/g/gintrotocss

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

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

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

כשהבעיות הופכות יותר מורכבות האימות נהיה קשה יותר אבל הרבה פעמים עדיין אפשרי. אם יש לך בעיה בקוד מקבילי שנובעת מ Race Condition בין התהליכונים השונים אז צריך יותר להתאמץ כדי לראות את הבעיה בסביבת בדיקות ואולי להוסיף המתנות יזומות כדי שמקרה הקצה באמת יקרה יותר פעמים. או אם יש לכם בעיית ביצועים בשרת רק במצב של עומס מסוים אז צריך להתאמץ ולסמלץ את אותו העומס בסביבת הבדיקות כדי שנוכל לבדוק אם השינוי שלנו פותר את הבעיה.

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

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