מדוע שמישהו ירצה להשתמש ב-nodejs?

[silent_enigma]

למדתי nodejs ב-2013. השתמשתי בזה עבור כ-10 פרוייקטים, עד 2017 (מבחירה ושלא מבחירה).
כיום כשיוצא לי לעתים לעבוד על הפרוייקטים האלה, אני פשוט לא מבין מדוע שמישהו ירצה להשתמש בדבר הזה.
אני מבין את המשיכה לשימוש בידע קיים ב-JS, קידוד מהיר, קהילת קוד פתוח, וכו׳.
אבל העסק הזה לא רציני בעליל.

• ה-static analysis מחורבן, לא משנה באיזה כלי משתמשים. חייבים להתבסס חיפוש באינטרנט של דוקומנטציה שלרוב אינה קיימת, ולקוות לטוב.
• לא ניתן לעשות parallelism.
• ה-async/await בכל מקום הוא מגוחך במקרה הטוב. במקרה הפחות טוב זה אסון.
• קשה מאוד לשמור על codebase ברמה תחזוקה סבירה כאשר יש הרבה ידיים עובדות.
• הקומפיילר, בין אם קיים (עבור Typescript) או לא, לחלוטין אינו עוזר במציאת באגים, ומעביר את האחריות לכך למשתמשי קצה מסכנים.
• ההסתמכות האינסופית על events מובילה כמעט תמיד לקוד ספגטי.
• צריך להשתמש בכל מיני טריקים מתוחכמים כדי לקבל פיצ׳רים מודרניים של JS.
• ה-stacktrace כמעט תמיד שבור.
• מתכנתים שעובדים בסביבה הזו מתנוונים כי הם לא מתעסקים בבעיות של thread safety (אשר ידועות בקושי שלהן).

אני לא מאשים את Ryan Dahl. הוא בעצמו נוטה להתנער מהגולם הזה. ברור שרוב הבעיות הגיעו והינן מ-JS.
מישהו יכול להסביר לי מדוע אדם שפוי בנפשו ירצה להשתמש בדבר הזה (עבור משהו שאינו PoC של כמה ימים)?
אם רוצים שפה\פריימוורק מודרני, מה הבעיה ללמוד ולהשתמש במשהו פשוט כמו Go?

הרעיון של thread אחד שאינם חוסם הוא נחמד. הרעיון להשתמש ב-JS למודל הזה גם הוא היה נחמד.
אבל ברור שהחסרונות של המודל הזה גדולים מן היתרונות (שניתן להשיג בדרכים אחרות).

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

 

[BravoMan]

למזלי, אני לא כותב back או front end, ולכן ניסיתי ללמוד JS רק מתוך סקרנות לצרכי העשרה אישית, אבל אני מאוד מזדהה עם התלונות שאני רואה פה.

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

on error resume next

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

 

[Be1n]

הייתי רוצה לשמוע את דעתך על Django

 

[AnarchistPhilosopher]

הייתי רוצה לשמוע את דעתך על Django

אין עליו...

 

[silent_enigma]

הייתי רוצה לשמוע את דעתך על Django

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

 

[Be1n]

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

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


האמת שהסינטקס אכן מוזר ואפילו הייתי אומר "עני" , אבל Django מאוד שונה (להבנתי הטרייה) מ Node.Js והיא מכילה בתוכה הרבה אפשרויות.

 

[silent_enigma]

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


האמת שהסינטקס אכן מוזר ואפילו הייתי אומר "עני" , אבל Django מאוד שונה (להבנתי הטרייה) מ Node.Js והיא מכילה בתוכה הרבה אפשרויות.

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

 

[Be1n]

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

זה בסדר לקחתי את זה בהומור..

פייתון פשוט נראית לי כשפה שעולה בפופולריות שלה ולכן בחרתי בה (מאוד ייתכן שאני טועה)

 

[choo]

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

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

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

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

במילותיו של Lloyd Braun :

 

[קלייטון.ש]

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

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

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

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

במילותיו של Lloyd Braun :

JS היא שפה מקומפלת. מנוע V8 מקמפל אותה לקוד מכונה.

 

[choo]

JS היא שפה מקומפלת. מנוע V8 מקמפל אותה לקוד מכונה.

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

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

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

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

 

[קלייטון.ש]

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

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

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

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

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

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

 

[choo]

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

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

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

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

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

עדיין, היכולת של כלי אוטומטי כלשהו לזהות שגיאות טיפוסים ושגיאות תחביר מוגבלת על ידי אופי שפת התיכנות, ולכן הרבה שגיאות בשפות כמו js ופייתון לא יכולות להתגלות על ידי ה-IDE - אבל כן יכולים להתגלות על ידיו אם מדובר בשפות עם הגדרת טיפוסים סטטית. הפער הזה הוא אינהרנטי, ולא תלוי באיש המקצוע או ברמתו המקצועית של מפתח ה-IDE, ולכן השפות הללו, באופן אינהרנטי, פחות סקיילאביליות לפרוייקטים גדולים. במובן הזה, ג'אווה נותרה אחת מהשפות שמשלבות בין העולמות הללו, והעובדה שהיא הוחלפה על ידי השפות הללו היא גליץ' מצער של עולם פיתוח התוכנה (גם ג'אווה הביאה איתה את ערימת הנזקים שלה, בראשם צריכת זכרון הרבה יותר גדולה של אפליקציות ביחס לפיתוח אפליקציות דומות בשפות כמו ++C, אבל בזמן שבעיית צריכת הזכרון היא trade-off בין זמן פיתוח התוכנה למשאבים הדרושים להרצתה - הרי שמערכות טיפוסים דינמיות הן trade-off בין זמן פיתוח ראשוני של תוכנה, לבין הזמן להוצאת גרסה יציבה של התוכנה. יש דומיינים שלמים שבהם בעיית היציבות אוזנה על ידי ארכיטקטורה מבוזרת ומערכות שהן stateless בשילוב עם מערכות טרנזקציות ומערכות ניטור מתאימות - אבל לא בכל דומיין הפתרונות הללו מתאימים/מספקים, והבעיה היא שבהרבה מקרים האנשים שבוחרים את הטכנולוגיות לא מודעים לנקודות הללו בזמן בחירת הטכנולוגיה, ובפועל "דוחים את הקץ" עד שיגלו שהם למעשה שחו בלי בגד ים.

 

[Nuke1985]

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

בשנים האחרונות נראה שזה נכנס למיינסטריים העניין הזה של gradual typing, כלומר אפשר להוסיף טיפוסים סטטיים בשפה דינמית או להפך (זה המצב בפייתון), מה שנותן להם יתרון על שפות סטטיות קלאסיות. אתה ייכול להשתמש בטיפוסים דינמיים אם הקוד קל להבנה (נניח סקריפט) או שמאוד חשוב ה time to market, ואחרי זה להוסיף טיפוסים כדי לשפר קריאות (ובאופן כללי גם בשפות סטטיות ודינמיות כנראה שעדיף שאיזה static analyzer יירוץ אוטומטית נניח אחרי שבוצע קומפילציה או commit, לא כדאי לסמוך על הקומפיילר יותר מדי כי עדיף שהוא לא יבצע אנליזות ארוכות ומסובכות שעלולות להאריך את זמן הקומפילציה).

 

[user32]

לכן TypeScript מוסיפה בדיוק את מה שחסר בJS מבלי להרוס את היתרונות של JS ושל node בכלל.

 

[קלייטון.ש]

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

 

[user32]

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

למה Node? יש המון סיבות ואת רובן תמצא במאמרים ברשת.

קודם כל נתחיל בשיטת אלימינציה:
דוט נט - אני אישית לא עובד בסביבות של מיקרוסופט או קוד סגור בכלל. אז יורד מהפרק.
פיתון - התחביר קצת ילדותי בעיניי ולא נוח. עניין של הרגל וסגנון אבל אני רגיל לנוחות של שפות ממשפחת הC: ג'אווה, C#, C++ וJS
וג'אווה שהיתה הבית שלי הרבה מאוד שנים הפכה למסורבלת ואיטית עד בלתי נסבלת. אולי בגרסאות האחרונות זה קצת השתפר אבל כל הקונטיינרים, הdependencies הלא נוחים, החוסר בכתיבה דינאמית. וכן, אני מניח שבג'אווה 10 חלק מהדברים נראים יותר טוב, אולי גם עם spring boot במקום הWAR והEAR הנוראיים ההם.

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

האסינכרוניות מאפשרת לך "לחכות" בלי לתפוס thread. תתפלא לשמוע כמה מתכנתים בכלל לא מודעים להבדל. שוב, בחזרה לג'אווה, כמעט כל מתכנת היה למשל מריץ שאילתה לDB ומעבד את התוצאה. אבל בזמן הרב שהשאילתא רצה (ורבע שניה זה המון!), הthread ממתין ותופס משאבים. זה בזבוז שבnode לא קיים. כשהתחלתי בnode זה היה לפני הasync/await ונאנקנו עם callbacks וPromises. עכשיו זה בכלל תענוג.

התכנות הדינאמי והחופש מאכיפת types הוא מאוד נוח. גם types זה חשוב ונוח ולכן TS מאפשר את השילוב של שניהם. לפעמים אתה רוצה לממש מודל מסודר ולפעמים אתה סתם רוצה לשלוח JSON עם 200 properties בלי לנהל קלאסים שלמים מאחוריהם.

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

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

 

[silent_enigma]

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

למה Node? יש המון סיבות ואת רובן תמצא במאמרים ברשת.

קודם כל נתחיל בשיטת אלימינציה:
דוט נט - אני אישית לא עובד בסביבות של מיקרוסופט או קוד סגור בכלל. אז יורד מהפרק.
פיתון - התחביר קצת ילדותי בעיניי ולא נוח. עניין של הרגל וסגנון אבל אני רגיל לנוחות של שפות ממשפחת הC: ג'אווה, C#, C++ וJS
וג'אווה שהיתה הבית שלי הרבה מאוד שנים הפכה למסורבלת ואיטית עד בלתי נסבלת. אולי בגרסאות האחרונות זה קצת השתפר אבל כל הקונטיינרים, הdependencies הלא נוחים, החוסר בכתיבה דינאמית. וכן, אני מניח שבג'אווה 10 חלק מהדברים נראים יותר טוב, אולי גם עם spring boot במקום הWAR והEAR הנוראיים ההם.

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

האסינכרוניות מאפשרת לך "לחכות" בלי לתפוס thread. תתפלא לשמוע כמה מתכנתים בכלל לא מודעים להבדל. שוב, בחזרה לג'אווה, כמעט כל מתכנת היה למשל מריץ שאילתה לDB ומעבד את התוצאה. אבל בזמן הרב שהשאילתא רצה (ורבע שניה זה המון!), הthread ממתין ותופס משאבים. זה בזבוז שבnode לא קיים. כשהתחלתי בnode זה היה לפני הasync/await ונאנקנו עם callbacks וPromises. עכשיו זה בכלל תענוג.

התכנות הדינאמי והחופש מאכיפת types הוא מאוד נוח. גם types זה חשוב ונוח ולכן TS מאפשר את השילוב של שניהם. לפעמים אתה רוצה לממש מודל מסודר ולפעמים אתה סתם רוצה לשלוח JSON עם 200 properties בלי לנהל קלאסים שלמים מאחוריהם.

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

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

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

אך למזלנו מאז הספיקו להתבסס 2 אלטרנטיבות מרשימות: Go ו-Rust.
ולאחר 3 שנים של שימוש קבוע בהם, כאשר יוצא לי לתחזק קוד JS (שלי או של אחרים), עולה בי השאלה שאיתה התחלתי את השרשור הזה.

וכן, Rust אכן לא קשורה לדיון הזה, כי מקרי השימוש שאליו היא מיועדת וקהל היעד שלה שונה לחלוטין מזה של JS (למרות שיש מצב שהיא תתחיל לנגוס ב-JS כבר בעתיד הקרוב, בעקבות התמיכה המצויינת שלה ב-Wasm).
אבל Go כן נמצאת בקו התפר בין שפה נמוכה ומסובכת כמו Rust, לשפת GC דינמית כמו JS, ולכן משעה שהיא הספיקה להתבגר ולהתבסס, אני לא מוצא סיבה הגיונית להמשיך להשתמש ב-nodejs ולא ב-Go כברירת מחדל.

מבוא מעניין על השפות למי שאינו מכיר: Rust, Julia, and Go: Disruptive New Programming Languages Changing the Face of Computing

לגבי עניין האסינכרוניות והת׳רדים - הנה מאמר שמסכם יפה את מה שיש לי להגיד על הנושא, ולמה אני חושב שהמודל ה-Async IO פגום: What Color is Your Function?

 

[user32]

אני מסכים לגבי GO. אם הייתי אוייבקטיבי לגמרי ולא תלוי בשום דבר, סיכוי טוב שהייתי נכנס לזה ברצינות.
אבל יש את בעיית הביצה והתרנגולת: אין מספיק מתכנתי GO בשוק, לא בטוח כמה קל לגייס מועמדים לשפה אקזוטית, לא יודע מה מצב האקוסיסטם והקהילה: ספריות, API, וכו'. כשאתה הולך על node, python, java, או אפילו דוט נט אתה הולך על בטוח. אין סיכוי שלא תמצא דרייבר/ספריה למה שאתה מחפש.
נפלתי בזמנו עם רובי און ריילס מהסיבות האלה ומאז החלטתי שאני לא אהיה ראשון לרוץ לשפה חדשה.

 

[silent_enigma]

אני מסכים לגבי GO. אם הייתי אוייבקטיבי לגמרי ולא תלוי בשום דבר, סיכוי טוב שהייתי נכנס לזה ברצינות.
אבל יש את בעיית הביצה והתרנגולת: אין מספיק מתכנתי GO בשוק, לא בטוח כמה קל לגייס מועמדים לשפה אקזוטית, לא יודע מה מצב האקוסיסטם והקהילה: ספריות, API, וכו'. כשאתה הולך על node, python, java, או אפילו דוט נט אתה הולך על בטוח. אין סיכוי שלא תמצא דרייבר/ספריה למה שאתה מחפש.
נפלתי בזמנו עם רובי און ריילס מהסיבות האלה ומאז החלטתי שאני לא אהיה ראשון לרוץ לשפה חדשה.

אני חושב ש-Go כבר עברה את שלב בעיית הביצה ותרנגולת, אבל כן, ביחס לשפות שציינת, מדובר עדיין בשפה אקזוטית.
אבל זו שפה שניתן ללמוד מהר ובקלות, כך שמבחינת חברות מוצר מבוססות שמעסיקות בעיקר Seniors, אין כאן סיכון, ואכן יש לא מעט חברות כאלה בארץ שהכניסו את Go לפיתוחי הליבה שלהם.
זה תקף גם מבחינת דרייברים וספריות. מצב האקוסיסטם הוא טוב, אבל גם אם לא תמצא את מה שאתה צריך ממומש ב-Go, בהנחה שהכל כבר קיים\נתמך עבור C, במקרה הכי גרוע תצטרך להשקיע כמה ימים בלעטוף את זה ב-cgo. זה רחוק מלהיות אידיאלי, אבל זה לא גרוע מהמצב בשפות אחרות (במקרים מסויימים ניתן גם להמיר קוד C ל-Go Assembly, מה שפותר את עניין הפינג פונג בין Go ל-C).

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