น่าสนใจดีนะ

ว้าว เป็นโปรแกรมที่ยอดเยี่ยมจริงๆ ดูเหมือนว่าผู้สร้างจะเป็นชาวนอร์เวย์ การสร้างโปรแกรมคุณภาพสูงแบบนี้ขึ้นมาแล้วเผยแพร่ออกสู่สาธารณะเพียงเพราะความสนุก ชวนให้นับถือจริงๆ ยิ่งคิดก็ยิ่งรู้สึกว่าโลกกว้างใหญ่และมีอัจฉริยะมากมาย นักพัฒนาชาวเกาหลีก็สู้ๆ แล้วลองสร้างอะไรเจ๋งๆ แบบนี้ออกมาเผยแพร่กันบ้างเถอะ

แถบนั้นก็มีแต่คนเยอะเหมือนกัน แต่สิ่งที่ทำไม่ว่าจะที่นี่หรือที่นั่นก็พอๆ กัน 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

king - man + woman = queen

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

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

โดน Komoot เล่นงาน

Namuwiki...

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

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

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

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

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

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