แถบนั้นก็มีแต่คนเยอะเหมือนกัน แต่สิ่งที่ทำไม่ว่าจะที่นี่หรือที่นั่นก็พอๆ กัน 555

 

เป็นภาพชีวิตประจำวันของประเทศหนึ่งที่คุ้นเคย ซึ่งขึ้นต้นด้วย "ฮัน" และลงท้ายด้วย "กุก" เลยนะ

 

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

 

ตั้งแต่แรกแล้ว หากจะพิจารณาใช้ SPA ด้วยเหตุผลแค่ว่า "ลื่นไหล" ผมก็คงยอมไม่เอาความลื่นไหลนั้นแล้วเขียนเป็น MPA ไปอยู่ดี เลยไม่ค่อยรู้สึกเห็นด้วยเท่าไรครับ...

 

พูดกันตามตรงก็มีคนอยู่เหมือนกันที่จริงๆ แล้วไม่ได้มีอะไรต้องทำ แต่ก็ฝืนรันหลายตัวเพื่อจะรีดให้คุ้มแบบสุดๆ...

 

ในบรรดากรณีที่คุณยกมา มีเพียงเครื่องมือทำงานร่วมกันแบบเรียลไทม์เท่านั้นที่ไม่สามารถแทนที่ SPA ด้วยสิ่งอย่าง View Transitions ได้ แต่เว็บไซต์ส่วนใหญ่ไม่ได้เป็นเครื่องมือทำงานร่วมกันแบบเรียลไทม์ เว็บไซต์การตลาด แดชบอร์ด และแอปคอมเมิร์ซ ล้วนสามารถสร้างได้โดยตัดเฟรมเวิร์ก SPA ออก และยึดเงื่อนไขอย่าง server rendering, หน้าแบบเต็ม, แอนิเมชันที่อิง CSS, การ preload อย่างตั้งใจ และการใช้ JS ให้น้อยที่สุด ฝั่ง Rails ก็มี Hotwire ที่มุ่งไปในทางนี้ และก็มีตัวอย่างใช้งานจริงในโปรดักชันอย่าง Basecamp และ HEY ด้วย เรื่องการจัดการ state? ถ้าไม่ใช่สิ่งอย่างเครื่องมือทำงานร่วมกันแบบเรียลไทม์ ก็ใช้วิธีฝั่งเซิร์ฟเวอร์อย่าง URL parameters หรือ server session หรือจะใช้ local storage ก็เพียงพอแล้ว แน่นอนว่าก็มีกรณีที่นำ SPA มาใช้เพราะการเปลี่ยนหน้าอยู่จริง (เช่นเว็บทางการของ AGF ที่แค่ Astro ก็น่าจะพอ แต่ก็นำ React มาใช้) และก็ปฏิเสธไม่ได้ว่าหนึ่งในข้อดีตัวแทนของ SPA ที่ถูกพูดถึงบ่อยมากก็คือการเปลี่ยนหน้านี่เอง

 

มีกรณีที่นำเฟรมเวิร์ก SPA มาใช้เพียงเพื่อให้ได้ปฏิสัมพันธ์ที่ลื่นไหลอยู่จริง แต่เว็บไซต์จำนวนมากที่ใช้ SPA ไม่ได้ต้องการปฏิสัมพันธ์ที่ซับซ้อนขนาดนั้น

 

ไม่ใช่ว่าทุกอย่างจะเป็น endofunctor ทั้งหมด ของที่มี type parameter หลายตัวอย่างเช่น Result<T, E> นั้นไม่ใช่ 𝒞 → 𝒞 แต่เป็น Result : 𝒞 × 𝒞 → 𝒞 ดังนั้นแบบนี้จึงเป็น bifunctor

 

ชี้ประเด็นได้อย่างแม่นยำครับ!
ดูเหมือนว่าจะมีความเข้าใจคลาดเคลื่อนเกิดขึ้นในกระบวนการนำเนื้อหาที่เขียนด้วยภาษาอื่นมาปรับใช้โดยอิงตาม Rust
เนื่องจากระบบชนิดข้อมูลของ Rust ก่อเป็นหมวดหมู่เดียว การแยกความแตกต่างระหว่าง endofunctor กับ functor ทั่วไปจึงน่าจะไม่มีความหมาย
เสียดายที่ในบล็อกไม่มีฟังก์ชันคอมเมนต์ คงต้องลองสอบถามดูว่าสามารถขอให้แก้ไขได้หรือไม่ครับ

 

เป็นบทความที่ดีครับ! แต่คำอธิบายเกี่ยวกับ endofunctor มีข้อผิดพลาดอยู่ จึงน่าจะดีหากมีการแก้ไข https://x.com/simnalamburt/status/1950074970647761168?s=46

 

มีฟีเจอร์ที่คิดว่า "ถ้ามีก็คงดี" ใส่มาครบหมดเลยนะเนี่ย ตัวนี้ตัวเดียวทำหน้าที่เป็น NAS ได้ครบเลย

 

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

 

โดน Komoot เล่นงาน

Namuwiki...

 

ยังไม่ค่อยเข้าใจว่า การยืนยันอายุจะใช้งานควบคู่กับการคุ้มครองข้อมูลส่วนบุคคลได้อย่างไร..

ในวินาทีที่ทำการยืนยัน อย่างน้อยก็แทบไม่ต่างจากการทิ้งลายเซ็นของตัวเองไว้ที่นั่นสักครั้งไม่ใช่หรือ?

ถ้าจะคุ้มครองข้อมูลส่วนบุคคลจริง ๆ ก็ควรต้องใช้งานแบบไม่ระบุตัวตนได้สิ

 

ยอดเยี่ยมมากครับ ชอบแนวทางแบบนี้มาก

 

เป็นแนวทางการเพิ่มประสิทธิภาพที่ไม่อิง ML ซึ่งน่ายินดีทีเดียว

 

ดูเหมือนว่าคนนี้กำลังพูดถึงค่าใช้จ่ายค่าสมาชิก IDE นะครับ FLCC ไม่มีให้ในเวอร์ชันฟรี
แต่ก็ไม่ใช่ว่าผู้คนจะยอมจ่ายเงินเพราะหวังแค่อย่างนั้นอย่างเดียว

 

จุดที่น่าเสียดายของบทความนี้

  1. ตีความเป้าหมายที่แท้จริงของ SPA แคบเกินไป
    View Transitions API นั้นยอดเยี่ยมมากจริง ๆ แต่เพียงแค่นั้นยังไม่ได้แปลว่า SPA จะไม่จำเป็นอีกต่อไป

  2. มองทุกเว็บไซต์ด้วยเกณฑ์เดียวกัน
    เว็บไซต์การตลาด ≠ แดชบอร์ด ≠ แอปคอมเมิร์ซ ≠ เครื่องมือทำงานร่วมกันแบบเรียลไทม์
    ทั้งหมดมีความต้องการเชิงโครงสร้างที่แตกต่างกัน

  3. ในการใช้งานจริง SPA + SSR + MPA กำลังอยู่ร่วมกัน
    ไฮบริดเฟรมเวิร์กอย่าง Next.js แสดงให้เห็นเรื่องนี้ได้อย่างชัดเจน
    สินทรัพย์แบบสแตติกใช้ SSG, แดชบอร์ดหลังล็อกอินใช้ CSR/SPA, ส่วนการรองรับเสิร์ชเอนจินใช้ SSR เป็นต้น จึงจำเป็นต้องมีการผสมผสานอย่างยืดหยุ่น

ผมคิดว่า SPA ไม่ได้เป็นเพียงเรื่องของประสบการณ์ผู้ใช้เท่านั้น แต่ใกล้เคียงกับการเป็นผลลัพธ์ของการปรับปรุงโครงสร้างมากกว่า
สำหรับหน้าที่ไม่จำเป็นต้องใช้ SPA, MPA + โมเดิร์น CSS อาจเป็นตัวเลือกที่ดีได้ แต่ในมุมของโครงสร้าง สถานะ ความสามารถในการขยาย และการบำรุงรักษา SPA ก็ยังคงจำเป็นอยู่ โมเดิร์น CSS อาจ "เสริม" SPA ได้ แต่ผมไม่คิดว่าจะ "แทนที่" ได้

 

พูดกันตามตรง มันดูเหมือนกับการพูดถึง Rust หรือ Haskell ทั้งที่ยังไม่เคยลองจับเลย แล้วบอกว่า ‘ไม่ต้องมีพวกนั้น ทุกวันนี้ C++ ก็ทำได้หมดแล้ว’