Tailwind Plus เพิ่มการรองรับ Vanilla JavaScript

• บล็อก UI ของ Tailwind Plus ตอนนี้สามารถทำงานได้อย่างสมบูรณ์ด้วย Vanilla JavaScript เพียงอย่างเดียว
• สามารถใช้ คอมโพเนนต์แบบโต้ตอบได้โดยไม่ต้องพึ่งเฟรมเวิร์ก อย่าง React, Vue เป็นต้น
• มีการเปิดตัว ไลบรารีที่อิงกับ custom elements ใหม่ในชื่อ @tailwindplus/elements
• เน้นการใช้งานที่เข้ากันได้กับ แพลตฟอร์มและเฟรมเวิร์ก ที่หลากหลาย
• ลูกค้า Tailwind Plus ทุกคน สามารถใช้งานฟีเจอร์นี้ได้ทันที

---

Tailwind Plus เริ่มรองรับ Vanilla JavaScript

บล็อก UI จำนวนมากของ Tailwind Plus (เช่น dialog, dropdown, command palette) ในทางปฏิบัติต้องมี JavaScript จึงจะนำไปใช้งานจริงได้ ก่อนหน้านี้ หากไม่ได้ใช้ React หรือ Vue ผู้ใช้จะต้องเขียน JavaScript เองเพื่อทำให้บล็อก UI เหล่านี้โต้ตอบได้

แต่ตอนนี้บล็อก UI ทั้งหมดมาพร้อม ฟังก์ชันครบถ้วน การเข้าถึงได้ และองค์ประกอบแบบอินเทอร์แอ็กทีฟ จึงสามารถทำงานได้ทันทีแม้ในตัวอย่าง Plain HTML กล่าวคือ สามารถนำบล็อกอินเทอร์เฟซต่าง ๆ เช่น dropdown, command palette, dialog, drawer ไปใช้ได้ทุกที่ในโปรเจ็กต์โดยไม่ต้องพึ่ง JavaScript framework

@tailwindplus/elements: ไลบรารีแกนหลัก

สิ่งที่ทำให้การเปลี่ยนแปลงนี้เป็นไปได้ก็คือไลบรารี @tailwindplus/elements โดยเป็นแพ็กเกจเฉพาะสำหรับลูกค้า Tailwind Plus และเป็นชุดของ headless custom elements

• custom elements สามารถใช้งานได้ทุกที่ เพียงเพิ่มแท็ก <script> หนึ่งบรรทัดในโค้ด HTML
• งานอย่างอินเทอร์แอ็กชันที่ซับซ้อน การจัดการโฟกัส การเข้าถึงด้วยคีย์บอร์ด และการกำหนดคุณสมบัติ ARIA จะถูกจัดการให้อัตโนมัติ
• การตกแต่งสไตล์สามารถปรับแต่งได้อย่างอิสระด้วย utility class ของ Tailwind CSS หรือ CSS ที่เขียนเอง

ตัวอย่างการใช้งานหลัก

• dropdown: ประกอบด้วย custom elements เช่น <el-dropdown>, <el-menu> และทำงานได้โดยไม่ต้องมี JavaScript เพิ่มเติม
• select: สามารถสร้างคอมโพเนนต์เลือกขั้นสูงได้ด้วย elements อย่าง <el-select>, <el-options>, <el-option>
• command palette: ใช้งานฟังก์ชันครบถ้วนได้ด้วยโครงสร้างอย่าง <el-command-palette>, <el-command-list> เป็นต้น

custom elements เหล่านี้จัดการคุณสมบัติ ARIA การย้ายโฟกัส และการนำทางด้วยคีย์บอร์ดโดยอัตโนมัติ จึงรองรับ web accessibility ได้อย่างแข็งแกร่ง

การผสานเข้ากับเฟรมเวิร์กและการลดการพึ่งพาแพลตฟอร์ม

• ใช้งานร่วมได้ทั้งในสภาพแวดล้อมที่ใช้ HTML อย่างเดียว รวมถึง Svelte, Rails(Ruby on Rails), React และสภาพแวดล้อมอื่น ๆ
• ตัวอย่าง Svelte: มีตัวอย่างการเพิ่ม two-way binding ให้กับ <el-autocomplete>
• ตัวอย่าง Rails: เมื่อส่งฟอร์ม ค่าใน <el-select> จะถูกส่งไปยังเซิร์ฟเวอร์เหมือน native form control
• ตัวอย่าง React: ต่างจาก Headless UI และ React Aria เดิมตรงที่สามารถใช้งานได้โดยไม่ผูกกับเฟรมเวิร์ก

มาตรฐานเว็บสมัยใหม่และการรองรับเบราว์เซอร์

• Elements ใช้ความสามารถของเว็บแพลตฟอร์มสมัยใหม่ (เช่น Web Components, Custom Elements) อย่างเต็มที่ เพื่อมอบโครงสร้างที่เบาและประสบการณ์แบบเนทีฟ
• หากจำเป็น จะมีการ bundle polyfill ให้อัตโนมัติเพื่อให้ได้ขอบเขตการรองรับเบราว์เซอร์เช่นเดียวกับ Tailwind CSS v4
• เมื่อมาตรฐานเว็บแพร่หลายมากขึ้น ขนาดของ Elements ก็มีแนวโน้มจะเบาลงตามธรรมชาติ

ความเป็นสากลอย่างแท้จริง: "HTML คือ least common denominator"

HTML คือ "least common denominator" ของเว็บเฟรมเวิร์กทั้งหมด และเมื่อใช้ Elements บล็อก UI แบบ HTML ของ Tailwind Plus จะทำงานได้อย่างสม่ำเสมอในทุกสภาพแวดล้อม

• มีตัวอย่างการใช้งานจริงและโค้ดสำหรับ Svelte, Rails, React เป็นต้น

การเปิดตัวและการเข้าถึง

• หากเป็น สมาชิก Tailwind Plus ก็สามารถใช้งานบล็อก UI ที่อัปเดตทั้งหมดและ Elements ได้ทันที
• มีเดโมตัวอย่างตามหมวดหมู่ UI ต่าง ๆ เช่น dropdown, command palette รวมถึง เอกสารทางการของ Elements
• สามารถปรับแต่งได้ตามต้องการให้เหมาะกับความต้องการของโปรเจ็กต์

ปิดท้าย

จากนี้ไป ผู้ใช้ Tailwind Plus ก็สามารถสร้าง UI ที่ทรงพลังและเข้าถึงได้ ได้อย่างง่ายดายในทุกสภาพแวดล้อมที่ต้องการ โดยไม่ต้องเขียน JavaScript ที่ซับซ้อน

[GN⁺]

ความคิดเห็นใน Hacker News

• พอเห็นการตั้งชื่อคลาสของ Tailwind ที่ยาวและเป็นลำดับชั้นอย่าง `` ก็รู้สึกว่าตอนนี้เราต้องเรียนรู้อีกระบบลำดับชั้นหนึ่งนอกเหนือจาก CSS แล้ว

  • ทุกครั้งที่เปิดโปรเจกต์ Tailwind ขนาดใหญ่ แล้วเจอรายการ class attribute ที่ยาวมหาศาลในบรรทัดเดียว ก็มักจะทึ่งอยู่เสมอ

    
    ...
    
    

  • ก่อนมี Tailwind เว็บดีไซเนอร์ที่เจอแทบทุกคนก็มักสร้างระบบแบบนี้ขึ้นมาในแบบของตัวเอง ในทางทฤษฎี CSS ก็ทรงพลังพอและทำได้โดยไม่ต้องมี Tailwind แต่ในทางปฏิบัติ CSS มีจุดอ่อนใหญ่ข้อหนึ่ง: ถ้าจะใช้ศักยภาพมันเต็มที่ คุณต้องออกแบบ semantic model แยกต่างหาก และนักออกแบบจำนวนมากมักโฟกัสกับการถ่ายทอดบรรยากาศและอารมณ์มากกว่าโครงสร้างเอกสารหรือสถาปัตยกรรมข้อมูล การทำมาร์กอัปแนวคิดเชิงอารมณ์แบบนี้ให้เป็นกฎเชิงตรรกะนั้นยากมากหรือแทบเป็นไปไม่ได้ Tailwind ก็แค่ทำสิ่งที่ทุกคนทำกันอยู่แล้วให้เป็นทางการ นั่นคือแทนที่จะทำ abstraction ของ “ความหมาย” ก็ใช้กฎที่นำไปใช้ได้ตรง ๆ อย่าง bold, red

  • ผมสงสัยว่าคนที่ดูโค้ดแบบนี้แล้วพูดว่า ‘ว้าว นี่มันโค้ดที่สะอาดจริง ๆ!’ เกิดขึ้นมาได้ยังไง ไม่รู้ว่า Tailwind ได้รับความนิยมขนาดนี้ได้อย่างไร และคิดว่าการเรียน CSS แบบเพียว ๆ นั้นดีจริง ๆ ทุกวันนี้ CSS ดีขึ้นมากจริง ๆ

  • ในโปรเจกต์จริงเรามักจัดกลุ่ม class เพื่อให้อ่านง่าย ตัวอย่างเช่น

    จะเขียนกันแบบนี้ ตอนนี้ยังจัดหมวดหมู่ด้วยมืออยู่ แต่ถ้ามีเครื่องมือที่ช่วยทำ format แบบนี้อัตโนมัติได้ก็คงดี

  • เดิมที Tailwind ดูเหมือนจะเริ่มจากแนวคิดของ utility class style CSS framework หรือที่เรียกกันประมาณว่า “Bourbon on Steroids” แต่ผู้คนกลับยอมรับโค้ดตัวอย่างได้ง่ายกว่าที่คิดมาก และก็ใช้วิธีสะสมมันไปตรง ๆ ในปี 2018 ผมลองใช้ Tailwind กับโปรเจกต์ใหม่ขนาดใหญ่ และเมื่อก่อนการซ้อนคลาสบน utility ของ Tailwind อย่าง .button, .button-primary จะทำให้ดูแลง่ายและ HTML ก็สะอาด แต่พอทีมได้ลองใช้จริง ก็พบว่าการซ้อน utility class ที่มีมาให้ตรง ๆ นั้นเร็วและง่ายกว่ามาก ถ้าไม่กังวลเรื่องความสวยงามของโค้ด การออกแบบก็สม่ำเสมอและทำได้เหมือนที่เห็นใน Photoshop เป๊ะ ดู Bourbon

• นี่เป็นวิธีที่ใช้ Web Components บนพื้นฐานของเว็บมาตรฐาน เบราว์เซอร์รองรับโดยตรง จึงทำงานได้โดยไม่ต้องมี JS framework รู้สึกดีที่นักพัฒนาหันมาใช้ Web Components กันมากขึ้น Web Components คืออะไร? (MDN)

  • นี่คือการเปลี่ยนแปลงที่รอคอยมานาน เมื่อก่อนตอนที่ยังไม่ต้องสนใจเรื่อง compatibility ผมเคยเล่นกับ Web Components ในโปรเจกต์ส่วนตัว และดีใจมากที่ตอนนี้แม้แต่ไลบรารีกระแสหลักก็เริ่มนำมาใช้แล้ว

  • ผมพูดเรื่องความจำเป็นของ Web Components มา 12 ปีแล้ว แต่ฝั่งเฟรมเวิร์กอย่าง React, Angular, Svelte ฯลฯ กลับไม่ค่อยสนใจ แค่เว็บคอมโพเนนต์กับ JS/TS แบบ scoped และ bundler อย่าง vite หรือ rollup ก็เพียงพอแล้ว ไม่จำเป็นต้องมี overhead เปล่าประโยชน์อย่าง Shadow DOM หรือการ rerender ทั้งหมด

  • ตอนที่ลองเล่นกับ Polymer ราวปี 2014 คำว่า “transclusion” ทำให้ผมประทับใจมาก ตอนนั้นมันดูน่าทึ่งดี แต่ตอนนี้จำความหมายแทบไม่ได้แล้ว

  • ผมเคยลองใช้ Web Components ใน hook สำหรับโค้ดโฆษณาของบริษัท แต่ส่วนตัวค่อนข้างผิดหวัง การ trigger การรันโค้ดนั้นง่าย แต่ API เองกลับไม่ค่อยดี

• เวลามองโลกของ UI component ยอดนิยม ก็สงสัยว่าทำไมฐานทั้งหมดถึงไม่เป็นแบบ ‘headless’ Web Components มีมานานแล้ว แต่กลับไม่ค่อยเห็นแนวทางนี้แพร่หลาย ซึ่งก็น่าแปลกใจ ไลบรารีแยกตามเฟรมเวิร์กต่าง ๆ (เช่น SHADCN) ต้องทำเอกสารแยกกันเองตามเวอร์ชันที่รองรับ และยังยึดติดกับสภาพแวดล้อมเฉพาะจนสุดท้ายความสมบูรณ์ก็ไม่สูงนัก น่าจะดีกว่าถ้าสร้างบนฐานของ Headless UI แล้วค่อยทำ wrapper ตามเฟรมเวิร์กเมื่อจำเป็น แน่นอนว่าผมรู้ว่ามันมีเรื่องซับซ้อนกว่านั้นมาก แต่ก็ยังอยากเห็นโลกแบบนั้น

  • สำหรับเฟรมเวิร์กยอดนิยมอย่าง React, Vue, Svelte ฯลฯ Web Components เป็นแค่ overhead ทั้งในแง่ bundle size และ runtime โดยเฉพาะใน React ถ้าไม่ยอมรับความไม่เข้ากันของแนวคิดก็ต้องเสียทั้งฟีเจอร์และการใช้งาน หรือไม่ก็ต้องทำ binding ที่ซับซ้อนจนไม่มีเหตุผลจะใช้ Web Components ตั้งแต่แรก ฟีเจอร์ขั้นสูงอย่าง SSR ก็มักมีปัญหาด้วย ในโลกที่ React ครองตลาด ผมไม่อยากใช้ Web Components เป็นพิเศษ และแนวทาง headless เองก็มักซับซ้อนหรือมี overhead สูงในภาคปฏิบัติ

• ถ้ามีใครสักคนช่วยสนับสนุนเงินทุนให้ทีม Tailwind มากพอ ก็ชวนให้จินตนาการว่าโลกคงดีขึ้นมาก เพราะทุกคนจะได้ใช้ ecosystem ทั้งหมดของ Tailwind ฟรีโดยไม่ต้องกังวลเรื่องเงิน เสียดายที่โอกาสในการทำ integration ลึก ๆ กับที่ต่าง ๆ อย่าง Tailwind Plus หายไปเยอะมาก มันทำให้นึกถึงกรณีที่ 37signals เคยได้รับเงินลงทุนจาก Jeff Bezos จนไม่ต้องกังวลเรื่อง VC

  • ทีม Tailwind ประสบความสำเร็จเกินกว่าที่หลายคนจินตนาการไว้แล้ว ที่ยังอยากสร้างและขยายอะไรต่อ ไม่ใช่เพราะต้องการเงิน แต่เป็นความทะเยอทะยานตามธรรมชาติ จากความรู้สึกของผม Tailwind (โอเพนซอร์ส) เป็นเพียงส่วนหนึ่งของธุรกิจทั้งหมด และพวกเขาก็อยากสร้างโปรเจกต์อื่นที่ทำรายได้ด้วย เทียบกับ Laravel ได้เหมือนกัน

  • พูดตรง ๆ ว่าตอนนี้ AI สร้างคอมโพเนนต์ Tailwind ได้ง่ายมาก เลยทำให้อยากซื้อคอมโพเนนต์เสียเงินอย่าง Tailwind Plus น้อยลง สมัย Tailwind UI ผมเคยจ่ายเงินจริงซื้อ แต่ทุกวันนี้ผมกลับชอบให้ AI อย่าง Claude สร้าง UI ให้ตรง ๆ มากกว่า และยังไม่ต้องกังวลเรื่องไลเซนส์ด้วย เลยสงสัยว่าโมเดลธุรกิจแบบไหนจะใช้ได้ในอนาคต

  • เรื่อง 37signals นั้น โดยส่วนตัวผมกลับคิดว่าผู้ก่อตั้งอาจทำได้ดีกว่าถ้าต้องทำงานโดยมีคนคอยถามความคืบหน้าอยู่บ้าง

  • จริง ๆ แล้ว “ประสบการณ์ทั้งหมดของ Tailwind” ก็มีให้ใช้ฟรีอยู่แล้ว ผมเลยสงสัยว่าคำว่า integration เชิงลึกที่ยังขาดนั้นหมายถึงอะไร Tailwind Plus (สินค้าพาณิชย์) ก็เป็นแค่ชุดเทมเพลตสำเร็จรูปและคอลเลกชันคอมโพเนนต์ที่เตรียมไว้แล้ว สะดวกสำหรับนักพัฒนาที่อยากเริ่มต้นเร็ว แต่สุดท้ายทุกอย่างก็สร้างเองได้หมดถ้ามีแค่ Tailwind

  • อยากรู้ว่าหมายถึง integration แบบไหนโดยเฉพาะ

• อย่าเพิ่งตื่นเต้นเกินไปน่าจะดีกว่า แต่ก่อนพวกเขาเคยรองรับ Vue ด้วย แต่ตอนนี้ดูเหมือนจะถูกทิ้งไปโดยพฤตินัยแล้ว

  • นี่แหละคือการรองรับ Vue เฟรมเวิร์กมีมากเกินไปจนแทบเป็นไปไม่ได้ที่จะทำ custom wrapper ให้เหมาะกับทุกตัว ถ้าใช้ Web Components ก็พัฒนาแค่ครั้งเดียวแล้วใช้ได้ทุกสภาพแวดล้อม สุดท้ายแค่ให้เฟรมเวิร์กรองรับ Web Components (หรือพูดอีกอย่างคือรองรับ HTML) ได้ดีก็พอ

  • Vue รองรับ Web Components ได้ดีมาก และ React 19 เองก็เพิ่งเริ่มรองรับได้ดีในที่สุด แม้ ecosystem ของ Web Components จะยังยุ่งเหยิงอยู่จริง แต่การส่งมอบ “คอมโพเนนต์ที่นำกลับมาใช้ได้ในทุกเฟรมเวิร์ก” แบบนี้ต่างหากคือ killer app ที่แท้จริงของ Web Components น่าแปลกใจที่พวกเขาไม่ได้โปรโมตสิ่งนี้ในฐานะ “รองรับทุกเฟรมเวิร์กแล้ว” แทนที่จะบอกว่าเป็น “สำหรับ vanilla JavaScript”

  • พวกเขาเคยทำไลบรารีดีไซน์สำหรับ Figma ด้วย แต่ตอนนี้มันหายไปแล้ว เป็นกรณีที่น่าเสียดายมากสำหรับการทำงานร่วมกับนักออกแบบ

  • ชื่อมันก็บอกอยู่แล้วว่าเน้น tailwindcss

• ผมคิดว่ากรณีใช้งาน custom element แบบนี้น่าสนใจดี แต่กับ Tailwind กลับเป็นฟีเจอร์เสียเงินก็เลยรู้สึกแปลก ๆ ตามสัญชาตญาณแล้วผมคาดหวังว่า custom element ควรฟรี ส่วน integration กับเฟรมเวิร์กค่อยเป็นแบบเสียเงินน่าจะดูสมเหตุสมผลกว่า ราคา Tailwind Plus

  • มันเป็นของเสียเงินเพราะใช้เงินราว $250,000 ในการพัฒนาไลบรารีนี้ ถ้าจะให้ฟรีและยังดูแลรักษาต่อไปด้วยก็คงเป็นไปไม่ได้ และวิศวกรฝีมือดีควรได้รับค่าตอบแทนที่เหมาะสม

  • Tailwind Plus เป็นคอลเลกชันคอมโพเนนต์ UI และเทมเพลตแบบเสียเงิน ส่วนตัว TailwindCSS เองก็เป็นแค่เครื่องมือจัดสไตล์คล้าย Bootstrap

  • อีกฟีเจอร์เสียเงินที่เป็นที่รู้จักก็คือ SSO มันเป็นสิ่งที่สัญชาตญาณบอกว่าไม่ควรต้องเสียเงิน แต่ก็เป็นกลยุทธ์ที่จงใจเลื่อนช่วงเวลาการตัดสินใจนำมาใช้

  • การขายของแบบนี้ดูแปลกอยู่บ้าง ในโลกเว็บดีเวลอปเมนต์ที่ของฟรีเป็นค่าเริ่มต้น ถ้าจะใช้เฟรมเวิร์กไปตลอดชีวิตแล้วต้องจ่ายค่าสมาชิกก็ดูประหลาดได้ เหมือนกับถ้า Postgres เรียกเก็บค่าบริการรายเดือน แต่พอดู pricing แล้วก็เป็นการซื้อครั้งเดียวใช้ได้ตลอดชีวิต เลยสงสัยว่าวิธีนี้จะเวิร์กแค่ไหน

• ดูเหมือน Alpine.js จะหายไปจาก custom block elements ของ tailwindcss plus แล้ว พอเห็นว่าในตัวอย่างโค้ดไม่มี alpinejs อีกต่อไปก็รู้สึกผิดหวัง ตอนนี้มันกลายเป็น

  แบบนี้แทน ในฐานะคนที่ใช้ Alpine มาก่อน ก็เสียดายที่ไม่สามารถใช้ตัวอย่างแบบคัดลอกวางได้อีกแล้ว

• อยากให้ฟีเจอร์นี้เปิดให้ผู้ใช้ Tailwind ฟรีได้ลองด้วยจริง ๆ มันน่าสนใจมากและอยากลองใช้สักครั้ง แต่เสียดายที่เวอร์ชันฟรีลองสัมผัสอะไรไม่ได้เลย ถึงอย่างนั้นก็ยังรู้ดีว่าโอเพนซอร์สหาผู้สนับสนุนได้ยากเสมอ จึงอยากขอบคุณ tailwind สักวันหนึ่งผมก็อยากเป็นคนที่บริจาคและมีส่วนร่วมกับโอเพนซอร์สเหมือนกัน

• เขาบอกว่าสามารถสร้างสิ่งอย่าง command palette ขั้นสูงใน Elements ได้ เช่น `` แต่ที่จริงแล้วก็เป็นไปได้เพราะพวกเขาเพิ่มฟีเจอร์นั้นเข้าไปในคอมโพเนนต์นั้นโดยตรงอยู่แล้ว

• ช่วงหลังมานี้พอได้ใช้ Tailwind มากขึ้น ก็ยอมรับว่ามันมีจุดเด่นด้านความสะดวกและการช่วย abstraction ความยุ่งยากของการออกแบบ design system แต่ในระยะยาว การลงทุนสร้าง design system และ component library ของตัวเองโดยตรงยังเป็นทางออกที่ครบถ้วนกว่ามาก ทั้งในด้าน DX ความยืดหยุ่น ภาษาด้านสุนทรียะ และการพึ่งพา