การทดลองความหนาแน่นของ UI ที่สร้างด้วย Svelte

• Grid คือการทดลองให้ผู้ใช้ปรับความหนาแน่นของ UI ได้ และขณะนี้กำลังพัฒนาเวอร์ชันใหม่อยู่
• Matrix ซึ่งมีลักษณะเป็นผลงานต่อยอด มุ่งเป้าไปที่ความหนาแน่นของ UI ที่สูงขึ้น โดยแสดงเมทริกซ์สหสัมพันธ์ของ S&P 500 และ NASDAQ-100
• เมื่อเลือกหุ้นที่เป็นองค์ประกอบของ S&P500 จะจัดการสหสัมพันธ์ของ เซลล์มากกว่า 250,000 เซลล์ และ จุดข้อมูลมากกว่า 30 ล้านจุด
• ฟีเจอร์บางส่วนไม่รวมอยู่ในพรีวิวด้านล่าง และหากต้องการตัดสินประเมินควรเปิด UI แบบเต็มหน้าจอของ Matrix
• ข้อมูลบนไซต์มีวัตถุประสงค์เพื่อให้ข้อมูลเท่านั้น ไม่ถือเป็นคำแนะนำการลงทุนหรือคำแนะนำให้ซื้อ·ขายหลักทรัพย์

---

การทดลองความหนาแน่นของ UI ที่ต่อเนื่องจาก Grid ไปสู่ Matrix

• Grid เป็นโปรเจกต์ทดลองความหนาแน่นของ UI ที่ปรับแต่งได้โดยผู้ใช้ และกำลังมีการพัฒนาเวอร์ชันใหม่
• Matrix เป็นการทดลองที่ผลักความหนาแน่นของ UI ให้ไกลยิ่งขึ้น โดยให้บริการ เมทริกซ์สหสัมพันธ์ ขนาดใหญ่ของ S&P 500 และ NASDAQ-100
• สามารถดูบางส่วนของ Matrix ได้ในพรีวิวด้านล่าง แต่ฟีเจอร์บางอย่างมีให้เฉพาะใน UI แบบเต็มหน้าจอของ Matrix เท่านั้น

ขนาดข้อมูลที่ Matrix จัดการ

• หากเลือกหุ้นองค์ประกอบของ S&P500 เป็นชุดข้อมูล จะมี เซลล์มากกว่า 250,000 เซลล์
  • คำนวณสหสัมพันธ์ของ จุดข้อมูลมากกว่า 30,000,000 จุด
  • ดูข้อมูลเพิ่มเติมได้ที่หน้า About ของการทดลอง Matrix
• หน้า home ให้ภาพรวมของ การทดลองด้านการแสดงผลข้อมูลเป็นภาพ ทั้งหมดที่มีอยู่ในปัจจุบัน

องค์ประกอบการควบคุมที่ดูได้ในพรีวิว

• รายการเลือก Dataset มี S&P500 และ NASDAQ100
• Horizon เลือกได้ระหว่าง 1M และ 1Y
• มีเช็กบ็อกซ์ Detrend Data เป็นตัวเลือกสำหรับการเตรียมข้อมูลล่วงหน้า
• ตัวเลือกที่เกี่ยวข้องกับการเรียงลำดับมีดังนี้
  • Sort By: Cluster, AvgCorr, MedCorr, Name
  • Cluster Method: Avg, Complete, Ward
  • Sort Direction: Asc, Desc
• UI พรีวิวมี Minimap, Search, Rolling Correlation Chart และคำแนะนำสำหรับการ hover และ click เซลล์
• ในสถานะที่แสดงอยู่ ระบุเป็น Symbols 101, Correlations 5,050, Cells 10,201

ข้อควรระวังในการใช้งาน

• ข้อมูลบนเว็บไซต์มี วัตถุประสงค์เพื่อให้ข้อมูล เท่านั้น ไม่ใช่คำแนะนำการลงทุนหรือคำแนะนำให้ซื้อ·ขายหลักทรัพย์

[GN⁺]

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

• ผมทำงานกับข้อมูลรูปแบบตารางเยอะ จึงชอบให้แสดงบนหน้าจอเดียวได้มากที่สุดเท่าที่เป็นไปได้ สิ่งที่มีอิทธิพลต่อการออกแบบรายงานของผมมากที่สุดกลับเป็น iTunes: เว้นที่ว่างเท่าที่จำเป็นเท่านั้น, แถวแบบสลับสี, การจัดเรียงที่เร็วและง่าย และถ้าเป็นไปได้ก็ใช้โครงสร้างคล้าย column browser ใช้ DataTables มาหลายปีและพอใจมาก
  ช่วงนี้กำลังทดลองระหว่าง การจัดเรียงกับการแสดงผล ถ้า issue ที่ดึงมาจาก Jira ติดขัดอยู่ ก็คิดอยู่ว่าจำเป็นต้องมีคอลัมน์ boolean แยกสำหรับ sort/filter ไหม หรือแค่ใส่สไตล์ให้คอลัมน์อื่น (เช่น เวลาที่ผ่านไป) ก็พอแล้ว กำลังดูว่าในตารางที่มีมากกว่า 100 แถว เพียงค่าในเซลล์ที่เป็นสีส้ม สีแดง และสีแดงตัวหนา จะทำให้รู้ได้ไหมว่าอะไรต้องจัดการตอนนี้
  สิ่งที่ชอบในมุมมองตารางของการทดลองนี้คือการอัปเดตแบบเรียลไทม์, stable sort หลายคอลัมน์, ไฮไลต์แถวเมื่อ hover เมาส์, ทำเลข 0 ด้านท้ายให้จางลง, สีที่ไม่มากเกินไป (โดยพื้นฐานประมาณสามคู่), และกราฟแบบ sparkline ในคอลัมน์ 24H Low/High สิ่งที่น่าเสียดายคือแถบเลื่อนแนวนอนที่แทบมองไม่เห็น, แถบเลื่อนแนวตั้งกว้างที่มีกราฟติดอยู่, ความไม่ชัดเจนว่า 24H Low/High ถูกจัดเรียงจริงอย่างไร และไม่มีการกรอง อีกอย่างเมื่อเทียบกับรายงานของผม จะเห็นว่าความกว้างของค่าต่าง ๆ ไม่แปรผันมากนัก ถ้ามีข้อความปนมากกว่าตัวเลขเป็นหลัก การจัดการความกว้างคอลัมน์จะยากขึ้น
  • จำได้ว่าเคยเลื่อนการอัปเกรดเป็น Catalina เพราะกลัวว่า iTunes.app จะหายไป มันเป็นแอปที่ถูกประเมินค่าต่ำไปมาก และดีใจจริง ๆ ที่ Music.app แทบจะเป็นแอปเดียวกัน แถมย้ายข้อมูลง่ายด้วย
  • DataTables ยอดเยี่ยมมาก ใช้ในผลิตภัณฑ์หนึ่งมานานกว่า 10 ปีแล้ว พยายามหาอะไรมาทดแทนที่ใหม่กว่าและดีกว่าอยู่เรื่อย ๆ แต่ยังหาไม่เจอ
  • กำลังทดลอง พัฒนาแอป Mac ที่เชื่อมกับ Jira หรือการทำงานอื่น ๆ ที่ดำเนินไปแบบ asynchronous อยู่เหมือนกัน เดิมสนใจเรื่องการควบคุมว่าจะรับการแจ้งเตือนอะไรและเมื่อไรมากกว่าการดูข้อมูลเอง แต่พอเห็นคอมเมนต์นี้กับ UI แล้วก็อยากลองไอเดียอื่นที่เคยติดอยู่บนหน้าจอข้อมูลหลัก
  • หมายถึง conditional formatting ที่ใช้สีแสดงขนาดหรือเปล่า?
• ผมค่อนข้างชอบวิธีที่ขยายแถบเลื่อนของตารางให้เหมือน minimap ใน code editor แล้วใส่ข้อมูลเพิ่มเติมเข้าไป ช่วยให้มองปราดเดียวรู้ว่าข้อมูลบนหน้าจออยู่ตรงไหนในชุดข้อมูลที่ใหญ่กว่า
  Helix รู้สึกอ่านยากและไม่ค่อยมีประโยชน์ กราฟแบบนี้เหมาะกับข้อมูลตามคาบที่มีคาบสั้นกว่าช่วงข้อมูลทั้งหมดมากกว่า
  Cube ทำให้อยากรู้อยากเห็น แต่ยังมองไม่เห็นข้อดีชัดเจน โดยทั่วไป visualization แบบ 3D มักมีประสิทธิภาพด้อยกว่าการแสดงสิ่งเดียวกันด้วยกราฟ 2D สามอัน (ในที่นี้คือ scatter plot 3 อัน) เพราะเมื่อฉายจาก 3D ลง 2D จะเกิดการบิดเบือน และสัญชาตญาณพื้นฐานของมนุษย์ในการเปรียบเทียบตำแหน่งก็ถูกรบกวนด้วย อยากรู้ว่าตั้งใจให้เกิดเอฟเฟกต์อะไรตรงนี้
  • ขอให้ชัดเจน ผมไม่ใช่ผู้สร้างโปรเจกต์สวยงามนี้
  • จริง ๆ แล้ว แท็บ Helix น่าทึ่งมากจนผมเข้ามาเพื่อพูดเรื่องนี้เลย ตัวอย่างเช่น น่าจะใช้วาดความผันผวนของหุ้นและสินค้าอื่น ๆ โดยเฉพาะอนุพันธ์ได้
    วิธีที่ให้มองย้อนอดีตได้เป็นธรรมชาติที่สุด ขณะเดียวกันก็ทำให้ข้อมูลล่าสุดดูใหญ่ขึ้นนั้นอัจฉริยะจริง ๆ แทบไม่อยากเชื่อว่าทำไมผมไม่เคยคิดแบบนี้มาก่อน
• หวังว่าโปรเจกต์แบบนี้จะเป็นสัญญาณของการกลับไปสู่อินเทอร์เฟซที่ออกแบบดี แต่มี ความหนาแน่นของข้อมูล สูงและประหยัดพื้นที่
  หลังจาก "Material Design" ซึ่ง Google ฝังกลบไปโดยพฤตินัย ก็มีความเทอะทะ พื้นที่ขาว ระยะห่างเกินจำเป็น และ “ความโปร่งโล่ง” แบบสิ้นเปลืองมากเกินไป
  ฝันไว้ก็ไม่เสียหาย
  • บนมือถือ พื้นที่แตะต้องมีขนาดเท่านิ้ว จึงจำเป็นต้องมี UI ที่ค่อนข้างกว้างในระดับหนึ่ง
    บริษัทต่าง ๆ ไม่อยากออกแบบ UI สองแบบที่แตกต่างกันมากตามแพลตฟอร์ม และโดยทั่วไปผู้ใช้ก็อยากให้วิธีใช้งานที่เรียนรู้จากแพลตฟอร์มหนึ่งต่อเนื่องไปยังอีกแพลตฟอร์มได้
    ด้าน accessibility ก็ทำได้ง่ายกว่าเมื่อดีไซน์มีพื้นที่เผื่อสำหรับฟอนต์ใหญ่ และไม่ต้องอาศัยการควบคุมการเคลื่อนไหวที่ละเอียดแม่นยำ พอมองพ่อของผมแก่ลงอย่างเห็นได้ชัด ผมก็เริ่มเข้าใจว่าแม้แต่แอปที่รู้สึกว่ากว้าง ก็ยังไม่พอจากมุมมองนี้
    ถ้าแรงที่ผลักเราไปทางนั้นตั้งแต่แรกไม่เปลี่ยน ผมก็ไม่ค่อยเห็นว่าจะกลับไปสู่ดีไซน์ที่มีความหนาแน่นของข้อมูลสูงได้อย่างไร

  • starting with (now Google-dead) "Material Design"
    ผมนึกว่ายังพัฒนาอย่างคึกคักอยู่ หมายความว่า Google ฆ่ามันทิ้งแล้วเหรอ?
    https://m3.material.io/

  • ผมว่ามันเริ่มจาก Apple ตอนเปลี่ยนจาก OS 9 ไป OS X ตอนนั้นอธิบายไม่ถูก แต่ถึงทุกวันนี้ก็ยังรู้สึกเสียดายที่พื้นที่หน้าจอราคาแพงถูกใช้อย่างสิ้นเปลืองมากเกินไป
• ผมมองว่าการทดลองนี้ขาดองค์ประกอบสำคัญในการออกแบบความหนาแน่นของ UI นั่นคือ typography
  หน้าจอเหล่านี้ใช้ฟอนต์ monospace ขนาดเดียว เป็นสไตล์ย้อนยุคแบบ text-mode UI ยุค 1980 และถ้านั่นคือข้อจำกัดที่ตั้งใจไว้ก็โอเค
  แต่ถ้าสามารถจัดลำดับชั้นของ typeface และขนาดได้อย่างเหมาะสม จะใส่ข้อมูลลงบนหน้าจอได้มากกว่านี้มาก
  ตัวอย่างพื้นฐานคือกล่อง “About” ตอนนี้กินพื้นที่เกือบ 1/4 ของหน้าจอโทรศัพท์ ถ้าเปลี่ยนเป็นฟอนต์ proportional ที่เล็กลง ก็ยังอ่านได้บนมือถือและใส่ข้อมูลนี้ได้ในพื้นที่ครึ่งหนึ่ง
  ถ้าดูงานของนักออกแบบข้อมูลชั้นยอดอย่าง Edward Tufte มักจะเห็นว่าเขาหมกมุ่นกับการปรับ typography ให้ถูกต้อง หนังสือของเขาใช้ทั้งองค์ประกอบและสเกลทาง typography หลายแบบแม้แต่กับเนื้อความนอก visualization
  • มีงานเขียนเฉพาะของ Edward Tufte ที่แนะนำเกี่ยวกับหัวข้อนี้ไหม?
• จะยก Perspective มาเป็นตัวเทียบที่ใกล้เคียงได้ไหม? (https://perspective.finos.org/)
  สงสัยว่าโฟกัสคือความหนาแน่นที่เกี่ยวกับ performance, visualization หรืออย่างอื่น
  • โหลดช้ากว่าเว็บต้นฉบับมาก ข้อมูลเพิ่มเติมคือ แท็บ Helix ของต้นฉบับน่าทึ่งจริง ๆ
  • ตอนเปิดครั้งแรกคิดว่าทำด้วย Perspective
    รู้สึกว่าได้รับอิทธิพลมาเยอะอย่างชัดเจน
• สิ่งที่ผมชอบเป็นพิเศษเวลาทำแอปการเงินที่มีข้อมูลจำนวนมากบน Windows Forms คือคอนโทรล DataGridView มีการกรอง การจัดเรียง การลากวางเพื่อจัดลำดับ/ปรับขนาดคอลัมน์ใหม่ พร้อมทั้งมีความหนาแน่นและ performance สูง ไม่ต้องมี pagination ด้วย ถ้าอยากใส่ 10,000 แถว ก็ใส่เข้าไปได้เลย UI ส่วนใหญ่ที่เราทำคือหน้าจอที่เต็มไปด้วยพาเนล DataGridView มันน่าเกลียดไหม? ใช่ เร็วไหม? ก็ใช่อีกเช่นกัน

ความพยายามที่จะสร้าง UI ที่คล้ายกันด้วย React ส่วนใหญ่ล้มเหลวเพราะประสิทธิภาพไม่ดี เพื่อให้ได้ประสิทธิภาพการเรนเดอร์ที่ยอมรับได้ ในตารางข้อมูลจึงเลี่ยง React ไปทั้งหมด ถึงอย่างนั้น หากไม่อยากให้การเรนเดอร์ของเบราว์เซอร์เองช้าจนทนไม่ได้ ก็ยังต้องลดจำนวนองค์ประกอบ DOM ต่อแถวให้เหลือน้อยที่สุด

• WinForms อาจยังเป็น UI framework ที่ผมชอบที่สุดอยู่ แน่นอนว่ามันเป็นเครื่องมือที่ทื่อ ๆ แต่ก็เหวี่ยงใช้งานได้เต็มที่ มันยืดหยุ่นมหาศาล ใช้ค่อนข้างง่าย เร็วพอสมควร และหน้าตาอัปลักษณ์สุด ๆ
  โยน Object ใด ๆ เข้าไปก็ทำงานได้เลย สามารถซ้อน PropertyGrid ไว้ใน PropertyGrid ขยายด้วยคอลเลกชันของอ็อบเจกต์ และซ้อนคอนโทรลลงไปได้ลึกเท่าที่ต้องการ โดยไม่ต้องไปแตะหรือใส่ใจโครงสร้างภายในของอ็อบเจกต์ที่ UI ผูกอยู่ (แม้จะมีขีดจำกัดก็ตาม)
  สำหรับผม WinForms คืออุดมคติแบบเพลโตของ UI framework ถ้าผมออกแบบเองก็คงทำออกมาแบบนี้เป๊ะ

• ผมชอบ ความหนาแน่นของข้อมูล มากจริง ๆ
  ผมสะสมหนังสือพิมพ์เก่า ๆ ซึ่งในสมัยนั้นความหนาแน่นของข้อมูลสูงกว่านี้มาก ถ้ากำลังมองหาหนังสือวางโต๊ะกาแฟดี ๆ ลองค้นหา "nytimes complete front pages" ดู ข้อมูลสำคัญจำนวนมากอยู่บนครึ่งหน้าบนของหน้าที่พับไว้จริง ๆ
  ผมมองว่าความหนาแน่นของข้อมูลสูงเท่ากับสติปัญญาสูง การจัดลำดับความสำคัญในการเรียงข้อมูลให้ถูกต้องนั้นมีคุณค่าและสำคัญมาก
  ในช่วงไม่กี่ปีที่ผ่านมา เว็บดูเหมือนจะมุ่งไปในทิศทางตรงกันข้าม แต่ก็ดีใจที่ยังเห็นคนพายเรือสวนทางอยู่
  อีกตัวอย่างหนึ่งคือบล็อกของผมถูกออกแบบให้ดูบทความราว 20 ปีได้ในครั้งเดียวผ่านการซูมเข้า/ออก (https://breckyunits.com/)
  นอกจากนี้ ผมกำลังจะเปิดตัวงานที่ช่วยโปรโมต cheat sheet ที่มีความหนาแน่นของข้อมูลสูงและทำให้สร้างได้ง่ายขึ้นด้วย คิดว่าจะใช้ชื่อว่า Leet Sheet (https://pldb.io/blog/leetSheets.html)

  • I think high information density === high intelligence.
    การยัดสิ่งต่าง ๆ จำนวนมากลงบนหน้าจอพร้อมกันด้วยฟอนต์เล็กและระยะขอบเล็ก ๆ ทำให้เกิด ปัญหาด้านการเข้าถึง มากมาย แม้กับคนที่มีสติปัญญาสูง
    บริษัทอย่าง Google เพิ่มระยะขอบและ padding ก็เพื่อให้ UI เข้าถึงได้สำหรับผู้คนจำนวนมากขึ้น ไม่ใช่แค่ปัญหาเรื่องสายตาเท่านั้น แต่ยังมีปัญหาทางกายภาพ เช่น โรคพาร์กินสัน ที่ทำให้คลิก/แตะเป้าหมายเล็ก ๆ อย่างแม่นยำได้ยาก และยังมีปัญหาความหลากหลายทางระบบประสาทที่อาจทำให้สับสนทิศทางเพียงเพราะมีข้อความหรือองค์ประกอบมากเกินไปบนหน้าจอพร้อมกัน (เช่น โรคลมชัก)
    แม้เป็นคนที่มีสติปัญญาสูงมาก ก็ยังได้ประโยชน์จาก UI ที่ออกแบบดีและเข้าถึงได้ ไม่ควรสมมติว่าคนที่ต้องการความช่วยเหลือแบบนั้นมีสติปัญญาน้อยกว่า

• เรื่องนี้น่าสนใจเพราะมันพิสูจน์บางอย่างเกี่ยวกับการมองเห็นและ ความเข้าใจทางสายตา ของผม
  มุมมอง "Grid" ใช้ได้ดีไม่มีปัญหา แต่มุมมอง "Table" ใช้ไม่ได้
  ผมมักมีปัญหาหลงว่าตัวเองอยู่บรรทัดไหนเวลาไล่สายตาข้ามบรรทัดยาว ๆ แบบนี้ ผมเพิ่งตระหนักว่าเป็นเพราะเมื่อสายตาเคลื่อนที่ ตาขวาที่เด่นกว่ามีแนวโน้มจะเลื่อนไปทางขวาเล็กน้อย การจัดแนวสองตาของผมคลาดเคลื่อนเล็กน้อยจนต้องใช้การแก้ด้วยปริซึม และการปรับค่าสายตาปริซึมครั้งล่าสุดทำให้สถานการณ์นี้ดีขึ้น
  ในการแสดงผลแบบนี้ ตำแหน่งของเส้นแสดงในคอลัมน์ low/high ยิ่งทำให้การเลื่อนไปผิดแถวโดยไม่ตั้งใจ (ซึ่งมักเกิดขึ้นขึ้นด้านบนเสมอ) แย่ลง
  สำหรับผม น่าจะดีกว่าถ้าเส้นกราฟเป็นพื้นหลังของเซลล์หรืออยู่ด้านล่างของเซลล์ แถวต่าง ๆ ก็ควรมีลายสลับสีอ่อน ๆ ด้วย
  บทเรียนที่ได้จากมุมมองของคนที่อ่านได้เร็วและคล่อง และไม่มีความบกพร่องทางสายตาหรือการรับรู้ คืออย่าสมมติว่าในตารางแบบนี้ การวางข้อมูลข้ามแถวกว้าง ๆ จะใช้ได้ ผู้ใช้ต้องมี เบาะแสให้ยึดแถวไว้ ระหว่างไล่สายตาในแนวนอน เส้นแบ่งบาง ๆ อย่างเดียวไม่พอ และการเปลี่ยนพื้นหลังเมื่อวางเมาส์ทับก็ใช้ไม่ได้บนอุปกรณ์สัมผัส
  ถ้าเจอแบบนี้ในสภาพปัจจุบัน ผมมักจะยกเลิกการขยายหน้าต่างเต็มจอ ลดความสูงของหน้าต่าง แล้วเลื่อนดูโดยใช้ขอบล่างของหน้าต่างหรือแถบชื่อของหน้าต่างอื่นเป็น “ขอบ” ที่สม่ำเสมอเพื่อดูข้อมูล เวลาใช้ iPad ผมก็เคยใช้กระดาษหรือการ์ดช่วยด้วย

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

• องค์ประกอบ UI ตรงนี้ดูยอดเยี่ยมมาก แต่ผมก็อยากรู้เหมือนกันว่า การทดลองคืออะไร และได้ข้อสรุปอะไร
  ถ้ามองแค่จำนวนองค์ประกอบแบบโต้ตอบล้วน ๆ จากประสบการณ์ของผม (Svelte 4) การเรนเดอร์มักก่อปัญหาก่อนการโต้ตอบ กล่าวคือจะเจอปัญหาประสิทธิภาพที่จำนวนองค์ประกอบเท่ากัน ไม่ว่าองค์ประกอบนั้นจะโต้ตอบได้หรือไม่ก็ตาม ทางแก้คือไปใช้ canvas เหมือนที่บางส่วนของหน้านี้ทำไว้

  • Svelte ใช้ร่วมกับคอมโพเนนต์ที่ไม่มีการเรนเดอร์ได้ https://imfeld.dev/writing/svelte_domless_components
    Svelte ยังวาดลงบน canvas ได้ด้วย มี Threlte ด้วย: https://threlte.xyz/
    ถ้าพูดถึงประสิทธิภาพภายในของ Svelte ผมไม่คิดว่าจำเป็นต้องมีอะไรอย่าง Jotai เท่ากับ React เพื่อกันการ re-render ที่ไม่จำเป็น

  • you run into performance problems at the same number of elements regardless of whether they're interactive. As you implemented for the some of these pages, the solution is to go to a canvas.
    น่าแปลกใจ ผมคิดว่าจุดแข็งของ Svelte คือการอัปเดต DOM ได้ละเอียดและมีประสิทธิภาพมาก เพราะมีขั้นตอนคอมไพล์และไม่มี virtual DOM แม้ใน paradigm แบบนั้น ตารางขนาดใหญ่แบบง่าย ๆ ก็ยังเป็นปัญหาอยู่หรือ? ในองค์ประกอบเหล่านี้ มีตัวไหนบ้างที่จริง ๆ สามารถเรนเดอร์เป็น DOM ได้ แต่ต้องใช้ canvas ล้วน ๆ เพราะเหตุผลด้านประสิทธิภาพ?

• เมื่อผสาน Svelte เข้ากับ เฟรมเวิร์ก WebGL ที่ยอดเยี่ยมอย่าง Phaser จะทำให้เรนเดอร์กราฟิกได้เร็วมาก: https://phaser.io/news/2024/03/official-phaser-3-and-svelte-...

• แผนภูมิ Helix นั่นดึงดูดใจมากจริง ๆ ไม่แน่ใจว่าจะนำไปใช้จริงได้ไหม แต่หน้าตาดูเจ๋งสุด ๆ
  ถ้านี่เป็นการทดลอง แล้วข้อสรุปคืออะไร?

  • ดูเหมือนจะไม่ทำงานบน Firefox หรือเป็นแค่ผมคนเดียว?