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

เป็นแนวทางการเพิ่มประสิทธิภาพที่ไม่อิง 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++ ก็ทำได้หมดแล้ว’

เป็นความจริงที่เฟรมเวิร์ก SPA ในปัจจุบันและเทรนด์ฟรอนต์เอนด์ที่อิงกับมัน จำเป็นต้องระวังการกลายเป็นสิ่งที่ไม่เป็นมาตรฐานอยู่เสมอ อีกทั้งยังเอื้อต่อการทำเกินความจำเป็นและการใช้ทรัพยากรโดยไม่จำเป็นได้ง่ายด้วย แต่…

ผมคิดว่ามีการมองแนวคิดของ SPA แคบเกินไป และยิ่งไปกว่านั้นก็อดสงสัยไม่ได้ว่าเข้าใจกันจริงหรือไม่ว่าเฟรมเวิร์ก SPA ส่งผลต่อภาพรวมของการพัฒนาอย่างไร

การบอกว่าแค่มี CSS กับ View Transition API อย่างเดียวก็ทำได้หมดนั้น ถ้าพูดอีกแบบก็คือฟังก์ชันทั้งหมดที่ไม่เกี่ยวกับสิ่งนั้น รวมถึงพาราไดม์ที่ใช้เพื่อทำให้มันเกิดขึ้น ล้วนไม่มีความหมายไปทั้งหมด ซึ่งผมคิดว่าเป็นมุมมองที่หยิ่งผยองเกินไปหน่อย

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

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

ดีจังที่ได้อ่านประเด็นชวนคิดหลายอย่างจากการทำงานกับการค้นหาแบบเวกเตอร์

เท่าที่ทราบ ถ้าจะใช้ใน Kotlin อาจมีปัญหาด้านประสิทธิภาพเพราะ primitive จะถูกห่อด้วย wrapper ทำให้ถูกเก็บบน heap แทนที่จะเป็น stack ได้ แน่นอนว่าในกรณีการใช้งานส่วนใหญ่ ความง่ายในการบำรุงรักษามักมาก่อน นอกจากนี้ยังสามารถใช้ value class เพื่อลดปัญหาด้านประสิทธิภาพให้เหลือน้อยที่สุดได้

สำหรับคนที่สนใจ ตั๋วติดตามการรองรับ rust: https://github.com/android/ndk/issues/1742

ถ้ามีอะไรแบบนี้ใน C++ ด้วยก็คงดีนะ!

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

น่าจะไม่ต้องเสียค่าใช้จ่าย เพราะรันบนเครื่องตัวเอง

จะให้จ่ายเดือนละ $20 ~ $200 เพื่อเรื่องนี้ก็ดูจะ...

ขณะเดียวกัน Pass:

อืม...^^;;; ผมพลาดเองครับ.. คราวหน้าจะตรวจทานให้มากกว่านี้ก่อนแล้วค่อยโพสต์ครับ..

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

> จะให้ผมสรุปฉบับนี้แยกเป็นเอกสารอีกชุดในรูปแบบ รายงานสรุป PDF (ภาพรวมสรุป-บทนำ-เนื้อหา-บทสรุป) ไหม?

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

ดูเหมือนว่าเรื่องความแม่นยำและความรู้สึกเป็นเจ้าของที่ลดลงจะเป็นเรื่องจริงนะครับ

แม้แต่สรุปย่อก็ยังเป็น llm..

เข้าใจแล้ว ขอบคุณ