สำหรับนักออกแบบที่ทำงานสายอาชีพนี้ เว็บไซต์พอร์ตโฟลิโอถือเป็นจุดกึ่งกลางที่ค่อนข้างก้ำกึ่ง มันต้องดูดี โหลดได้ทันที และต้องทันสมัยอยู่เสมอโดยไม่เบียดบังเวลาทำงานที่ต้องคิดเงินลูกค้า (billable hours) การตั้งค่าเดิมของผมอยู่บน Webflow ซึ่งช่วยเชื่อมช่องว่างระหว่างเครื่องมือแบบลากวาง (drag-and-drop) กับผลลัพธ์ระดับมืออาชีพได้ดีกว่าเครื่องมือส่วนใหญ่ แต่เมื่อใบแจ้งเตือนการต่ออายุส่งมาพร้อมบิลรายปี 300 ปอนด์ ผมก็ต้องตั้งคำถามสำคัญกับตัวเองว่า: ผมกำลังจ่ายเพื่อความคุ้มค่า หรือแค่จ่ายเพื่อความสะดวกสบายกันแน่?

ผมตัดสินใจสร้างมันขึ้นมาใหม่ตั้งแต่ต้น โดยใช้ stack ใหม่คือ Astro และ Sanity หลังจากใช้งานมาสักพัก นี่คือสิ่งที่ได้ผล สิ่งที่ไม่ได้ผล และสิ่งที่มันตอบโจทย์เมื่อเทียบกับเครื่องมือที่ผมเคยใช้ก่อนหน้านี้

ทำไมต้องเป็น Astro สำหรับพอร์ตโฟลิโอ?

เฟรมเวิร์กเว็บสมัยใหม่ส่วนใหญ่มักจะส่ง JavaScript มาให้ก่อนแล้วค่อยจัดการเรื่องอื่นทีหลัง แต่ Astro พลิกสมมติฐานนั้น มันจะสร้างไฟล์ HTML แบบ static ธรรมดาในขั้นตอน build time และจะส่ง JavaScript ไปยังเบราว์เซอร์ก็ต่อเมื่อคอมโพเนนต์นั้นๆ จำเป็นต้องใช้จริงๆ เท่านั้น พวกเขาเรียกสิ่งนี้ว่า islands architecture แต่ผลลัพธ์ในทางปฏิบัติที่เข้าใจง่ายกว่าคือ: หน้าพอร์ตโฟลิโอของผมแทบจะไม่มีน้ำหนักเลย

การทำ Routing เป็นแบบ file-based ดังนั้นการสร้างหน้าใหม่จึงง่ายพอๆ กับการลากไฟล์ไปวางในโฟลเดอร์ ส่วนคอมโพเนนต์ต่างๆ ก็ใช้ไวยากรณ์ (syntax) ที่คุณจะคุ้นเคยหากเคยสัมผัส React, Vue หรือ Svelte ผมไม่ต้องเริ่มเรียนรู้กระบวนทัศน์ (paradigm) ใหม่ทุกครั้งที่ต้องการเพิ่มกรณีศึกษาของโปรเจกต์ (project case study)

อย่างไรก็ตาม ผมจะไม่ใช้ Astro เพื่อสร้างเว็บแอปพลิเคชันที่มีความซับซ้อน หากคุณกำลังทำระบบยืนยันตัวตน (authentication), การจัดการ global state หรือการจัดการข้อมูลแบบ real-time คุณจะต้องต่อสู้กับเฟรมเวิร์กนี้ แต่สำหรับเว็บไซต์การตลาด บล็อก และพอร์ตโฟลิโอ มันจะไม่เข้ามาเกะกะ หน้าเว็บจะรู้สึกเร็วเพราะมันเร็วจริงๆ โดยไม่มี hydration overhead มาคอยรอเรนเดอร์หัวข้อหรือย่อหน้า

การเปลี่ยนจาก WordPress มาเป็น Sanity

ก่อนการสร้างใหม่ครั้งนี้ ทางเลือกสำรองของผมคือ WordPress ร่วมกับ Advanced Custom Fields (ACF) เสมอ ACF มอบพลังพิเศษให้กับ WordPress แต่คุณก็ยังคงต้องปรับแต่งภายใน "บ้าน" ของคนอื่นอยู่ดี ในขณะที่ Sanity ทำงานในทางตรงกันข้าม คุณเขียน schema ด้วยโค้ดที่กำหนดว่าโมเดลเนื้อหาของคุณจะมีหน้าตาอย่างไร และ Sanity จะสร้างอินเทอร์เฟซสำหรับการแก้ไขขึ้นมารอบๆ การตัดสินใจของคุณ

ผมใช้การควบคุมนั้นในการสร้าง page builder อย่างง่ายจากบล็อกที่นำกลับมาใช้ใหม่ได้ (reusable blocks) ผมกำหนด hero section ไว้ครั้งเดียว กำหนด testimonial carousel ไว้ครั้งเดียว และกำหนด card grid ไว้ครั้งเดียว ตอนนี้ผมสามารถประกอบหน้าใหม่ๆ ได้ด้วยการวางบล็อกเหล่านั้นซ้อนกันในลำดับใดก็ได้ โดยไม่ต้องเขียนโค้ดใหม่หรือแตะต้อง page template เลย

ความแตกต่างในด้านวิธีคิดนั้นสำคัญมาก เมื่อใช้ WordPress ผมมักจะรู้สึกเหมือนกำลังต่อสู้กับเครื่องมือที่อยากจะเป็นแค่บล็อก แต่เมื่อใช้ Sanity ผมรู้สึกเหมือนกำลังสร้างซอฟต์แวร์ เนื้อหาจะกลายเป็นข้อมูลที่มีโครงสร้าง (structured data) ที่สะอาด แทนที่จะเป็น HTML ที่ผสมปนเปไปกับ shortcodes คำอธิบายโปรเจกต์ของผมจะอยู่ในรูปแบบของออบเจกต์ที่พกพาไปใช้ได้ ไม่ว่าจะเป็นการส่งเข้าไปในโมบายแอปหรือจดหมายข่าวหากผมต้องการ

เวิร์กโฟลว์การ Deployment ที่สะอาดและเป็นระเบียบ

เวิร์กโฟลว์ WordPress แบบเดิมของผมวุ่นวายไปด้วยการอัปโหลดผ่าน FTP, การใช้ staging subdomains และการอัปเดตปลั๊กอินที่ดูเหมือนจะพังในจังหวะที่แย่ที่สุดเสมอ ผมต้องมีรายการตรวจสอบในใจเพียงเพื่อจะแก้ไขคำผิดเล็กๆ น้อยๆ

เวิร์กโฟลว์ใหม่นั้นสั้นและง่าย:

  • ผมแก้ไขงานในเครื่อง (locally) และเห็นผลได้ทันที
  • ผม commit งานลง GitHub เมื่อโค้ดพร้อมแล้ว
  • Vercel จะดึงการ push นั้นไป deploy เว็บไซต์โดยอัตโนมัติ

ไม่มี FTP client ไม่ต้องมีฐานข้อมูล staging เพื่อซิงค์ข้อมูล ตัว repository คือแหล่งข้อมูลที่ถูกต้องที่สุด (source of truth)

เนื้อหาก็ทำงานในลักษณะเดียวกัน เมื่อผมเผยแพร่หรืออัปเดตโพสต์ใน Sanity ตัว webhook จะบอกให้ Vercel ทำการ rebuild เว็บไซต์ หน้าเว็บแบบ static จะถูกสร้างขึ้นใหม่พร้อมเนื้อหาที่สดใหม่ และ CDN จะอัปเดตโดยที่ผมไม่ต้องแตะต้องเซิร์ฟเวอร์เลย ทุกอย่างซิงค์กันโดยไม่ต้องคัดลอกด้วยมือ, ส่งออกข้อมูล หรือภาวนาว่าการย้ายฐานข้อมูลของปลั๊กอินจะทำงานได้จริง

การเชื่อมโยงงานดีไซน์และโค้ดเข้าด้วยกันด้วย tokens

หนึ่งในการค้นพบที่เงียบเชียบแต่สำคัญในการสร้างใหม่ครั้งนี้ คือการตั้งระบบ token ที่เหมาะสม ผมเก็บไฟล์ JSON เพียงไฟล์เดียวที่ควบคุมทุกอย่าง ทั้งสี, type scale และค่า spacing ในเว็บไซต์ ไฟล์นั้นคือหัวหน้าใหญ่

ผมใช้ Token Studio เพื่อดึงค่าเหล่านั้นเข้าสู่ Figma โดยตรง เมื่อไฟล์ดีไซน์ของผมระบุว่า surface-default มันจะชี้ไปยังตัวเลขเดียวกันกับที่โค้ดใช้ สคริปต์ขนาดเล็กจะแปลง JSON เป็น CSS custom properties ในขั้นตอน build time ดังนั้น stylesheet ของผมจะอ้างอิงตัวแปรอย่าง --color-surface-default แทนที่จะเป็นรหัสสี hex แบบ hardcoded

นี่คือเหตุผลว่าทำไมมันถึงสำคัญในทางปฏิบัติ หากผมพบว่าสีแดงประจำแบรนด์ดูแรงเกินไปเล็กน้อยบนหน้าจอมือถือ ผมแค่เปลี่ยนค่าเดียวในไฟล์ JSON ไลบรารีใน Figma จะอัปเดต CSS จะอัปเดต และทุกจุดที่ใช้งานในเว็บไซต์จะอัปเดตตาม ผมไม่จำเป็นต้อง grep