การพัฒนาที่ยึด JavaScript มากเกินไป กำลังทำลายเว็บ

 (jonoalderson.com)
19 คะแนน โดย baeba 2025-07-11 | 23 ความคิดเห็น | แชร์ทาง WhatsApp

สรุปภาพรวม

การพัฒนาที่ยึด JavaScript มากเกินไป กำลังทำลายเว็บ

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

บทนำ

ปัญหาของเว็บที่ขับเคลื่อนด้วยมุมมองของนักพัฒนา

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

เนื้อหา

ต้นเหตุคือความอยากให้เว็บดูเหมือนแอป

  • หลังยุค 2010 ความต้องการ “เว็บที่เหมือนแอป” เพิ่มขึ้นพร้อมกับกระแสแอปมือถือ
  • เมื่อมีการนำ JS framework อย่าง Angular มาใช้ ความซับซ้อนก็พุ่งสูงขึ้น
  • แม้แต่คอนเทนต์ธรรมดาก็ถูกพัฒนาเหมือนเป็นระบบขนาดใหญ่

วัฒนธรรมที่ให้ความสำคัญกับประสบการณ์นักพัฒนา (DX) ก่อน

  • framework สมัยใหม่เน้นความสะดวกของนักพัฒนา
  • การทำ abstraction ของ component ทำให้เกิดช่องว่างกับ UX
  • คำถามอย่าง “ทำไมบล็อกถึงต้องใช้ React” กลับถูกกลบด้วยการถกเรื่องความเข้ากันได้กับ SSR

โลกความจริงที่ความซับซ้อนกลายเป็นมาตรฐาน

  • แม้งานง่าย ๆ ก็ยังต้องมีโครงสร้างหลายชั้น เช่น build, routing, API, cache
  • เพราะ stack ที่ซับซ้อน คนที่ไม่ใช่นักพัฒนาจึงแก้ไขคอนเทนต์เองไม่ได้
  • เทคโนโลยีเปลี่ยนเร็วเกินไปจนดูแลรักษาได้ยาก

ผลเสียจากการใช้ framework เกินพอดี

  • กำลังสร้างความสามารถดั้งเดิมของเว็บอย่าง SSR, cache, metadata ขึ้นมาใหม่
  • ประสิทธิภาพต่ำลง แต่ dependency กลับเพิ่มขึ้น
  • ผลลัพธ์คือเกิดความย้อนแย้งที่นำ JS framework มาสร้าง CMS ขึ้นมาใหม่

การทำซ้ำที่ไร้ความหมายและต้นทุนที่เพิ่มขึ้น

  • มีการนำ framework มาใช้แล้วเลิกใช้อยู่ซ้ำ ๆ จนไม่มีโครงสร้างที่มั่นคง
  • แทนที่จะโฟกัสการแก้ปัญหาของผู้ใช้จริง กลับไปโฟกัสการแก้ความซับซ้อนภายใน
  • content marketing, SEO และการทดลองต่าง ๆ ล่าช้า ขณะที่ประสบการณ์ผู้ใช้กลับแย่ลง

ผู้ใช้และนักการตลาดได้รับผลกระทบจากการใช้ JS มากเกินไป

  • การแก้ไขคอนเทนต์ต้องอาศัยนักพัฒนาเข้ามาเกี่ยวข้อง
  • SEO และคุณภาพของหน้าเว็บลดลง
  • ผู้ใช้ต้องเจอกับความไม่สะดวกมากขึ้น เช่น โหลดช้า หรือ interaction ผิดพลาด

JS เป็นเพียงเครื่องมือ ไม่ใช่เป้าหมาย

  • JS เป็นเครื่องมือที่ทรงพลัง แต่สำหรับเว็บไซต์ส่วนใหญ่ถือว่าเกินความจำเป็น
  • สำหรับคอนเทนต์แบบ static ใช้แค่ HTML, CSS และ JS เล็กน้อยก็เพียงพอ
  • Vanilla JS, server rendering และ script เท่าที่จำเป็น มีประสิทธิภาพมากกว่า

การรวมศูนย์อำนาจและปัญหาเชิงโครงสร้าง

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

บทสรุป

ทางออกคือการฟื้นคืนแก่นแท้ของเว็บ

  • เราต้องการเว็บไซต์ที่โหลดเร็ว ค้นหาเจอ และดูแลรักษาง่าย
  • คำตอบคือการกลับไปสู่พื้นฐาน เช่น HTML ที่ render จาก server, semantic markup และ JS ให้น้อยที่สุด
  • จำเป็นต้องมีแนวทางที่ยึดผลลัพธ์มากกว่าเทคโนโลยี
  • ต้องตั้งคำถามว่า “ทำไมเราจึงใช้เทคโนโลยีนี้?”
  • เว็บที่เรียบง่ายและยึดผู้ใช้เป็นศูนย์กลาง คือสิ่งที่จะให้ทั้งประสิทธิภาพ การลดต้นทุน และความยืดหยุ่น

บทความที่เกี่ยวข้อง

23 ความคิดเห็น

 
ws0051 2025-07-23

ดูแค่ WordPress ก็เหมือนจะเป็นคำตอบของปัญหาข้างต้นแล้ว
ส่วนแบ่งตลาดของ WordPress ก็มากกว่ามาก แม้จะช้าก็ตาม ..
 
test831767639 2025-07-17

ผมคิดว่าถ้ามีผลการเบนช์มาร์กมาเป็นหลักฐาน นักพัฒนาน่าจะเห็นด้วยได้มากกว่า ถ้ามีการเขียนโค้ดด้วยเฟรมเวิร์กมากเกินไป เว็บไซต์ก็น่าจะช้าลงอย่างแน่นอน แต่โดยส่วนตัวแล้ว ในแง่ของการเปลี่ยนหน้าภายในเว็บไซต์ ผมกลับเห็นเว็บไซต์ที่ทำด้วยโค้ดวานิลลาช้ากว่าเว็บไซต์ที่ใช้เฟรมเวิร์กแต่ปรับแต่งมาอย่างดีอยู่บ่อยกว่า แน่นอนว่าถ้าเป็นเว็บไซต์ที่มีแต่ข้อมูลแบบสแตติก การมีแค่ HTML + CSS อาจจะเร็วกว่า แต่ผมก็ไม่แน่ใจว่าในยุคนี้เว็บไซต์ที่มีแต่ข้อมูลแบบสแตติกจะยังพบได้บ่อยแค่ไหน
 
dnflajt3 2025-07-16

ถ้าไม่มีอย่าง React หรือ Vue
ต่อให้ทำฟังก์ชันเดียวกัน ก็ต้องเขียนโค้ดให้ซับซ้อนขึ้นไม่ใช่เหรอ?
โดยเฉพาะตอนจัดการป๊อปอัป แค่ส่ง props ตัวเดียว ถ้าทำด้วย JavaScript ล้วน โค้ดก็ซับซ้อนขึ้นมาก
แค่ทำอะไรที่ง่ายขนาดนี้ โค้ดยังซับซ้อน
ถ้าเป็นฟังก์ชันที่ซับซ้อนจริง ๆ ก็ยิ่งทำได้ยากขึ้น
 
slowandsnow 2025-07-15

มันเป็นความซับซ้อนที่หลีกเลี่ยงไม่ได้ ไม่ใช่ HTML เทมเพลตแบบเรียบง่ายเหมือนในอดีตอีกต่อไป
 
ahwjdekf 2025-07-12

เบราว์เซอร์ที่คนใช้กันจริง ๆ ก็มีอยู่ไม่กี่เจ้า แต่ทำไมเฟรมเวิร์กถึงมีมากขนาดนี้กันนะ ทางบริษัทที่ดูแลเบราว์เซอร์น่าจะช่วยกันสร้างเฟรมเวิร์กที่เหมาะสมที่สุดขึ้นมาแล้วดูแลไปด้วยกัน แบบนั้นไม่ใช่ทางออกที่ดีที่สุดหรือครับ จะปล่อยให้วงจรอุบาทว์นี้วนซ้ำไปถึงเมื่อไรกัน
 
spp00 2025-07-12

เพราะปรัชญาการพัฒนาที่แต่ละคนยึดถือนั้นแตกต่างกันอย่างมากนี่แหละครับ.........
 
lastiverse 2025-07-12

ผมเห็นด้วยกับการวิเคราะห์ปรากฏการณ์ แต่ไม่เห็นด้วยกับข้อสรุป

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

จริง ๆ แล้ว จุดกำเนิดของเว็บเองก็เป็นแพลตฟอร์มที่สร้างขึ้นมาเพื่อแชร์ "เอกสาร" บางประเภทอย่างเช่นงานวิชาการ
แค่ดูองค์ประกอบพื้นฐานของ HTML ก็พอจะเห็นได้

จากนั้นก็มีเทคโนโลยีที่สามารถสร้างคอนเทนต์แบบไดนามิกได้อย่าง cgi เกิดขึ้น และเมื่อฝั่งเบราว์เซอร์เองก็เริ่มฝังภาษา scripting ไว้ ทำให้สามารถเพิ่มความไดนามิกให้กับผลลัพธ์ได้ การหลุดออกจาก "เว็บในฐานะเอกสาร" จึงเริ่มต้นขึ้น

ปัญหาคือ ตั้งแต่ช่วงแรกที่เริ่มหลุดออกมาจนถึงปัจจุบัน รากฐานของเว็บก็ยังคงเป็นระบบที่ตั้งอยู่บนฐานของ "เอกสาร" อยู่ดี
แน่นอนว่าได้มีเทคโนโลยีใหม่ ๆ อย่าง web socket, webrtc, wasm ที่ออกห่างจากแนวทางแบบ "เอกสาร" มากขึ้น แต่จนถึงตอนนี้ เว็บไซต์ส่วนใหญ่ก็ยังคงพัฒนาบนแพลตฟอร์มแบบเดิมที่อิงกับ "เอกสาร" เป็นหลัก
ทุกวันนี้เราก็ยังต้องซ้อนแท็ก div กันเพื่อวาดหน้าจออยู่ดี

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

(ไม่ได้หมายความว่าทุกเว็บไซต์ต้องเป็นแบบนี้ แต่จำกัดเฉพาะเว็บที่มีลักษณะเป็นแอปพลิเคชัน)
ก่อนอื่น เบราว์เซอร์จะกลายเป็นตัวเปิดแอปประเภทหนึ่ง
เมื่อดาวน์โหลดไว้ครั้งหนึ่งแล้ว ก็ควรจะสามารถรันแบบออฟไลน์ได้
และตัวแอปเองก็จะถูกพัฒนาด้วยภาษาอื่น แทนที่จะยึดติดกับ html/css/js แบบเดิม
ในกระบวนการนั้น เบราว์เซอร์อาจให้เฟรมเวิร์กบางอย่างเหมือนกับ Android ก็ได้
รูปแบบการสื่อสารกับเซิร์ฟเวอร์ก็น่าจะหลุดออกจากคำขอแบบ web เดิม ๆ ไปใช้พาราไดม์อื่นได้
ถ้าเป็นการสื่อสารที่ต้องการความเป็นเรียลไทม์ ก็อาจใช้การสื่อสาร tcp แบบเดิมตรง ๆ ได้อยู่แล้ว
หรือจะสร้างการสื่อสารแบบ rpc ที่เรียบง่ายกว่าและไม่ใช้โปรโตคอล http ขึ้นมาใหม่เพื่อใช้งานก็ยังได้เหมือนกัน
 
techiemann 2025-07-13

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

สุดท้ายแล้วก็เป็นเรื่องยุคที่ต้องดาวน์โหลดโปรแกรมเนทีฟมาใช้ แล้วใช้ ActiveX บนนั้นนั่นเองครับ
 
lastiverse 2025-07-13

แก่นของปัญหาก็คือการพยายามฝืนสร้างเว็บให้มีลักษณะเหมือนแอปภายในโปรโตคอล HTTP ที่มีพื้นฐานอยู่บน "เอกสาร" ของเว็บ
และจึงมีความเห็นว่าถ้าต้องการความสามารถระดับแอปเพื่อแก้ปัญหานี้ ก็น่าจะสร้างโปรโตคอลและเฟรมเวิร์กใหม่สำหรับแอปไปเลยจะดีกว่า
เหมือนกับที่บนสมาร์ตโฟนไม่ได้รันโปรแกรมเนทีฟล้วน ๆ โดยตรง แต่รันแอปที่ถูกแซนด์บ็อกซ์ไว้รูปแบบหนึ่ง ซึ่งในกรณีนี้ก็คือโครงสร้างที่ทำงานอยู่ในระดับเบราว์เซอร์
แน่นอนว่าเพื่อไม่ให้จบลงแบบ ActiveX ก็ต้องมีความเปิดกว้างและการทำให้เป็นมาตรฐานนำหน้าก่อน
 
spp00 2025-07-12

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

จริง ๆ ก็ไม่ใช่ว่าจะไม่มีเฟรมเวิร์กที่ทำแบบนั้นได้ อย่าง Next.js เอง ถ้าลดการใช้ client component ให้เหลือเฉพาะตอนที่จำเป็น ก็พอทำได้ประมาณหนึ่ง และอย่างฝั่ง Rails ที่อีกท่านพูดถึงก็มี Hotwire(https://hotwired.dev/) ซึ่งเป็นชุดเฟรมเวิร์กที่รองรับเว็บแบบแอป (เช่น Turbo, Stimulus เป็นต้น) ให้เข้าใกล้ข้อสรุปที่ผู้เขียนพูดถึงได้มากทีเดียว
 
kunggom 2025-07-12

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

ตัวอย่างเช่น เว็บไซต์สำหรับประชาสัมพันธ์บริการหนึ่งที่บริษัทของเราดูแลอยู่ ก็ยังคงรักษาความเรียบง่ายแบบเดียวกับที่บทความนี้ยกย่องไว้ โชคดีที่เว็บไซต์นี้มีองค์ประกอบส่วนใหญ่ค่อนข้างเป็นแบบสแตติก โค้ดฝั่งฟรอนต์เอนด์อย่าง HTML และ CSS เขียนด้วยมือทั้งหมดโดยไม่ใช้เฟรมเวิร์กใด ๆ และ JS ก็มีเพียง jQuery กับ Google Analytics เท่านั้น ส่วนประกาศหรือบอร์ดต่าง ๆ นั้นทำด้วย AJAX โดยใช้ jQuery แต่ผมก็ไม่คิดว่ามันจะไร้เหตุผลหรือซับซ้อนเกินไป ผมมองว่ามันอยู่ในระดับที่ตอนผมเริ่มเรียนรู้การพัฒนาเว็บพื้นฐานเมื่อหลายปีก่อนก็สามารถทำด้วย jQuery ได้ เท่าที่ผมทราบ เว็บไซต์นี้เปิดให้บริการมาตั้งแต่ยุค Internet Explorer จึงไม่ใช่สิ่งที่ผมสร้างขึ้นเอง แต่ผมก็คิดว่ามันไม่ได้แย่อะไร

อย่างไรก็ตาม ที่นี่มี Git สำหรับจัดการเวอร์ชันและมี CI/CD pipeline รวมถึงแยก staging server ออกจาก production server จริงไว้ด้วย เมื่อ Pull Request ถูก merge เข้า branch Main แล้ว pipeline จะรัน bundler และ deploy ผลลัพธ์ไปยัง staging server โดยอัตโนมัติ จากนั้นเมื่อผู้รับผิดชอบตรวจสอบ staging server และอนุมัติการ deploy ขั้นสุดท้ายแล้ว จึงจะถูก deploy ไปยัง production server อีกทอดหนึ่ง แต่ก่อนเราใช้วิธีเขียนทับไฟล์ต้นฉบับลงบน production server โดยตรงผ่าน FTP และหลังจากงานที่เกี่ยวข้องถูกโอนมายังทีมเรา เราก็เปลี่ยนมาเป็นแบบนี้

แบบนี้ถือเป็นความซับซ้อนที่ไร้เหตุผลจริงหรือ? ในอดีต การแก้ไข title tag ของเว็บไซต์นั้นเป็นงานที่จบได้ด้วยการเปิด AcroEdit ที่รองรับการเชื่อมต่อ FTP (ใช่ครับ คนที่เคยเขียน HTML ของเว็บนี้โดยตรงแต่แรกยังคงใช้อยู่แบบนั้น) เข้าไปที่ไฟล์ HTML บน production server แก้เพียงหนึ่งบรรทัดแล้วกดบันทึก ทุกอย่างก็เสร็จสิ้น ดังนั้นคนกลุ่มนั้นอาจจะรู้สึกเช่นนั้นก็ได้

แต่ในมุมมองของผม การเพิ่มความซับซ้อนระดับนี้ถือว่าคุ้มค่าที่จะรับไว้ งานทุกอย่างไม่ได้มีระดับเดียวกับการแก้ title tag เพียงจุดเดียวเสมอไปไม่ใช่หรือ และการที่โค้ดเก่าซึ่งเคยถูกคอมเมนต์ทิ้งไว้รก ๆ สามารถลบออกได้อย่างไม่ต้องกังวลเพราะย้อนกลับได้ตลอดเวลา การติดตามความเปลี่ยนแปลงอย่างโปร่งใสและการ rollback ที่ทำได้ รวมถึงการที่ bundler สามารถเพิ่มการปรับแต่งพื้นฐานบางอย่างได้หากจำเป็น ล้วนเป็นข้อดีที่ชัดเจนในความเห็นของผม การเพิ่ม staging server เพื่อดูตัวอย่างก่อน deploy สู่สภาพแวดล้อมจริงก็อาจถูกมองว่าเป็นความซับซ้อนเช่นกัน แต่ผมคิดว่าสิ่งนี้จำเป็น

ผมเองก็ไม่พอใจมากกับการที่โครงสร้างโค้ดภายในของเว็บไซต์ต่าง ๆ ซับซ้อนและหนักเกินไป ทุกวันนี้แอป Outlook บน Windows เป็นแอปที่ทำบนพื้นฐานของเว็บแอป และช่วงหลังมานี้ยิ่งหนักขึ้นเป็นพิเศษ แค่พิมพ์เนื้อหาอีเมลบนหน้าจอหรือเลือกข้อความทั้งหมดในเนื้อหา ก็หน่วงจนสะดุด หรือถึงขั้นขึ้นว่า "หน้านี้ไม่ตอบสนอง" เลยด้วยซ้ำ ผมสงสัยว่ามันเกิดอะไรขึ้น เลยเปิด Developer Tools ใน Outlook เวอร์ชันเว็บดู แล้วก็ตกใจมาก พอล้างแคชแล้วรีเฟรช กลับพบว่าผ่านไป 1 นาทีก็ยังมี request อะไรสักอย่างวิ่งอยู่เรื่อย ๆ เมื่อตรวจดูในเบราว์เซอร์ก็พบว่ามีการเก็บข้อมูลไว้หลายกิกะไบต์เฉพาะที่เกี่ยวกับเว็บไซต์ของ MS Office เท่านั้น

อย่างไรก็ตาม บทความนี้ปะปนหลายประเด็นเข้าด้วยกัน บางส่วนผมเห็นด้วย แต่บางส่วนก็ไม่ค่อยเห็นด้วย เรื่อง semantic HTML หรือ accessibility นั้น เท่าที่ผมรู้ อดีตกลับแย่กว่านี้เสียอีก นอกจากนี้ ประเด็นที่ว่าการพัฒนาเพื่อให้ developer experience ดีขึ้นกลับทำให้ user experience แย่ลงนั้น ผมไม่รู้ว่าเพราะผมไม่ใช่นักพัฒนาเว็บฟรอนต์เอนด์หรือเปล่า แต่ผมไม่รู้สึกเห็นด้วยเลย แม้กระทั่งคำกล่าวที่ว่าทุกอำนาจและการควบคุมไปรวมศูนย์อยู่ที่นักพัฒนาก็ดูเป็นคำพูดเกินจริง ในบริษัท อำนาจอยู่ที่ฝ่ายบริหารไม่ใช่หรือ? หรือว่าในโลกตะวันตกโครงสร้างบริษัทแตกต่างจากเกาหลีมากขนาดนั้น?

อย่างที่เป็นอยู่เสมอ ผมเห็นด้วยอย่างยิ่งว่าความสมดุลและความพอดี รวมถึงความเรียบง่ายและการใช้งานได้จริง เป็นคุณค่าที่สำคัญและควรให้ความสำคัญเป็นอันดับแรกในการตัดสินใจ แต่บทความนี้กลับเหมือนพยายามชี้ว่า "การปฏิบัติต่อทุกเว็บไซต์เหมือนเป็นผลิตภัณฑ์ซอฟต์แวร์" เป็นความรับผิดชอบของนักพัฒนาแต่ฝ่ายเดียว ซึ่งผมคิดว่าจุดนี้กลับทำให้ประเด็นปัญหาพื้นฐานพร่ามัวลง อีกทั้งส่วนที่ดูเหมือนยกย่อง "ยุคเก่าที่ดี" ซึ่งในความเป็นจริงยังไม่มีระบบระเบียบ ก็น่าจะเป็นสิ่งที่ควรถูกวิจารณ์มากกว่า
 
techiemann 2025-07-13

มันเป็นคนละประเด็นกับที่คุณกำลังพูดถึงโดยสิ้นเชิงไม่ใช่หรือ?
 
kunggom 2025-07-14

คุณคิดว่าตรงไหนที่เป็นคนละเรื่องกันโดยสิ้นเชิงหรือครับ?
ท้ายที่สุด ผมคิดว่าสิ่งที่บทความนี้วิจารณ์ก็คือความซับซ้อนที่มากเกินไปและการบวมพองที่เกิดตามมา เพียงเพราะผมไม่ได้พูดถึง JavaScript ในความเห็นของผม ผมก็ไม่คิดว่านั่นจะทำให้มันกลายเป็นความเห็นที่ไม่เกี่ยวข้องกันโดยสิ้นเชิง อย่างไรเสีย มันก็เป็นการวิจารณ์ในประเด็นย่อยเช่นกัน และอย่างที่ผมพูดไว้ตั้งแต่ต้นในความเห็นของผม ผมเองก็เห็นด้วยกับสำนึกเชิงประเด็นพื้นฐานของบทความต้นฉบับอยู่แล้ว
 
techiemann 2025-07-14

ดูเหมือนว่าคุณจะเข้าใจเจตนาของบทความต้นฉบับผิดไปนะครับ

"...ในที่นี้มีทั้งการจัดการเวอร์ชันด้วย Git และ CI/CD pipeline แยก staging server กับ production server ออกจากกันไว้ เมื่อ Pull Request ถูกรวมเข้า branch หลัก pipeline ก็จะนำผลลัพธ์ที่ได้จากการรัน bundler ไป deploy ไปยัง staging server โดยอัตโนมัติ และหลังจากผู้รับผิดชอบตรวจสอบ staging server แล้วอนุมัติการ deploy ขั้นสุดท้าย ระบบก็จะ deploy ไปยัง production server อีกที เดิมทีนั้นใช้วิธีอัปโหลดทับไฟล์ต้นฉบับบน production server โดยตรงผ่าน FTP แต่หลังจากงานที่เกี่ยวข้องย้ายมาอยู่กับทีมของเรา ก็ได้เปลี่ยนมาเป็นแบบนี้

นี่คือความซับซ้อนที่ไร้เหตุผลจริง ๆ เหรอ?"

คุณพูดแบบนี้ แต่ผมคิดว่ามันเป็นคนละประเด็นกับบทความนี้พอสมควร งานในระดับการ deploy และการจัดการแบบนั้น กับสิ่งที่บทความนี้พยายามจะสื่อนั้นดูแตกต่างกันมากครับ
 
kunggom 2025-07-14

เจตนาของบทความต้นฉบับไม่ได้มีไว้เพื่อวิจารณ์แค่เพียง 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 และอะไรจะถูกลดลำดับความสำคัญออกไปอย่างไม่มีกำหนด และยิ่งพวกเขาเพิ่มความซับซ้อนมากเท่าไร พวกเขาก็ยิ่งกลายเป็นสิ่งที่ขาดไม่ได้มากขึ้นเท่านั้น
 
spp00 2025-07-12

ต่างจากวัฒนธรรมการพัฒนาในเกาหลีที่งานไหลลงมาตามสายจากผู้บริหาร -> นักวางแผน -> นักพัฒนา ในโลกตะวันตกไม่มีแนวคิดเรื่องนักวางแผนแบบเกาหลี และนักพัฒนามักมีส่วนร่วมอย่างจริงจังกับการวางแผนผลิตภัณฑ์ด้วย บทบาทอย่าง PM ในตะวันตกเองก็ไม่ได้ตรงกับนักวางแผนของเกาหลีแบบสมบูรณ์ เช่นเดียวกับที่ cover letter กับจดหมายแนะนำตัวไม่ได้เป็นแนวคิดเดียวกันทั้งหมด แน่นอนว่าในกรณีของเกมซึ่งมีลักษณะเป็นโปรเจกต์เชิงสร้างสรรค์สูง และความสนุกกับเกมเพลย์เป็นสิ่งสำคัญ แม้ในตะวันตกจะมีโครงสร้างแนวราบมากกว่าเอเชีย แต่ก็ยังเป็นการไหลลงมาจากผู้กำกับไปสู่นักพัฒนาอยู่ดี
 
kunggom 2025-07-14

อ้อ มีความแตกต่างแบบนั้นนี่เอง
แต่ดูเหมือนว่าจะไม่ได้เกี่ยวข้องกับเนื้อหาข้างต้นมากนัก
 
eajrezz 2025-07-11

ใช้ Rails แล้วมีความสุข
 
spp00 2025-07-11

ผมเห็นด้วยกับใจความของบทความนี้ ทุกวันนี้มีการใช้ JS พร่ำเพรื่อเกินไป จนบ่อยครั้งที่แม้จะใช้ i9-9900k เว็บไซต์ก็ยังหน่วงอยู่ดี แม้จะเป็นสเปกที่ก้ำกึ่งสำหรับเล่นเกมหรือทำงาน แต่ความจริงก็คือยังมีคอมพิวเตอร์สำนักงานที่สเปกต่ำกว่านี้อยู่อีกมาก

เพราะงั้นผมจึงชอบ Astro และ hotwired ซึ่งเป็นเฟรมเวิร์กที่มีแนวคิดว่าให้ใช้ JS เฉพาะตอนที่จำเป็นจริง ๆ เช่น ส่วนที่ต้องโต้ตอบหรือการนำทางหน้าแบบโต้ตอบ ผมยังชอบ server-side rendering ที่ให้เรนเดอร์จากฝั่งเซิร์ฟเวอร์ด้วย ในทางกลับกันผมไม่ชอบ CSR อย่างมาก (รวมถึงกรณีที่เรนเดอร์แค่เมตาแท็กจากฝั่งเซิร์ฟเวอร์ แล้วให้ส่วนที่เหลือจัดการด้วย CSR) เพราะมองว่าเป็นการผลักภาระงานที่เซิร์ฟเวอร์ควรทำไปให้ไคลเอนต์รับแทน ส่วนตัวผมคิดว่าวิธี SPA แบบดั้งเดิมที่ใช้ CSR ควรใช้ตอนรันฟรอนต์เอนด์แบบโลคัลในแอปอย่าง Electron มากกว่า แน่นอนว่าถ้าโหลดฟรอนต์เอนด์จากเซิร์ฟเวอร์ก็ควรใช้ SSR ครับ
 
baeba 2025-07-11

ด้านล่างนี้คือสรุปที่จัดหมวดหมู่ปฏิกิริยาในคอมเมนต์ต่อโพสต์ออกเป็น 5 ประเภท:

1. เห็นด้วยและสนับสนุนอย่างเต็มที่

  • ลักษณะสำคัญ: เห็นด้วยกับข้อโต้แย้งในบทความอย่างมาก และยอมรับปัญหาของสแตก JS ที่ซับซ้อน

  • ตัวอย่างความเห็น:

    • “ในที่สุดก็มีคนพูดสิ่งที่ควรพูดเสียที”
    • “นี่เป็นบทความที่ยอดเยี่ยมและมองความจริงตรงไปตรงมา”
    • “ประสิทธิภาพเว็บและการเข้าถึงเป็นสิ่งจำเป็น”

2. กังวลต่อการใช้เฟรมเวิร์กมากเกินไป

  • ลักษณะสำคัญ: วิจารณ์การใช้เฟรมเวิร์กอย่าง React, Angular มากเกินจำเป็น และมองว่าเทคโนโลยีที่เรียบง่ายก็เพียงพอแล้ว

  • ตัวอย่างความเห็น:

    • “React ไม่จำเป็นสำหรับบล็อก”
    • “Vanilla JS แก้ปัญหาได้เกือบทั้งหมด”
    • “ทางเลือกที่เบากว่าอย่าง Svelte, Eleventy ดีกว่า”

3. เห็นด้วยบางส่วน + คำนึงถึงความเป็นจริง

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

  • ตัวอย่างความเห็น:

    • “ความซับซ้อนคือปัญหา แต่ในบางสถานการณ์ก็หลีกเลี่ยงไม่ได้”
    • “สำหรับการทำงานร่วมกันและการบำรุงรักษา เฟรมเวิร์กก็ยังจำเป็น”
    • “HTML/CSS เองก็ยังไม่สมบูรณ์ เลยจำเป็นต้องใช้ JS”

4. วิจารณ์วัฒนธรรมการพัฒนาและโครงสร้างอุตสาหกรรม

  • ลักษณะสำคัญ: ชี้ว่าการใช้เฟรมเวิร์กมากเกินไปไม่ใช่แค่ปัญหาทางเทคนิค แต่เป็นผลผลิตของโครงสร้างด้านการจ้างงาน วัฒนธรรม และการตลาด

  • ตัวอย่างความเห็น:

    • “เฟรมเวิร์กกลายเป็นทักษะไว้ใส่ในเรซูเม่”
    • “นักพัฒนาก็แค่ทำตามสิ่งที่บริษัทต้องการ”
    • “นี่คือปัญหาของวัฒนธรรมองค์กรและตลาดแรงงาน”

5. วิจารณ์หรือคัดค้าน

  • ลักษณะสำคัญ: ไม่เห็นด้วยกับสมมติฐานของบทความ หรือวิจารณ์ว่ามันเป็นข้อโต้แย้งด้านเดียวเกินไป

  • ตัวอย่างความเห็น:

    • “ไม่มีหลักฐานว่าเว็บช้าลง”
    • “บทความนี้ลำเอียงเกินไป”
    • “การแก้ปัญหา JS ด้วย WordPress กลับเป็นการถอยหลังมากกว่า”
 
dlehals2 2025-07-11

โอ แบ่งตามประเภทแบบนี้แล้วดูง่ายดี ชอบเลย
 
slidingv 2025-07-14

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

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

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

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

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

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

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

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

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

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

ฉบับแปลภาษาเกาหลีอยู่ด้านล่าง
https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…