AI กำลังทำให้ฟรอนต์เอนด์ต้องวนกลับไปสู่ทศวรรษที่สูญหายอีกครั้งหรือไม่?

 (mastrojs.github.io)
1 คะแนน โดย GN⁺ 6 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การลดทักษะ (deskilling) คือการแทนที่แรงงานที่มีทักษะด้วยการใช้งานเทคโนโลยีโดยแรงงานกึ่งมีทักษะหรือไร้ทักษะ เพื่อลดต้นทุนและลดอุปสรรคในการเข้าสู่สายงาน แต่ก็ทำให้อำนาจต่อรองของแรงงานอ่อนแอลง
  • ตลอด 10 ปีที่ผ่านมา ฟรอนต์เอนด์เผชิญกับการลดทักษะผ่านเฟรมเวิร์กและเครื่องมือที่บดบังความรู้เรื่องเบราว์เซอร์ การเข้าถึง และประสิทธิภาพ จนความเชี่ยวชาญแบบ front of the frontend ถูกผลักออกไป
  • Agentic AI ยกระดับการเขียนโค้ดไปสู่นามธรรมที่สูงขึ้น แต่ก็เป็นนามธรรมแบบรั่วไหล (Leaky) ที่ไม่เป็นเชิงกำหนดตายตัว และผลลัพธ์อาจเปลี่ยนไปมากจากการเปลี่ยนแปลงเล็กน้อยของอินพุตหรือโมเดล
  • LLM เป็นส่วนต่อเนื่องของการ คัดลอก-วางจาก Stack Overflow ทำให้คนมีประสบการณ์ทำงานได้เร็วขึ้น และทำให้มือใหม่ก็สร้างสิ่งที่พอใช้งานได้ แต่สุดท้ายก็ยังต้องมีใครสักคนที่เข้าใจและแก้ไขผลลัพธ์นั้นได้
  • AI อาจสร้าง AI slop มากขึ้นและช่วยลดต้นทุนได้ แต่ไม่ได้หมายความว่าความต้องการคนที่เข้าใจคุณภาพ ผู้ใช้ และการประนีประนอมจะหายไป

ฟรอนต์เอนด์และ AI coding ในมุมของการลดทักษะ

  • การลดทักษะ (deskilling) คือกระบวนการแทนที่แรงงานมีทักษะด้วยเทคโนโลยีที่แรงงานกึ่งมีทักษะหรือไร้ทักษะสามารถใช้งานได้ ซึ่งช่วยลดต้นทุนและลดอุปสรรคในการเข้าสู่สายงาน แต่ก็ทำให้อำนาจต่อรองของแรงงานอ่อนแอลง
  • ตลอด 10 ปีที่ผ่านมา การพัฒนาฟรอนต์เอนด์ประสบกับการลดทักษะผ่าน JavaScript framework และเครื่องมือต่าง ๆ และในวงการโปรแกรมมิงโดยรวม Agentic AI ก็กำลังสร้างการเปลี่ยนแปลงในลักษณะเดียวกัน
  • ดังที่มีการเรียกว่า Frontend’s Lost Decade ความเชี่ยวชาญด้านฟรอนต์เอนด์ที่เคยอาศัยความเข้าใจเชิงลึกต่อเบราว์เซอร์และสภาพแวดล้อมของผู้ใช้ ได้ถูกการพัฒนาแบบยึดเฟรมเวิร์กเป็นศูนย์กลางเบียดออกไป

ความเชี่ยวชาญที่หายไปจากฟรอนต์เอนด์

  • ในอดีต การพัฒนาฟรอนต์เอนด์ต้องอาศัยความรู้เฉพาะทางอย่าง semantic HTML, CSS, ความแตกต่างของเบราว์เซอร์, การเข้าถึง, progressive enhancement, ประสิทธิภาพเครือข่าย, การออกแบบอินเทอร์เฟซ และการทดสอบผู้ใช้
  • ผู้ปฏิบัติงานบางส่วนเรียกขอบเขตเหล่านี้ว่า front of the frontend เพื่อแยกจาก “frontend” ในความหมายปัจจุบัน
  • การลดทักษะของฟรอนต์เอนด์เกิดขึ้นผ่านการนำเฟรมเวิร์กและเครื่องมือที่ปฏิบัติต่อเบราว์เซอร์เหมือนเป็นเพียงเป้าหมายสำหรับการคอมไพล์ เช่นเดียวกับ JVM หรือ iOS app runtime
  • หากดึงคอมโพเนนต์อย่าง Shadcn radio button มาใช้ ก็สามารถสร้างฟังก์ชันการทำงานได้โดยไม่ต้องเข้าใจอย่างลึกซึ้งถึง HTML พื้นฐาน ความละเอียดอ่อนเฉพาะของแต่ละเบราว์เซอร์ ประสิทธิภาพการโหลดหน้า หรือการเข้าถึง
  • บริษัทต่าง ๆ จึงสามารถโยกโปรแกรมเมอร์ทั่วไปมาทำงานฟรอนต์เอนด์ได้ง่ายขึ้นเพื่อลดต้นทุน
  • คำว่า “full-stack developer” จึงมักไม่ได้หมายถึงคนที่เข้าใจทั้งฟรอนต์เอนด์และแบ็กเอนด์อย่างลึกซึ้ง แต่หมายถึงนักพัฒนาสายอเนกประสงค์ที่ใช้ JavaScript framework จัดการได้ทั้งสองฝั่ง
  • นักพัฒนาคนเดิมยังสามารถ โยกย้าย ระหว่างหลายโปรเจกต์ได้ง่ายขึ้น และยังอาจถูกมอบหมายให้ทำ native app ด้วย React Native และ Electron ได้อีกด้วย
  • ข้อดีคืออุปสรรคในการเข้าสู่สายงานต่ำลง แต่ในอีกด้านหนึ่ง อำนาจต่อรอง ของแรงงานก็อ่อนแอลง

AI coding คือทั้งนามธรรมที่สูงขึ้นและนามธรรมแบบรั่วไหล

  • การเปลี่ยนแปลงที่กำลังเกิดขึ้นในโปรแกรมมิงโดยรวมตอนนี้ มีความคล้ายกับสิ่งที่นักพัฒนาเว็บเคยเจอมาแล้ว
  • งานที่เคยต้องอาศัยทักษะในการเขียนโค้ดด้วยมือ กำลังเคลื่อนไปสู่การถูกแทนที่ด้วยเทคโนโลยีที่แรงงานกึ่งมีทักษะหรือไร้ทักษะสามารถใช้งานได้
  • ตอนนี้ยังไม่ชัดเจนว่าในท้ายที่สุดแรงงานที่ใช้งาน Agentic AI จะต้องมีความสามารถแบบใด และต้นทุนแรงงานรวมถึงค่าใช้จ่ายของ local และ remote LLM จะไปจบที่ตรงไหน
  • แต่สิ่งที่ดูชัดคือบริษัทมีแนวโน้มจะใช้เทคโนโลยีนี้เพื่อลดต้นทุนและทำให้อำนาจต่อรองของแรงงานลดลง
  • สถานการณ์ที่มูลค่าตลาดของทักษะที่สั่งสมมายาวนานลดลงนี้ คล้ายกับช่วงที่ช่างฝีมือและผู้ผลิตงานแฮนด์เมดถูกแทนที่ด้วยแรงงานสายการประกอบ
  • การลดทักษะยังอาจมองได้ว่าเป็นการเพิ่มประสิทธิภาพผ่านระบบอัตโนมัติ หรือการขยับไปทำงานใน ระดับนามธรรม ที่สูงขึ้น
  • เทคโนโลยีใหม่ช่วยซ่อนรายละเอียด ทำให้ผู้ใช้งานโฟกัสกับภาพรวมได้มากขึ้น แต่การตัดสินใจว่ารายละเอียดใด “ไม่สำคัญ” นั้นเป็นเรื่องใหญ่
  • เพราะรายละเอียดของนามธรรมย่อม รั่วออกมาในสักวันหนึ่ง

  • นามธรรมที่รั่วไหลของฟรอนต์เอนด์แบบ “สมัยใหม่”

    • นามธรรมมักมาพร้อมต้นทุนด้านประสิทธิภาพ และการยอมเสีย runtime performance บางส่วนเพื่อแลกกับ productivity ของนักพัฒนา อาจเป็นทางเลือกที่สมเหตุสมผลบนเซิร์ฟเวอร์แรง ๆ และภาระงานระดับปกติ
    • แต่บนโทรศัพท์มือถือที่ใช้งานผ่านเครือข่ายช้า ๆ การประนีประนอมแบบเดียวกันอาจกลายเป็นปัญหาคนละแบบไปเลย
    • การใช้ client-side JavaScript framework ที่หนักอย่าง React รวมถึงแพ็กเกจใน ecosystem จำนวนมาก จะไปทำให้ปัญหาเรื่องการเข้าถึง และประสิทธิภาพบนมือถือสเปกต่ำกับเครือข่ายช้า ถูกซ่อนไว้ในนามธรรม
    • ผลก็คือผู้คนเลือกทางที่ไม่ต้องคิดถึง และไม่ต้องใส่ใจกับปัญหาเหล่านั้น

  • ความไม่เป็นเชิงกำหนดตายตัวของ agentic coding

    • เมื่อต้องสร้างฟีเจอร์หรือแก้บั๊กด้วย Agentic AI เราไม่ได้เขียนทุกบรรทัดเอง แต่ใช้น้อยคำกว่าเดิมเพื่ออธิบายการเปลี่ยนแปลงในระดับสูง
    • AI จะดูจากข้อมูลฝึกและบริบทรอบข้างเพื่อเติมรายละเอียดที่ถูกละไว้ บางครั้งก็เดาได้ดี บางครั้งก็ล้มเหลว
    • วิธีนี้จะมีประโยชน์แค่ไหน ขึ้นอยู่มากกับว่าคุณมองว่าอะไรคือสิ่งสำคัญในการเขียนโค้ด
    • Agentic coding ไม่ได้เป็นเชิงกำหนดตายตัวแบบคอมไพเลอร์ และการเปลี่ยนแปลงเล็กน้อยของอินพุตหรือโมเดลก็อาจให้ผลลัพธ์ที่ต่างกันมาก ทำให้นามธรรมนี้รั่วไหลมากกว่านามธรรมในโปรแกรมมิงแบบเดิมอย่างมาก
    • เหตุผลที่มีคนเปรียบ AI กับ “วิศวกรจูเนียร์” ก็อยู่ตรงความไม่เป็นเชิงกำหนดตายตัวนี้ แต่ต่างกันตรงที่มนุษย์สามารถเรียนรู้ได้โดยไม่ต้องคอยปรับไฟล์ AGENTS.md หรือ SKILL.md แบบไม่มีที่สิ้นสุด

LLM คือภาคต่อของการคัดลอก-วางจาก Stack Overflow

  • อุปมาที่ใกล้เคียงที่สุดกับการใช้ LLM คือวิธีใช้ Google Search ในอดีต
  • ความสามารถในการเลือกคีย์เวิร์ดอย่างแม่นยำเพื่อให้โพสต์ในฟอรัมหรือคำตอบจาก Stack Overflow ที่เหมาะสมขึ้นมาอยู่ในหน้าผลลัพธ์แรก ๆ ก็เคยเป็นทักษะที่นักพัฒนาต้องฝึก
  • การเขียนพรอมป์ต์ให้ LLM ก็เป็นกระบวนการทำให้มันคืนชุดข้อมูลฝึกที่เหมาะสมกลับมา และใกล้เคียงกับการดึงข้อมูลจากพื้นที่เชิงมิติสูงแบบการค้นเว็บที่คลุมเครือ
  • ผลการค้นหานั้นไวต่อการเปลี่ยนแปลงเล็กน้อยของถ้อยคำและการเปลี่ยนแปลงในดัชนีค้นหาของ Google และ LLM ก็ไวต่อรูปแบบของอินพุตและการเปลี่ยนโมเดลเช่นกัน
  • ไม่นานมานี้ Google ปรับการค้นหาให้ทำ normalization ของคำค้นแรงขึ้น ทำให้คนที่ไม่ชำนาญ Google-fu ค้นหาง่ายขึ้น แต่สำหรับผู้มีทักษะกลับทรงพลังน้อยลง
  • Google และ Stack Overflow เปลี่ยนการเขียนโปรแกรมไปอย่างย้อนกลับไม่ได้ และทำให้การคัดลอก-วางคำตอบแทนการอ่านคู่มือ สามารถให้ผลลัพธ์ที่ใช้งานได้ในระดับหนึ่งบ่อยจนน่าประหลาดใจ
  • LLM ก็คือส่วนต่อเนื่องของแนวโน้มเดียวกัน
    • ทำให้คนที่รู้ว่าตัวเองกำลังทำอะไรอยู่ ทำงานได้เร็วขึ้นอีกเล็กน้อย
    • ทำให้คนที่ยังไม่ค่อยรู้ว่ากำลังทำอะไรอยู่ ก็ยังสร้างสิ่งที่พอใช้ได้ขึ้นมาได้
  • แต่นามธรรมย่อมรั่วออกมาในสักวัน และเมื่อถึงตอนนั้น ก็ต้องมีใครบางคนที่เข้าใจอย่างลึกซึ้งว่าเกิดอะไรขึ้นจริงและแก้ไขมันได้
  • เช่นเดียวกับที่เราเคยสอนนักพัฒนาจูเนียร์ให้อ่านและทำความเข้าใจคำตอบจาก Stack Overflow ก่อนจะนำไปใช้ ตอนนี้ก็ต้องสอนให้พวกเขาอ่านและเข้าใจผลลัพธ์จาก LLM และมองให้ออกว่ามันเข้ากับ codebase เดิมอย่างไร

ระยะห่างระหว่างคุณภาพกับธุรกิจ

  • โปรแกรมเมอร์บางคนไม่เคยก้าวไปถึงขั้นเข้าใจคำตอบจาก Stack Overflow อย่างแท้จริง และมองว่าแค่ผลลัพธ์ใช้งานได้ก็เพียงพอแล้ว
  • หลายบริษัทเอง แม้จะไม่ยอมรับกันตรง ๆ ก็พึงพอใจกับแนวทางแบบนี้
  • ตอนนี้สถานการณ์กลายเป็นว่าหลายบริษัทประกาศอย่างเปิดเผยว่าตัวเองใช้ AI มากแค่ไหน ทั้งที่แทบไม่ได้แม้แต่แสร้งทำเป็นตรวจดูผลลัพธ์เลย
  • แน่นอนว่า use case ที่ใช้ได้จริงของ LLM มีอยู่ แต่ขณะเดียวกันก็มีวิธีใหม่ ๆ มากมายที่ทำให้โค้ดพัง และทำลายการสื่อสารกับกระบวนการทำงานในองค์กรได้
  • เช่นเดียวกับ code review มีความเห็นต่างอย่างมากว่า LLM ควรถูกใช้และผสานเข้ากับ workflow อย่างไร และหากไม่สอดคล้องกับสิ่งที่ทีมให้คุณค่า ก็อาจเกิดปัญหาใหญ่ในกระบวนการทำงาน
  • หลายบริษัทก็ยังดำเนินธุรกิจได้ดี ทั้งที่สร้างซอฟต์แวร์แย่ ๆ ออกมาอย่างต่อเนื่อง
  • ตรงกันข้ามกับที่โปรแกรมเมอร์ชอบเชื่อ ความสำเร็จทางธุรกิจกับคุณภาพซอฟต์แวร์นั้นแทบไม่ค่อยสัมพันธ์กัน
  • โดยทั่วไปแล้วปัจจัยอื่นอย่างแบรนด์หรือราคา มักมีผลมากกว่า และโปรเจกต์ซอฟต์แวร์ก็มักถูกมองเป็นกล่องดำที่มีโอกาสสำเร็จหรือพังพอ ๆ กัน
  • ในฟรอนต์เอนด์ก็เช่นกัน เว็บไซต์ที่ช้าและมี cookie banner เยอะอาจทำลาย conversion rate ได้ แต่ผลกระทบนั้นมักน้อยกว่าปัจจัยอย่างความภักดีต่อแบรนด์หรือราคา และเว็บของคู่แข่งก็มักช้าเหมือนกัน
  • ภายใต้บรรยากาศแบบ “ไม่มีใครถูกไล่ออกเพราะเลือก React” การเลือกทางที่ปลอดภัยจึงมักถูกให้ความสำคัญมากกว่าคุณภาพ
  • นี่ไม่ได้หมายความว่าเราควรเลิกใส่ใจผู้ใช้และความประณีตในงาน แต่หมายความว่าการหางานที่เปิดโอกาสให้ทำเช่นนั้นได้ กลับยากขึ้นกว่าเดิม
  • เมื่อกระแสเกินจริงซาลง และผู้คนเข้าใจมากขึ้นว่า LLM เหมาะกับงานแบบไหนและไม่เหมาะกับงานแบบไหน สมดุลบางส่วนอาจกลับมาได้ แต่ตัวอาชีพเองคงไม่เหมือนเดิมอีกแล้ว

ทักษะที่ยังคงอยู่หลังยุคอุตสาหกรรม

  • เมื่อสินค้าทั่วไปและอาคารต่าง ๆ สามารถถูกผลิตจำนวนมากด้วยกระบวนการอุตสาหกรรมได้ ปฏิกิริยาอย่างหนึ่งคือการผลิตสินค้าและอาคารจากโรงงานให้ดูเหมือนงานทำมือ ด้วยการเลียนแบบรูปแบบในอดีต
  • เพื่อตอบโต้ historicism นี้ ช่วงต้นศตวรรษที่ 20 Bauhaus ได้พัฒนาแนวทางที่ไม่ได้มองแรงงานโรงงานกับช่างฝีมือเป็นฝ่ายตรงข้าม แต่ให้ทั้งสองทำงานร่วมกัน และพัฒนาศิลปะกับงานฝีมือใหม่บนสมมติฐานของกระบวนการผลิตแบบอุตสาหกรรม
  • Bauhaus เรียกร้องให้นักออกแบบกลับไปสู่เวิร์กช็อป ลงมือกับวัสดุด้วยตนเอง แต่ตั้งเป้าสุดท้ายไว้ที่การออกแบบที่ผลิตจำนวนมากได้
  • ซอฟต์แวร์มีความใกล้กับงานฝีมือ เพราะโปรแกรมที่เขียนเสร็จจะถูกส่งถึงผู้ใช้ “ตามนั้น” โดยไม่ผ่านขั้นตอนการผลิต แต่ก็ใกล้กับ industrial design เพราะสิ่งเดียวกันนั้นถูกกระจายไปยังผู้ใช้หลายพันคน
  • ความสามารถในการเขียนโค้ดด้วยมือยังคงจำเป็นอยู่ และเช่นเดียวกับที่นักออกแบบอุตสาหกรรมต้องรู้จักวัสดุของผลิตภัณฑ์ นักออกแบบเว็บก็ควรชำนาญ HTML และ CSS อย่างมาก
  • Google, Stack Overflow, ไลบรารีพร้อมใช้, และ LLM ช่วยให้ผู้เริ่มต้นเริ่มต้นได้ง่ายขึ้น แต่ก็ลดกำแพงตามธรรมชาติของการทำให้บางสิ่ง “ใช้งานได้จริง” ลงเรื่อย ๆ
  • การทำให้เป็นอุตสาหกรรมได้สร้างสินค้าพลาสติกราคาถูกจำนวนมากที่ไม่ได้คิดถึงวิธีใช้และผู้ใช้อย่างเพียงพอ แต่ industrial design ที่ดีก็ยังคงมีอยู่
  • โปรแกรมประมวลผลคำทำให้เกิดเอกสารที่จัดรูปแบบแย่ ๆ จำนวนมาก แต่ typography และ graphic design ก็ยังคงมีอยู่
  • Wix และ Next.js ทำให้การสร้างเว็บไซต์ที่ช้าและเข้าถึงได้ไม่ดีเกิดขึ้นได้มากขึ้น แต่ผู้ปฏิบัติงานสาย front of the frontend ก็ยังคงมีอยู่
  • AI อาจทำให้เกิด AI slop ได้มากมาย แต่ไม่ได้หมายความว่าเราไม่ต้องการคนที่รู้ว่ากำลังทำอะไรอยู่และใส่ใจกับงานของตนอีกต่อไป

การเปลี่ยนแปลงและการประนีประนอมในอนาคต

  • เช่นเดียวกับอุตสาหกรรมอื่น ๆ สัดส่วนของงานที่ทำอย่างถูกต้องจริง ๆ อาจเล็กลงเมื่อเทียบกับภาพรวมทั้งหมด
  • ขณะเดียวกัน เพราะการสร้างสิ่งต่าง ๆ ง่ายและถูกลง ขนาดของตลาดรวมก็น่าจะขยายต่อไป
  • ตอนนี้ยังยากจะตัดสินว่าจำนวนคนที่ได้รับค่าตอบแทนจากการทำงานได้ดีจะเพิ่มขึ้นหรือลดลงในเชิงจำนวนจริง
  • บางครั้งการปั่น prototype หรือ MVP ออกมาอย่างรวดเร็วก็เป็นทางเลือกที่ถูกต้อง
  • หากยังหา product-market fit ไม่เจอ การทำซ้ำอย่างรวดเร็วและการเรียนรู้ อาจสำคัญกว่าการทำทุกอย่างให้พร้อมรองรับอนาคตตั้งแต่แรก
  • แต่ก็ต้องรู้ว่าต้องการเรียนรู้อะไร และจะตรวจสอบการเรียนรู้นั้นอย่างไร
  • และเมื่อถึงเวลาที่เหมาะสม การถอยกลับมาหนึ่งก้าวแล้วทำใหม่ให้ถูกต้องตั้งแต่ต้น มักจะดีกว่า
  • ตัวอย่างเช่น ในฟรอนต์เอนด์ที่มีสถาปัตยกรรมแย่ การจะทำให้มีประสิทธิภาพดีในภายหลังนั้นยากมาก
  • การเริ่มจากสแตกที่เรียบง่ายแล้วค่อยเพิ่มความสามารถภายหลัง ง่ายกว่าการทำตรงกันข้าม
  • Mastro สนับสนุนอย่างชัดเจนให้เริ่มจากประสิทธิภาพที่ดีและสแตกที่เรียบง่าย
  • ไม่ว่าจะเลือกซื้อบริการ ใช้โอเพนซอร์สไลบรารี ใช้สิ่งที่ LLM สร้าง หรือเขียนเอง ก็ควรรู้ว่ากำลังแลกอะไรกับอะไรในแต่ละส่วนของระบบ
  • เมื่อกระแสเกินจริงจางลง วงการจะตระหนักว่า AI เป็นเพียงเครื่องมืออีกชิ้นหนึ่งในกล่องเครื่องมือเท่านั้น
  • แต่ก่อนจะถึงจุดนั้น โค้ดอัปลักษณ์ การสื่อสารที่พัง และการเลย์ออฟที่เลวร้าย ก็อาจยังคงปรากฏต่อไปภายใต้ชื่อของ AI

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

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

 
GN⁺ 6 시간 전
ความคิดเห็นจาก Hacker News

  • ผมมองว่า ความเชี่ยวชาญเชิงลึก ที่ OP เสียดายนั้น จริง ๆ แล้วเป็นสิ่งที่ค่อนข้างสร้างความอึดอัดให้คนจำนวนมาก
    เรื่องความแปลกเฉพาะของแต่ละเบราว์เซอร์ การต้องลงมือทำคอมโพเนนต์ที่เข้าถึงได้ด้วยตัวเอง หรือการหาเลี้ยงชีพด้วยความชำนาญในการระบุ CSS นั้นก็เข้าใจได้ แต่สำหรับคนส่วนใหญ่ มันใกล้เคียงกับ ความซับซ้อนที่เกิดขึ้นโดยบังเอิญ มากกว่า การที่ผู้คนจำนวนมากขึ้นสามารถสร้างบางสิ่งได้ย่อมเป็นเรื่องดีอย่างชัดเจน และถ้าผลลัพธ์บางส่วนช้ากว่าหรือการเข้าถึงแย่ลง นั่นก็เป็นการแลกเปลี่ยนที่เลือกได้
    จะบอกก็ได้ว่านามธรรมระดับสูงโยนผลลัพธ์ที่ผู้ใช้ไม่ได้เลือกมาให้ แต่ผมก็คิดว่า LLM อาจเข้าใจแนวปฏิบัติด้านการเข้าถึงได้ดีกว่าผมเสียอีก

    • การจัดการองค์ประกอบของ UX/การพัฒนาซอฟต์แวร์ที่สังเกตเห็นได้ยากกว่า เช่น การเข้าถึงได้ ความใช้งานง่าย ความเข้ากันได้ การตอบสนอง การขยายระบบ สถาปัตยกรรม และประสิทธิภาพ เป็นเรื่องยากมาโดยตลอด
      แต่เฟรมเวิร์กระดับสูงมาก ๆ และตอนนี้ก็รวมถึง LLM ทำให้มันง่ายขึ้นที่จะปล่อย MVP ที่สุก ๆ ดิบ ๆ ออกมาอย่างรวดเร็วพร้อมกับทำลายจุดเหล่านี้ไปด้วย จึงทำให้ช่องว่างระหว่าง “พอรับได้” กับ “ดีใช้ได้” กว้างขึ้นเรื่อย ๆ สำหรับคนที่มุ่งไปทาง “ดีใช้ได้” การแข่งขันกับฝั่งที่ผลักแค่ “พอรับได้” จึงยากขึ้นเรื่อย ๆ
      สุดท้ายก็ลงเอยด้วยการทำงานล่วงเวลามากขึ้นและ คุณภาพซอฟต์แวร์ที่ลดลง และอาจรวมถึงความพึงพอใจในงานโดยรวมที่ถดถอยลง ทุกวันนี้เริ่มมีการใช้เครื่องมือนักพัฒนาและ uBlock ไปซ่อมเว็บที่พังหรือเอาสิ่งรบกวนออกเพื่อให้ฟังก์ชันพื้นฐานกลับมาใช้งานได้ และผมก็เห็นคนอื่นบอกว่าทำแบบเดียวกันอยู่ที่นี่เหมือนกัน(https://news.ycombinator.com/item?id=47042747) เมื่อก่อนแม้แต่สมัย Flash หรือยุคเบราว์เซอร์แรก ๆ ก็ไม่เคยต้องมานั่งแก้เองแบบนี้
      ถ้าจะยกตัวอย่างที่ไม่ใช่แค่ประสบการณ์ส่วนตัว ก็มี: https://news.ycombinator.com/item?id=47390945
      ที่แย่กว่านั้นคือ เงินส่วนใหญ่ที่ประหยัดได้จากการตัดทอนพวกนี้กลับไปตกอยู่กับคนชั้นบนสุดขององค์กรเท่านั้น
    • AI ชอบทำพลาดโดยเอาวัตถุที่เคลื่อนไหวได้ไปวางไว้หลังวัตถุที่มี blur ทำให้เบราว์เซอร์ต้องวาดใหม่ซ้ำ ๆ ตลอด
      ใน AI mode ของ Google ก็มีแบบนั้นอยู่ และเว็บอื่น ๆ ก็ดูเหมือนจะใส่สิ่งคล้ายกันเข้ามาอย่างชัดเจนผ่านการ vibe coding
      ตอนแรกผมยังงงว่าทำไมการใช้ GPU ถึงพุ่งสูงและพัดลมถึงหมุนแรง แต่ตอนนี้เห็นแล้วว่านี่เป็นความผิดพลาดที่ AI ทำบ่อยและไม่มีใครทดสอบให้ดี แม้คนก็อาจพลาดแบบนี้ได้ แต่ก่อนหน้านี้ผมแทบไม่เคยเจอเลยตลอดชีวิต
      พอใช้จอ 240Hz เบราว์เซอร์ก็พยายามวาดใหม่ 240 ครั้งต่อวินาที และสุดท้ายก็ต้องบล็อกด้วย uBlock Origin เท่านั้น มันเหลือเชื่อจริง ๆ
    • บทความแนว “เรากำลังสูญเสียงานฝีมือของเรา” มักมีโครงสร้างหดหู่แบบเดิมเสมอ
      ที่แย่กว่านั้นคือ พอถึงกลางเรื่องก็มักหักล้างข้อโต้แย้งของตัวเอง
      เช่นมีประโยคว่า “การตัดสินใจว่ารายละเอียดใดไม่สำคัญเป็นการตัดสินใจที่สำคัญมาก บางครั้งก็เป็นเรื่องอัตวิสัย และสุดท้ายรายละเอียดก็จะเล็ดลอดออกมาเสมอ” ถ้าอย่างนั้นก็แปลว่าเทคโนโลยีใหม่นี้ท้ายที่สุดก็ยังให้รางวัลกับ ความเข้าใจทางเทคนิคอย่างลึกซึ้ง อยู่ดี เพราะเลี่ยงไม่ได้ ผมเห็นด้วยกับจุดนั้น แต่ถ้าอย่างนั้นทำไมโทนโดยรวมถึงกลายเป็น “AI กำลังทำให้ทักษะของฉันกลายเป็นสินค้าเกรดต่ำ” ล่ะ?
      ในเชิงเทคนิคแล้ว เว็บไซต์โดยทั่วไปดีกว่าเมื่อ 10 ปีก่อน ฟีเจอร์มีมากขึ้น เร็วขึ้น และ SSL/การเข้าถึงได้/การรองรับหน้าจอแบบ responsive ก็กลายเป็นค่าเริ่มต้นที่แข็งแรงกว่าเดิม ปัญหาของ content farm, SEO และเว็บข่าว เป็นรูปแบบความล้มเหลวอันเลวร้ายอีกแบบที่เกิดจากโฆษณาและแรงจูงใจขององค์กร ไม่ใช่ ความผิดของ React
    • ที่ว่า “LLM จะเข้าใจแนวปฏิบัติด้านการเข้าถึงได้ดีกว่าฉัน” นั้น ที่จริงก็เพราะคนอื่นเข้าใจและเขียนมันไว้ต่างหาก
      LLM อาจหยิบมันมาใช้ได้เป็นครั้งคราว แล้วถ้าคนเลิกเขียนกันไป หลังจากนั้นจะเกิดอะไรขึ้น?
      ผมเห็นด้วยว่าการมีคนจำนวนมากขึ้นสร้างสิ่งต่าง ๆ เป็นเรื่องดี ถ้าปัจจัยอื่นเท่ากัน มากกว่าก็ดีกว่า ถ้า “AI” แพร่ไปทุกที่เพราะการปรับปรุงที่ปฏิเสธไม่ได้จริง ๆ บริบทและความรู้สึกโดยรวมก็คงต่างออกไปมาก
      ถึงอย่างนั้น ผู้คนก็ไม่ได้มีสิทธิโดยอัตโนมัติต่อความรู้ที่ถูก “สร้างขึ้น” ผ่านงานของคนอื่น ถ้าจะจัดการเรื่องการให้เครดิตและค่าตอบแทนอย่างจริงจัง และถ้าจะฝึกได้เฉพาะกับข้อมูลที่มีการจ่ายเงินให้ผู้สร้างข้อมูลแล้ว การไป เรียน CSS เอง อาจเร็วกว่าและถูกกว่ามากก็ได้
    • ผมมองว่าความสะดวกที่เกิดจากการเมิน ความเชี่ยวชาญเชิงลึก แล้วกองทับด้วยการแฮ็กและนามธรรมแบบขี้เกียจ เป็น ความเสื่อมถอย ที่ลากยาวมาจนถึงเฟรมเวิร์กขนาดหลาย MB และ Electron ในยุคปัจจุบัน
      แน่นอนว่าไม่มีใครสนใจคอมพิวเตอร์ของผู้ใช้/การใช้หน่วยความจำ ประสบการณ์ที่แย่ลง แบนด์วิดท์ที่สูญเปล่า ต้นทุนพลังงานที่เพิ่มขึ้นสำหรับคน 8 พันล้านคน และผลกระทบต่อสิ่งแวดล้อม
      การที่คนจำนวนมากขึ้นมาสร้างโครงสร้างพื้นฐานสาธารณะก็เป็น “เรื่องดีอย่างชัดเจน” ด้วยหรือ? ถ้าผลลัพธ์คือถนนที่แย่ลง สะพานที่แย่ลง ระบบที่ล้มเหลว? ซอฟต์แวร์ก็เหมือนกัน และจริง ๆ แล้วสิ่งส่วนใหญ่ก็เป็นแบบนั้น

  • ส่วนใหญ่ของสิ่งที่บทความนี้บอกว่า “ทักษะฟรอนต์เอนด์” กำลังสูญเสียความเกี่ยวข้องนั้น จริง ๆ คือการต้องลุยผ่านทุ่งระเบิดที่เต็มไปด้วยข้อยกเว้นที่ไม่เป็นธรรมชาติ ความเข้ากันไม่ได้ของเบราว์เซอร์ ภาระทางประวัติศาสตร์ และข้อยกเว้นของข้อยกเว้นของข้อยกเว้น
    ฟรอนต์เอนด์สมัยใหม่ หรือก็คือ “หอคอยแห่ง abstraction ที่รั่ว” ในที่สุดก็เข้าใกล้ mental model ที่สมเหตุสมผลสำหรับการพัฒนาเว็บมากขึ้น มันคือสิ่งที่ถูกฝืนครอบทับลงบนวัตถุระเบิดแห่งความประหลาดของมาตรฐานและธรรมเนียมเว็บ แต่การที่มันยังใช้งานได้และรั่วเพียงเล็กน้อยก็นับเป็นความสำเร็จแล้ว

    • คำว่า “mental model ที่สมเหตุสมผลสำหรับการพัฒนาเว็บ” ฟังดูขัดแย้งในตัวเอง จะเป็นโลกของข้อยกเว้นแบบทุ่งระเบิด หรือจะเป็นโมเดลที่สมเหตุสมผล อย่างใดอย่างหนึ่ง จะเป็นทั้งสองอย่างพร้อมกันไม่ได้
      เรายังอยู่ในทุ่งระเบิดของข้อยกเว้นเหมือนเดิม และคงยากจะบอกว่าเทคโนโลยีที่ใช้สร้างฟรอนต์เอนด์ตอนนี้สะอาด คาดเดาได้ และปลอดจากภาระทางประวัติศาสตร์แล้ว
      สิ่งที่เราทำมีแค่ฉาบปูนทับความผิดพลาดและความไม่เข้ากันของรากฐาน ไม่ได้แก้ปัญหา React ไม่ได้แก้ความจริงที่ว่า HTML ไม่ได้ถูกออกแบบมาให้เป็นชุดเครื่องมือสำหรับ UI Next.js ไม่ได้แก้ความจริงที่ว่า JavaScript เต็มไปด้วยความผิดพลาดเชิงออกแบบที่ทำให้มันไม่อาจเป็นภาษาที่ปลอดภัย มีเหตุมีผล และไม่เพี้ยนได้ Tailwind ไม่ได้แก้ปัญหาที่ CSS ถูกยัดเข้ามาแบบมวยวัดเพื่อใช้ตกแต่ง markup ที่ไม่ได้ถูกออกแบบมาเพื่อการจัดสไตล์
      สิ่งที่ LLM ทำอยู่ตอนนี้ ก็แค่ “รู้” ความสยองใต้ชั้นปูนฉาบนั้นผ่านโมเดลเชิงสถิติ โมเดลนั้นถูกฝึกจากตัวอย่างในยุคที่ 99% เป็นแค่การกลับไปอุดรอยร้าวของชั้นปูนฉาบก่อนหน้า
    • ผมไม่ใช่ผู้เชี่ยวชาญ แต่ถ้าเคย deploy ฟรอนต์เอนด์ที่คนทั่วไปต้องใช้ ฟรอนต์เอนด์ก็เหมือนถนนอิฐสีเหลืองในเรื่อง The Wizard of Oz
      ถ้าไม่ออกนอกชุดแนวปฏิบัติที่ดีเล็ก ๆ แต่ใช้ได้ ก็สามารถมอบประสบการณ์ที่ค่อนข้างดีได้ด้วยไลบรารีน่าเบื่อแต่ผ่านการพิสูจน์มาแล้วไม่กี่ตัว
      แต่พอไปพัวพันกับเฟรมเวิร์กฟรอนต์เอนด์ที่กำลังฮิตในวันนี้ หรือแย่กว่านั้นคือเฟรมเวิร์กที่เคยฮิตเมื่อวาน หรือจำเป็นต้องทำงานให้เข้ากับความชอบประหลาดของนักพัฒนาคนอื่นที่ยึดติดกับวิธีใดวิธีหนึ่ง หรือเริ่มแตะ “แฮ็กอัจฉริยะ” ที่แปะรวมกันไว้ด้วยความหวังและเทปกาว ความซับซ้อนและรูปแบบการปฏิสัมพันธ์ก็จะเพิ่มขึ้นแบบยกกำลัง
    • ต้นฉบับกำลังเสียดายยุคทองที่ไม่เคยมีอยู่จริง
      ผมผ่านยุคนั้นมาแล้ว JavaScript เพียว ๆ ที่ทำเพื่อ IE6 โดยเฉพาะ ถูกแทนที่ด้วย jQuery ที่บั๊กเยอะ จากนั้นก็เป็น Angular single-page app ที่บำรุงรักษาไม่ได้ แล้วต่อมาก็กลายเป็น codebase React สัตว์ประหลาด
    • ฟังดูเหมือนคำพูดที่เผยให้เห็นความไม่รู้
      ของจริงมีมากกว่านั้นอีกเยอะ
      ผมเจอคนมาสัมภาษณ์ที่อ้างว่าเป็นผู้เชี่ยวชาญ Next.js เยอะมาก แต่บ่อยครั้งทำอย่างอื่นแทบไม่ได้เลย นั่นไม่ใช่ทักษะ แต่มันเป็นแค่ความรู้ และตอนนี้ก็มีให้ใช้ฟรีเกลื่อนแล้ว
    • ความสามารถในการเข้าใจว่า abstraction ที่รั่วนั้นอยู่ในหอคอยไหน ชั้นไหน ห้องไหน ก็ยังมีคุณค่ามากอยู่ดี และ LLM อาจมองไม่เห็นมัน
      แค่เพราะบางอย่างไม่ได้ถูกคณะกรรมการออกแบบมาอย่างสมบูรณ์แบบตั้งแต่ต้น ไม่ได้แปลว่าเราจะลืมทุกอย่าง ปิดหนังสือ แล้วปล่อยให้เครื่องคำนวณแทนได้
      ผมเองก็ใช้วิธีหลังอยู่เหมือนกัน เลยรู้ว่ามันพลาดอะไรได้บ้าง แต่ก็ไม่ได้หลงจนสร้างความเละเทะที่บำรุงรักษาไม่ได้ ทุกครั้งที่เอเจนต์หลุดราง ทักษะฟรอนต์เอนด์ ของผมจะมีประโยชน์มากจริง ๆ

  • คำพูดที่ว่า “ฟรอนต์เอนด์เป็นทักษะที่เฉพาะทางสูง ต้องรู้ HTML เชิงความหมาย, CSS, ความแตกต่างของเบราว์เซอร์, การเข้าถึง, progressive enhancement, ประสิทธิภาพเครือข่าย, การออกแบบอินเทอร์เฟซ, การทดสอบผู้ใช้ ฯลฯ” คงฟังตลกพอสมควรสำหรับนักพัฒนาฟรอนต์เอนด์รุ่นก่อนหน้า หรือก็คือนักพัฒนา C/C++
    เว็บเคยถูกมองว่าเป็นสิ่งที่ลดกำแพงการเข้าสู่วงการอย่างมากและทำให้ทักษะถูกลดความชำนาญลง นักเขียนแอสเซมบลีก็คงเคยมองนักพัฒนา C/C++ แบบเดียวกัน

    • ทุกเลเยอร์ต่างคิดว่าตัวเองสำคัญที่สุด เฉพาะทางที่สุด และต้องใช้ทักษะสูงที่สุด
      แต่ทุกเลเยอร์ก็ผิด เพราะแต่ละเลเยอร์ถูกสร้างอยู่บน abstraction ของเลเยอร์ที่ต่ำกว่า ถ้าย้อนไปจนถึงฟิสิกส์และคณิตศาสตร์ คุณจะพบว่าแม้แต่นักทฤษฎีเซตก็ยังต้องสมมติสัจพจน์บางอย่างอยู่ดี ส่วนนักตรรกศาสตร์ทำอะไรกันนั้นไม่มีใครรู้
    • ข้อความที่ยกมานั้นไม่ได้มาจากบทความนี้ และก็ไม่ได้เกี่ยวอะไรกับบทความด้วย ไม่รู้จริง ๆ ว่าเกิดอะไรขึ้น

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

    • นี่ใกล้เคียงกับการ “วางอิฐเพิ่มอีกก้อนบนกำแพง” มากกว่า
      ก่อนหน้านี้ก็มีแรงกดดันมหาศาลให้ออกของแบบขั้นต่ำที่พอผ่าน requirement แล้วประกาศว่าประสบความสำเร็จได้เลย ตอนนี้รู้สึกเหมือนแรงกดดันนั้นเกินรับไหวไปแล้ว
    • สำหรับสมมติฐานที่ว่าก่อนยุค AI มีช่างฝีมือมีฝีมือที่ทุ่มเทกับคุณภาพ ก็มีคนที่โชคดีพอจะเคยเจอช่วงเวลาแบบนั้นอยู่บ้างในเส้นทางอาชีพ
      แต่ก็เห็นด้วยว่าสิ่งนั้นหายไปตั้งแต่ก่อน AI แล้ว
    • มาตรฐานคุณภาพดูต่ำจนน่ากลัว
    • ใช่แล้ว เว็บก่อนยุค jQuery และ Bootstrap นั้นเละเทะและเขียนโค้ดก็ไม่สนุก
      ถ้าจะพูดถึงคุณภาพต่ำ ยุคนั้นต่างหากที่เป็นเรื่องปกติ

  • ช่วงหลังมานี้ฉันก็คิดคล้าย ๆ กัน
    ฉันแทบไม่ได้ทำฟรอนต์เอนด์มานานอย่างน้อย 10 ปีแล้ว แต่ก็ยังแก่พอที่จะจำช่วงปลายยุค 2000 ได้ ว่าจู่ ๆ ทุกคนก็เลิกทำเว็บ GUI ด้วยมือแล้วหันไปใช้เฟรมเวิร์ก และคนที่ยังเขียน HTML/CSS/JS กับคำสั่ง query ฐานข้อมูลด้วยมือก็จะถูกล้อเลียน ประกาศรับงานก็เริ่มเปลี่ยนจากการต้องการ PHP/HTML/CSS/SQL/JS ไปเป็น Ruby on Rails, Django, Spring, GWT และต่อมาก็ Angular
    มันให้ความรู้สึกคุ้น ๆ แบบประหลาดกับตอนนี้ ตอนนั้นคุณสร้างเว็บแอปที่ใช้งานได้ภายในไม่กี่นาทีโดยไม่ต้องมีความรู้ลึกมากนักได้ และมันดูเหมือนเวทมนตร์ หลังจากนั้นก็จะคอยไล่อ่านเอกสารแบบคร่าว ๆ แล้วค้นหาไปเรื่อย ๆ เพื่อปรับแต่งภายในเฟรมเวิร์ก จนถึงจุดหนึ่งก็ไปต่อไม่ได้อีก เพราะไม่รู้เลยว่าข้างในมันทำงานอย่างไร เช่นเดียวกับเว็บแอปแบบ vibe coding เว็บแอปมาตรฐานจากเฟรมเวิร์กที่ต่อ ๆ กันขึ้นมาในบ่ายเดียวดูออกได้จากระยะไกล แต่สำหรับผู้บริหารแล้วมันดูน่าประทับใจมาก
    สิ่งที่น่าสนใจคือ นักพัฒนาพูดถึง โมเดลแนวหน้าที่สุด ที่ตัวเองใช้บ่อยในแบบที่คล้ายกับที่นักพัฒนา GUI เมื่อ 15~20 ปีก่อนพูดถึงเว็บเฟรมเวิร์กที่ตัวเองชอบมาก พวกเขาทำกับเครื่องมือเหมือนเป็นบุคคลหรือถึงขั้นระบุตัวตนร่วมกัน แล้วก็หงุดหงิดว่าเวอร์ชัน X ทำได้ แต่ X.1 กลับแย่ลง และก็มีประโยคอย่าง “ตอนนี้พัฒนาได้เร็วขึ้น 10 เท่า”, “ฉันจะกลับไปเขียน XYZ ด้วยมือ” วนซ้ำอยู่ตลอด

    • ในอีกมุมหนึ่ง การใช้เฟรมเวิร์กในเวลาต่อมาก็เป็นความพยายามที่ดีเพื่อสร้างมาตรฐาน
      GUI ทำเองที่ไม่มีใครใช้เป็นก็ไม่ได้ถือเป็นข้อดีอะไร
      ส่วนตัวฉันไม่ชอบอะไรที่ “ให้ความรู้สึก” ใหญ่เกินไปแบบ Nuxt/Next แต่ชอบ Vue อย่างไรก็ดี ตอนนี้ฉันอยากลด JavaScript ออกให้มากที่สุด เลยพยายามไปทางโซลูชันสาย HTMX หรือ Alpine ร่วมกับ server-side template
      โดยส่วนตัวฉันคิดว่ายิ่งใช้เทคโนโลยีน้อยยิ่งดี สมัยก่อนก็มีช่วงที่เว็บแอปเต็มไปด้วยของไม่จำเป็นสารพัดตั้งแต่ก่อนจะเพิ่ม custom code แม้แต่บรรทัดเดียว
    • ตั้งแต่ต้นยุค 2000 นักพัฒนาเว็บก็เหนื่อยกับการเขียนทุกอย่างด้วยมือแล้ว และกำลังมองหาระบบอัตโนมัติอย่างเฟรมเวิร์กหรือ CMS
      ย้อนกลับไปปี 2004 ฉันก็เคยทำเว็บด้วยแนวทางพื้นฐานอย่างเอาไฟล์ txt ใส่ไว้ใน directory tree แล้วให้ PHP แปะลงใน HTML โดยเติมแท็กแทนการขึ้นบรรทัดใหม่ ตอนนั้นทางเลือกอีกด้านคือระบบจัดการคอนเทนต์ที่หนักมาก
      ฉันผ่านเฟรมเวิร์ก PHP สุดสยองสองตัวที่หัวหน้านักพัฒนาที่ทำงานสร้างไว้ ก่อนจะมาถึง Django ดังนั้นเฟรมเวิร์กอย่าง Django จึงเป็นการเปลี่ยนผ่านที่ค่อยเป็นค่อยไปกว่าและสนุกกว่ามาก
      แน่นอน ถ้าผลักมันไปอีกขั้น เช่นใส่ version control ลงไปใน object ต่าง ๆ มันก็จะยุ่งยากมาก ใช้งานได้ไม่แน่นอน และแก้อะไรก็ไม่ได้แล้ว
      ถึงอย่างนั้น ทัศนคติโดยรวมก็ดูคล้ายกับตอนนี้

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

    • จุดประสงค์ของซอฟต์แวร์คือการเข้ารหัสเจตจำนงของมนุษย์ให้อยู่ในรูปแบบที่เครื่องจักรสื่อสารกันได้
      ข้อไม่พอใจตรงนี้คือ ระบบอัตโนมัตินั้นเสี่ยงจะเข้ารหัส สิ่งที่เราไม่ได้ต้องการ
    • แทนที่จะยอมแพ้กับฟรอนต์เอนด์ ประสิทธิภาพใหม่ที่ AI สร้างขึ้นควรปลดทรัพยากรให้เราผลักดันทั้งฟรอนต์เอนด์และแบ็กเอนด์ได้ไกลกว่าเดิม
      โลกนี้ยังต้องการซอฟต์แวร์มากกว่าที่เราสร้างได้ในตอนนี้อีกมหาศาล
    • ฉันไม่เข้าใจเลยว่าคำว่า “โปรเจ็กต์ฟรอนต์เอนด์มีงานที่ซ้ำ ๆ มาก” หมายถึงอะไรกันแน่
      เป็นความเห็นที่แย่มากจนไม่รู้จะเริ่มโต้แย้งจากตรงไหนดี หมายความว่า UI ทุกตัวมีปุ่มเหมือนกันเลยถือว่าซ้ำ ๆ งั้นหรือ?
      ถ้าคนเชื่อกันแบบนี้จริง ก็พอจะเข้าใจได้ว่าทำไม UX ถึงพังมาตั้งแต่ยุค 90 และยิ่งแย่ลงหลังจากนั้น
    • คุณอาจจะแปลกใจถ้ารู้ว่า “สิ่งที่น่าสนใจ” ให้สร้างนั้นไม่ได้มีมากขนาดนั้น

  • การเขียนโค้ดด้วย AI มีประโยชน์มากในการทำ product prototype แต่ขณะเดียวกันมันก็สร้างผลิตภัณฑ์ที่มองปราดเดียวก็รู้ว่า AI ทำ
    เมื่อกี้นี้เองก็มีสตาร์ตอัปรายหนึ่งเดโมแอปของตัวเอง และแอปนั้นให้ความรู้สึกแบบ UI จาก vibe coding ชัดมาก
    ฟีดแบ็กที่พวกเขาได้รับค่อนข้างเย็นชา แต่ก็ตรงประเด็น: “ก็ดูโอเคอยู่ แต่เห็นชัดเกินไปว่า AI เป็นคนทำ และถ้าเป็นแบบนั้น คนอื่นที่อยากได้สิ่งนี้ก็คงใช้ AI ทำเองได้เร็วมากเหมือนกัน เพราะงั้นสิ่งที่คุณกำลังขายจึงไม่มีมูลค่าอะไรนัก”

    • อยากให้เรื่องแบบนี้เกิดขึ้นมากกว่านี้ ทั้ง UI ที่ LLM สร้างขึ้น และคนที่คิดว่านั่นเพียงพอแล้ว ต่างก็ทนดูได้ยาก
    • เรื่องที่น่าสนใจคือ ถ้าตั้งค่า design system พื้นฐานกับ CSS เอาไว้ก่อน โค้ดฟรอนต์เอนด์ที่ AI สร้างก็เข้ากันได้ค่อนข้างเป็นธรรมชาติ
      แต่คนส่วนใหญ่ก็ไม่ใส่ใจแม้แต่พื้นฐานระดับนั้น
      มุมโค้งมนก็ยังเป็นกระแสที่ไม่มีวันจบ และดูเหมือนทุกอย่างที่ยังไม่ได้ถูกนิยามให้ชัดก็จะติดเชื้อรูปแบบนั้นไปหมด
    • ฟังดูเหมือนภาพฝันในหัวมากกว่าจะเป็นเรื่องที่เกิดขึ้นจริง
      นักลงทุนร่วมทุนที่มีฝีมือจะไม่ให้ฟีดแบ็กไร้สาระแบบนี้หรอก ถ้ามันดี ก็คือดี แล้วจะสนอะไรว่า AI เป็นคนทำ? ถ้าเป็นผลิตภัณฑ์คุณภาพเท่ากันแต่ไม่มีกลิ่น vibe coding จะถือว่าโอเคงั้นหรือ? มีแต่คนที่ต่อต้าน AI ในเชิงอุดมการณ์เท่านั้นแหละที่จะใส่ใจกับเรื่องนี้

  • บางครั้งก็รู้สึกว่าเทคนิคการสร้างส่วนติดต่อผู้ใช้ที่ซับซ้อนด้วย HTML โดยไม่ใช้ AJAX หรือการจัดการ DOM แบบที่เคยมีในช่วงต้นยุค 2000 นั้นแทบสูญหายไปแล้ว ราวกับเทคนิคการสร้างพีระมิด
    นักพัฒนา full-stack รุ่นใหม่มีด้านที่ถูก “ลดทอนทักษะ” ลง จนมีไม่น้อยที่คิดว่าถ้าจะทำการตรวจสอบฟอร์มก็จำเป็นต้องใช้ JavaScript
    พอเริ่มใช้ AJAX และเริ่มจัดการ DOM ความซับซ้อนของการสื่อสารแบบ asynchronous ก็มักจะพาไปสู่บางสิ่งที่มีขนาดใกล้เคียงกับ React อย่างหลีกเลี่ยงไม่ได้ ต่อให้เขียนได้แบบ document.title="A new title" และไม่ต้องดึงอะไรเข้ามาเพิ่มก็ตาม ถ้ามองฟรอนต์เอนด์ว่าเป็นแค่ “เมื่อข้อมูลจากเซิร์ฟเวอร์มาแล้วก็อัปเดต UI” แอปพลิเคชันที่ซับซ้อนก็ยังต้องอัปเดตหลายส่วนของ UI อยู่ดี และเมื่อถึงจุดหนึ่งคุณก็จะลงเอยด้วยการสร้างอะไรอย่างระบบสื่อสารหรือ state management bus ขึ้นมาเอง ถามว่ามันทำแบบอื่นได้ไหม แน่นอนว่าทำได้
    ถ้าจะบอกว่าระบบนิเวศ React มีปัญหา ปัญหาไม่ได้อยู่ที่มันสร้าง abstraction ซ้อนบน abstraction อื่น แต่คือ abstraction นั้นมีการรั่วไหล ถ้าคุณแค่ทำของง่ายมาก ๆ และไม่สนใจหน้าตามากนัก ก็อาจใช้ Bootstrap หรือ MUI ได้โดยไม่ต้องเข้าใจ CSS แต่ถ้าจะทำงานระดับมืออาชีพที่ต้องนำเสนอให้ลูกค้า คุณจำเป็นต้องเข้าใจ HTML, CSS, JS และทุก framework ที่ใช้ในโปรเจกต์

    • โดยเฉพาะใน HN มักรู้สึกว่า React ถูกใช้เหมือนคำด่าสี่ตัวอักษรที่เอาไว้แทนความไม่พอใจที่กว้างกว่าต่อเว็บแบบ interactive โดยรวม
      คนส่วนใหญ่ที่วิจารณ์ React จริง ๆ แล้วไม่ได้เข้าใจว่ามันแก้ปัญหาอะไร ถ้าเอาซอร์สโค้ดของเว็บแอปที่ซับซ้อนพอสมควรแต่ไม่พึ่ง React มาให้ดู คุณก็จะหา ของเลียนแบบ React ที่ทำขึ้นเองอยู่ในนั้นได้

  • ไม่เห็นด้วยว่าการดูแลแอปพลิเคชันฟรอนต์เอนด์ที่ใช้ server-side rendering, lazy loading ฯลฯ ของ NextJS นั้น “ง่ายกว่า” สมัยที่ใช้แค่ HTML, JS, CSS
    ระดับความซับซ้อนและความคาดหวังของผู้ใช้อยู่กันคนละโลกโดยสิ้นเชิง
    แถมตอนนี้ยังมีวิศวกรฝีมือดีมากขึ้นราว 1000 เท่า และต้องแข่งขันกับตลาดทั้งโลก ช่วงต้นยุค 2000 แทบไม่มีการแข่งขันเลย ทักษะของแรงงานโดยมากจะมีความสัมพันธ์แบบหลวม ๆ กับระดับที่ตลาดต้องการ แต่ตอนนี้การแข่งขันรุนแรงอย่างยิ่ง