นี่คือสิ่งที่ผมกำลังทำอยู่พอดีเพราะต้องการมันมาก แล้วเขาก็ทำออกมาให้เลย... ผมใช้ Claude Code Max อยู่ และนี่คือซอฟต์แวร์ที่จำเป็นมากจริง ๆ ตอนที่ต้องพัฒนาหลายโปรเจ็กต์พร้อมกันในครั้งเดียว

สุขสันต์วันเกิด Django!

ฉบับแปลภาษาเกาหลีอยู่ด้านล่าง
https://roy-jung.github.io/250701-history-of-js/

อยากให้แสดงออกมาเป็นตัวเลขว่าดีขึ้นมากแค่ไหน ยอดเยี่ยมแค่ไหน และแม่นยำแค่ไหนนะครับ

เกาหลีใต้จะแตกต่างอย่างไรนะ

ผมเห็นด้วยกับประเด็น ปัญหาการสิ้นเปลืองพื้นที่ดิสก์ อยู่ไม่น้อยเลยครับ...
ผมดูแล AKS อยู่ แล้วทุกครั้งที่เห็นแอป Python ที่มีขนาดอิมเมจคอนเทนเนอร์เกิน 1GB ก็ปวดหัวมากครับ
ตอนนี้ก็แค่เอา Dockerfile มาปรับเองเพื่อลดขนาดแล้วอัปขึ้นไปใหม่ ถ้าลดให้ต่ำกว่า 500MB ไม่ได้ก็ยอมแพ้เลยครับ 555

ว้าว...! ตอนที่ใช้ครั้งแรก เป็นโปรเจกต์ที่ใช้เพราะเป็น Python...
เวลาผ่านไปนานเลยนะ!
ถ้าได้ทำงานในสภาพแวดล้อมที่สามารถกลับมาใช้อีกครั้งก็คงดี :) 555
หรือจะลองทำเป็นงานข้างดูดี...

ในจังหวะที่ Claude 4 ออกมาแล้ว การเอาไปเทียบกับ Claude 3 นี่แทบจะเข้าข่ายหลอกลวงไม่ใช่เหรอ...

ตั้งแต่ประมาณ 7:00 น. ตามเวลาเกาหลี มีการหยุดให้บริการอยู่ราว 50 นาที ตอนนี้กลับมาทำงานได้ตามปกติแล้ว
CMD> nslookup news.hada.io 1.1.1.1

ผมก็มีการแจ้งเตือนแบบพุชบน Android เด้งขึ้นมาเรื่อย ๆ ว่าไม่สามารถเข้าถึงเซิร์ฟเวอร์ DNS ได้
เลยย้ายไปใช้ Google DNS ชั่วคราวครับ
https://developers.google.com/speed/public-dns/…

ว้าว...

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

ขอบคุณที่ชื่นชอบบทความครับ!

ขอบคุณสำหรับคำพูดดี ๆ ครับ!

ถ้ามีเครื่องแรง ๆ ที่คุ้มราคาสักเครื่องก็น่าจะพอ? บริษัทกฎหมายที่โหด ๆ ก็คงซื้อมาใช้กันแหละ แต่ก็ต้องเปิดเครื่องเหมือนเดินเครื่องจักรในโรงงาน 24 ชั่วโมงเลย 555

คนหนึ่งที่คิดแค่ราคารถ Porsche แต่ไม่ได้คิดเรื่องค่าบำรุงรักษา ค่าน้ำมัน ประกัน ฯลฯ เลยแม้แต่นิดเดียว

เจตนาของบทความต้นฉบับไม่ได้มีไว้เพื่อวิจารณ์แค่เพียง JS framework ที่ซับซ้อนขึ้นเท่านั้น
เพื่อความสะดวก จะขออ้างอิงจากลิงก์ฉบับแปลภาษาเกาหลีด้านบน

ทุกวันนี้ แค่เปลี่ยนหัวข้อหนึ่งบรรทัดก็ยังต้องใช้วิศวกร 4 คน framework 3 ตัว และ CI/CD pipeline อีกหนึ่งชุด การเผยแพร่หน้าเว็บกลายเป็นเรื่องซับซ้อนอย่างผิดปกติ

และเว็บก็ค่อย ๆ กลายเป็นสิ่งที่ต้อง compile ก่อนเผยแพร่ ไม่ใช่เพราะผู้ใช้ต้องการ แต่เพราะนักพัฒนาต้องการให้มันดูทันสมัย

ทุกอย่างถูก optimize มาเพื่อนักพัฒนา และเป็นปฏิปักษ์กับคนอื่นทั้งหมด

เราไม่ได้แค่ทนรับความซับซ้อนอีกต่อไป แต่กลับมองว่ามันเป็นเรื่องปกติ เราสมมติว่า ทุกไซต์ต้องมี build step, bundler, hydration strategy, routing layer, API layer, design system และ logic การทำ cache invalidation แบบชาญฉลาด สร้างด้วย microservices, โฮสต์บน edge network และ deploy pipeline เพื่อส่งมอบคอนเทนต์ธรรมดา ๆ

เรากำลังสร้างความสามารถของแพลตฟอร์มอย่าง WordPress ขึ้นมาใหม่ แต่ได้ผลลัพธ์ที่หนักกว่าเดิม 10 เท่าและใช้งานได้แย่กว่ามาก ที่แย่กว่านั้นคือ ทุกเลเยอร์ใหม่จะนำบั๊กใหม่ ปัญหาความเข้ากันได้ใหม่ และภาระทางความคิดใหม่เข้ามา ตอนนี้เราเลยต้องคอยบำรุงรักษา hydration logic, cache strategy และ build pipeline เพียงเพื่อเอาโฮมเพจธรรมดาขึ้นออนไลน์

แคมเปญการตลาดล่าช้าเพราะ component library ยืดหยุ่นไม่พอ การทดสอบ A/B ถูกยกเลิกเพราะ analytics layer ไม่เข้ากับ hydration strategy การอัปเดตคอนเทนต์ต้องรอ build เป็นวัน ๆ ส่วนการปรับ SEO พื้นฐานก็ถูกกลบอยู่ใน backlog

นักการตลาดไม่สามารถอัปเดตข้อความโฆษณาหรือรันทดลองได้โดยไม่ส่ง ticket พวกเขาไม่สามารถพรีวิวคอนเทนต์ ทดสอบเลย์เอาต์ หรือเผยแพร่หน้าได้ การเปลี่ยนแปลงทุกอย่างต้องผ่านนักพัฒนา pipeline การอนุมัติ และการ rebuild

นักการตลาด บรรณาธิการคอนเทนต์ ผู้ดูแล SEO และนักออกแบบ ต่างถูกกันออกจากกระบวนการ เพราะแม้แต่งานง่าย ๆ ตอนนี้ก็ต้องอาศัยความชำนาญทางเทคนิค หากคุณอยากเปลี่ยน title tag ก็จะถูกบอกให้ไปคุยกับวิศวกร และถ้าอยากปล่อยแคมเปญ ก็ให้ส่ง ticket แล้วรออีกสองสปรินต์

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

น่าจะใช้กับบริษัทเกาหลีไม่ได้

ฉันเห็นด้วยกับประเด็นเรื่อง "ความซับซ้อนที่มากเกินไปของเว็บ" ที่บทความต้นฉบับชี้ไว้ แต่ยากจะเห็นด้วยกับการวินิจฉัยที่โยนสาเหตุไปให้แค่วัฒนธรรมนักพัฒนาหรือการใช้เฟรมเวิร์กเกินความจำเป็นเท่านั้น ความซับซ้อนของเว็บในปัจจุบัน ส่วนใหญ่มาจากฟังก์ชันและเงาด้านความปลอดภัยที่ "โมเดลธุรกิจ" เรียกร้องอย่างหลีกเลี่ยงไม่ได้ หากละประเด็นนี้ไป การวิเคราะห์ก็ย่อมได้เพียงครึ่งเดียวเท่านั้น。

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

เมื่อมองจากมุมนี้ "เว็บคอนเทนต์น้ำหนักเบา" ที่บทความต้นฉบับวาดภาพไว้ในเชิงอุดมคติ ย่อมชนเข้ากับกำแพงของความต้องการทางธุรกิจในโลกจริง ตัวอย่างเช่น ธุรกิจที่ขายคอนเทนต์ไม่สามารถดำเนินงานได้ด้วยหน้าเว็บแบบสแตติกอย่างเดียว หากต้องรองรับการสมัครสมาชิกแบบเสียเงินและการชำระเงิน ก็จำเป็นต้องมีตรรกะที่อิงสถานะ เช่น การยืนยันตัวตนผู้ใช้ การตรวจสอบสถานะสมาชิก และการจัดการสิทธิ์ อีกทั้งเพื่อปกป้องคอนเทนต์ ก็จำเป็นต้องมีชั้นความปลอดภัย เช่น การตรวจสอบโทเค็นแบบเรียลไทม์เพื่อป้องกันการคัดลอกเถื่อนหรือการเข้าถึงโดยไม่ได้รับอนุญาต นอกจากนี้ หากต้องการเพิ่มประสบการณ์ผู้ใช้และอัตรา conversion ผ่านการทำ personalization และ A/B testing ก็ยังต้องมีการประมวลผลข้อมูลแบบไดนามิกด้วย

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

แน่นอนว่าไม่ใช่ทุกความซับซ้อนที่จะอธิบายว่าชอบธรรมได้ เราควรแยกความซับซ้อนออกเป็นสองประเภท

• ความซับซ้อนที่หลีกเลี่ยงไม่ได้: เป็นความซับซ้อนที่เกิดขึ้นเพื่อสร้างฟังก์ชันทางธุรกิจ เช่น การยืนยันตัวตน การชำระเงิน และ personalization ซึ่งมี ROI ชัดเจน นี่คือต้นทุนที่ต้องยอมรับ

• ความซับซ้อนที่เกิดขึ้นโดยบังเอิญ: เป็นความซับซ้อนที่ไม่จำเป็นซึ่งเกิดจากความสะดวกในการพัฒนา หรือการทำ abstraction ทางเทคนิคมากเกินไป นี่คือหนี้ทางเทคนิคและความสูญเปล่าที่ต้องวัดผลและกำจัดอย่างต่อเนื่อง

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

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

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

บริการอย่างแชตบอตที่ต้องมีฟีเจอร์สตรีมมิง พอประมวลผลพร้อมกัน งาน Prefill จะส่งผลไปถึง decode ด้วย เลยทำให้ถึง VRAM จะเหลือเยอะ แต่ในมุมผู้ใช้กลับดูเหมือนประสิทธิภาพลดลงมากครับ

ผมลองใช้ทั้งออปชันที่เกี่ยวกับ chunk prefill และฟีเจอร์ Disaggregated Prefilling ที่ vLLM มีให้แบบทดลองแล้ว แต่พอมีคำขอใหม่เข้ามา ก็ยังเกิดอาการที่คำตอบซึ่งกำลังสร้างอยู่เดิมสะดุดเป็นช่วง ๆ อยู่ดี เลยอยากทราบว่าในมุมของนักพัฒนามือใหม่ นอกจากวิธีเพิ่ม GPU หรือเพิ่มโหนดแล้ว ยังมีวิธีที่มีประสิทธิภาพที่สุดอีกไหมครับ