เพราะดีลเข้าซื้อกิจการของ OpenAI ทำให้ Claude หยุดให้ไลเซนส์เวอร์ชันล่าสุด ดังนั้นถ้าจะใช้โมเดล Claude 4.x บน Windsurf ก็ต้องซื้อ API ตรงในราคาแพง ไม่ทราบว่า Claude จะกลับมาไหม?
ตัวอย่างเช่น เว็บไซต์สำหรับประชาสัมพันธ์บริการหนึ่งที่บริษัทของเราดูแลอยู่ ก็ยังคงรักษาความเรียบง่ายแบบเดียวกับที่บทความนี้ยกย่องไว้ โชคดีที่เว็บไซต์นี้มีองค์ประกอบส่วนใหญ่ค่อนข้างเป็นแบบสแตติก โค้ดฝั่งฟรอนต์เอนด์อย่าง 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 เท่านั้น
แม้จะเป็นเว็บที่มีลักษณะเหมือนแอป ผมก็คิดว่าควรมุ่งไปในทิศทางที่ใกล้เคียงกับข้อสรุปที่บทความกล่าวไว้ การใช้ JavaScript มาก ๆ จะทำให้ฝั่งไคลเอนต์หนักขึ้น
จริง ๆ ก็ไม่ใช่ว่าจะไม่มีเฟรมเวิร์กที่ทำแบบนั้นได้ อย่าง Next.js เอง ถ้าลดการใช้ client component ให้เหลือเฉพาะตอนที่จำเป็น ก็พอทำได้ประมาณหนึ่ง และอย่างฝั่ง Rails ที่อีกท่านพูดถึงก็มี Hotwire(https://hotwired.dev/) ซึ่งเป็นชุดเฟรมเวิร์กที่รองรับเว็บแบบแอป (เช่น Turbo, Stimulus เป็นต้น) ให้เข้าใกล้ข้อสรุปที่ผู้เขียนพูดถึงได้มากทีเดียว
เพราะดีลเข้าซื้อกิจการของ OpenAI ทำให้ Claude หยุดให้ไลเซนส์เวอร์ชันล่าสุด ดังนั้นถ้าจะใช้โมเดล Claude 4.x บน Windsurf ก็ต้องซื้อ API ตรงในราคาแพง ไม่ทราบว่า Claude จะกลับมาไหม?
ต่างจากวัฒนธรรมการพัฒนาในเกาหลีที่งานไหลลงมาตามสายจากผู้บริหาร -> นักวางแผน -> นักพัฒนา ในโลกตะวันตกไม่มีแนวคิดเรื่องนักวางแผนแบบเกาหลี และนักพัฒนามักมีส่วนร่วมอย่างจริงจังกับการวางแผนผลิตภัณฑ์ด้วย บทบาทอย่าง PM ในตะวันตกเองก็ไม่ได้ตรงกับนักวางแผนของเกาหลีแบบสมบูรณ์ เช่นเดียวกับที่ cover letter กับจดหมายแนะนำตัวไม่ได้เป็นแนวคิดเดียวกันทั้งหมด แน่นอนว่าในกรณีของเกมซึ่งมีลักษณะเป็นโปรเจกต์เชิงสร้างสรรค์สูง และความสนุกกับเกมเพลย์เป็นสิ่งสำคัญ แม้ในตะวันตกจะมีโครงสร้างแนวราบมากกว่าเอเชีย แต่ก็ยังเป็นการไหลลงมาจากผู้กำกับไปสู่นักพัฒนาอยู่ดี
เพราะปรัชญาการพัฒนาที่แต่ละคนยึดถือนั้นแตกต่างกันอย่างมากนี่แหละครับ.........
สมกับเป็น AI ที่ไม่เป็นธรรมเหมือนกันนะ
น่ากลัวมาก
เพราะอาจเกิดเหตุการณ์ที่บันทึกซึ่งถูกสร้างขึ้นอย่างมุ่งร้าย
เอาชนะความทรงจำและประสบการณ์ กลายเป็นหลักฐาน
และย้อนกลับมาคุกคามพวกเราได้
เบราว์เซอร์ที่คนใช้กันจริง ๆ ก็มีอยู่ไม่กี่เจ้า แต่ทำไมเฟรมเวิร์กถึงมีมากขนาดนี้กันนะ ทางบริษัทที่ดูแลเบราว์เซอร์น่าจะช่วยกันสร้างเฟรมเวิร์กที่เหมาะสมที่สุดขึ้นมาแล้วดูแลไปด้วยกัน แบบนั้นไม่ใช่ทางออกที่ดีที่สุดหรือครับ จะปล่อยให้วงจรอุบาทว์นี้วนซ้ำไปถึงเมื่อไรกัน
สงสัยว่าทำไมดีลถึงล่มครับ
รูปแบบสูงสุดของ AI ที่คอยประจบผู้ใช้ ที่แท้ก็คือ AI ที่คอยประจบเจ้านายนี่เอง...
ผมเห็นด้วยกับการวิเคราะห์ปรากฏการณ์ แต่ไม่เห็นด้วยกับข้อสรุป
อย่างที่ในบทความกล่าวไว้ สาเหตุเชิงผิวเผินของปรากฏการณ์นี้คือความต้องการต่อ "เว็บที่เหมือนแอป" เพิ่มมากขึ้น และไม่ว่าจะตอนนี้หรือในอดีต เว็บก็ไม่เคยเหมาะกับการสร้าง "อะไรบางอย่างที่เหมือนแอป" อยู่แล้ว แต่ผมคิดว่าถ้าฝืนทำกันเต็มที่ก็ยัง "พอทำให้คล้ายได้"
จริง ๆ แล้ว จุดกำเนิดของเว็บเองก็เป็นแพลตฟอร์มที่สร้างขึ้นมาเพื่อแชร์ "เอกสาร" บางประเภทอย่างเช่นงานวิชาการ
แค่ดูองค์ประกอบพื้นฐานของ HTML ก็พอจะเห็นได้
จากนั้นก็มีเทคโนโลยีที่สามารถสร้างคอนเทนต์แบบไดนามิกได้อย่าง cgi เกิดขึ้น และเมื่อฝั่งเบราว์เซอร์เองก็เริ่มฝังภาษา scripting ไว้ ทำให้สามารถเพิ่มความไดนามิกให้กับผลลัพธ์ได้ การหลุดออกจาก "เว็บในฐานะเอกสาร" จึงเริ่มต้นขึ้น
ปัญหาคือ ตั้งแต่ช่วงแรกที่เริ่มหลุดออกมาจนถึงปัจจุบัน รากฐานของเว็บก็ยังคงเป็นระบบที่ตั้งอยู่บนฐานของ "เอกสาร" อยู่ดี
แน่นอนว่าได้มีเทคโนโลยีใหม่ ๆ อย่าง web socket, webrtc, wasm ที่ออกห่างจากแนวทางแบบ "เอกสาร" มากขึ้น แต่จนถึงตอนนี้ เว็บไซต์ส่วนใหญ่ก็ยังคงพัฒนาบนแพลตฟอร์มแบบเดิมที่อิงกับ "เอกสาร" เป็นหลัก
ทุกวันนี้เราก็ยังต้องซ้อนแท็ก div กันเพื่อวาดหน้าจออยู่ดี
ถึงตรงนี้คือการวิเคราะห์ปรากฏการณ์ แล้วพอถามว่าคำตอบคืออะไร ผมก็ลองจินตนาการถึงความสามารถของแพลตฟอร์มถัดไปในอุดมคติโดยไม่สนความเป็นจริงเลย จะได้ประมาณนี้
(ไม่ได้หมายความว่าทุกเว็บไซต์ต้องเป็นแบบนี้ แต่จำกัดเฉพาะเว็บที่มีลักษณะเป็นแอปพลิเคชัน)
ก่อนอื่น เบราว์เซอร์จะกลายเป็นตัวเปิดแอปประเภทหนึ่ง
เมื่อดาวน์โหลดไว้ครั้งหนึ่งแล้ว ก็ควรจะสามารถรันแบบออฟไลน์ได้
และตัวแอปเองก็จะถูกพัฒนาด้วยภาษาอื่น แทนที่จะยึดติดกับ html/css/js แบบเดิม
ในกระบวนการนั้น เบราว์เซอร์อาจให้เฟรมเวิร์กบางอย่างเหมือนกับ Android ก็ได้
รูปแบบการสื่อสารกับเซิร์ฟเวอร์ก็น่าจะหลุดออกจากคำขอแบบ web เดิม ๆ ไปใช้พาราไดม์อื่นได้
ถ้าเป็นการสื่อสารที่ต้องการความเป็นเรียลไทม์ ก็อาจใช้การสื่อสาร tcp แบบเดิมตรง ๆ ได้อยู่แล้ว
หรือจะสร้างการสื่อสารแบบ rpc ที่เรียบง่ายกว่าและไม่ใช้โปรโตคอล http ขึ้นมาใหม่เพื่อใช้งานก็ยังได้เหมือนกัน
โอ้ แบบนี้ดูเหมือนว่าอนาคตของ Windsurf เองก็ไม่ได้สดใสนักเหมือนกันนะ
เมื่อหนึ่งเดือนก่อน ผมใช้ CURSOR เพื่อเรียนรู้ว่า AI coding คืออะไรไปด้วย และเริ่มพัฒนาเฟรมเวิร์กสำหรับการพัฒนาไปด้วย
ตลอดราว 3 สัปดาห์ ผมวนซ้ำอยู่กับความสำเร็จและการที่ซอร์สโค้ดซึ่งเคยได้รับการตรวจสอบโดย AI Agent กลับพังลง ผมพยายามทุกวิถีทางเพื่อควบคุม AI Agent แต่ก็ล้มเหลว
แล้วผมก็ตระหนักได้ว่า ก่อนจะพัฒนาเฟรมเวิร์กสำหรับการพัฒนา สิ่งที่ต้องมาก่อนคือการพัฒนาซอร์สโค้ดสำหรับควบคุม AI Agent
ท้ายที่สุด หลังจากเริ่มต้นเพราะอยากรู้ว่า AI ตัวแรกคืออะไรได้ครบ 1 เดือน ผมก็สามารถบรรลุผลสำเร็จในการพัฒนาซอฟต์แวร์ที่ AI สามารถทำได้ 100% + การดำเนินงานได้ 100% อย่างสมบูรณ์ภายใต้การควบคุม AI Agent อย่างสมบูรณ์ (หรือพูดให้แม่นยำคือไม่จำเป็นต้องใช้ external LLM หรือ AI Agent)
ตอนนี้เป็นวันที่ 14 แล้วของการเดินหน้าทำให้ก้าวหน้ายิ่งขึ้นเพิ่มเติม โดยกำลังฝึกสอน META AI ตัวนั้นเพิ่ม พร้อมทั้งสร้างกฎการปฏิบัติงานและให้มันปฏิบัติตาม และกำลังทำ migration, ปรับปรุง และทำมาตรฐานให้กับระบบ MES 3 ระบบที่เดิมมนุษย์เคยสร้างไว้แบบไม่สมบูรณ์ไปพร้อมกัน ซึ่งตอนนี้เข้าสู่ช่วงใกล้เสร็จสิ้นแล้ว
และตอนนี้ผมก็กำลังเตรียมวิวัฒนาการอีกขั้นหนึ่งอยู่
วิสัยทัศน์หลักของเทคโนโลยี MCP-B อาจมองได้ว่าเป็นดังนี้
"ผ่านตัวกลางที่เชื่อถือได้อย่าง Chrome Extension โดยใช้ข้อมูลผู้ใช้ที่เบราว์เซอร์จัดการไว้อย่างปลอดภัยอยู่แล้ว (คุกกี้, เซสชัน, การยืนยันตัวตน ฯลฯ)
เพื่อเรียกใช้และควบคุม 'เครื่องมือ (Tools)' ที่นักพัฒนากำหนดไว้ล่วงหน้าบนหน้าเว็บ จากหน้าต่างแชต AI ด้วยคำสั่งภาษาธรรมชาติ"
แต่ผมรู้สึกว่า "ดูไม่มีช่องทางที่จะขยายต่อได้" และคิดว่าเหตุผลมีดังนี้
หากความสะดวกที่เทคโนโลยีนี้มอบให้ไม่ได้เหนือกว่าความกังวลนั้นอย่างชัดเจน ผู้ใช้ก็จะลังเลที่จะติดตั้ง
หากประโยชน์ที่ได้จากการที่เทคโนโลยีนี้ถูกนำไปใช้อย่างแพร่หลายไม่ได้มากพอ นักพัฒนาก็คงไม่อยากทุ่มแรงซ้ำซ้อนโดยไม่จำเป็น
ความซับซ้อนลักษณะนี้ทำให้บริษัทต่าง ๆ ไม่อยากนำเทคโนโลยีมาใช้
สรุปคือ
แม้แนวคิดของ MCP-B เองจะน่าสนใจและมีนวัตกรรมอย่างมากในเชิงเทคนิค แต่ดูเหมือนว่าจะยังไม่สามารถให้คำตอบที่ชัดเจนต่อคำถามพื้นฐานสำหรับทั้งผู้ใช้และนักพัฒนาว่า "แล้วทำไมต้องใช้วิธีนี้ด้วย?" ได้ เมื่อเทียบกับแนวทาง API แบบเดิม ข้อดีที่ได้รับยังไม่ชัดเจน ขณะที่ข้อเสียอย่างความกังวลด้านความปลอดภัยและความซับซ้อนในการพัฒนากลับชัดเจน
ดังนั้น ในตอนนี้เทคโนโลยีนี้อาจถูกนำไปใช้เชิงทดลองในหมู่ผู้ที่ชื่นชอบเฉพาะทางหรือนักพัฒนาที่มีวัตถุประสงค์เฉพาะบางกลุ่มได้ แต่หากจะขยายไปสู่ระบบนิเวศเว็บโดยรวม ก็ดูเหมือนว่ายังมีอุปสรรคอยู่อีกมาก
ฉันเห็นด้วยกับประเด็นหลักของบทความนี้ แต่ก็มีบางส่วนที่ทำให้ต้องเอียงคอสงสัยอยู่บ้าง
ตัวอย่างเช่น เว็บไซต์สำหรับประชาสัมพันธ์บริการหนึ่งที่บริษัทของเราดูแลอยู่ ก็ยังคงรักษาความเรียบง่ายแบบเดียวกับที่บทความนี้ยกย่องไว้ โชคดีที่เว็บไซต์นี้มีองค์ประกอบส่วนใหญ่ค่อนข้างเป็นแบบสแตติก โค้ดฝั่งฟรอนต์เอนด์อย่าง 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 แย่ลงนั้น ผมไม่รู้ว่าเพราะผมไม่ใช่นักพัฒนาเว็บฟรอนต์เอนด์หรือเปล่า แต่ผมไม่รู้สึกเห็นด้วยเลย แม้กระทั่งคำกล่าวที่ว่าทุกอำนาจและการควบคุมไปรวมศูนย์อยู่ที่นักพัฒนาก็ดูเป็นคำพูดเกินจริง ในบริษัท อำนาจอยู่ที่ฝ่ายบริหารไม่ใช่หรือ? หรือว่าในโลกตะวันตกโครงสร้างบริษัทแตกต่างจากเกาหลีมากขนาดนั้น?
อย่างที่เป็นอยู่เสมอ ผมเห็นด้วยอย่างยิ่งว่าความสมดุลและความพอดี รวมถึงความเรียบง่ายและการใช้งานได้จริง เป็นคุณค่าที่สำคัญและควรให้ความสำคัญเป็นอันดับแรกในการตัดสินใจ แต่บทความนี้กลับเหมือนพยายามชี้ว่า "การปฏิบัติต่อทุกเว็บไซต์เหมือนเป็นผลิตภัณฑ์ซอฟต์แวร์" เป็นความรับผิดชอบของนักพัฒนาแต่ฝ่ายเดียว ซึ่งผมคิดว่าจุดนี้กลับทำให้ประเด็นปัญหาพื้นฐานพร่ามัวลง อีกทั้งส่วนที่ดูเหมือนยกย่อง "ยุคเก่าที่ดี" ซึ่งในความเป็นจริงยังไม่มีระบบระเบียบ ก็น่าจะเป็นสิ่งที่ควรถูกวิจารณ์มากกว่า
ทำเป็นน่าเบื่อสุด ๆ…
เกาหลีนี่เป็นประเทศแห่ง Java แบบเปิดเรื่อง-กลางเรื่อง-จบเรื่องด้วย Java เลย เลยรู้สึกแปลกกันนิดหน่อย 555
ผมคิดว่าเทคโนโลยีของต่างประเทศ != ข้อมูลของต่างประเทศ
ตอนนี้ยังไม่เชื่อหรอก จนกว่าจะปล่อยให้ใช้ฟรีก่อน Grok นี่ถึงขั้น 30 ดอลลาร์เลย เลยไม่กล้าสมัครสมาชิก...
555555 นักศึกษาปริญญาโทที่อยู่ดี ๆ ก็โดนลูกหลงเข้าอย่างจัง งงไปเลย ..
ใช้ Rails แล้วมีความสุข