3 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตั้งแต่เดือนกรกฎาคม 2026 เป็นต้นไป shadcn/ui จะเปลี่ยนโฟลว์เริ่มต้นสำหรับโปรเจกต์ใหม่และเอกสารให้ยึด Base UI เป็นศูนย์กลาง โดยเปลี่ยนทิศทางจากค่าเริ่มต้นเดิมที่ใช้ Radix มาตั้งแต่เปิดตัวในปี 2023
  • Base UI ไปถึง เวอร์ชันเสถียร 1.6.0 แล้ว และมียอดดาวน์โหลดมากกว่า 6 ล้านครั้งต่อสัปดาห์ อีกทั้งในโปรเจกต์ shadcn/create ก็ถูกเลือกมากกว่า Radix ในสัดส่วน 2:1
  • Radix ไม่ได้ถูกยกเลิกการรองรับ แอปเดิมสามารถใช้งานต่อได้ตามเดิม และยกเว้นคอมโพเนนต์ที่มีเฉพาะใน Base UI ก็จะยังคงได้รับอัปเดตและคอมโพเนนต์ใหม่ต่อไป
  • การย้ายระบบไม่ได้มาในรูปแบบ codemod แต่เป็น agent skill ที่ช่วยย้ายคอมโพเนนต์ที่ถูกแก้ไขแล้วและตำแหน่งที่ใช้งานแบบค่อยเป็นค่อยไปทีละคอมโพเนนต์ พร้อมทิ้งรีพอร์ตไว้ใน .migration/ และสร้าง git commit
  • มีการเพิ่มคอมโพเนนต์สำหรับแชต UI, registry ที่อิงกับ GitHub repository, shadcn eject และสไตล์ใหม่ Rhea ทำให้ขอบเขตของ shadcn/ui ขยายจากการแจกจ่ายคอมโพเนนต์ไปสู่การประกอบ UI ของผลิตภัณฑ์โดยรวม

Base UI กลายเป็นไลบรารีคอมโพเนนต์เริ่มต้น

  • ตั้งแต่เดือนกรกฎาคม 2026 เป็นต้นไป Base UI จะถูกกำหนดให้เป็นไลบรารีคอมโพเนนต์เริ่มต้นของ shadcn/ui
  • ตอนที่ shadcn/ui เปิดตัวในเดือนมกราคม 2023 มันถูกสร้างบน Radix ซึ่งในเวลานั้นเป็นตัวเลือกที่มีทั้งเฮดเลสคอมโพเนนต์แบบไร้สไตล์, API, accessibility และประสบการณ์ใช้งานจริงในแอป
  • Base UI เป็นไลบรารีใหม่ที่สร้างโดยทีมเดียวกับที่สร้าง Radix และ shadcn/ui ก็ได้สร้างคอมโพเนนต์ทั้งหมดใหม่สำหรับ Base UI โดยยังคง abstraction เดิมไว้
  • ในเดือนธันวาคม 2025 npx shadcn create ได้เปิดให้เลือกใช้ได้ทั้งสองไลบรารี และในเดือนมกราคม 2026 ก็มีเอกสารของ Base UI ครบถ้วน

เหตุผลที่เปลี่ยนค่าเริ่มต้น

  • ความเสถียรและโฟลว์การใช้งานของ Base UI

    • เวอร์ชันของ Base UI คือ 1.6.0
    • มียอดดาวน์โหลดรายสัปดาห์ มากกว่า 6 ล้านครั้ง
    • ทีม Base UI ปล่อยคอมโพเนนต์ใหม่ที่มีประโยชน์ออกมาอย่างสม่ำเสมอ
    • โปรเจกต์ใหม่ของ shadcn/ui ใช้ Base UI อยู่แล้ว
    • โปรเจกต์ที่สร้างด้วย shadcn/create เลือก Base UI มากกว่า Radix ในสัดส่วน 2:1
    • shadcn/ui จึงสะท้อนแนวโน้มการเลือกใช้นี้ให้เป็นค่าเริ่มต้นอย่างเป็นทางการ

สิ่งที่จะเปลี่ยนไปในโปรเจกต์ใหม่และเอกสาร

  • เมื่อรัน npx shadcn init ในโปรเจกต์ใหม่ Base UI จะกลายเป็นตัวเลือกเริ่มต้น
  • shadcn/create จะแสดง Base UI ก่อน
  • หน้าคอมโพเนนต์ในเอกสารจะเปิดแท็บ Base UI เป็นค่าเริ่มต้น และสามารถเข้าเอกสาร Radix ได้ด้วยการคลิกครั้งเดียว

สิ่งที่ผู้ใช้ Radix ควรรู้

  • Radix ยังได้รับการรองรับต่อไป

    • shadcn/ui จะยังคงรองรับ Radix
    • ยกเว้นคอมโพเนนต์ที่มีเฉพาะใน Base UI อัปเดตทั้งหมดและคอมโพเนนต์ใหม่จะมีให้ทั้งสองไลบรารี
    • แอปเดิม ไม่จำเป็นต้องย้ายระบบ
    • Radix เป็นไลบรารีที่เติบโตเต็มที่และผ่านการทดสอบมาแล้ว
    • shadcn/ui เองก็ยังใช้ Radix ใน production ต่อไป และโปรเจกต์ภายในก็จะไม่ย้ายเช่นกัน
    • หากยังต้องการใช้ Radix ในโปรเจกต์ใหม่ สามารถใช้ flag ได้
    • หากมีสคริปต์หรือ CI ที่รัน shadcn init แบบ non-interactive และคาดหวัง Radix อยู่ ต้องเพิ่ม -b radix เพื่อคงพฤติกรรมเดิมไว้
    • หากต้องการล็อก registry ให้ใช้กับไลบรารีใดไลบรารีหนึ่งโดยเฉพาะ สามารถกำหนดค่า registry:base ได้
    • รายการที่ไม่มีการตั้งค่านี้จะถูกเริ่มต้นด้วย Base UI นับจากนี้
    • สำหรับโปรเจกต์ใหม่ แนะนำให้ใช้ Base UI

วิธีการย้ายไป Base UI

  • การย้ายระบบไม่ใช่ข้อบังคับ แต่ถ้าต้องการสามารถใช้ skill ได้
  • สามารถสั่ง coding agent ได้แบบนี้
    • migrate accordion to base-ui
  • วิธีหลักคือการย้ายแบบค่อยเป็นค่อยไป
    • ย้ายคอมโพเนนต์และตำแหน่งที่ใช้งานทีละรายการ
    • โปรเจกต์จะยังคงอยู่ในสถานะ green และพร้อม deploy ต่อเนื่อง
    • ระหว่างการทำงาน ทั้งสองไลบรารีสามารถอยู่ร่วมกันได้
    • สามารถหยุดกลางทางแล้วกลับมาทำต่อภายหลังได้
    • หากต้องการก็สามารถสั่งให้ย้ายทั้งโปรเจกต์ในครั้งเดียวได้เช่นกัน

ทำไมเลือกใช้ skill แทน codemod

  • คอมโพเนนต์ของ shadcn/ui เป็นโค้ดที่ผู้ใช้เป็นเจ้าของและแก้ไขเอง ดังนั้น codemod อาจใช้ได้กับคอมโพเนนต์ที่ไม่ถูกแตะต้อง แต่มีโอกาสพังกับคอมโพเนนต์ที่ถูกปรับแก้แล้ว
  • ใน skill มีการตรวจทานด้วยมือทั้ง การเปลี่ยนชื่อ, การเปลี่ยน prop และความต่างของพฤติกรรม โดยอิงจากทั้งสองไลบรารี
  • agent จะตรวจจับการแก้ไขของผู้ใช้และนำการเปลี่ยนแปลงนั้นไปสะท้อนกับสิ่งที่กำลังย้ายด้วย
  • การเปลี่ยนที่ทำแบบกลไกได้จะถูกแก้ให้ทั่วทั้งโปรเจกต์
    • ตัวอย่าง: asChild จะเปลี่ยนเป็น render
  • ส่วนการเปลี่ยนด้านพฤติกรรมจะไม่ถูกแพตช์แบบเงียบ ๆ แต่จะถูกแสดงให้เห็น และการตัดสินใจสุดท้ายเป็นของผู้ใช้

สิ่งที่การย้ายระบบจะทิ้งไว้ให้

  • ทุกการรันจะทิ้งผลลัพธ์ไว้ 3 อย่าง
    • โค้ดที่ทำงานได้: มีการรัน typecheck และ build ก่อนรายงานว่าสำเร็จ
    • รีพอร์ตแยกตามคอมโพเนนต์: เก็บไว้ใน .migration/ ที่รากโปรเจกต์ โดยระบุสิ่งที่เปลี่ยน สิ่งที่ปล่อยไว้เหมือนเดิม และ checklist สำหรับตรวจด้วยมือ
    • ประวัติ git ที่สะอาด: สร้างหนึ่ง commit ต่อหนึ่งคอมโพเนนต์บน branch โดยหากต้องการ rollback ก็ลบ branch นั้นได้เลย
  • ตัวอย่างรีพอร์ตคือ .migration/accordion.md และมีส่วนต่อไปนี้
    • Changed
    • Left alone
    • Behavior changes
    • Verify by hand
  • เพราะไม่มีสถานะที่ซ่อนอยู่ ความคืบหน้าจึงถูกทิ้งไว้ในไฟล์และประวัติ git ทำให้สามารถทำงานต่อได้จาก agent หรือ session ใดก็ได้
  • ใช้งานได้กับ Claude Code, Cursor และ agent ที่รองรับ skill
  • ในการทดสอบกับโปรเจกต์จริง จากคอมโพเนนต์มากกว่า 60 ตัว มี 36 ตัวที่เป็น Radix และการย้ายทั้งหมดใช้เวลาประมาณ 25 นาที หรือราว 10,000 โทเค็นต่อคอมโพเนนต์
  • build ผ่านอย่างสะอาด และการปรับแต่งเดิมยังคงอยู่

เพิ่มคอมโพเนนต์สำหรับอินเทอร์เฟซแชต

  • ในเดือนมิถุนายน 2026 มีการเพิ่มคอมโพเนนต์ใหม่สำหรับสร้างอินเทอร์เฟซแชต
  • ชุดแรกนี้คือชิ้นส่วนหลักสำหรับประกอบเลเยอร์บทสนทนา
    • การเลื่อน
    • แถวข้อความ
    • บอลลูนข้อความ
    • ไฟล์แนบ
    • มาร์กเกอร์
  • MessageScroller คือคอนเทนเนอร์เลื่อนสำหรับบทสนทนา
    • anchored turns
    • streamed replies
    • saved thread restore
    • prepended history
    • jump-to-message
    • scroll controls
    • visibility tracking
  • MessageScroller ไม่ได้เป็นเจ้าของข้อความ, สถานะ AI, การส่ง, การบันทึก หรือสถานะโมเดล โดยตัวเรนเดอร์เนื้อหาผู้ใช้ต้องจัดเตรียมเอง
  • MessageScroller ยังมีให้ใช้งานในรูปแบบเฮดเลสคอมโพเนนต์ไร้สไตล์ของ @shadcn/react ด้วย

บทบาทของ Message, Bubble, Attachment และ Marker

  • Message ใช้จัดวางหนึ่งแถวของบทสนทนา
    • avatar
    • alignment
    • header
    • content
    • footer
    • รองรับ grouped message
  • Bubble ใช้เรนเดอร์พื้นผิวของข้อความ
    • variants
    • alignment
    • reactions
    • links
    • buttons
    • รองรับ collapsible content
  • Attachment ใช้เรนเดอร์ไฟล์และรูปภาพ
    • media
    • metadata
    • upload state
    • actions
    • มี full-card trigger ที่ยังคงแยก action ที่คลิกได้ไว้อย่างอิสระ
  • Marker ใช้เรนเดอร์การอัปเดตสถานะ, system note, แถวคั่น และเส้นแบ่งแบบมีป้ายกำกับ
    • streaming state
    • tool activity
    • ใช้ได้กับกรณีอย่าง date breaks
  • คอมโพเนนต์เหล่านี้ถูกออกแบบให้มีขนาดเล็ก เพื่อให้สามารถนำไปประกอบเป็น AI chat, support inbox, team thread, group chat และ UI บทสนทนาเฉพาะของแต่ละผลิตภัณฑ์ได้

CSS utility สำหรับแชต UI และ @shadcn/react

  • มีการเพิ่ม CSS utility ใหม่ 2 ตัว
    • scroll-fade: เพิ่มเอฟเฟกต์ fade บริเวณขอบของคอนเทนเนอร์เลื่อนเพื่อบอกว่ามีการเลื่อน
    • shimmer: เพิ่ม shimmer ให้กับข้อความสถานะสด เช่น "Thinking…", "Generating response…", การรันเครื่องมือ และมาร์กเกอร์ระหว่างสตรีม
  • utility ทั้งสองถูกรวมไว้ใน shadcn/tailwind.css
    • โปรเจกต์ที่เริ่มต้นด้วย npx shadcn@latest init จะมีมาให้แล้ว
  • @shadcn/react คือแพ็กเกจใหม่สำหรับเฮดเลส React คอมโพเนนต์แบบไร้สไตล์
    • primitive ตัวแรกคือ @shadcn/react/message-scroller
    • คอมโพเนนต์ใน registry จะห่อด้วยสไตล์แบบ shadcn/ui แต่พฤติกรรมการเลื่อนอย่าง anchoring, auto-follow, prepend preservation, scroll commands และ visibility จะอยู่ในแพ็กเกจนี้
  • แนวทางนี้ช่วยให้ได้พฤติกรรมโดยไม่ผูกกับสไตล์ภาพ และสามารถทดสอบตรรกะ interaction ที่ซับซ้อนได้จากจุดเดียว
  • ใช้งานได้ทั้งกับ Radix และ Base UI

ความสัมพันธ์กับ AI Elements

  • คอมโพเนนต์แชตชุดใหม่นี้ไม่ได้มาแทนที่ AI Elements
  • คอมโพเนนต์และแพตเทิร์นสำหรับ AI interface ของ AI Elements ยังใช้งานต่อได้
  • รีลีสนี้โฟกัสที่การค่อย ๆ นำชิ้นส่วนแกนหลักของแชตเข้ามาใน shadcn/ui ทีละตัว
  • หากใช้งานคอมโพเนนต์ของ AI Elements อยู่แล้ว ก็ไม่จำเป็นต้องเขียนแอปใหม่
  • หากต้องการ abstraction ที่ใหม่กว่า, สไตล์ที่อัปเดตขึ้น และการรองรับทั้ง Radix กับ Base UI ก็สามารถลองเวอร์ชันของ shadcn/ui ได้

ใช้ GitHub repository เป็น registry

  • ตั้งแต่เดือนมิถุนายน 2026 เป็นต้นไป สามารถใช้ GitHub repository แบบสาธารณะเป็น registry ได้
  • เพียงเพิ่ม registry.json ที่ราก repository และนิยามรายการที่จะเผยแพร่ ผู้ใช้ก็สามารถติดตั้งจาก GitHub ได้โดยตรงผ่าน shadcn CLI
  • GitHub registry เป็น source registry
    • ไม่จำเป็นต้องรัน shadcn build
    • ไม่จำเป็นต้อง publish ไฟล์ item JSON ที่สร้างขึ้น
    • ไม่จำเป็นต้องตั้งค่า registry server
  • CLI จะอ่าน registry.json จากรากโปรเจกต์ ตีความรายการ include ค้นหารายการที่ร้องขอ แล้วติดตั้งไฟล์ที่เกี่ยวข้อง
  • รายการใน registry ไม่ได้จำกัดแค่คอมโพเนนต์
    • components
    • hooks
    • utilities
    • design tokens
    • feature kits
    • project conventions
    • agent instructions
    • testing setup
    • CI workflows
    • release workflows
    • templates
    • codemods
    • migration kits
    • และไฟล์อื่น ๆ ของโปรเจกต์ที่ต้องการเผยแพร่
  • ที่อยู่ของ GitHub registry ใช้ได้กับคำสั่งเดียวกับ registry แบบเดิม
    • list
    • search
    • view
    • install

shadcn eject และ shadcn/tailwind.css

  • เมื่อรองรับทั้ง Radix และ Base UI ก็จำเป็นต้องมีที่สำหรับวาง Tailwind utility กลางที่ทั้งสองไลบรารีต้องพึ่งพา
    • ตัวอย่างเช่น custom variant อย่าง data-open:, data-closed:
    • ตัวอย่างเช่น utility อย่าง no-scrollbar
  • ระหว่างการทำงานเรื่องรองรับ RTL ก็พบว่าบั๊กบางอย่างแก้จากจุดเดียวได้ง่ายกว่าการใส่ซ้ำในทุกคอมโพเนนต์
  • จึงได้มี shadcn/tailwind.css ขึ้นมา
    • เมื่อรัน init จะมีการเพิ่ม @import "shadcn/tailwind.css" ลงในไฟล์ global CSS
    • ทำงานคล้าย CSS import อย่าง tw-animate-css
    • เป็น dependency ขนาดเล็กที่ถูก tree-shaken ใน production และถูก resolve ตอน build
  • หากไม่ต้องการพึ่งพา CSS จากแพ็กเกจ shadcn สามารถใช้ shadcn eject ได้
    • มันจะ inline shadcn/tailwind.css ลงในไฟล์ global CSS
    • และลบ dependency ของ shadcn ออกจากโปรเจกต์
  • ใน monorepo ต้องรันคำสั่งจาก workspace ที่มี components.json และไฟล์ global CSS

สไตล์ใหม่ Rhea

  • ในเดือนพฤษภาคม 2026 มีการเพิ่มสไตล์ใหม่ของ shadcn/ui ชื่อ Rhea
  • Rhea คือ Luma ที่มีความ compact มากขึ้น มี spacing ที่เล็กลงและ surface ที่หนาแน่นขึ้น ออกแบบมาสำหรับ product interface ที่โฟกัสชัดเจน
  • Rhea ยังคงความนุ่มนวลและรูปทรงของ Luma ไว้ แต่จัดวางปุ่ม, input, เมนู, การ์ด และลิสต์ให้กระชับขึ้น
  • ไม่ได้เลือกวิธีปรับ --spacing ของ Luma
    • เพราะ --spacing เป็น multiplier ดังนั้นถ้าเปลี่ยน ความหมายของ Tailwind utility ที่คุ้นเคยอย่าง p-2, w-4, m-16 ก็จะเปลี่ยนไปทั้งแอป
  • Rhea จึงถูกแยกเป็นอีกหนึ่งสไตล์ เพื่อให้สามารถปรับขนาดคอมโพเนนต์, gap และ density ได้โดยตรง ขณะเดียวกันยังคงให้ underlying utility scale มีความคาดเดาได้
  • Rhea ใช้ได้กับทั้ง Radix และ Base UI ใน shadcn/create

1 ความคิดเห็น

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Hacker News
  • ในบทความนี้รู้สึกได้ค่อนข้างชัดถึง สำนวนเฉพาะแบบ Claude จนตอนนี้เริ่มเหนื่อยและรู้สึกห่างเหิน
    ถ้าแม้แต่บทความเปิดตัวผลิตภัณฑ์สำคัญก็ยังไม่คุ้มให้มนุษย์ใส่ใจอย่างเต็มที่ ก็ไม่รู้แล้วว่าควรขีดเส้นตรงไหน

    • บทความสื่อสารสิ่งที่จำเป็นได้อย่างมีประสิทธิภาพ และดูเหมือนถูก เขียนและจัดโครงสร้าง ให้อ่านง่ายสำหรับมนุษย์
      ถ้าการใช้ AI เขียนทำให้มีเวลาไปพัฒนาซอฟต์แวร์โอเพนซอร์สยอดเยี่ยมตัวนี้ได้มากขึ้น ผมกลับมองว่าเป็นเรื่องดี
    • เข้าใจเลยว่าหมายถึงอะไร ผมใช้ Claude กับ plannotator บ่อย และหลังจากขอ style guide เฉพาะก็ได้ผลดีขึ้นมาก
      พอใช้ “MSDN reference ยุค CD และสไตล์บล็อกของ Raymond Chen” เป็นพรอมป์ตั้งต้น ความสามารถในการย่อยแผนที่ AI สร้างขึ้นก็ดีขึ้นมาก และขอแนะนำอย่างยิ่ง เพราะเป็นสไตล์ที่ถ่อมตัว มี insight และเคารพผู้อ่าน
    • อ่านบทความแล้ว แต่ไม่ได้ฟังดูเหมือน AI เขียน
      ถ้ามีใครในทีมออกมาบอกว่ามนุษย์เป็นคนเขียนเอง ก็คงตลกนิดหน่อย
    • ถามจริง ๆ นะ ทำไมเรื่องนั้นถึงสำคัญ อาจร่างไว้ก่อนแล้วค่อยให้ Claude ตรวจประโยคก่อนโพสต์ก็ได้
      ไม่เข้าใจว่าทำไมทุกครั้งที่ AI ช่วยงาน ถึงต้องพยายาม “จับให้ได้” กันด้วย และนี่เป็น โปรเจกต์โอเพนซอร์ส ไม่ใช่บริษัท F500 ทรัพยากรก็จำกัด และภาษาอังกฤษอาจไม่ใช่ภาษาแม่ด้วยซ้ำ
    • ผมกลับคิดว่าไม่ใช่เรื่องที่ควรฟังแล้วเฉย ๆ เพราะวิธีที่มันถูกใช้และนำเสนอในตอนนี้ใกล้เคียงกับ การหลอกลวงและความเท็จ
      ผมเชื่อว่าวัฒนธรรมของการร่วมมือกันต้องอาศัยความไว้วางใจและความจริง และไม่อยากได้บทความที่ AI โกหกว่า “ฉันทำ/ฉันพูด”
      เช่น ถ้าบทความนี้ Claude เขียนจริง ทำไมต้องทำเหมือนว่าคนในทีมพูดเองตรง ๆ ด้วยคำอย่าง “I said”, “I meant it” นั่นคือ การสวมรอย และเป็นการหลอกลวง ถ้าเป็นวัฒนธรรมที่รักษาความร่วมมือและความซื่อสัตย์ ก็ควรพูดว่า “มนุษย์ของฉันพูดไว้” หรืออย่างน้อยต้องระบุให้ถูกต้องว่าเป็น AI ที่ทำหน้าที่แทนมนุษย์
  • สงสัยว่าในแอปพลิเคชันน่าเบื่อ ๆ ผู้คนชอบ แนวทาง copy-paste ของ shadcn มากกว่าไลบรารี UI แบบดั้งเดิมอย่าง Mantine หรือเปล่า
    แนวทาง copy-paste แก้ไขได้ง่ายก็จริง แต่ก็สร้างปัญหาใหม่ด้วย เช่น เรื่องที่ควรจะแค่เพิ่มเลขเวอร์ชัน ตอนนี้กลับต้องมี AI agent สำหรับอัปเกรด

    • คำว่า “แค่เพิ่มเลขเวอร์ชันก็พอ” ประเมินความปวดหัวที่ Material UI สร้างไว้ในช่วงหลายปีหลังต่ำเกินไปมาก
      ไม่ใช่แอปน่าเบื่อ แต่เป็นแอปใหญ่มาก และทุกครั้งที่อัปเดต major version ก็พลิก API ครั้งใหญ่ จนต้องทำ migration น่าเบื่อ ๆ พอย้ายมา shadcn แล้วก็ง่ายขึ้น เพราะอัปเกรดเฉพาะคอมโพเนนต์เดี่ยว ๆ และเพิ่มคอมโพเนนต์ใหม่ได้อย่างอิสระ ใน Material UI ถ้าอยากใช้ฟีเจอร์ใหม่ตรงไหน ก็ต้องเปลี่ยนทั้งหมดให้เข้ากับ API ใหม่ แต่ shadcn เลือกทำเฉพาะจุดได้
    • ผมไม่เข้าใจแนวทาง copy-paste เลย Shadcn ให้กลิ่นเหมือนเป็นแค่ กระแส และแม้จะลองคัดลอกไปใช้เองก็ยังไม่เห็นว่ามันวิเศษตรงไหน
      แต่ถ้าชอบใช้ก็ใช้ไปเถอะ และข้อดีอย่างหนึ่งของ AI คือ HN ไม่ได้ถูกอุดตันด้วยเรื่อง JavaScript framework มากเท่าเมื่อก่อนแล้ว
    • ในโปรเจกต์ใหม่ ๆ ผมเอนเอียงไปทาง vendoring มากขึ้นเรื่อย ๆ
      การหยิบไลบรารี UI สำเร็จรูปมาใช้ระยะสั้นอาจง่าย แต่โดยมากมักซับซ้อนเกินไป มีฟีเจอร์ที่ไม่ได้ใช้ถูกทำไว้แล้ว แก้ไขยากเมื่อต้องการทำให้ต่างจากแอปจำนวนมากที่ใช้ไลบรารีเดียวกัน และตอนอัปเกรด การแก้ไขเหล่านั้นก็มักพังแบบละเอียดอ่อน ผมคิดว่าแนวทางที่ดีที่สุดคือสร้างไลบรารี UI ของตัวเอง เป็นเจ้าของเอง ใช้ซ้ำได้ในหลายโปรเจกต์ คงสไตล์ภาพแบบเดียวกันได้ถ้าต้องการ และเพิ่มเฉพาะฟีเจอร์ที่จำเป็น
    • Mantine ยอดเยี่ยมมาก สร้างได้แทบทุกอย่างอย่างรวดเร็ว แล้วหลังจากนั้นยังขยายหรือปรับแต่งธีมกับคอมโพเนนต์รายตัวได้เต็มที่
      มี learning curve อยู่บ้าง แต่ผมว่าไม่ได้ใหญ่โตอะไร
    • ในหลายระบบ ความจริงแล้วแทบไม่เคยเป็น “แค่เพิ่มเลขเวอร์ชัน” เลย จะเป็นแบบนั้นได้ก็ต่อเมื่อไลบรารีคอมโพเนนต์ทำสิ่งที่ต้องการได้ตรงเป๊ะเท่านั้น
      ในความเป็นจริง คอมโพเนนต์มักไม่ได้ให้พฤติกรรมที่ต้องการครบถ้วน และผู้คนก็มักแปะ CSS เพิ่มเข้าไปในคอมโพเนนต์บ่อย ๆ ถ้าทางเลือกคืองานที่ต้องใช้เวลาหลายชั่วโมง CSS สองบรรทัดก็ล่อใจมาก แต่สองบรรทัดนั้นก็ต้องตรวจสอบกับฟีเจอร์ใหม่ทุกครั้งของไลบรารีคอมโพเนนต์ด้วย พอมี การปะ CSS แบบนี้ มากขึ้น การอัปเกรดก็กลายเป็นโปรเจกต์หนึ่งไปเลย
  • สิ่งที่รำคาญคือ toolkit UI ยอดนิยมพวกนี้ เรนเดอร์ div มากเกินไป
    ดู Base UI แล้วแทบทุกคอมโพเนนต์เหมือนจะ “เรนเดอร์ element” ทั้งนั้น ทั้งที่ใน accordion ก็มี element native อย่าง details/summary ที่ทำงานแบบเดียวกันได้ ผมไม่ใช่นักเผยแผ่เว็บ native และคิดว่า Web API โดยเฉพาะ HTML ก็มีข้อบกพร่องเยอะ แต่การใช้ div พร่ำเพรื่อก็ผิดเหมือนกัน

  • เคยใช้ Shadcn และโดยรวมชอบ แต่ radio button ที่อิง Radix นั้นเกินไปหน่อย มีตัวเลือกบางอย่างที่ใช้วิธีแก้ปัญหาโป่งพองเกินเหตุคล้าย ๆ กันด้วย
    https://news.ycombinator.com/item?id=46688971

    • ข้อบ่นหลักต่อ Shadcn และไลบรารี UI ส่วนใหญ่ในยุคนี้คือมันกำลังประดิษฐ์ล้อใหม่เป็นครั้งที่ราว ๆ พัน
      ผมกำลังลองใช้ Ark UI ใน side project อยู่ และก็มีคอมโพเนนต์ที่มีประโยชน์จริง ๆ อย่าง tags input: https://ark-ui.com/docs/components/tags-input
      คอมโพเนนต์ tabs/“segment group” มีตัวบ่งชี้ active แบบมีแอนิเมชัน ซึ่งน่าจะ implement ได้ค่อนข้างยาก: https://ark-ui.com/docs/components/segment-group
      แต่ก็มีปุ่ม “click to copy” หรือการทำใหม่ที่ซับซ้อนเกินไปปนอยู่ด้วย และทั้งหมดเรนเดอร์ ซุป div พร้อมมาร์กอัปยืดยาว: https://ark-ui.com/docs/components/clipboard, https://ark-ui.com/docs/components/collapsible
  • กระแสที่งานไมเกรชันย้ายจาก codemod ไปสู่ LLM น่าสนใจ
    ถึง codemod จะมีความแน่นอนเชิงกำหนดมากกว่า แต่ก็สงสัยว่ายุคของมันกำลังจะจบลงหรือเปล่า

    • ผมคิดว่าน่าลองใช้ LLM สร้าง codemod แบบ deterministic
      จากนั้นรัน codemod แล้วใส่กลไกป้องกันแบบ deterministic อื่น ๆ วนซ้ำไปเรื่อย ๆ และนำผลลัพธ์กลับเข้า LLM เพื่อปรับปรุง codemod ได้
    • กรอบความคิดในบทความต้นฉบับเป็นวิธีคิดที่อันตราย ตัว codemod เองจะมีหรือไม่มีก็ได้
      สิ่งที่ควรต้องการไม่ใช่ไฟล์ skill สำหรับ LLM แต่ควรเป็นเอกสารสำหรับคน เขียน คู่มือไมเกรชัน สำหรับคนก็พอ สุดท้ายคงต้องใช้เวลาสักพักกว่าจะตระหนักว่าไฟล์ skill กับเอกสารควรเป็นสิ่งเดียวกัน
    • สงสัยว่าในที่นี้ codemod หมายถึงอะไร
    • ผมคิดว่าสองอย่างนี้เสริมกันได้อย่างสมบูรณ์ และจะเป็นแบบนั้นต่อไป
      ผมยังใช้ไฟล์ AGENTS.md สำหรับกฎแบบยืดหยุ่น และใช้กฎลินเตอร์แบบคัสตอมสำหรับกฎที่เข้มงวด ซึ่งมองว่าเป็นวิธีที่ได้ข้อดีของทั้งสองโลก
  • อยากใช้ shad-CN แต่สุดท้ายทุกครั้งก็กลับไปใช้ Mantine
    มันเร็วกว่าการต้องจำว่าควรผูก context อะไรบ้างมาก

  • สงสัยว่าการเปลี่ยนแปลงนี้ให้ผลลัพธ์ที่ดีกว่าสำหรับผู้ใช้ เช่น ขนาดบันเดิลลดลง หรือไม่
    หรือเป็นการเปลี่ยนแปลงที่ใกล้เคียงกับการทำให้ชีวิตของผู้ดูแล Shadcn ดีขึ้นมากกว่า

  • สงสัยว่าใน Angular อะไรคือ สิ่งที่เทียบเท่ากับ shadcn/ui
    PrimeNG เพิ่งเปลี่ยนไลเซนส์เมื่อไม่นานนี้ เลยกำลังมองหาทางเลือกที่เหมาะกับโปรเจกต์ใหม่

    • มีความพยายามสองครั้ง[1] ที่จะดันข่าวการเปลี่ยนไลเซนส์ของ PrimeNG ขึ้น HN แต่ล้มเหลว อย่างไรก็ตามถ้าคุณใช้ไลบรารีคอมโพเนนต์ของ PrimeTek ก็ควรรู้การเปลี่ยนแปลงนี้ไว้
      PrimeNG, PrimeReact, PrimeVue จะเปลี่ยนไปเป็นซอร์สปิดทั้งหมด และตั้งแต่ปี 2027 ไลเซนส์สำหรับใช้งานต่อเนื่องจะอยู่ที่ 800 ดอลลาร์ ต่อที่นั่งนักพัฒนา[2] รีโพซิทอรีเดิมจะถูกเก็บถาวร[3] ส่วน PrimeFaces จะยังคงเป็นโอเพนซอร์สต่อไป แต่ตอนนี้พัฒนาและดูแลโดยนักพัฒนาอาสาสมัครอิสระที่ไม่ใช่พนักงานของ PrimeTek
      [1]: https://hn.algolia.com/?q=The+Next+Chapter+of+PrimeTek
      [2]: https://primeui.dev/nextchapter
      [3]: https://github.com/primefaces/primeng
    • อยู่ในสถานการณ์เดียวกัน ที่ทำงานใช้ PrimeNG กับหลายแอปมาโดยตลอด และดูเหมือนคงต้องติดอยู่กับ Angular 21 จนกว่าจะหาตัวแทนที่เหมาะสมได้
      แต่มีอยู่กลุ่มหนึ่งที่ fork PrimeNG และบอกว่ามีแผนจะดูแลต่อ ชื่อใหม่ยังไม่ได้กำหนด
      https://github.com/openng-org/open-prime
    • https://spartan.ng/
    • กำลังสร้าง Lily Design System เพื่อตอบโจทย์ที่ยังไม่มีระบบคล้าย Shadcn ให้ใช้ได้โดยตรงในหลายสแต็ก เช่น Svelte, Angular, Nunchucks
      ทั้งหมดฟรีและเป็นโอเพนซอร์ส ถ้าส่งฟีดแบ็กหรือข้อเสนอแนะมา ก็สามารถเพิ่มเข้า Lily ได้ง่าย
      https://lilydesignsystem.github.io
    • https://www.zardui.com
  • คิดถึง สไตล์ไกด์แบบ skeuomorphic สมัยก่อน
    ตัวสุดท้ายคงเป็น Blueprint

  • URL ควรเป็น https://ui.shadcn.com/docs/changelog/2026-07-base-ui-default