ไปให้สุดแบบเนทีฟ จนกว่าจะถึงวันที่ต้องใช้ข้อความ

 (justsitandgrin.im)
2 คะแนน โดย GN⁺ 12 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • หากสร้าง UI แชต Markdown บน macOS ด้วย SwiftUI เพียงอย่างเดียว แม้ประสิทธิภาพพื้นฐานจะพอใช้ได้ แต่รองรับการเลือกทั้งเอกสารได้ยาก
  • เมื่อย้ายไปใช้ NSTextView และ TextKit 2 จะต้องสูญเสียงานทดสอบและงานปรับประสิทธิภาพที่ทำไว้ใน SwiftUI และเกิด CPU spike ระหว่างการรับข้อมูลแบบสตรีม
  • การเขียนใหม่ด้วย NSCollectionView ทำให้เซลล์กะพริบ และแม้ใช้ TextKit 2 แบบล้วน ๆ ประสิทธิภาพจะใช้ได้ แต่การเชื่อมกับ สตรีมมิง ยังไม่ดี
  • WebKit เข้ากันได้ค่อนข้างดีกับการเรนเดอร์ Markdown, ประสิทธิภาพ, ไทโปกราฟี และระดับการควบคุม ขณะที่ Electron ก็ทำงานด้านข้อความได้ดีเป็นพื้นฐาน
  • สำหรับแชตยาวและ rich text นั้น SwiftUI และ Apple native SDK กลายเป็นข้อจำกัด และแนวทางแบบเว็บได้เปรียบกว่าในด้าน โมเดลข้อความ·การเรนเดอร์

ข้อจำกัดของ UI แชต Markdown แบบเนทีฟบน macOS

  • หากสร้างแชตเรียบง่ายที่รองรับ Markdown ด้วย SwiftUI เพียงอย่างเดียว แม้ประสิทธิภาพพื้นฐานจะพอเป็นไปได้ แต่ไม่สามารถเลือกทั้งเอกสาร Markdown ที่ประกอบจาก SwiftUI primitives ได้
  • หากย้ายไปใช้ NSTextView จะได้การรองรับ TextKit 2 แต่จะสูญเสียงานทดสอบและงานปรับประสิทธิภาพส่วนใหญ่ที่ทำไว้ใน SwiftUI และยังทำงานร่วมกับ SwiftUI ได้ไม่ค่อยดี
  • เมื่อส่งคำตอบของโมเดลเข้า NSTextView แบบสตรีม จะเกิด CPU spike
  • แม้จะเขียนใหม่ด้วย NSCollectionView เซลล์ก็ยังคงกะพริบอย่างต่อเนื่อง และยังเป็นพฤติกรรมที่หลีกเลี่ยงได้ยากจากข้อจำกัดด้านการออกแบบ
  • ต้นแบบที่ใช้ TextKit 2 แบบล้วน ๆ มีประสิทธิภาพพอใช้ได้ แต่การสตรีมยังคงแย่ และยังไม่เข้ากับองค์ประกอบสมัยใหม่ได้ดี
  • ต่อให้ถอด SwiftUI ออกทั้งหมดแล้วใช้ AppKit อย่างเดียว ก็ยังต้องจัดการชิ้นส่วนข้อความที่ขยายตัวเองแบบแมนนวล และกว่าจะเลือกข้อความได้ หลายส่วนก็อยู่ในสภาพที่พังไปแล้ว
  • หากต้องการให้ใกล้เคียงพฤติกรรมพื้นฐานของ macOS ก็ต้องกลับมาปรับฟีเจอร์ที่ผู้ใช้คาดหวังว่า "ควรมีอยู่แล้ว" ใหม่อีกครั้ง เช่น เมนูบริบท, การเปิดพจนานุกรม, การเลือก, การช่วยการเข้าถึง, และการโต้ตอบกับข้อความ

จุดที่ WebKit และ Electron เหมาะกว่า

  • หากใช้ WebKit เรนเดอร์ Markdown แม้มีจุดที่ต้องระวังอยู่บ้าง แต่โดยรวมทำงานได้ดี มีทั้งประสิทธิภาพและไทโปกราฟีที่ดี รวมถึงให้ระดับการควบคุมที่เพียงพอ
  • หากสร้างโปรเจ็กต์ Electron แบบง่าย ๆ งานด้านข้อความ, การเรนเดอร์ Markdown, และไทโปกราฟีที่ดีจะใช้งานได้ทันที และยังได้ประสิทธิภาพที่หาได้ยากกว่าจากการทำด้วย TextKit 2 แบบล้วน ๆ
  • ใน Electron ก็ยังมีการผสานกับ macOS และสามารถเรนเดอร์ Git diff ที่สวยงามได้ด้วยโค้ดเพียงไม่กี่บรรทัด โดยมีตัวอย่างอย่าง diffs.com
  • แม้จะพิจารณาทั้ง SwiftUI, AppKit, TextKit และ WebKit ก็ยังยากที่จะตอบโจทย์ง่าย ๆ อย่าง “แชตที่รองรับ Markdown และเลือกข้อความทั้งข้อความของแต่ละข้อความได้” ให้สมบูรณ์
  • จึงยิ่งเห็นชัดขึ้นว่าเหตุใดแอปใหม่ ๆ ที่ให้ความสำคัญกับแชต, rich text แบบยาว, และไทโปกราฟีที่ยืดหยุ่น จึงหันไปใช้แนวทางแบบเว็บ
  • SwiftUI เหมาะกับหน้าจอเรียบง่ายที่ไม่ต้องมีการเลื่อนมากนัก และ Swift ก็ยังมีประโยชน์ในส่วนที่ต้องการประสิทธิภาพสูง
  • Electron หรือ React Native สามารถได้ประสิทธิภาพในระดับสูงผ่านการทำงานร่วมกับเนทีฟ พร้อมคง โมเดลข้อความ·การเรนเดอร์ ที่ดีกว่าไว้ได้
  • สำหรับการเรนเดอร์ rich text เพื่อแชตรูปแบบยาวนั้น SwiftUI และ Apple native SDK ไม่ได้เป็นข้อดีอีกต่อไป แต่กลับกลายเป็นข้อจำกัด
  • การสนทนาที่เกี่ยวข้อง: Hacker News, Lobsters

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

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

 
GN⁺ 11 시간 전
ความคิดเห็นจาก Hacker News

  • เพิ่งปล่อยตัวแก้ไขข้อความสำหรับ iOS ที่ใช้ TextKit 2 และประสิทธิภาพยังดีแม้กับไฟล์ 5,000 บรรทัด
    ทดสอบด้วย Moby Dick ของ Project Gutenberg สร้างขึ้นระหว่างเดือนสิงหาคม 2025 ถึงเมษายน 2026 และยังพัฒนาต่ออยู่
    ทุกครั้งที่พิมพ์จะจัดสไตล์ใหม่ได้ภายใน 8ms และแม้พิมพ์เร็ว 20 ครั้งติดกันโดยไม่มี debouncing หรือ delayed rendering ก็ยังประมวลผลได้ใน 150ms พร้อมรวมการจัดสไตล์ใหม่ทั้งชุดหลังแต่ละครั้ง
    การค้นหาแบบ tag และ boolean เสร็จภายใน 20ms และถ้าเรนเดอร์เฉพาะช่วงที่มองเห็นจะเร็วกว่าการจัดสไตล์ทั้งเอกสาร 25 เท่า พร้อมรองรับการรีเฟรชหน้าจอ 120Hz
    ขนาดไฟล์แอปในเวอร์ชัน 1.0 คือ 722KB และใน 1.1 ที่มีฟีเจอร์เพิ่มขึ้นก็น่าจะอยู่ราว 950KB
    ถ้าทำได้ระดับนี้บน iOS บน macOS ก็น่าจะง่ายกว่าราว 10 เท่า
    https://www.gingerbeardman.com/apps/papertrail/

    • ถ้าฟีเจอร์หลักของสินค้าที่ขายคือ editor ก็พอเข้าใจได้ แต่ถ้า Markdown rendering ไม่ใช่หน้าที่หลักของแอป และในปี 2026 มันใกล้เคียงกับฟีเจอร์อำนวยความสะดวกที่ผู้ใช้คาดหวังมากกว่า การต้องใช้เวลา 8 เดือน และยังต้องพัฒนาต่อเพื่อทำ custom implementation ระดับล่างสำหรับสิ่งนี้มันดูแปลก
      ไม่ได้บอกว่า “เป็นไปไม่ได้” แต่หมายถึงเข้าใจว่าทำไมคนถึงเลือก เว็บเทคโนโลยี แทน native สำหรับเรื่องแบบนี้ คนอยากสร้างสินค้า ไม่ได้อยากสู้กับข้อจำกัดของระบบ
    • จากมุมคนที่เคยสร้าง interactive fiction ด้วย NSString และ attributes ในปี 2012 เคยทำ roguelike ด้วย low-level glyph API ที่ถูกยกเลิกไปแล้ว และเคยทำแอปแชตรองรับ Markdown 2 ตัวกับเกม idle ที่ผสมลูกเล่น iOS ด้วย SwiftUI ปฏิกิริยาแบบนี้สรุปได้ว่าเป็นเรื่องของ ระดับความชำนาญ
    • 5,000 บรรทัดนี่เล็กมากจนคำอธิบายนี้ชวนสับสน Moby Dick ที่บอกว่าใช้ทดสอบก็ดูเหมือนจะมีเกิน 22,000 บรรทัด และแม้แต่ Notepad พื้นฐานของ Windows ก็ยังไม่หน่วงกับไฟล์ระดับนั้น
      ถ้าเป็น text viewer อย่างน้อยก็ควรจัดการไฟล์ที่ใหญ่กว่านั้นอีกเป็นหลักสิบเท่า ไฟล์ JSON หลายแสนบรรทัดเป็นเรื่องปกติ และไฟล์ CSV กับ log ก็ยาวกว่านั้นอีก
    • มีโอกาสสูงว่า SwiftUI บน Mac จะทำออกมาได้ไม่ดี สำหรับแอปแบบนี้ SwiftUI-on-Catalyst อาจดีกว่าด้วยซ้ำ แต่ก็คงมีปัญหาอื่นตามมา
    • คำพูดที่ว่าถ้าทำได้บน iOS ก็จะง่ายกว่าบน macOS 10 เท่านี่น่าสงสัยมาก น่าจะตรงกันข้ามมากกว่า และอยากฟังจากคนที่รู้จริง

  • ปกติแล้วเหตุผลที่ใช้ native API แทน webview คือเรื่องประสิทธิภาพ แต่ตอนนี้ดูเหมือนจะไม่แน่เสมอไปแล้ว
    browser rendering engine สุกงอมมากแล้ว มี GPU acceleration เยอะ และโดน stress test จากเว็บแอปอ้วน ๆ มานานกว่าสิบปี
    ในทางกลับกัน SwiftUI ไม่ได้รู้สึกว่าเร็วอะไรเป็นพิเศษ แม้แต่ System Settings เวอร์ชันล่าสุดที่ Apple ทำใหม่ก็ลดความซับซ้อนของ UI ให้เหลือแนวแถว checkbox เป็นหลัก แต่ตอนสลับ section ยังหน่วงกว่าการโหลดเว็บเพจจาก us-east-1 เสียอีก

    • ปัญหาตรงนี้ไม่ใช่ native apps โดยรวม แต่เป็น SwiftUI
      เคยทำ native apps ด้วย Qt C++ และ QML และพิสูจน์ได้ว่ามันเร็วกว่าเว็บแอปที่ใกล้เคียงกันมาก แถมใช้ RAM น้อยกว่ามาก
      ดังนั้นโดยทั่วไปเว็บแอปจะช้ากว่าและกินทรัพยากรมากกว่า native app ที่ออกแบบมาดี
      [1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...
      [2] https://x.com/daniel_nguyenx/status/1734495508746702936
      [3] https://rubymamistvalove.com/block-editor#8-performance
    • ถึงอย่างนั้น ระหว่าง native app กับ browser app ที่เบาที่สุดก็ยังต่างกันมาก และยิ่งเห็นชัดบนอุปกรณ์พลังต่ำ
      เดิมทีเป็นนักพัฒนาเว็บ แต่ช่วง 6–12 เดือนที่ผ่านมาเริ่มทำ native cross-platform apps แล้วพบว่าแม้แต่งานง่าย ๆ ก็มี ช่องว่างด้านประสิทธิภาพ ค่อนข้างชัด
    • browser นั้นแย่มากบน ฮาร์ดแวร์เก่า Chromebook รุ่นเก่ายังพบได้ทั่วไป และสำหรับงานเบา ๆ หรือการใช้งานเฉพาะทาง สเปกมันก็พอได้ แต่ browser กลับทำงานช้ามาก
    • ถ้าเป็นเว็บแอปง่าย ๆ อาจไม่เป็นไร แต่พอเป็นแอปซับซ้อนจะเห็นอาการช้าชัดเจน ไม่ต้องถึงระดับสัตว์ประหลาดอย่าง Jira แม้แต่แอปที่ optimize ดีอย่าง VS Code ก็ยังมี เพดานประสิทธิภาพที่ต่ำกว่า native app
    • WebView เองสุดท้ายก็เป็น “native” เหมือนกัน
      การทิ้ง optimization ที่สะสมมาหลายพันคน-ปี และการพิสูจน์ใช้งานจริงอีกหลายล้านคน-ปี แล้วไปคิดว่าจะสร้าง text rendering engine ใหม่ที่แย่กว่านั้นเอง มันฟังดูแปลก

  • บน macOS นั้น WebKit เป็น native OS framework การใช้ WebKit สำหรับเรนเดอร์ Markdown ดูเหมาะสมอย่างยิ่ง
    แน่นอนว่าการเรนเดอร์ทุกอย่างด้วย WebKit ก็ไร้เหตุผลพอ ๆ กับการเรนเดอร์ทุกอย่างด้วย PDFKit แต่ถ้าเป็น Markdown view แล้ว WebKit เป็นตัวเลือกที่สมเหตุสมผล และก็ไม่ได้หมายความว่าต้องพลิกโต๊ะไปทำเป็น Chromium web app ทั้งหมด

    • ถ้า HTML engine เรนเดอร์ rich text ซึ่งอาจเป็นสิ่งที่ยากที่สุดใน UI ได้ดีกว่า native UI library แล้วทำไมจะไม่ใช้มันเรนเดอร์ของที่ง่ายกว่านั้นอย่างปุ่มหรือ text field ด้วยล่ะ?
      อีกอย่าง OS X ก็เคยเรนเดอร์ UI ด้วย DisplayPDF/Quartz มานาน
    • ทำไมการเรนเดอร์ Markdown ด้วย WebKit ถึงเหมาะสม ต้องมีคำอธิบายหน่อย
    • ผู้เขียนต้นฉบับดูเหมือนจะมองว่า “native” หมายถึงการใช้ primitive ของ Swift/ObjC ล้วน ๆ
      หรือเพราะ WebKit มีบนแพลตฟอร์มอื่นด้วย เลยถือว่าโกง? ถ้าอย่างนั้นใช้ Java ก็คงได้เหมือนกัน
    • ไม่เข้าใจว่าทำไมเราควรคาดหวังว่าต้องใช้ WebKit เพื่อเรนเดอร์ rich text
      ถ้าการเรนเดอร์ข้อความด้วย HTML/CSS/JS renderer “เหมาะสมอย่างยิ่ง” แล้วมีขอบเขตไหนบ้างที่ไม่เหมาะสม? ทำไมไม่เรนเดอร์ทุกอย่างด้วยมันไปเลย?
      ตรรกะจาก “เหมาะกับการเรนเดอร์ข้อความ” ไปสู่ “แต่ไม่ใช่กับการเรนเดอร์ทุกอย่าง” ฟังไม่ต่อกัน
    • ที่จริงแนวทางที่กำลังใช้ตอนนี้ก็คือเรนเดอร์ Markdown ขั้นสุดท้ายและสตรีมมิงด้วย WebKit
      เห็นด้วยว่าใน macOS นั้น WebKit เป็น native OS framework และในความหมายนั้นมันก็ “native”
      แต่มันก็ยิ่งตอกย้ำประเด็นใหญ่กว่าว่า ถ้าต้องจัดการ rich text, Markdown, selection, typography และ formatted content แบบยาว ๆ ให้ดี เว็บเทคโนโลยีก็กำลังกลายเป็นตัวเลือกเชิงปฏิบัติเพียงตัวเดียวอย่างรวดเร็ว
      ไม่ได้บอกว่าการใช้ WebKit สำหรับ Markdown view เป็นเรื่องผิด ตรงกันข้าม มันอาจเป็นตัวเลือกที่สมเหตุสมผลที่สุดด้วยซ้ำ ปัญหาคือทางออกแบบ “native” ตรงนี้กลับเป็นทางออกแบบเว็บเรนเดอร์ริงในทางปฏิบัติ
      WKWebView แต่ละตัวแบก WebKit engine ของตัวเองมาพร้อม overhead ด้านประสิทธิภาพและหน่วยความจำ จึงไม่ใช่ของที่เอาไปโปรยทั่ว ๆ แล้วมองว่าเป็น native macOS component ฟรี ๆ ได้
      สิ่งที่น่าหงุดหงิดคือใน UI ประเภทนี้ SwiftUI / AppKit / TextKit ไม่ได้ให้เส้นทางที่สะอาด ทันสมัย และ composable ซึ่งดีกว่าแค่ “ใช้ WebKit ไปเถอะ”

  • การที่แค่ “ทำให้เลือกข้อความทั้งข้อความได้ในแชตที่มี Markdown” ยังทำไม่ได้ ฟังดูไม่น่าเป็นไปได้
    ใน SwiftUI มี Markdown renderer ที่สุกงอมให้ใช้ได้อยู่แล้ว ดู https://github.com/gonzalezreal/swift-markdown-ui และตัวแทนรุ่นถัดไป https://github.com/gonzalezreal/textual
    เคยใช้เองและไม่มีปัญหาอะไร แม้แต่ฉันที่ไม่ชอบ Swift หรือ SwiftUI และเป็นคนประหลาดที่ชอบ Objective-C มากกว่า ก็ยังทำได้โดยไม่ต้องพึ่ง LLM

    • วันนี้ก่อนหน้านี้ลอง Textual แล้ว แต่ผลไม่ค่อยดี
      การเลื่อนดู Markdown แบบ static ที่เสร็จสมบูรณ์ไม่ผ่าน focus probe ใหม่ โดยได้ p95 18.86ms เกินงบ 16.7ms และสูงสุด 232.49ms
      เส้นทางอัปเดต Markdown/โค้ดยาวแบบ realtime ก็ไม่ผ่านเช่นกัน: p95 59.33ms เทียบกับ 16.7ms สูงสุด 75.94ms เป็น stress case อีกแบบที่แยกกันแต่เกี่ยวข้องกัน เพราะต้องจัดการ rich text surface ขนาดใหญ่ระหว่างการอัปเดต
      การขยาย history ยาว ๆ ผ่านในเชิงเทคนิค แต่เรียกว่าลื่นไม่ค่อยได้: 120 turns p95 21.35ms, 500 turns 23.11ms, 1000 turns 36.77ms
      ไม่ได้แย่ แต่ช้ากว่าแนวทางของฉันเล็กน้อย และช่องว่างด้านประสิทธิภาพก็ดูเกี่ยวกับ SwiftUI มากกว่าตัว implementation ของ Textual เป็นหลัก
    • แล้วตอนมี การสตรีม ข้อความใหม่เข้ามา มันจัดการได้โดยไม่กะพริบไหม?
    • ถ้าเรนเดอร์เอกสาร Markdown แค่ครั้งเดียว หรือเอกสารเรียบง่ายและสั้น ก็น่าจะพอได้
      เคยใช้ swift-markdown-ui ในแอปมาก่อน แต่ประสิทธิภาพเทียบ wkwebview ไม่ติดเลย ถ้าสตรีมเอกสารใหญ่ที่มีองค์ประกอบหนัก ๆ อย่างตารางใหญ่ code block และ nested quote ถึงขั้นเจอ beachball ได้ แต่ถ้าใช้ wkwebview ไม่เคยเจอแบบนั้น
    • library แรกดูเหมือนว่า แอป Claude บน iOS ใช้อยู่ และมันก็รองรับทั้งการเลือกข้อความและการสตรีม พร้อมประสิทธิภาพที่ดูโอเค
    • ในมุมผู้ใช้ จะเห็นว่า แอปเก่าที่ไม่อิง HTML หลายตัวไม่ทำตาม “กฎ” เช่น ข้อความที่ควรเลือกได้กลับเลือกไม่ได้ หรือกด control/option C เพื่อคัดลอกไม่ได้
      แล้วก็ทำให้ตระหนักว่า browser และเทคโนโลยีฐานของมันได้นำพารูปแบบใหม่ให้ UI ไปไกลมาก ขณะที่ native UI framework กลับตามไม่ทัน
      แม้จะเป็นคนที่ชอบ native apps มากกว่าเว็บแอป ก็ยังรู้สึกแบบนั้น

  • โชว์โค้ดมา ไม่งั้นก็ออกไปเลย ตอนนี้ก็มี native Mac/iOS apps จำนวนมากที่จัดการ Markdown rendering และข้อความแบบสตรีมมิงได้ดีอยู่แล้ว
    เลยสงสัยแค่ว่าจะอ้างอะไรได้อีก

    • กำลังพูดถึงว่า “อยากเลือกทั้งเอกสาร Markdown ที่สร้างจาก primitive ของ SwiftUI” แต่ใครต้องการแบบนั้น? การตัดสินใจทางผลิตภัณฑ์แบบนั้นแทบจะเท่ากับบอกว่าจะสร้าง document editor ซึ่งเป็นพื้นที่ที่ยากมาหลายสิบปี และดูเกินขอบเขตของ LLM chat UI
      ส่วนใหญ่ลงเอยที่รองรับการเลือกเฉพาะภายในแต่ละบล็อกต่อเนื่อง และใส่ปุ่มคัดลอกสำหรับทั้งข้อความแทน
    • ถ้าทำได้โดยไม่ใช้ webview ก็แชร์โค้ดมาได้เลย

  • เรื่องน่าสนใจคือ Apple เองก็เคยทำแบบนี้มาก่อน
    macOS / AppKit รุ่นเก่าเคยใช้ WebKit เพื่อเรนเดอร์ rich text ภายใน NSTextField แบบ native ข้อความเป็นปัญหาที่ยาก
    แถม native WebView ก็เร็วและเบามาก จึงไม่แปลกที่จะใช้เป็น text layout engine แม้จะใช้ WebView แยกต่อหนึ่งแถวในตารางก็ยังให้ประสิทธิภาพดีมากได้
    iMessage บน Mac ก็เคยใช้ WebView และ Adium ก็เช่นกัน ถ้ากำลังเรนเดอร์ ข้อความแบบ rich/markup แล้ว HTML ก็คือเครื่องมือที่เหมาะสมอย่างยิ่ง

    • ตรงนี้กำลังสับสนระหว่าง iOS กับ Mac OS
      Mac ไม่เคยใช้ WebKit สำหรับการเรนเดอร์ NSTextField ตอนที่ iOS ถูกสร้างขึ้นใหม่ ๆ มันใช้ WebKit เป็น text renderer ค่อนข้างกว้าง รวมถึงใน UIKit controls ด้วย และเรียกแนวทางนี้ว่า “sweet solution”
      แต่สุดท้ายก็พบว่ามันทั้งหนักและยุ่งยากเกินไป จึงเปลี่ยนไปใช้แนวทางเรนเดอร์ข้อความแบบ Core Text/AppKit แทน
    • ลำดับเรื่องในต้นฉบับฟังดูแปลกนิดหน่อย
      ผู้เขียนค้นพบว่าการเรนเดอร์ข้อความแบบ native ที่ซับซ้อนนั้นยาก จึงไปเรนเดอร์ข้อความแบบ low-level แล้วก็บ่นว่าต้องกลับมาเขียน native interactions เองใหม่
      พอลอง WebKit ก็ได้ผลดีมาก แต่กลับทิ้งมันแล้ววนกลับไปอยู่ในสถานการณ์ที่ต้องเขียน native interactions ใหม่อีก
      ส่วนตัวถ้าเป็นฉันคงหยุดตั้งแต่จุดที่ WebKit ใช้งานได้ดี แล้ว

  • จำได้ว่าตอนเป็นวิศวกรจูเนียร์ในปี 2015 เคยได้รับงานให้เรนเดอร์ลิงก์ที่กดได้ภายในย่อหน้าในแอป iOS
    ตอนนั้น Swift เพิ่งออกมาใหม่ ๆ จึงเป็นสแตก ObjC/UIKit ล้วน ๆ และมันเป็นฝันร้ายจริง ๆ สุดท้ายก็ทำให้พอใช้ได้แบบกระท่อนกระแท่น
    หลังราวปี 2016 แทบไม่ได้แตะ iOS อีกเลย เลยคิดว่า SwiftUI รุ่นใหม่ต้องมีของแบบนี้มาให้เป็นพื้นฐานแล้วแน่ ๆ แต่ถ้ายังไม่มีก็ค่อนข้างบ้าเหมือนกัน

    • มันมีของชื่อ Link อยู่ตรงตัวเลย
      https://developer.apple.com/documentation/swiftui/link
      ณ จุดนี้ก็ไม่รู้จะทำให้ง่ายกว่านี้ได้อีกแค่ไหน
    • Qt ทำเรื่องนี้ได้ค่อนข้างง่ายตั้งแต่ 10 ปีก่อนแล้ว
    • ไม่มี NSLinkAttributeName เหรอ?
    • ฉันนึกมาตลอดว่า attributed text จัดการเรื่องนี้ได้ดีมาตั้งนานแล้ว ไม่ใช่หรือ?
    • แค่ข้อกำหนดให้มี ลิงก์ที่กดได้ อยู่ในย่อหน้าก็เป็นไอเดียที่ไม่ดีอยู่แล้ว

  • การที่ “พอพ้นหน้าจอง่าย ๆ ไปแล้ว native ยังไม่สุกงอมแบบนี้” ถือเป็นเรื่องปกติ
    ถ้าคนไม่ทุ่มแรงมากพอ ก็ไม่ควรคาดหวังว่ามันจะสุกงอมขึ้นเอง
    เพราะความพยายามส่วนใหญ่ไหลไปกองอยู่กับเว็บเทคโนโลยี ผู้คนจึงติดอยู่ตรงนั้น มอง native แล้วบอกว่า “ยังพัฒนาไม่พอ” จากนั้นก็กลับไปพัฒนาเว็บต่อ วนเป็นวงจรแบบนี้
    บน browser มัน “ใช้ได้เลย” อยู่แล้ว จึงแทบไม่มีใครอยากลงทุนแรงเพื่อทำให้ native ดีขึ้น

    • ถึงอย่างนั้น native UI development kit ก็เป็นสินค้าพาณิชย์ไม่ใช่หรือ? มันไม่ใช่เรื่องที่คนต้องไปโน้มน้าวตัวเอง แต่เป็นเรื่องที่ฝั่งนั้นต้องขายให้คนเชื่อ
      เหตุผลหนึ่งที่ฝั่งเว็บดูสุกงอมกว่ามาก ก็เพราะผู้ผลิต commercial OS รายใหญ่ไม่ยอมตามโลกให้ทันมาเนิ่นนาน ชุดเครื่องมือ UI ของ Windows นี่เละจริง ๆ
    • เห็นด้วย สุดท้ายก็เหมือนกำลังบ่นว่ายังไม่มีใครทุ่มแรงมากพอให้ Swift จัดการ Markdown ได้เร็ว แต่ตัวเองก็ไม่ได้ตั้งใจจะช่วยลงแรงตรงนั้นเหมือนกัน

  • ใน แอปแชต AI ของฉันก็เจอแทบจะเหมือนกัน ไม่มีอะไรที่ทำงานได้ดีเลย
    การเรนเดอร์ Markdown ช้าและกระตุก การสตรีมก็ช้าและกระตุก และทุกอย่างทำให้ UI ค้าง
    ลอง text editing component ยอดนิยมบน GitHub สำหรับทั้ง UIKit และ SwiftUI อย่างน้อย 5 ตัวแล้ว ทุกตัวพังในทางใดทางหนึ่ง หรือมีบั๊ก หรือช้า มันไร้สาระมาก

  • นี่เป็นปัญหาที่ยาก ฉันเคยเขียนยาวไว้แล้วว่าตอนสร้าง block editor จากศูนย์ด้วย Qt C++ และ QML แก้ปัญหานี้อย่างไร
    เจอปัญหาคล้ายกันทั้งการเลือกข้ามบล็อกที่ไม่ต่อเนื่อง การแสดง Markdown ต้นฉบับใต้เคอร์เซอร์ และขนาด delegate ที่ต่างกัน
    จากบทเรียนตอนนั้น ตอนนี้กำลังสร้าง native LLM client ที่มี streaming Markdown parser
    [1] https://rubymamistvalove.com/block-editor
    [2] https://www.get-vox.com
 
GN⁺ 12 시간 전
ความเห็นจาก Lobste.rs
  • เห็นด้วยว่าสำหรับ การจัดวางข้อความ ที่ซับซ้อน WebView เหมาะกว่า แต่ก็ยังไม่แน่ใจว่าจำเป็นต้องไปถึงขั้น Electron เพียงเพื่อความสะดวกหรือไม่
    จริง ๆ แล้ว Electron ก็คือแรปเปอร์ที่หุ้ม WebView เอาไว้ แต่เพราะมันพา Chromium ทั้งเอนจินมาด้วย ขนาดแอปจึงใหญ่เกินไปเมื่อเทียบกับความสะดวกที่ได้
    ช่วงปี 2001~2002 เคยทำเลย์เอาต์ข้อความแบบบอลลูนแชตอันเป็นเอกลักษณ์ของ iChat ด้วย NSTextView และสารพัดลูกเล่น แม้จะได้ Hideki Itamura ซึ่งเป็นผู้ออกแบบระบบข้อความของ AppKit มาช่วยก็ยังลำบากพอสมควร เดี๋ยวนี้ทำด้วย HTML+CSS ได้ค่อนข้างง่ายแล้ว
    • เวลาต้องรองรับหลายระบบ สุดท้าย ความเรียบง่าย มีน้ำหนักมาก
      เคยมีส่วนร่วมกับแอปที่ใช้ Tauri แล้วพอเปลี่ยนไปใช้ Chromium ผ่าน Electron มันทำงานได้ดีกว่ามาก โดยเฉพาะเมื่อเป้าหมายคือช่วงที่กว้างมากตั้งแต่ win7 ถึง win11
      ฝั่ง Tauri ดูดีตรงที่ใช้ system webview แต่บน Windows ก็เท่ากับพึ่ง Chrome หรือ Edge, บน macOS ก็พึ่ง Safari, ส่วนสภาพแวดล้อมอื่น ๆ ก็แทบต้องลุ้นเอา สุดท้ายความคาดเดาได้และความสุกงอมของแพลตฟอร์มเป็นฝ่ายชนะ และด้วยเหตุผลที่อธิบายไม่ได้ชัดเจน ประสิทธิภาพก็ดีกว่าด้วย
    • มองว่านี่เป็น ทางเลือกส่วนบุคคล ไม่ว่าจะเป็นขนาดแอปหรือการใช้ RAM ถ้าพร้อมจ่ายต้นทุนเพื่อแลกกับความสะดวก ผู้ใช้หลายล้านคนของแอปอย่าง Visual Studio Code ก็ดูจะเห็นด้วย
      สุดท้ายก็ต้องการซอฟต์แวร์ที่ดีกว่า มากกว่าจะทำให้กราฟ htop ดูน่าพอใจ
      ประเด็นหลักของบล็อกโพสต์ไม่ใช่ว่า “ทุกคนควรเลือก Electron” แต่คือ ตอนนี้เข้าใจแล้วว่าทำไมแม้แต่บริษัทที่มีทั้งทรัพยากรและเงินก็ยังเลือก Electron หรือเทคโนโลยีเว็บ อย่างน้อยในมุมมองของฉัน มันยอมประนีประนอมในจุดที่เหมาะสมเพื่อมอบประสบการณ์ใช้งานที่ดี
      มีคนมากมายที่ปกป้อง Apple TextKit 2 หรือ native text framework อื่น ๆ แต่แทบไม่มีโปรแกรมแก้ไขข้อความยอดนิยมและประสิทธิภาพสูงที่สร้างด้วย Apple SDK ล้วน ๆ Xcode ทำได้ค่อนข้างดี และอาจเป็นกรณีใช้งานจริงเพียงรายเดียวที่ใกล้เคียงที่สุด ส่วน Zed, Sublime Text, Visual Studio Code และ JetBrains IDE ต่างก็ใช้โซลูชันเรนเดอร์ข้อความของตัวเองด้วยเหตุผลบางอย่าง
  • ปัญหาอย่างหนึ่งคือคนที่สร้างซอฟต์แวร์พัฒนาบนคอมพิวเตอร์และโทรศัพท์ระดับท็อป 0.1% ของโลก
    เพราะแบบนั้น ต่อให้สร้างด้วยวิธีที่แย่ที่สุด มันก็อาจยังดูโอเคในสภาพแวดล้อมของตัวเอง
    แต่คนที่เหลือซึ่งใช้อุปกรณ์สเปกต่ำกว่ามากกลับต้องแบกรับ ซอฟต์แวร์ที่เทอะทะและช้า ต่อไป
  • สงสัยว่าช่วงนี้ฝั่ง GTK/Qt เป็นอย่างไรบ้าง ไม่ได้ทำ GUI มานานแล้ว
    • เท่าที่เข้าใจ งานนี้ก็น่าจะทำได้ใน Qt โดยไม่ต้องใช้ WebView
      เพียงแต่ดูเหมือนผู้เขียนจะไม่ได้สำรวจไปถึงทางนั้นในที่นี้
  • สงสัยว่าถ้าเทียบ Electron กับ Flutter จะเป็นอย่างไร
    จากมุมคนนอก Flutter ดูเหมือนคำตอบของคำถามว่า “ถ้าตัด Chromium เหลือแค่ Skia ซึ่งเป็นตัวเรนเดอร์ แล้วเอามาใช้กับแอป GUI จะเป็นอย่างไร?” มันน่าจะเป็นเครื่องมือข้ามแพลตฟอร์มที่เบากว่า Electron แต่มีความสามารถใกล้เคียงกัน
  • ผู้เขียน https://github.com/stevengharris/MarkupEditor เสนอว่านี่เป็นแนวทางที่ค่อนข้างดีในบรรดาวิธีที่ทำได้ตอนนี้: https://blog.krzyzanowskim.com/2025/08/14/textkit-2-the-promised-land/
    • แต่ MarkupEditor ไม่ได้ใช้ TextKit2 มันใช้ WebView README ก็ระบุว่า MarkupEditor โต้ตอบกับเอกสาร HTML ที่ใช้ contentEditable DIV เดียว และใช้คลาสย่อยของ WKWebView
      ความย้อนแย้งคือเอนจินข้อความแบบ native ของ Apple มี data model ที่ดีกว่า HTML DOM tree มาก นั่นคือสตริงกับคุณสมบัติการจัดสไตล์ที่เข้ารหัสแบบ run-length
      การแก้ไขข้อความบน DOM นั้นแทบเป็นฝันร้าย เพราะพื้นที่เลือกมักพาดผ่านหลายองค์ประกอบในหลายลำดับชั้น ทำให้ต้องแยกและรวมอย่างซับซ้อนมาก ตอนที่เคยลอง Safari build รุ่นแรก ๆ ที่รองรับ contenteditable เคยส่งรายงานบั๊กไปมหาศาล และจนถึงตอนนี้ตัวแก้ไข rich text บนเว็บจำนวนมากก็ยังพังเวลาตัดหรือวางรายการลิสต์
      สุดท้ายมันก็ดูคล้ายกับเรื่อง CISC ปะทะ RISC ในยุค 90~00 คือสถาปัตยกรรมที่ “ด้อยกว่า” กลับได้รับทรัพยากรมากกว่า จนเกิดเป็น implementation ที่เหนือกว่า