עבור מעצב מקצועי, אתר פורטפוליו נמצא בנקודת אמצע לא נוחה. הוא צריך להיראות חד, להיטען באופן מיידי, ולהישאר מעודכן מבלי לגזול שעות חיוב. המערך הישן שלי התבסס על Webflow, שגישר בין בוני אתרים מסוג drag-and-drop לבין תוצר מקצועי טוב יותר מרוב הכלים. אבל כשהגיעה הודעת החידוש עם חשבון שנתי של £300, נאלצתי לשאול שאלה קשה: האם שילמתי על ערך, או רק על נוחות?

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

למה Astro עבור פורטפוליו?

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

הניתוב (Routing) מבוסס קבצים, כך שיצירת דף חדש מרגישה קלה כמו גרירת קובץ לתוך תיקייה. הרכיבים (Components) משתמשים בתחביר שירגיש מוכר אם נגעתם ב-React, Vue, או Svelte. אני לא נאלץ לאמץ פרדיגמה חדשה בכל פעם שאני רוצה להוסיף מקרה בוחן (case study) של פרויקט.

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

המעבר מ-WordPress ל-Sanity

לפני הבנייה מחדש הזו, ברירת המחדל שלי הייתה תמיד WordPress עם Advanced Custom Fields. ACF מעניק ל-WordPress כוחות על, אבל אתם עדיין מגדירים את הבית של מישהו אחר. Sanity עובדת הפוך. אתם כותבים סכימה בקוד שמגדירה בדיוק איך מודל התוכן שלכם נראה, ו-Sanity בונה את ממשק העריכה סביב ההחלטות שלכם.

השתמשתי בשליטה הזו כדי לבנות בונה דפים (page builder) פשוט מבלוקים ניתנים לשימוש חוזר. הגדרתי hero section פעם אחת. הגדרתי קרוסלת עדויות (testimonial carousel) פעם אחת. הגדרתי גריד של כרטיסים (card grid) פעם אחת. עכשיו אני יכול להרכיב דפים חדשים על ידי ערמת הבלוקים הללו בכל סדר שרוצים, מבלי לכתוב קוד חדש או לגעת בתבנית דף.

ההבדל בתפיסה הוא קריטי. עם WordPress, הרגשתי לעיתים קרובות שאני נאבק בכלי שרוצה להיות בלוג. עם Sanity, אני מרגיש שאני בונה תוכנה. התוכן הופך לנתונים מובנים (structured data) נקיים במקום HTML מעוצב מעורבב עם shortcodes. תיאורי הפרויקטים שלי חיים כאובייקטים ניידים שאני יכול להזרים לאפליקציית מובייל או לניוזלטר אם ארצה.

תהליך פריסה (deployment workflow) נקי

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

תהליך העבודה החדש הוא קצר:

  • אני מבצע שינויים מקומית ורואה אותם מיידית.
  • אני מבצע commit ל-GitHub כשהקוד מרגיש נכון.
  • Vercel קולט את ה-push ופורס את האתר באופן אוטומטי.

אין לקוח FTP. אין מסד נתונים של staging לסנכרן. ה-repository הוא מקור האמת (source of truth).

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

חיבור עיצוב וקוד באמצעות tokens

אחת הפריצות המשמעותיות השקטות בבנייה מחדש הזו הייתה הקמת מערכת tokens מסודרת. אני שומר קובץ JSON יחיד שמחזיק כל צבע, סקאלת טיפוגרפיה (type scale) וערך ריווח (spacing) באתר. הקובץ הזה הוא הבוס.

אני משתמש ב-Token Studio כדי למשוך את אותם ערכים ישירות לתוך Figma. כשהקובץ העיצובי שלי אומר surface-default, הוא מצביע בדיוק על אותו מספר שהקוד משתמש בו. סקריפט קטן ממיר את ה-JSON ל-CSS custom properties בזמן ה-build, כך שגיליונות העיצוב שלי מתייחסים למשתנים כמו --color-surface-default במקום לקודי hex קשיחים (hardcoded).

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