XMLUI

 (blog.jonudell.net)
2 คะแนน โดย GN⁺ 2025-07-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • XMLUI นำโมเดลการพัฒนาคอมโพเนนต์ของ Visual Basic มาประยุกต์ใช้กับเว็บสมัยใหม่ ทำให้สามารถพัฒนา เว็บแอปได้อย่างง่ายดายโดยไม่ต้องมีความรู้เรื่อง React และ CSS
  • XMLUI สามารถประกอบ คอมโพเนนต์ หลากหลายแบบด้วย XML markup ได้อย่างสะดวก และรองรับ reactive data binding, การจัดการธีม, การขยายสคีมา และอื่น ๆ
  • ผ่าน Model Context Protocol(MCP) จึงสามารถ ทำงานร่วมกับ AI เพื่อเพิ่มประสิทธิภาพการพัฒนาและยกระดับความสามารถในการดูแลรักษาโค้ด
  • XMLUI ทำให้ระบบนิเวศของ React ที่ซับซ้อนเรียบง่ายลง จึงมอบสภาพแวดล้อมที่ แม้แต่ผู้ที่ไม่ใช่ผู้เชี่ยวชาญก็สามารถพัฒนา UI และแอปได้อย่างง่ายดาย
  • การดีพลอยและการขยายระบบ ทำได้ง่าย และนักพัฒนาที่ไม่คุ้นเคยกับ React·CSS ก็ยังสามารถทำโปรเจกต์เว็บและสร้าง CMS ได้หลากหลาย

บทนำและภาพรวม

โปรเจกต์ XMLUI คือความพยายามในการนำแนวทางการประกอบคอมโพเนนต์แบบเข้าใจง่ายที่พบได้ใน Visual Basic ยุค 1990s มาสู่สภาพแวดล้อมบนเว็บ ในเวลานั้น Visual Basic ทำให้แม้แต่คนที่ไม่ใช่โปรแกรมเมอร์มืออาชีพก็สามารถเชื่อมต่อคอมโพเนนต์ต่าง ๆ เพื่อสร้างซอฟต์แวร์ที่มีประโยชน์ได้อย่างง่ายดาย ตรงกันข้ามกับโลกเว็บที่ยังไม่สามารถสร้างระดับการใช้งานและระบบนิเวศแบบนั้นขึ้นมาได้ XMLUI ห่อหุ้ม React component และ CSS ไว้ แล้วเปิดทางให้พัฒนาเว็บแอปได้ด้วย XML markup เพียงอย่างเดียว

ต่อไปนี้คือตัวอย่างโค้ด XMLUI ไม่กี่บรรทัด:

<App>
  <Select id="lines" initialValue="bakerloo">
    <Items data="https://api.tfl.gov.uk/line/mode/tube/status">;
    </Items>
  </Select>
  <DataSource
    id="tubeStations"
    url="https://api.tfl.gov.uk/Line/{lines.value}/Route/Sequence/inbound";
    resultSelector="stations"/>
  <Table data="{tubeStations}" height="280px">
    <Column bindTo="name" />
    <Column bindTo="modes" />
  </Table>
</App>

เพียง XML ราว 12 บรรทัดก็สามารถอธิบายงานต่อไปนี้ได้:

  • เติมตัวเลือกใน Select แบบอัตโนมัติผ่านการเรียก API
  • ใช้ค่าจาก Select เพื่อ ดึงข้อมูลจาก API อื่น
  • ดึงเฉพาะฟิลด์บางส่วนจากผลลัพธ์ API แล้ว bind เข้ากับตาราง

XMLUI มีทั้งความ ทันสมัยแบบ component-based และ reactive แต่ผู้ใช้ยังสามารถพัฒนาและดูแลรักษาได้โดยไม่ต้องมีความรู้เชิงลึกเกี่ยวกับ React หรือ CSS จุดนี้เป็นความแตกต่างสำคัญที่ช่วยลดกำแพงของระบบนิเวศ JavaScript แบบเดิม

ระบบนิเวศของคอมโพเนนต์

อดีตและปัจจุบัน

ในยุค Visual Basic ผู้ใช้สามารถรวม องค์ประกอบต่าง ๆ (คอมโพเนนต์) อย่าง chart, network, data access, media playback เข้ากับแอปได้อย่างง่ายดาย แต่ระบบนิเวศคอมโพเนนต์ที่มีประสิทธิภาพแบบนั้นไม่ได้ถูกย้ายมาสู่เว็บอย่างสมบูรณ์ ทุกวันนี้คอมโพเนนต์บนเว็บส่วนใหญ่ยังอิงกับ React และยังต้องอาศัยทักษะของนักพัฒนาเฉพาะทางอยู่ดี XMLUI จึงเข้ามาห่อหุ้ม React component เหล่านี้ให้ทุกคนใช้งานได้ง่ายขึ้น

คอมโพเนนต์แบบกำหนดเอง

XMLUI มีทั้ง คอมโพเนนต์ในตัวที่หลากหลาย และยังสามารถ นิยามคอมโพเนนต์ขึ้นเอง เพื่อนำมาผสมผสานและใช้ซ้ำตามต้องการได้ ตัวอย่างเช่น สามารถนิยามคอมโพเนนต์ TubeStops สำหรับแสดงข้อมูลสถานีรถไฟใต้ดินลอนดอนได้ดังนี้:

<Component name="TubeStops">
  <DataSource ... />
  <Text variant="strong">{...}</Text>
  <Table ... >
    <Column ... />
  </Table>
</Component>

TubeStops จะดึงข้อมูลจาก API ตามชื่อ Line และแสดงผลในรูปแบบตาราง เมื่อดูจาก markup จริงจะพบว่าอ่านง่าย และเมื่อโค้ดยาวเกิน 100 บรรทัดก็สามารถ refactor เป็นคอมโพเนนต์เพื่อให้ดูแลรักษาง่ายขึ้นได้ ช่วงหลังมานี้ ด้วยความช่วยเหลือของ LLM(large language model) การ refactor คอมโพเนนต์และการดูแลรักษาโค้ดก็ยืดหยุ่นมากขึ้นอีก

Reactive binding และการพัฒนาแบบ declarative

ใน XMLUI ข้อมูลและการเปลี่ยนแปลงค่าของ UI จะเชื่อมโยงกันโดยอัตโนมัติ (Reactive Data Binding) ตัวอย่างเช่น เมื่อมีการเปลี่ยนค่าที่เลือกใน Select ค่า API address ที่อ้างอิงมันอยู่ (url ของ DataSource) ก็จะอัปเดตอัตโนมัติและดึงข้อมูลใหม่อีกครั้ง วิธีนี้คล้ายกับการอ้างอิงเซลล์ใน Excel

ผู้ใช้จำเป็นต้องคุ้นเคยกับแนวคิดการพัฒนาแบบ declarative แทนการพัฒนาเชิงคำสั่งแบบเก่า แต่เมื่อคุ้นเคยแล้วจะได้ประสบการณ์พัฒนาที่รวดเร็วและตรงไปตรงมา ตัวอย่างเช่น เมื่อต้องการสร้างฟังก์ชันค้นหา (Search) ก็สามารถทำโครงสร้างที่เชื่อมข้อมูลแบบเรียลไทม์และสะท้อนผลในตารางได้ง่าย ๆ จากการเปลี่ยนค่าของ input box โดยไม่ต้องมีปุ่มเลย

ระบบธีม

ในช่วงแรกอาจไม่ได้ให้ความสำคัญกับระบบธีมมากนัก แต่ฟีเจอร์ การจัดการธีม ของ XMLUI นั้นทรงพลังมาก โดยสามารถจัดการ สี พื้นหลัง ระยะห่าง ฟอนต์ และอื่น ๆ ของแต่ละคอมโพเนนต์ ได้อย่างสม่ำเสมอบนฐานของตัวแปร โดยไม่ต้องเขียน CSS ตัวอย่างเช่น สามารถกำหนดสีของปุ่มให้ต่างกันตาม context และ state (เช่น hover)

ธีมสามารถควบคุมอย่างละเอียดในรูปแบบ color-primary, backgroundColor-Button เป็นต้น ทำให้กำหนดชุดสีของ UI โดยรวมได้ง่าย และนำไปใช้ได้ทั้งระดับ global หรือเฉพาะส่วน

การใช้สคริปต์

XMLUI ไม่ได้เป็น declarative ทั้งหมดแบบสมบูรณ์ เช่นเดียวกับ Visual Basic มันเปิดให้มี การแทรกสคริปต์ง่าย ๆ (ส่วนใหญ่คือ JavaScript) แบบบางส่วน เพื่อนำไปใช้กับงานอย่างการประมวลผล API response (transformResult) หรือ conditional rendering ระดับความยากของส่วนนี้ไม่ได้ซับซ้อนถึงขั้นผู้เชี่ยวชาญ นักพัฒนาทั่วไปก็สามารถใช้งานได้เพียงพอ

Model Context Protocol(MCP) และการทำงานร่วมกับ AI

ต่อคำถามที่ว่า “ตอนนี้ LLM ก็สร้าง React app ให้ได้ตรง ๆ แล้ว XMLUI ยังมีความหมายอะไร?” ผู้เขียนเน้นย้ำคุณค่าของ XMLUI ในด้าน การเข้าถึงโค้ด ความสามารถในการบำรุงรักษา และการทำงานร่วมกัน

MCP(Model Context Protocol) เป็นเซิร์ฟเวอร์ที่ช่วยให้เอเจนต์อย่าง LLM สามารถค้นหา ทำความเข้าใจ และอ้างอิงโค้ด/เอกสาร/ตัวอย่างของ XMLUI ได้ สิ่งนี้ทำให้ AI และนักพัฒนาสื่อสารกันบนชุดความหมายเดียวกัน และสามารถประสานการสร้างหรือแก้ไขโค้ดแบบค่อยเป็นค่อยไปได้

  • ตัวอย่าง: สามารถถาม-ตอบกับ LLM เกี่ยวกับวิธีใช้ฟีเจอร์ ตัวอย่าง เอกสาร หรือจุดที่มีการใช้งานได้ทันทีระหว่างการพัฒนา

ยังมีการให้แนวทางสำหรับการทำงานร่วมกับ LLM อย่างมีประสิทธิภาพ เช่น การพูดคุยกันก่อนเสนอโค้ด การใช้เฉพาะตัวอย่างที่มีเอกสารรองรับ และการจำกัดการตกแต่งสไตล์ที่ไม่จำเป็น นอกจากนี้ยังเตรียมโครงสร้างให้ AI เข้าถึงได้ง่ายผ่านส่วน "How To" ในเว็บไซต์เอกสารและการเชื่อมต่อ MCP

การจัดการคอนเทนต์และการประยุกต์ใช้กับ CMS

เมื่อใช้ XMLUI ก็สามารถจัดทำ เว็บไซต์และ CMS ได้ง่าย และยังแก้ไขหรือดูแลรักษาหน้าเว็บทั่วไปได้สะดวก โดยไม่ต้องมีความรู้เรื่อง React หรือ Next.js ในความเป็นจริง เว็บไซต์ทางการ เดโม และเอกสาร ของ XMLUI ก็ถูกสร้างและดูแลด้วย XMLUI ทั้งหมด

สามารถรวมโค้ด คำอธิบาย และเดโมแบบเรียลไทม์ไว้ในเอกสารเดียวได้ จึงใช้งานได้จริงมาก

ความสามารถในการขยายระบบ

โดยพื้นฐานแล้ว XMLUI ห่อหุ้ม React component หลากหลายชนิดไว้ แต่ก็ยัง ห่อหุ้ม external component ใหม่ ๆ เพิ่มได้ง่าย ตัวอย่างเช่น สามารถห่อหุ้ม Tiptap ซึ่งเป็น advanced document editor ให้กลายเป็น XMLUI TableEditor ได้อย่างสะดวก ทำให้ส่วนที่ยากในการแก้ไข Markdown (เช่น การสร้างตาราง) ถูกแก้ได้ง่ายด้วย visual editor

จากเดิมที่บทบาทของผู้พัฒนาคอมโพเนนต์และผู้พัฒนาโซลูชันถูกแยกจากกันอย่างชัดเจน XMLUI ทำให้นักพัฒนาทั่วไปก็สามารถขยายและประกอบ UI component ที่มีประโยชน์ขึ้นมาได้ด้วยตนเอง

การดีพลอย

การดีพลอยแอป XMLUI ง่ายมาก

  • องค์ประกอบขั้นต่ำ: ต้องมีเพียง Main.xmlui, index.html และไฟล์ XMLUI JS
  • ใช้ได้กับ static web server ใดก็ได้ และสามารถรันได้ทันทีบน AWS S3 bucket
  • ไม่จำเป็นต้องมีสภาพแวดล้อมเซิร์ฟเวอร์ที่ซับซ้อน และหากจำเป็นก็สามารถตั้งค่า local server เพิ่มเติมหรือ CORS proxy ได้

การพัฒนาเว็บสำหรับทุกคน

Gent Hito ผู้สร้าง XMLUI มุ่งมั่นมาโดยตลอดในการลดอุปสรรคในการเข้าถึงสภาพแวดล้อมการพัฒนา ผ่านงานที่ /n software, CData และอื่น ๆ

  • /n software: ทำให้ network component ใช้งานได้ง่าย
  • CData: ทำให้ data access เรียบง่ายขึ้น
  • XMLUI: ทำให้การพัฒนา UI ง่ายขึ้น

ตลอดกว่า 20 ปีที่ผ่านมา การพัฒนา UI บนเว็บมีความเฉพาะทางและซับซ้อนขึ้นเรื่อย ๆ แต่ XMULI ถูกออกแบบมาเพื่อให้แม้แต่ผู้ที่ไม่ใช่ผู้เชี่ยวชาญก็ยังสามารถสร้าง UI และแอปของตัวเองได้อย่างง่ายดายในฐานะ solution developer ในทางปฏิบัติยังสามารถนำไปใช้กับตัวอย่างหลากหลาย เช่น dashboard UI ที่เกี่ยวข้องกับ CoreSSH ได้ทันที

จึงขอแนะนำอย่างมากสำหรับนักพัฒนาทุกคนที่ต้องการสภาพแวดล้อมการสร้างเว็บแอปที่ง่ายขึ้น โดยเฉพาะ solution builder ที่ไม่ใช่ผู้เชี่ยวชาญ นักพัฒนารุ่นจูเนียร์ และนักพัฒนาที่เน้นฝั่งแบ็กเอนด์

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2025-07-21
ความคิดเห็นใน Hacker News

  • Jon อยู่ในวงการมานานมาก และฉันก็เป็นแฟนของเขา เขาเป็นคนมากประสบการณ์ที่ผ่านอะไรมาเยอะ และสิ่งที่เขาพูดก็ควรค่าแก่การรับฟัง ฉันเป็นแฟนของ web components แต่คิดว่าเหตุผลที่ React ครองความนิยมก็เพราะสภาพแวดล้อมมันเข้าถึงยากสำหรับนักพัฒนาที่เคยใช้ประโยชน์จากคอมโพเนนต์ของ Visual Basic ได้ดีในอดีต นี่แหละคือประเด็นสำคัญที่สุดของบทความนี้ รายละเอียดทางเทคนิคก็สำคัญ แต่บทความนี้ชี้ให้เห็นแก่นแท้ว่าทำไมความพยายามแบบนี้ถึงจำเป็น ยังต้องรอดูว่า XMLUI จะมอบ abstraction ที่เหมาะกับนักพัฒนากลุ่มนี้ได้หรือไม่ ถึงอย่างนั้น แค่ได้เห็นความพยายามแบบนี้ก็น่าสนุกแล้ว

    • ตอนนี้โค้ดทำงานได้เฉพาะบนเบราว์เซอร์ JS evergreen เท่านั้น ให้ความรู้สึกคล้าย VB สมัยก่อนที่ทำงานได้ดีจริง ๆ แค่บน Windows และในสภาพแวดล้อมที่ติดตั้ง DLL บางตัวไว้แล้ว

  • ราว ๆ ปี 2014 ก็มีความพยายามคล้ายกันใน Polymer เช่น ใช้คอมโพเนนต์อย่าง <iron-ajax> เพื่อทำ network request ลิงก์ iron-ajax อีกด้านหนึ่งก็เคยมีช่วงที่ Adobe Flex ฮิตมาก และตอนนี้ยังหลงเหลืออยู่ในชื่อ Apache Royale ลิงก์ Apache Royale ฝั่ง Microsoft ก็มี XAML, NetUI, FlexUI และ UI ของ Office 2007 ก็สร้างแบบนั้นเหมือนกัน ในทางทฤษฎีทั้งหมดนี้ดูยอดเยี่ยม แต่ในทางปฏิบัติฉันรู้สึกว่า abstraction แบบ markup-based พวกนี้มีประสิทธิภาพน้อยกว่าแนวทาง code-first อย่าง JSX แม้แต่สำหรับมือใหม่

    • ยังมี Coldfusion ด้วย (แค่นึกถึงก็ขนลุกด้วยความทรงจำ)

  • ฉันมีทั้งความคิดว่า "เรากำลังประดิษฐ์ HTML ขึ้นมาใหม่อีกแล้ว" และความรู้สึกว่า "สิ่งนี้น่าจะมีประโยชน์กับฉันทันที" พร้อมกันไป มนุษย์เราก็เป็นสิ่งมีชีวิตหลายมิติแบบนี้แหละ

    • ขอบคุณที่แนะนำกวีชื่อ Walt Whitman และผลงานของเขา “ฉันขัดแย้งกับตัวเองหรือ? ถ้าอย่างนั้นฉันก็ยินดีจะเป็นคนที่ขัดแย้งกับตัวเอง”
    • เป็นถ้อยคำที่โดนใจมาก สุดท้ายสิ่งสำคัญคือมันมีประโยชน์ได้ทันทีหรือเปล่าสำหรับคนที่คุณจินตนาการว่าต้องการมันจริง ๆ

  • ฉันเคยทำโอเพนซอร์สให้ KDE ด้วย Qt C++ อยู่ 7 ปี แนวทางนี้ทำให้นึกถึงไฟล์ .ui ของ QtWidgets หรือก็คือไฟล์ UI แบบกำหนดเองที่ใช้ XML schema เฉพาะ ภายหลังก็มี QML ออกมา แต่สำหรับฉันมันไม่ค่อย intuitive เลยหมดความสนใจไป ถึงอย่างนั้นฉันก็ยังคิดว่าการใช้ XML นิยาม UI เป็นเรื่องที่สมเหตุสมผล และเข้าใจได้ว่าทำไมในสภาพแวดล้อมขนาดใหญ่จึงยังมีการใช้อยู่

    • ยังมีคนใช้ Qt ด้วย C++ และไฟล์ .ui อย่างเดียวอยู่จนถึงทุกวันนี้ พวกเขาไม่รู้สึกว่ามีเหตุผลมากพอจะย้ายไป QML
    • เคยได้ยินว่า launcher เกมของ Blizzard ก็ใช้ QT และฉันก็คิดมาตลอดว่า UI ของซอฟต์แวร์ Blizzard ทำออกมาได้เนี้ยบมาก อยากรู้เหมือนกันว่ามีโปรเจกต์ Qt อื่นที่น่าแนะนำอีกไหม
    • wxWidgets กับไฟล์ glade ก็อยู่ในบริบทเดียวกัน

  • สำหรับฉัน แนวทาง GUI ที่ดีที่สุดคือ JUCE องค์ประกอบ UI ทุกตัวเป็นคลาส C++ และมีฟังก์ชันวาดแยกต่างหาก UI element ใหม่สามารถสร้างเป็นอีกคลาสหนึ่งจากการประกอบ element อื่น ๆ เข้าด้วยกัน และ editor ก็สร้างซอร์สโค้ดให้อัตโนมัติ ส่วนพวกปุ่มก็มีส่วน if…else ขนาดใหญ่ไว้จัดการการวาดตามสถานะต่าง ๆ (hover, pressed, active, disabled ฯลฯ) ภายในใช้ไลบรารีวาดภาพแบบบาง ๆ อย่าง Metal/OpenGL/DirectX วิธีแบบ imperative เต็มรูปแบบนี้ให้ความรู้สึกสดใหม่มาก คุณตั้ง breakpoint ได้ทุกที่และดูได้ทันทีว่าถูกเรียกอย่างไร ด้วยพารามิเตอร์อะไร แถมยัง export ผลลัพธ์ระหว่างทางของการเรนเดอร์ออกไปเป็น imdraw ได้ง่ายด้วย ถ้าไม่นับเรื่อง font anti-aliasing ก็ถือว่าเรนเดอร์ได้แม่นยำระดับพิกเซลแทบทุกแพลตฟอร์ม แต่แนว XML ที่พูดถึงที่นี่คือเวทมนตร์พึ่งพา framework แบบที่ฉันพยายามหลีกเลี่ยงมาตลอด มั่นใจเลยว่าอัปเดตไปอีกสัก 3 ครั้ง เลย์เอาต์คงเริ่มเบี้ยวทีละนิด ผู้ใช้ไม่ได้ควบคุมเลย์เอาต์เอง แต่ต้องหวังพึ่งความเมตตาของ framework แทน Electron อย่างน้อยก็เจอปัญหานี้น้อยลงบ้างเพราะอยู่บนเทคโนโลยีเก่าอย่าง CSS แต่ถ้าไม่ใช่ก็จะลำบากกับการควบคุมเลย์เอาต์อยู่เสมอ

    • ฉันไม่เคยใช้ JUCE แต่ก็คิดถึงสมัย Qt ก่อนหน้านี้ที่ทุกอย่างเป็นคลาส C++ เทมเพลตภาษากลายเป็นกระแสหลักก็จริง แต่ฉันรู้สึกว่าการประกอบกันของคลาสและอ็อบเจ็กต์อ่านง่ายกว่ามาก ข้อดีที่ใหญ่ที่สุดของเทมเพลตเหมือนจะมีแค่ว่า “โมดูลนี้ถูกวางไว้ใต้ parent ถูกต้องไหม?”
    • ถ้ามีใครแชร์ประสบการณ์การใช้ JUICE กับเรื่อง accessibility ได้ก็คงดี
    • ฉันไม่ได้รู้จัก JUCE ลึกมาก แต่ JUCE::Component ดูคล้าย element ของ DOM/canvas จนพอเทียบกับเว็บแพลตฟอร์มได้ XMLUI น่าจะควรถูกเทียบกับระบบ declarative UI บน JUCE มากกว่า เช่น GUI Magic, JIVE, VITRO จะว่าไป declarative UI กับ imperative UI ก็ไม่ได้ขัดกันเสียทีเดียว อย่าง SwiftUI กับ UIKit ก็เป็นตัวอย่างของสภาพแวดล้อมที่ใช้ทั้งคู่ร่วมกันได้
    • ฉันไม่เคยใช้ JUCE แต่ข้อดีของแนว imperative คือแม้ implementation จะใหญ่ขึ้น คุณก็ยังรู้ชัดว่าเกิดอะไรขึ้นทั้งหมด จึงควบคุมได้ง่าย ส่วน declarative นั้นต้องมีทางหนีทีไล่เสมอ และทางหนีนั้นก็มักทำเองยากหรือทะลุผ่านได้ยากเสมอ
    • ฉันใช้มันมาทางด้านพัฒนาเสียงอยู่ 7 ปี และทุกวันนี้ก็ใช้ JUCE กับ GUI ประสิทธิภาพสูงแบบ cross-platform รวมถึงแอปทั่วไปทั้งหมด พอสร้าง JUCE -> CI pipeline ที่ใช้งานได้จริงขึ้นมาสักครั้ง ก็เหมือนมีความเป็นไปได้ไม่สิ้นสุดเปิดออกมาเลย แต่บางครั้งก็จินตนาการเล่น ๆ ว่าถ้าเอาโค้ด GUI ทั้งหมดของ JUCE ไปเขียนด้วยฟรอนต์เอนด์คล้าย Lazarus อย่าง LUA แล้วผสมกับ C++ จนกลายเป็นสัตว์ประหลาด Lua-C++ ก็คงสนุกดี

  • เสียดายที่ไม่ได้พูดถึง XSLT ฉันคิดว่านี่เป็นองค์ประกอบสำคัญในการอธิบายว่าความก้าวหน้าในปัจจุบันกระโดดไกลแค่ไหนสำหรับคนที่เคยขลุกอยู่กับการ style/transform XML มาก่อน พอเห็นว่า Jon Udell ก็เคยเขียนเรื่อง XSLT อยู่เหมือนกัน ลิงก์อ้างอิง ก็เลยสงสัยว่าเขาน่าจะตั้งใจละมันออกไปในครั้งนี้ แต่ไม่ค่อยเข้าใจเหตุผล

    • ในภาคสนาม XSLT มักจะเป็น “ก้อนผมพันกันซับซ้อนที่ไม่มีใครนอกจากคนเขียนเดิมกล้าแตะ” เทคโนโลยีนี้ดูจะมีแนวโน้มประหลาด ๆ ที่พาตัวเองตกหลุมความซับซ้อน หรือดึงดูดคนที่หลงใหลในความซับซ้อนเข้ามา อย่างไรก็ดี ฉันไม่คิดว่ามันเหมาะกับเป้าหมายที่ OP ตั้งใจไว้
    • แม้จะควรมีบริบททางประวัติศาสตร์อยู่บ้าง แต่เป้าหมายของบทความนี้ไม่ใช่การหมกมุ่นกับอดีต แต่เป็นการก้าวไปข้างหน้า จุดประสงค์คือให้ลองใช้เครื่องมือนี้จริงและประเมินว่ามันช่วยให้สร้าง UI ได้อย่างมีผลิตภาพหรือไม่
    • XSLT ไม่ได้สำคัญมากในบทความนี้ ประเด็นหลักคือการอธิบายให้ผู้อ่านยุคปัจจุบันเข้าใจว่าทำไมเครื่องมือแบบนี้ถึงมีประโยชน์ XSLT เกี่ยวข้องกันในเชิงประวัติศาสตร์ก็จริง แต่การพูดถึงมันที่นี่ไม่น่าจะช่วยสื่อไอเดียได้มากนัก
    • หลังจากได้รู้จัก SXML/SSAX ของ oleh kiselyov ฉันก็เลิกใช้ XSLT ไปเลย SSAX เป็น XML parser ที่ดีที่สุดเท่าที่ฉันเคยใช้มา
    • ประสบการณ์ครั้งแรกของฉันกับ XSLT คือ sketchers.com Sketchy Skechers.com น่าเสียดายที่ตอนนี้ดูเหมือนจะไม่ได้ใช้อีกแล้ว

  • ช่วงนี้ฉันกำลังทำของคล้ายกันโดยใช้ HTML, web components และ signals โปรเจกต์ชื่อ Heximal ลิงก์ Heximal ฉันคิดว่าการเสริม HTML ด้วย expression, template, reactivity และโครงสร้างคอมโพเนนต์ ทำให้มันเป็นฐานที่ยอดเยี่ยมสำหรับสร้างแอปหรือเพจที่ modular สูงและเป็น declarative มาก ฟีเจอร์จำนวนมากที่เพิ่มเข้ามาใน HTML เองก็น่าจะสามารถทำให้เป็นมาตรฐานได้

    • ไอเดียน่าสนใจ แต่บนมือถือ (Android+Firefox) เว็บไซต์แสดงผลได้ไม่ค่อยดี
    • เว็บไซต์อ่านยาก ในแอป HN เองก็มองคอมเมนต์อื่นไม่ค่อยเห็น เลยไม่รู้ว่าคนอื่นเจอปัญหาเดียวกันหรือเปล่า ใช้ Mobile Firefox อยู่นะ
    • บนมือถือข้อความบางส่วนถูกตัด และซูมก็ไม่ช่วยอะไร ฝากไว้เป็นข้อมูล
    • ฉันคิดว่าแนวทางนี้อาจกลายเป็นกระแสหลักได้ เหมือนที่ C++ เคยเป็น เพราะความเข้ากันได้ย้อนหลังเป็นจุดแข็งที่ทรงพลังมากจริง ๆ

  • ฉันคิดว่า uiSchema ของ RJSF ได้ชี้ทางที่ดีมากในฐานะ presentation layer ที่ช่วยเสริม model definition ของ jsonSchema ลิงก์อ้างอิง uiSchema จำได้ว่ามันออกแบบได้น่าประทับใจ แต่ก็แปลกใจที่ไม่แพร่หลายกว่านี้

  • ฉันตื่นเต้นเป็นพิเศษกับส่วนที่ยังมองไม่เห็น นอกจากงานวิศวกรรมที่แข็งแรงแล้ว ดูเหมือนว่าจะใส่ใจนักพัฒนาแบบ WYSIWYG programmer (คนที่ประกอบ UI อย่างเป็นธรรมชาติ) อย่างชัดเจน ฉันคิดว่าตอนเด็ก ๆ ตัวเองเข้าถึงการเขียนโปรแกรมได้ก็เพราะ Visual Basic มันทำอะไรได้ง่ายและมหัศจรรย์มากโดยไม่ต้องเจอกับ pointer ซับซ้อนของ C++ และฉันหวังว่ากระแสนี้จะเชื่อมต่อไปสู่การเขียนโปรแกรมบนเว็บในแบบที่ให้ความสำคัญกับมือใหม่ก่อน โดยยังไม่ต้องประนีประนอมเรื่อง responsiveness หรือความลื่นไหลมากเกินไป และมีการประนีประนอมกับโลกจริงอย่างเหมาะสม ที่น่าสนใจกว่านั้นคือ https://docs.xmlui.com/mcp เครื่องมืออย่าง Claude สามารถลดจำนวนโทเคนที่ต้องใช้เมื่อสร้างโค้ด UX/แดชบอร์ด ทำให้ได้โค้ดที่กระชับขึ้น ฉันตั้งใจว่าจะลองใช้ตั้งแต่วันนี้เลย

    • อย่าลืมมาเล่าประสบการณ์การใช้งานให้ฟังด้วย

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