Shadcn/UI เปลี่ยนค่าเริ่มต้นจาก Radix มาเป็น Base UI
(ui.shadcn.com)- ตั้งแต่เดือนกรกฎาคม 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และมีส่วนต่อไปนี้ChangedLeft aloneBehavior changesVerify 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 จะอยู่ในแพ็กเกจนี้
- primitive ตัวแรกคือ
- แนวทางนี้ช่วยให้ได้พฤติกรรมโดยไม่ผูกกับสไตล์ภาพ และสามารถทดสอบตรรกะ 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 ได้โดยตรงผ่านshadcnCLI - 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
- ตัวอย่างเช่น custom variant อย่าง
- ระหว่างการทำงานเรื่องรองรับ 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ออกจากโปรเจกต์
- มันจะ inline
- ใน 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 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ในบทความนี้รู้สึกได้ค่อนข้างชัดถึง สำนวนเฉพาะแบบ Claude จนตอนนี้เริ่มเหนื่อยและรู้สึกห่างเหิน
ถ้าแม้แต่บทความเปิดตัวผลิตภัณฑ์สำคัญก็ยังไม่คุ้มให้มนุษย์ใส่ใจอย่างเต็มที่ ก็ไม่รู้แล้วว่าควรขีดเส้นตรงไหน
ถ้าการใช้ AI เขียนทำให้มีเวลาไปพัฒนาซอฟต์แวร์โอเพนซอร์สยอดเยี่ยมตัวนี้ได้มากขึ้น ผมกลับมองว่าเป็นเรื่องดี
พอใช้ “MSDN reference ยุค CD และสไตล์บล็อกของ Raymond Chen” เป็นพรอมป์ตั้งต้น ความสามารถในการย่อยแผนที่ AI สร้างขึ้นก็ดีขึ้นมาก และขอแนะนำอย่างยิ่ง เพราะเป็นสไตล์ที่ถ่อมตัว มี insight และเคารพผู้อ่าน
ถ้ามีใครในทีมออกมาบอกว่ามนุษย์เป็นคนเขียนเอง ก็คงตลกนิดหน่อย
ไม่เข้าใจว่าทำไมทุกครั้งที่ AI ช่วยงาน ถึงต้องพยายาม “จับให้ได้” กันด้วย และนี่เป็น โปรเจกต์โอเพนซอร์ส ไม่ใช่บริษัท F500 ทรัพยากรก็จำกัด และภาษาอังกฤษอาจไม่ใช่ภาษาแม่ด้วยซ้ำ
ผมเชื่อว่าวัฒนธรรมของการร่วมมือกันต้องอาศัยความไว้วางใจและความจริง และไม่อยากได้บทความที่ AI โกหกว่า “ฉันทำ/ฉันพูด”
เช่น ถ้าบทความนี้ Claude เขียนจริง ทำไมต้องทำเหมือนว่าคนในทีมพูดเองตรง ๆ ด้วยคำอย่าง “I said”, “I meant it” นั่นคือ การสวมรอย และเป็นการหลอกลวง ถ้าเป็นวัฒนธรรมที่รักษาความร่วมมือและความซื่อสัตย์ ก็ควรพูดว่า “มนุษย์ของฉันพูดไว้” หรืออย่างน้อยต้องระบุให้ถูกต้องว่าเป็น AI ที่ทำหน้าที่แทนมนุษย์
สงสัยว่าในแอปพลิเคชันน่าเบื่อ ๆ ผู้คนชอบ แนวทาง copy-paste ของ shadcn มากกว่าไลบรารี UI แบบดั้งเดิมอย่าง Mantine หรือเปล่า
แนวทาง copy-paste แก้ไขได้ง่ายก็จริง แต่ก็สร้างปัญหาใหม่ด้วย เช่น เรื่องที่ควรจะแค่เพิ่มเลขเวอร์ชัน ตอนนี้กลับต้องมี AI agent สำหรับอัปเกรด
ไม่ใช่แอปน่าเบื่อ แต่เป็นแอปใหญ่มาก และทุกครั้งที่อัปเดต major version ก็พลิก API ครั้งใหญ่ จนต้องทำ migration น่าเบื่อ ๆ พอย้ายมา shadcn แล้วก็ง่ายขึ้น เพราะอัปเกรดเฉพาะคอมโพเนนต์เดี่ยว ๆ และเพิ่มคอมโพเนนต์ใหม่ได้อย่างอิสระ ใน Material UI ถ้าอยากใช้ฟีเจอร์ใหม่ตรงไหน ก็ต้องเปลี่ยนทั้งหมดให้เข้ากับ API ใหม่ แต่ shadcn เลือกทำเฉพาะจุดได้
แต่ถ้าชอบใช้ก็ใช้ไปเถอะ และข้อดีอย่างหนึ่งของ AI คือ HN ไม่ได้ถูกอุดตันด้วยเรื่อง JavaScript framework มากเท่าเมื่อก่อนแล้ว
การหยิบไลบรารี UI สำเร็จรูปมาใช้ระยะสั้นอาจง่าย แต่โดยมากมักซับซ้อนเกินไป มีฟีเจอร์ที่ไม่ได้ใช้ถูกทำไว้แล้ว แก้ไขยากเมื่อต้องการทำให้ต่างจากแอปจำนวนมากที่ใช้ไลบรารีเดียวกัน และตอนอัปเกรด การแก้ไขเหล่านั้นก็มักพังแบบละเอียดอ่อน ผมคิดว่าแนวทางที่ดีที่สุดคือสร้างไลบรารี UI ของตัวเอง เป็นเจ้าของเอง ใช้ซ้ำได้ในหลายโปรเจกต์ คงสไตล์ภาพแบบเดียวกันได้ถ้าต้องการ และเพิ่มเฉพาะฟีเจอร์ที่จำเป็น
มี 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
ผมกำลังลองใช้ 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 จะมีความแน่นอนเชิงกำหนดมากกว่า แต่ก็สงสัยว่ายุคของมันกำลังจะจบลงหรือเปล่า
จากนั้นรัน codemod แล้วใส่กลไกป้องกันแบบ deterministic อื่น ๆ วนซ้ำไปเรื่อย ๆ และนำผลลัพธ์กลับเข้า LLM เพื่อปรับปรุง codemod ได้
สิ่งที่ควรต้องการไม่ใช่ไฟล์ skill สำหรับ LLM แต่ควรเป็นเอกสารสำหรับคน เขียน คู่มือไมเกรชัน สำหรับคนก็พอ สุดท้ายคงต้องใช้เวลาสักพักกว่าจะตระหนักว่าไฟล์ skill กับเอกสารควรเป็นสิ่งเดียวกัน
ผมยังใช้ไฟล์ AGENTS.md สำหรับกฎแบบยืดหยุ่น และใช้กฎลินเตอร์แบบคัสตอมสำหรับกฎที่เข้มงวด ซึ่งมองว่าเป็นวิธีที่ได้ข้อดีของทั้งสองโลก
อยากใช้ shad-CN แต่สุดท้ายทุกครั้งก็กลับไปใช้ Mantine
มันเร็วกว่าการต้องจำว่าควรผูก context อะไรบ้างมาก
สงสัยว่าการเปลี่ยนแปลงนี้ให้ผลลัพธ์ที่ดีกว่าสำหรับผู้ใช้ เช่น ขนาดบันเดิลลดลง หรือไม่
หรือเป็นการเปลี่ยนแปลงที่ใกล้เคียงกับการทำให้ชีวิตของผู้ดูแล Shadcn ดีขึ้นมากกว่า
สงสัยว่าใน Angular อะไรคือ สิ่งที่เทียบเท่ากับ shadcn/ui
PrimeNG เพิ่งเปลี่ยนไลเซนส์เมื่อไม่นานนี้ เลยกำลังมองหาทางเลือกที่เหมาะกับโปรเจกต์ใหม่
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
แต่มีอยู่กลุ่มหนึ่งที่ fork PrimeNG และบอกว่ามีแผนจะดูแลต่อ ชื่อใหม่ยังไม่ได้กำหนด
https://github.com/openng-org/open-prime
ทั้งหมดฟรีและเป็นโอเพนซอร์ส ถ้าส่งฟีดแบ็กหรือข้อเสนอแนะมา ก็สามารถเพิ่มเข้า Lily ได้ง่าย
https://lilydesignsystem.github.io
คิดถึง สไตล์ไกด์แบบ skeuomorphic สมัยก่อน
ตัวสุดท้ายคงเป็น Blueprint
URL ควรเป็น https://ui.shadcn.com/docs/changelog/2026-07-base-ui-default