- Primo v3.2 แสดงเว็บไซต์ทั้งในรูปแบบไฟล์ภายในเครื่องและแถวข้อมูลในฐานข้อมูลบนเซิร์ฟเวอร์ ทำให้เอเจนต์แก้โค้ดได้ และผู้แก้ไขที่ไม่ใช่สายเทคนิคก็แก้เว็บไซต์เดียวกันผ่านเบราว์เซอร์ได้
- นักพัฒนาจัดการหน้าเว็บ เนื้อหา การตั้งค่า และเส้นทางด้วย คอมโพเนนต์ Svelte และไฟล์ YAML แล้วซิงก์กับฐานข้อมูลเชิงสัมพันธ์บนเซิร์ฟเวอร์ด้วย
primo push
- ตัวแก้ไขบนเบราว์เซอร์รองรับการแก้ข้อความบนหน้าที่เรนเดอร์แล้ว การลากวางบล็อก และการสร้างประเภทหน้าเว็บกับฟิลด์แบบกำหนดเอง จึงพึ่งพาหน้า CMS แบบฟอร์มเป็นศูนย์กลางน้อยลง
- กลุ่มเป้าหมายหลักคือ นักพัฒนา ฟรีแลนซ์ และเอเจนซีที่ต้องส่งมอบเว็บไซต์แบบปรับแต่งให้ผู้แก้ไขที่ไม่ใช่สายเทคนิค พร้อมสตาร์เตอร์ 12 แบบและบล็อกมากกว่า 40 แบบ
- เนื้อหาถูกเก็บใน SQLite ที่ทำงานบน PocketBase ส่วนโค้ดยังคงอยู่ในรีโพซิทอรีของผู้ใช้ และสามารถลดการผูกกับบริการได้ด้วยไลเซนส์ MIT และการส่งออกแบบสแตติกผ่าน
primo pull
โมเดล CMS ที่ใช้ทั้งไฟล์และฐานข้อมูลร่วมกัน
- Primo v3.2 เป็น CMS โอเพนซอร์สที่พัฒนาต่อเนื่องมาตั้งแต่ปี 2019 โดยแสดงทั้งเว็บไซต์เป็นทั้งไฟล์และแถวข้อมูลในฐานข้อมูลไปพร้อมกัน
- ไฟล์ภายในเครื่องใช้ให้เอเจนต์แก้โดยตรง ส่วนฐานข้อมูลบนเซิร์ฟเวอร์ใช้ให้คนแก้ไขแบบภาพผ่านเบราว์เซอร์
- เวิร์กโฟลว์หลักคือสร้างเว็บไซต์ด้วยเอเจนต์ก่อน แล้วค่อยส่งสิทธิ์แก้ไขผ่านเบราว์เซอร์ให้ลูกค้าหรือคนรู้จักภายหลัง
- ในตัวอย่าง
claude สร้างประเภทหน้าราคา เขียน pages/pricing.yaml, blocks/pricing-tiers/component.svelte แล้วนำส่ง 3 ไฟล์ด้วย primo push
- หลังดีพลอยแล้ว ผู้ใช้สามารถแก้ข้อความและราคาของแต่ละ tier ได้เองจากเบราว์เซอร์
โครงสร้างไฟล์ภายในเครื่องที่เอเจนต์จัดการ
primo pull จะดาวน์โหลดทั้งเว็บไซต์ออกมาเป็น ไฟล์ทั่วไป
- รวมคอมโพเนนต์ หน้าเว็บ เนื้อหา การตั้งค่า และเส้นทาง
- บล็อกเป็นคอมโพเนนต์ Svelte และเนื้อหากับการตั้งค่าเป็น YAML
- สามารถ scaffold เว็บไซต์ใหม่หรือดาวน์โหลดเว็บไซต์เดิมลงมาได้
- เอเจนต์แบบ CLI อย่าง Claude Code, Cursor และ Codex จะแก้ไขทั้งรีโพซิทอรี
- เป็นเวิร์กโฟลว์แบบแก้ทั้งโค้ดเบส คล้ายการทำงานกับโค้ดเบส Next.js หรือ SvelteKit
- คำสั่งตัวอย่างคือ
$ claude "redesign the pricing page"
primo push จะซิงก์ไฟล์ที่แก้ไขแล้วกับ ฐานข้อมูลเชิงสัมพันธ์ บนเซิร์ฟเวอร์
- ลูกค้าสามารถแก้เว็บไซต์เดียวกันบนเบราว์เซอร์ผ่านหน้าที่เรนเดอร์แล้ว
- ฟิลด์ที่บล็อกประกาศไว้จะถูกแสดงเป็นฟิลด์ที่แก้ไขได้
CMS ที่แก้ไขบนหน้าที่เรนเดอร์แล้ว
- ตัวแก้ไขทำงานบนหน้าที่เรนเดอร์แล้ว และไม่บังคับให้ต้องใช้แท็บ CMS แยกหรือมุมมองแบบฟอร์มเป็นประสบการณ์แก้ไขหลัก
- ทุกฟิลด์ที่บล็อกประกาศจะถูกแสดงเป็นพื้นผิวที่คลิกได้พร้อมป้ายกำกับ
- ใช้โมเดลเดียวกับที่ตัวเรนเดอร์อ่าน จึงไม่มีชั้นแปลงข้อมูลแยกต่างหาก
- การแก้ไขบนหน้าโดยตรง คือการคลิกข้อความบนหน้าที่เรนเดอร์แล้วแล้วพิมพ์แก้ได้ทันที
- ชิปฟิลด์จะแสดงว่ากำลังแก้ไขรายการใดอยู่
- บล็อกแบบลากวาง ช่วยให้จัดลำดับ เพิ่ม หรือลบบล็อกใน tree ของหน้า และบันทึกการเปลี่ยนแปลงกลับไปยังซอร์สได้ทันที
- ประเภทหน้าเว็บแบบกำหนดเอง ช่วยให้กำหนดรูปแบบหน้าหนึ่งครั้ง แล้วลูกค้าสร้างหน้าได้ตามต้องการโดยไม่ทำให้โมเดลเดียวกันเสีย
- ฟิลด์แบบกำหนดเอง รองรับข้อความ rich text รูปภาพ ลิงก์ ตัวเลข กลุ่ม และ repeater
- UI สำหรับแก้ไขจะถูกสร้างจากสคีมา
- การทำงานร่วมกันแบบเรียลไทม์ คือการที่หลายคนแก้หน้าเดียวกันพร้อมกันได้ รวมถึงการแสดงสถานะผู้ใช้งานสดและการแก้ไขแบบไม่เกิดคอนฟลิกต์
- มุมมองแบบฟอร์มเชิงโครงสร้างใช้กับฟิลด์ที่ไม่ปรากฏบนหน้า เช่น SEO เมทาดาทา repeater และการตั้งค่าที่ซ่อนไว้
สตาร์เตอร์และบล็อกสำหรับผู้สร้างเว็บไซต์แบบปรับแต่ง
- Primo มุ่งเป้าไปที่นักพัฒนา ฟรีแลนซ์ และเอเจนซีที่สร้าง เว็บไซต์แบบปรับแต่งสำหรับผู้แก้ไขที่ไม่ใช่สายเทคนิค
- Marketplace มีทั้งสตาร์เตอร์ตามประเภทลูกค้าและบล็อกเซกชันทั่วไป
- ตัวอย่างได้แก่สตาร์เตอร์สำหรับร้านอาหาร โค้ช พอร์ตโฟลิโอ และบริการท้องถิ่น
- ปัจจุบันมีสตาร์เตอร์ 12 แบบและบล็อกมากกว่า 40 แบบ
- แต่ละสตาร์เตอร์เป็น เว็บไซต์ที่สมบูรณ์ในตัวเอง
- มีทั้งคอมโพเนนต์ Svelte และฟิลด์ของประเภท
- ถูก scaffold ออกมาเป็นรีโพซิทอรี
- ไม่มี framework lock-in หรือ runtime ที่ซ่อนไว้
- ผู้ใช้สามารถ fork สตาร์เตอร์แล้วแก้ไขเพื่อนำไปใช้งาน หรือคัดสรรสตาร์เตอร์และบล็อกของตนเองได้
ความต่างจาก WordPress, Headless CMS และเว็บไซต์บิลเดอร์
- WordPress ให้เว็บไซต์ที่ลูกค้าแก้ไขได้ แต่ถูกเปรียบเทียบว่าเนื้อหาและธีม PHP พันกันอยู่
- Headless CMS ทำให้โครงสร้างโค้ดสะอาดได้ แต่สคีมาอยู่ในหน้าผู้ดูแลแยกต่างหาก
- เว็บไซต์บิลเดอร์มีการลากวาง แต่ผลลัพธ์เป็นลักษณะการเช่าใช้งานอยู่บนแพลตฟอร์ม
- จุดต่างที่ Primo เน้นคือมีแหล่งความจริงเดียวที่ทั้งทีมและเอเจนต์แก้ไขร่วมกันได้
- ตำแหน่งของโค้ดอยู่ในไฟล์ Svelte และรีโพซิทอรีของผู้ใช้
- จุดที่ลูกค้าแก้ไขคือหน้าที่เรนเดอร์แล้ว
- สคีมาอยู่ใน
fields.yaml ข้างไฟล์ .svelte
- เอเจนต์แก้ไขทั้งเว็บไซต์ในรูปแบบไฟล์ได้
- โฮสติ้งและไลเซนส์ถูกนำเสนอในรูปแบบ self-host และ MIT
ความเป็นเจ้าของข้อมูลและสถานะการดำเนินงาน
- เนื้อหาถูกเก็บใน SQLite ผ่าน PocketBase ส่วนโค้ดยังคงอยู่ในรีโพซิทอรีของผู้ใช้
primo pull สามารถส่งออกโค้ดและเนื้อหาแบบสแตติกได้ทุกเมื่อ- Primo ใช้ไลเซนส์ MIT และระบุว่าต่อให้โปรเจกต์หายไป โค้ดที่รันอยู่และเว็บไซต์ที่สร้างไว้ก็ยังทำงานต่อได้
- สถานะการดำเนินงานคือ เข้าสู่ปีที่ 7 ที่ v3.2 โดยตัวอย่างเว็บไซต์ production มีทั้งงานลูกค้าของเอเจนซี ร้านค้าอีคอมเมิร์ซขนาดเล็ก เว็บเอกสาร และหน้าการตลาดของตัวเอง
- เอเจนต์ถูกอธิบายว่าไม่ใช่ผลิตภัณฑ์ใหม่ แต่เป็นไคลเอนต์ใหม่ของโมเดลเดิมที่ดูแลมาตั้งแต่ปี 2019
Payload, TinaCMS, Sanity Studio และการรองรับ React
- Payload เป็น headless CMS ที่มีสคีมาอยู่ในหน้าผู้ดูแล และดึงเนื้อหาผ่าน API
- TinaCMS ถูกเปรียบเทียบว่าเป็นแนวทางนำตัวแก้ไขแบบอิง Git มาวางหน้าไฟล์ Markdown
- Sanity Studio เป็นหน้าผู้ดูแลแบบ React บน content lake ที่โฮสต์ไว้
- Primo ให้ทั้งตัวแก้ไขและตัวเรนเดอร์อ่านไฟล์ Svelte และแถวข้อมูลในฐานข้อมูลชุดเดียวกัน โดยไม่มีชั้นแปลงผ่าน API คั่นกลาง
- ขณะนี้ Primo blocks ยังไม่รองรับ React
- Primo ถูกสร้างโดยยึดแนวทาง compile-time ของ Svelte เป็นหลัก และโครงสร้างนี้ทำให้บล็อกเป็นไฟล์ที่ทั้งตัวแก้ไขและตัวเรนเดอร์อ่านได้โดยตรง
- การรองรับ React ภายใน Primo blocks ไม่อยู่ในโรดแมป
- ในโรดแมปมี
primo integrate <framework>
- แนวทางแรกคือวาง Primo ทับบนแอป SvelteKit ที่มีอยู่แล้ว
- หลังจากนั้นมีการกล่าวถึง Astro และ Next.js ยังเป็นสิ่งที่หวังไว้
- ในทิศทางนี้ คอมโพเนนต์ production จะยังอยู่ในเฟรมเวิร์กนั้น ส่วน Primo รับหน้าที่เฉพาะเนื้อหาและตัวแก้ไข
โครงสร้างบล็อกและการยืนยันตัวตนของ CLI
- บล็อกประกอบด้วยไฟล์สองไฟล์ที่วางคู่กัน
- คอมโพเนนต์ทำหน้าที่เรนเดอร์
- สคีมาบอกตัวแก้ไขว่ามีฟิลด์อะไรบ้าง
- ตัวอย่าง
blocks/hero/fields.yaml ประกาศฟิลด์ headline, subheadline, cta
headline และ subheadline เป็น textcta เป็น link
- การยืนยันตัวตนของ CLI ใช้วิธีอ่าน
PRIMO_TOKEN จากตัวแปรสภาพแวดล้อม
- โทเค็นถูกสร้างจากหน้าผู้ดูแลแบบแยกตามแต่ละเว็บไซต์
primo pull <host> ใช้โคลนโปรเจกต์primo push อัปโหลดเฉพาะไฟล์ที่เปลี่ยนแปลง
- การยืนยันตัวตนใช้แบบเดียวกับที่ผู้แก้ไขใช้ จึงไม่ต้องเรียนรู้ API แยกต่างหาก
- ใช้งานได้กับทุก Primo instance ผ่าน HTTPS รวมถึงอินสแตนซ์ที่ self-hosted
คำสั่งเริ่มต้น
- สร้าง workspace ใหม่ด้วยคำสั่งต่อไปนี้
npx primo-cli init my-workspace
- หลังสร้างแล้วจะแสดงสถานะ
workspace ready และ server.yaml written
- ข้อความเรื่องไลเซนส์และราคาแสดงเป็น MIT, โอเพนซอร์ส และใช้ฟรีถาวร
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตัวตัวแก้ไข CMS แบบลากและวางดูเท่มากในเดโม แต่พอเคยดูแลตัวแก้ไขคล้ายกันภายในบริษัทจริง ๆ มันกลายเป็นนรกแห่งการอัปเดตไม่รู้จบ
จะมีคำขอประมาณว่า “จัดข้อความชิดขวาและทำให้เป็นสีน้ำเงินได้ไหม?” เข้ามาเรื่อย ๆ และสุดท้ายแต่ละบล็อกก็มีพร็อพเพอร์ตีเพิ่มขึ้นไม่หยุด
คนที่เขียนคอนเทนต์จริงกลับใช้งานได้ไม่คล่อง และผลงานที่ออกมาก็มักไม่น่าพอใจนัก
การเทรนนิ่งเพิ่มอาจช่วยได้บ้าง แต่การประนีประนอมระหว่างอิสระในการปรับแต่งกับการรักษาอัตลักษณ์ของแบรนด์ก็ยังคงอยู่
สำหรับกรณีของเรา headless CMS ดูเป็นแนวทางที่ดีกว่า ให้มันส่งมอบเฉพาะคอนเทนต์ แล้วให้ผู้เชี่ยวชาญไม่กี่คนลงมือทำเป็นโค้ดให้เข้ากับดีไซน์จะดีกว่า แต่ก็ไม่ใช่ทุกทีมจะมีทรัพยากรแบบนั้น จึงชัดเจนว่า CMS ลักษณะนี้ก็ยังมีที่ทางของมัน
ไม่กี่เดือนก่อนตอนรีเฟรชเว็บไซต์อีคอมเมิร์ซของลูกค้า เราสร้าง section/block ที่แก้ไขได้ด้วย Maglev และประสบการณ์การแก้ไขเองก็ถือว่าดี
แต่หลังเปิดใช้งาน ลูกค้าก็จ้างนักการตลาดที่รู้ HTML/CSS แค่พื้นฐานมาก ๆ และต้องพยายามหนักเพื่อโน้มน้าวว่าควรให้นักพัฒนาสร้าง section ที่ต้องการ แทนที่จะเขียน HTML/CSS เอง
อาจใส่ตัวแก้ไขสำหรับนักพัฒนาแบบ Primo ก็ได้ แต่จากประสบการณ์ยาวนาน เราไม่อยากให้ลูกค้าไปแตะ HTML/CSS ของเว็บไซต์โดยตรง
และก็ไม่อยากได้ความสัมพันธ์แบบ “ถ้าทำพังคุณต้องจ่าย” เช่นกัน
มองให้กว้างขึ้น CMS ไหน ๆ ก็เจอปัญหาเดียวกัน เราเคยช่วยบริษัทที่เว็บไซต์ Webflow พังมาแล้ว ซึ่งเป็นเคสคลาสสิกที่ดีไซเนอร์ทำไว้ แล้วนักการตลาดพยายาม “ปรับปรุง” UI จนพังหมด
จำนวนคอมโพเนนต์ที่สร้างได้มันมีขีดจำกัด
ในอุดมคติแล้วควรมี CMS ที่ให้ลูกค้าปรับ HTML ได้ง่ายโดยไม่ต้องเขียนโค้ด แบบนั้นถึงจะโหลดเร็ว ทำ SEO ได้ดี และนักพัฒนาไม่ต้องประดิษฐ์ล้อขึ้นมาใหม่
นั่นจึงเป็นเหตุผลที่สร้าง Versoly(https://versoly.com/) ขึ้นมา ทำไมแค่จะเปลี่ยนสีพื้นหลังหรือเพิ่ม section ใหม่ถึงต้องติดต่อหานักพัฒนาทุกครั้งด้วย
แต่ไม่ว่าจะใช้ CMS อะไร ปัญหาที่ผู้แก้ไขคอนเทนต์อยากจัดข้อความชิดขวาและทำเป็นสีน้ำเงินก็น่าจะยังอยู่ดีไม่ใช่หรือ
ตอนนี้แทบยังไม่มีเอกสารอย่างเป็นทางการ แต่ถ้าสนใจก็อยากให้ลองดูหน้าแรกแล้วบอกหน่อยว่าน่าใช้ไหม
อยากฟังทั้งฟีดแบ็กทั่วไปและบทเรียนจากประสบการณ์ตรงของคนอื่นด้วย
https://brick-cms.com/
GitHub:
https://github.com/primocms/primo
การพูดคุยก่อนหน้า:
https://news.ycombinator.com/item?id=23820201
https://news.ycombinator.com/item?id=25301040
Show HN ที่มีข้อความแนบมาจากที่ที่ดูเหมือนจะเป็นอีกบัญชีของผู้เขียนเดิม:
https://news.ycombinator.com/item?id=36801101
ดูเหมือน SSG จะหมายถึงตัวสร้างเว็บไซต์แบบสแตติก (Static Site Generator) แต่ก็น่าจะต้องพยายามเขียนให้คนอ่านเข้าใจง่ายขึ้นหน่อยเมื่อออกนอกสายเฉพาะทางไปเพียงเล็กน้อย
ถึงจะเป็นคนทำเว็บเอง ผมก็ยังต้องหยุดคิดนิดหนึ่งถึงจะแปลตัวย่อนี้ออก
ถึงอย่างนั้น การเขียนคำเต็มไว้ก็น่าจะช่วยผู้ใช้ที่ยังไม่รู้ได้มากกว่า
น่าจะดีถ้ามีเครื่องมือแบบนี้สำหรับจัดการคอนเทนต์ไดนามิกแบบต่อเนื่องอย่างโพสต์บล็อกหรือรีวิว
คนจำนวนมากยังติดอยู่กับ WordPress แต่การคัสตอมกับธีมนั้นแทบจะเป็นฝันร้าย
ในยุคนั้นมันแทบเป็นหนึ่งในวิธีเดียวที่ทำบล็อกได้ง่าย
ปัญหาคือทันทีที่ออกนอกกรอบมาตรฐาน ก็จำเป็นต้องมีความรู้เชิงลึกเกี่ยวกับโครงสร้างภายในของ WordPress ขึ้นมาทันที
เมื่อประมาณ 3 ปีก่อน HN ดันโอเพนซอร์ส CMS Primo ขึ้นหน้าแรก(https://news.ycombinator.com/item?id=23820201) และด้วยแรงส่งนั้น ผมเลยลาออกจากงานรีโมตที่สบาย ๆ กลางช่วงโรคระบาดเพื่อมาทุ่มทำมันเต็มเวลา
หลังจากนั้นก็ใช้เงินเก็บจนหมด เสียโดเมน primo.af ให้ Taliban ไป และถึงขั้นกล่อมให้ภรรยามาเป็นนักพัฒนา/นักออกแบบเพื่อช่วยกันทำ
ถึงอย่างนั้นผมก็ยังภูมิใจกับสิ่งที่สร้างมา และเมื่อเห็นว่ามันช่วยให้ผู้คนเรียนรู้การพัฒนาเว็บ สร้างเว็บไซต์ส่วนตัว และจัดการเว็บไซต์ของลูกค้าได้ ก็ยิ่งมั่นใจในพลังและความเรียบง่ายของแนวทางนี้มากขึ้น
วันนี้ Primo 2 ที่ปล่อยเป็น public beta มาพร้อมการแก้ไขคอนเทนต์บนหน้าเพจ การสร้างหน้าเพจ และอื่น ๆ
Primo เริ่มต้นจากความเหนื่อยล้ากับการสร้างเว็บไซต์ และความจริงที่ว่าผู้ใช้ที่ไม่ใช่สายเทคนิคมักจัดการมันได้ยาก
ตอนทำโปรเจ็กต์ฟรีแลนซ์ ผมต้องปวดหัวกับธีม WordPress ที่พังง่าย การไล่หาตัวเลือกในแดชบอร์ด และการประกอบปลั๊กอินหลายตัวเข้าด้วยกัน ส่วนตอนเป็นนักพัฒนาเอเจนซี ผมก็รู้สึกว่า CMS แบบ monolith กับ meta-framework/headless CMS มันเกินความจำเป็นสำหรับหน้า landing page หรือเว็บแนะนำบริษัท
ในฐานะครูสอนเขียนโค้ด ผมเห็นนักเรียนรู้สึกกลัวเมื่อเจอกับ CLI, API, package manager, bundler, framework และ meta-framework จนไม่กล้าใช้เว็บให้เป็นประโยชน์
ยังไม่มีเส้นทางที่เรียบง่ายและเข้าถึงได้สำหรับการสร้าง จัดการ พัฒนา และโฮสต์เว็บไซต์ทั่วไปอย่างบล็อก, landing page และเว็บแนะนำตัว
โดยพื้นฐานแล้ว Primo เป็น CMS ที่ทำให้จัดการคอนเทนต์ได้ง่าย แต่ยังรวมการสร้างหน้าเพจ การแก้ไขโค้ด การสร้าง static site และการ deploy/hosting ผ่าน GitHub ไว้ในอินเทอร์เฟซเดียว
บล็อกต่าง ๆ เขียนด้วย Svelte หรือก็คือ HTML/CSS/JS ทำให้ responsive และมีการ encapsulate สไตล์
และเพราะมันเป็น static site จึงได้ข้อดีด้านต้นทุน ความปลอดภัย การขยายระบบ และความเร็วแบบ serverless ไปด้วย
Primo เป็นเครื่องมือสำหรับคนที่อยากควบคุมเว็บไซต์ได้เต็มที่ด้วย HTML/CSS/JavaScript แต่ก็ยังอยากให้ตัวเองรวมถึงเพื่อน ลูกค้า หรือผู้ร่วมงานที่ไม่ใช่สายเทคนิคมีประสบการณ์แก้ไขคอนเทนต์ที่เรียบง่ายมาก มากกว่าจะเหมาะกับคนที่ชอบเครื่องมือออกแบบแบบ WYSIWYG สไตล์ SquareWixFlow
มันมุ่งไปที่คนที่อึดอัดกับเครื่องมือ no-code และแพลตฟอร์มปิด แต่ก็ยังอยากรักษาพลังของการเขียนโค้ดไว้พร้อมความเรียบง่ายที่มากขึ้น
ไปไกลกว่านั้น Primo คือความพยายามที่จะทำให้เว็บยังอยู่ในมือของปัจเจกชน
ถ้าทำให้การเผยแพร่บนเว็บเข้าถึงง่ายขึ้นได้ ก็หวังว่าจะช่วยยกระดับความรู้เท่าทันเทคโนโลยี และทำให้ผู้คนมีอิสระในการแสดงออกโดยไม่ถูกผลักเข้าไปอยู่ในระบบปิดแบบ black box และ walled garden ได้ง่าย ๆ
แต่ระบบจัดการคอนเทนต์นี่แหละที่เป็นปัญหา ผมคาดหวังว่ามันจะทำงานเหมือน static site generator ทั่วไป คือใส่ไฟล์ Markdown ไว้ในโฟลเดอร์ แล้วสร้างบทความหรือบล็อกโพสต์ตามเทมเพลต
ช่วงหนึ่งผมเคย fork รีโพซิทอรีของ Primo เพื่อทำวิธีแบบคัสตอมที่แปลงรายการในฐานข้อมูลให้เป็นโครงสร้างไฟล์/โฟลเดอร์ แต่ดูเหมือนการแปลงย้อนกลับจะยุ่งยาก เลยไปเลือกทางอื่น และสุดท้ายก็ได้แรงบันดาลใจจากไกด์นี้จนสร้าง Markdown static site generator ของตัวเองขึ้นมา: https://joshcollinsworth.com/blog/build-static-sveltekit-mar...
use case ของผมอาจไม่ใช่กลุ่มเป้าหมายหลัก แต่ถ้าโปรเจ็กต์นี้เก็บข้อมูลเป็นโครงสร้างไฟล์/โฟลเดอร์แบบไดนามิกแทนการเขียนลงฐานข้อมูล และสามารถแก้ไข/ทำเวอร์ชันคอนโทรลได้เหมือนโปรเจ็กต์ SvelteKit ปกติ มันน่าจะเป็นผลิตภัณฑ์ที่ยอดเยี่ยมมาก
โดยแก่นแล้วมันจะกลายเป็น เฟรมเวิร์ก static site generator ที่ใช้ Svelte พร้อมไลบรารีคอมโพเนนต์และ UI เฉพาะทาง
ฟอรัมก็ดีมาก และคำถามบางข้อที่ผมสงสัยก็มีคนตอบไว้แล้ว
ผมใช้ WordPress มานานและช่วงนี้ก็เพิ่งลอง Svelte อยู่ นี่ใกล้เคียงกับสิ่งที่ผมตามหามากจริง ๆ
ขอชื่นชมอย่างมากกับความพยายามที่ทุ่มลงไปเพื่อสร้างสิ่งนี้
เป็นโปรเจ็กต์ที่ดี แต่พูดตามตรงก็น่าผิดหวังนิดหน่อยที่ถ้าอยาก “self-host” จะต้องมี บัญชี Supabase
ดูเหมือนมันจะทำงานได้เฉพาะบนบริการโฮสต์บางเจ้าที่เชื่อมกับ Supabase ได้ และยังชี้นำให้ดึงคอนเทนต์ของหน้าเพจมาจาก GitHub
เพราะงั้นมันเลยดูใกล้เคียงกับ CMS ที่รันร่วมกับผู้ให้บริการบางเจ้ามากกว่า CMS ที่ self-host ได้จริง
เป้าหมายคือทำให้คนตั้งเซิร์ฟเวอร์ของตัวเองได้ง่ายที่สุด จึงต้องเชื่อมกับบริการพวกนั้น
แต่ตอนนี้กำลังแยก backend ออกมาเพื่อให้โฮสต์เองได้จริง ๆ
บริการภายนอกที่จำเป็นจริง ๆ ดูจะมีแค่ GitHub และภายหลังก็น่าจะเพิ่มผู้ให้บริการอื่นอย่าง GitLab ได้
เป็นโปรเจ็กต์ที่ดี แต่พูดกันตรง ๆ ผมรู้สึกว่าเรามาถึงจุดที่ทั้งนักพัฒนาและผู้ใช้ควรได้ใช้ JavaScript ให้น้อยลง หรือไม่ใช้เลยจะดีกว่า
ตอนนี้ผมกำลังย้ายบล็อกเก่าไปเป็นบล็อกใหม่ที่สร้างด้วย Zola(https://www.getzola.org) และแม้แต่เว็บไซต์พอร์ตโฟลิโอที่เคยทำใหม่ด้วย React/Gatsby ผมก็กลับมาทำด้วย Zola อีกครั้งเพราะเรื่องประสิทธิภาพต่างกันมาก
บางครั้งผมก็ปิด JavaScript แล้วท่องเว็บ และถ้าเว็บไซต์ใช้งานไม่ได้เลยหรือแม้แต่โหลดไม่ขึ้นในสภาพนั้น สำหรับผมถือว่าเป็นข้อเสียร้ายแรง
เว็บไซต์เก่าของผมใช้ jQuery ซึ่งก็น่าหงุดหงิดพออยู่แล้ว และการลองใช้ของอย่าง React ก็เหมือนฝันร้าย
ภายในใช้ Svelte compiler
แทบไม่อยากเชื่อเลยว่าการที่เคยสร้างตัวสร้างเว็บไซต์ชื่อ Stiqr ในปี 2010 นั้นผ่านมามากกว่า 10 ปีแล้ว
แม้เว็บไซต์จะไม่ได้เปิดให้บริการแล้ว แต่ยังพอเห็นร่องรอยได้จากวิดีโอ YouTube
https://www.youtube.com/watch?v=B-ff53t8TuU&t=224s
ตอนนั้นในปี 2010 กระแส responsive design กำลังมาแรง เลยยุติโปรเจกต์ไป แต่ก็ยังเชื่อว่าวิธีสร้างเว็บไซต์ในอนาคตอันใกล้น่าจะไปในทิศทางนี้อยู่ดี
การผสมระหว่างวิธีแบบลากวาง/บล็อกกับ Svelte นั้นเจ๋งมาก แต่สำหรับฉันมันดูเป็นเครื่องมือที่อยู่ปลายสเปกตรัมผิดด้าน
นี่คือ ตัวสร้างเว็บไซต์แบบภาพ ที่ปรับแต่งบล็อกได้ผ่านตัวแก้ไขออนไลน์
สิ่งที่ฉันต้องการคืออินเทอร์เฟซออนไลน์ที่ให้ลูกค้าเพิ่มหรือแก้ข้อความ หรือปรับเล็กน้อยกับเว็บไซต์ Svelte ที่ฉันทำแบบออฟไลน์ด้วยเครื่องมือของตัวเอง
ถ้าสามารถสร้างเว็บไซต์ให้ตรงตามมาตรฐานอินเทอร์เฟซบางอย่างเพื่อให้ Primo อ่านได้ แล้วลูกค้าจะแก้ไขผ่านอินเทอร์เฟซแบบภาพได้ ก็คงดีมาก
การแก้ไขใหญ่ ๆ ก็กลับมาที่ฉัน และฉันก็ยังรักษาความเร็วและอิสระของเวิร์กโฟลว์แบบออฟไลน์ไว้ได้
จะบอกว่าต้องใช้ headless CMS ก็ได้ แต่ทุกตัวที่เคยใช้ล้วนซับซ้อนเกินไป และแค่การตั้งค่ากับบำรุงรักษาก็ทำให้ปวดหัวมากแล้ว
ถ้าไม่ได้สร้างฟิลด์เฉพาะไว้ ก็จะไม่สามารถแก้ด้านภาพ เช่น ทำให้รูปเป็นวงกลมหรือสี่เหลี่ยม ได้
ถ้าปัญหาคือใช้ local IDE ไม่ได้ ตอนนี้สามารถ bundle Svelte component เป็น vanilla JavaScript แล้วนำเข้าเป็นบล็อกของ Primo พร้อมส่งข้อมูลผ่านฟิลด์ได้
แต่ก็น่าจะดีกว่าถ้ารออีกสักสองสามสัปดาห์ก่อนนำไปใช้ใน production จนกว่าจะนิ่ง
วิธีที่อธิบายมานั้นจริง ๆ ก็แทบจะตรงกับวิธีที่ฉันทำโปรเจกต์ให้ลูกค้าเลย คือเขียนโค้ดทั้งหมดเอง ปกติก็นำบล็อกจากโปรเจกต์อื่นมาใช้ซ้ำ แล้วส่งมอบเว็บไซต์ที่ลูกค้าสามารถแก้ไขได้ตั้งแต่วันแรกด้วยการสอนเพียงเล็กน้อย
อยากรู้ว่าคำว่า “การปรับแต่งบล็อก” ของคุณไม่ได้รวมถึงการแก้ข้อความ หรือหมายถึงมันยังจำกัดพฤติกรรมที่ส่งต่อให้ลูกค้าได้ไม่มากพอ
มันสามารถแทรกส่วนที่จัดการแบบลากวางเข้าไปในมาร์กอัปของหน้าปกติได้ และดูเหมือนจะรองรับเฟรมเวิร์กส่วนใหญ่รวมถึง Svelte
ตั้งค่าผ่าน FTP ได้เลย