דף זה תורגם על ידי Cloud Translation API.

ההבדל בין ספריות JavaScript ו-frameworks

עומר האנסה

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

הדיונים בפוסט זה מתמקדים בהבדלים איכותניים ולא בהבדלים הכמותיים בין ספריות ומסגרות. לדוגמה:

כמותית: מסגרות בדרך כלל פועלות בהתאם לעקרון היפוך השליטה.
איכותית: חוויית השימוש ב-framework יכולה למשוך יותר מעסיקים עתידיים כשמחפשים עבודה.

למה כדאי ללמוד על ספריות ותבניות framework?

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

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

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

דוגמאות לספריות ולמסגרות

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

עבור ספרייה, קוד האפליקציה מבצע קריאה לקוד הספרייה.
במסגרת, ה-framework קורא לקוד האפליקציה שלכם.

ספרייה

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

הנה דוגמה לספרייה lodash:

import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello

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

הצהרת import מייבאת את ספריית Lodash לתוכנית ה-JavaScript.
השיטה capitalize() מופעלת.
ארגומנט אחד מועבר לשיטה.
הערך המוחזר מתועד במשתנה.

מסגרת

המסגרות בדרך כלל גדולות יותר מספריות ותורמות יותר למשקל הכולל של הדף. למעשה, framework יכול לכלול ספרייה.

בדוגמה הזו מוצגת מסגרת פשוטה ללא ספרייה, ומשתמשת ב-Vue, שהיא מסגרת פופולרית של JavaScript:

<!-- index.html -->
<div id="main">
  {{ message }}
</div>

<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';

new Vue({
  el: '#main',
  data: {
    message: 'Hello, world'
  }
});
</script>

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

קוד ה-framework כולל כמה טכניקות, ומפשט אותן לממשק API מקובע משלו.
למפתחים אין שליטה מלאה על האופן והמועד של ביצוע פעולות. לדוגמה, האופן והמועד שבהם Vue כותב את המחרוזת 'Hello, world' בדף מופשט ממך.
ליצירת המחלקה Vue יש כמה אפקטים לוואי, שנפוצים כשמשתמשים ב-frameworks, ואילו ספרייה עשויה להציע פונקציות טהור.
ה-framework קובע מערכת ספציפית של תבניות HTML במקום להשתמש במערכת משלכם.
אם תקראו לעומק את מסמכי התיעוד של Vue framework או את רוב מסמכי ה-framework האחרים, תוכלו לראות איך ה-frameworks מתארות תבניות ארכיטקטוניות שבהן אתם יכולים להשתמש. מסגרות JavaScript מונעות מכם קשיים קוגניטיביים, כי אתם לא צריכים לגלות את זה בעצמכם.

מתי כדאי להשתמש בספרייה ומתי כדאי להשתמש ב-framework

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

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

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

יכולת החלפה

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

קשה יותר להסיר חבילה שקשורה לקוד המקור ולהחליף אותה בחבילה אחרת. יכול להיות שתצטרכו להחליף חבילה במקרים הבאים:

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

עיין בדוגמה זו:

// header.js file
import color from '@package/set-color';
color('header', 'dark');

// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');

// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');

בדוגמה הקודמת השתמשנו בחבילה @package/set-color של צד שלישי בשלושה קבצים נפרדים. אם אתם עובדים על הקוד הזה ואתם צריכים להחליף את חבילת הצד השלישי, עליכם לעדכן את הקוד בשלושה מקומות.

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

// lib/set-color.js file
import color from '@package/set-color';

export default function color(element, theme = 'dark') {
  color(element, theme);
}

// header.js file
import color from './lib/set-color.js';
color('header');

// article.js file
import color from './lib/set-color.js';
color('.article-post');

// footer.js file
import color from './lib/set-color.js';
color('.footer-container');

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

קלות השימוש

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

ל-framework יש API מורכב מטבעו.
מסגרת העבודה אינה מתועדת כראוי ונדרשות הרבה ניסיונות ושגיאות כדי לפתור בעיות.
המסגרת כוללת טכניקות לא מוכרות לכם ולצוות שלכם.

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

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

בדרך כלל הנקודות האלה משויכות ל-frameworks, אבל אפשר לשייך אותן גם לספריות. לדוגמה, ספריית ה-JavaScript D3.js היא בעלת עוצמה רבה ויש לה סביבה עסקית גדולה שמציעה סדנאות, מדריכים ותיעוד, בין היתר, וכל הגורמים האלה משפיעים על קלות השימוש בה.

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

ביצועים

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

עץ רועד

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

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

כשאתם מייבאים קוד של צד שלישי לקוד המקור, אתם בדרך כלל אוגדים את הקוד בקובץ פלט אחד או בכמה קובצי פלט. לדוגמה, כל הקבצים header.js, footer.js ו-sidebar.js משולבים בקובץ output.js, שהוא קובץ הפלט שטוענים באפליקציית האינטרנט.

כדי להבין טוב יותר את רעידת העצים, כדאי לעיין בדוגמאות הקוד הבאות:

// library.js file
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// main.js file
import {add} from './library.js';

console.log(add(7, 10));

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

תהליך של חבילה נייבית עשוי לייצא את הקוד עם הפלט הזה:

// output.js file
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

console.log(add(7, 10));

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

// output.js file
function add(a, b) {
  return a + b;
}

console.log(add(7, 10));

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

console.log(7+10);

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

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

עדכוני תוכנה

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

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

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

תעסוקה

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

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

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

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

סיכום

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

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