30 ปีของเว็บผ่านแท็ก `<br>`

• บทความที่สรุปให้เห็นว่าเว็บพัฒนา วิวัฒนาการ มาอย่างไร โดยไล่ตามความเปลี่ยนแปลงตั้งแต่เว็บแบบสแตติกในยุค 1990, เว็บที่มี JavaScript เป็นศูนย์กลางในยุค 2010 ไปจนถึงเว็บในยุค AI ของทศวรรษ 2020
• เว็บที่เริ่มต้นจากแท็ก <br> และ FTP ได้ขยายตัวอย่างรวดเร็วผ่าน PHP และ MySQL จนกลายเป็น แพลตฟอร์มที่ใครก็สร้างได้
• จุดเปลี่ยนในยุค 2000 อย่าง Rails, Git และ Heroku ได้ปรับโฉมการพัฒนาเว็บให้เป็น อุตสาหกรรมที่เน้นโครงสร้าง ระบบอัตโนมัติ และการทำงานร่วมกัน พร้อมวางรากฐานสู่ยุคคลาวด์และมือถือ
• การมาของ React, build chain, Docker และ ecosystem ของ Node ในยุค 2010 ทำให้เว็บถูกตรึงสถานะจากเอกสารธรรมดาไปเป็น แพลตฟอร์มแอปพลิเคชันอย่างเต็มตัว
• ในทศวรรษ 2020 ChatGPT และ Copilot ได้เปลี่ยนวิธีการเขียนโค้ด และกลายเป็นจุดเปลี่ยนใหม่ที่ AI เข้ามาเพิ่มพลังให้ผลิตภาพของนักพัฒนา
• การเปลี่ยนแปลงทั้งหมดนี้เกิดขึ้นโดยแลกกับความซับซ้อน และนำไปสู่ กระบวนการทำให้เว็บเป็นของมหาชน ที่เปิดทางให้ผู้คนจำนวนมากขึ้นสร้างสิ่งที่ยิ่งใหญ่ขึ้นได้

---

The Static Web - ยุคของเว็บแบบสแตติก

"View Source was how you learned"

• เว็บใน ช่วงปลายยุค 90 (late 90s) เป็นดินแดนบุกเบิกที่ไม่มีใครรู้แน่ชัดว่ามันจะกลายเป็นอะไร และความไม่แน่นอนนั้นเองก็เป็นเสน่ห์ของมัน
• เว็บไซต์ส่วนตัวในเวลานั้นเริ่มต้นจาก เซิร์ฟเวอร์ส่วนบุคคลและโฟลเดอร์ของแต่ละคน ไม่ใช่จากบริษัทหรือองค์กร
  • แค่มีไดเรกทอรีส่วนตัวบนเซิร์ฟเวอร์ Unix, ไฟล์ HTML และไคลเอนต์ FTP ก็มีพื้นที่บนอินเทอร์เน็ตได้แล้ว
  • เขียนข้อความด้วยโปรแกรมแก้ไขข้อความง่าย ๆ อย่าง Notepad แล้วเผยแพร่ได้ทันที
• เว็บในยุคนั้นเป็น พื้นที่สร้างสรรค์ที่ไม่มีผู้ตรวจกรองหรือขั้นตอนอนุมัติ
  • โพสต์เนื้อหาได้อย่างอิสระตามความสนใจ เช่น อาหาร ไดโนเสาร์ หรือเพลง
  • เป็นโครงสร้างแบบ “สิ่งที่ฉันสนใจในสัปดาห์นี้” แล้วโพสต์ขึ้นไปได้เลย
• วิธีการเรียนรู้ในเวลานั้นคือ ดูของจริงแล้วทำตามโดยตรง อย่างแท้จริง
  • ยังไม่มี YouTube tutorial หรือ Stack Overflow
  • ถ้าอยากรู้ว่าเว็บอื่นทำอย่างไร ก็คลิกขวา → View Source ซึ่งเป็นเครื่องมือเรียนรู้พื้นฐาน
  • ถ้าอยากลงลึกกว่านั้นก็ต้องเรียนจากหนังสือกระดาษจริง
• การวางหนังสือเทคนิคหนา ๆ หลายร้อยหน้าอย่าง Core Java ไว้ข้างตัว แล้วสลับดูโค้ดกับหนังสือไปมาถือเป็นวิธีเรียนที่พบได้ทั่วไป
  • แม้จะช้า แต่เป็นประสบการณ์การเรียนรู้ที่ทำให้ความรู้ติดตัวได้นาน
• HTML ในเวลานั้นยังอยู่ในสภาพที่โครงสร้างและสไตล์ปะปนกัน
  • แท็ก <table>, <font>, <center> ถูกใช้ทั้งจัดเลย์เอาต์และจัดสไตล์ในเวลาเดียวกัน
  • ใช้ GIF โปร่งใสขนาด 1x1 (spacer GIF) เพื่อปรับช่องว่าง
  • มันหยาบและไม่มีประสิทธิภาพ แต่ ใช้งานได้จริง
• CSS มีอยู่แล้ว แต่ยังแทบไม่ใช่กระแสหลัก
  • สไตล์ส่วนใหญ่ยังใส่ผ่านแอตทริบิวต์แบบอินไลน์หรือตัวแท็ก HTML เอง
  • การจัดเลย์เอาต์แก้กันด้วยตารางซ้อนตาราง
• ฟังก์ชันแบบไดนามิกมีอุปสรรคในการเข้าถึงสูงมาก
  • แม้แต่ฟังก์ชันพื้นฐานอย่างสมุดเยี่ยมชมหรือตัวนับผู้เข้าชมก็ยังต้องใช้ CGI script
  • ต้องเขียนด้วย Perl หรือ C และแค่จัดการ URL parameter เพียงตัวเดียวก็ต้องใช้โค้ดจำนวนมาก
  • ความซับซ้อนนี้จำกัดการแพร่หลายของเว็บแบบไดนามิกอย่างมาก
• ปัญหาเรื่องเลย์เอาต์ร่วมกันแทบไม่มีทางออกที่ดี
  • ต้องคัดลอก/วาง header, navigation และ footer ลงในไฟล์ HTML ทุกไฟล์
  • ถ้าจะแก้ไขก็ต้องแก้ทุกไฟล์
  • มีวิธีแทรกองค์ประกอบร่วมด้วย <iframe> อยู่บ้าง แต่ผลข้างเคียงเยอะ
• ความเข้ากันได้ของเบราว์เซอร์ก็เป็นปัญหาใหญ่ตั้งแต่ตอนนั้นแล้ว
  • Netscape Navigator (1994) และ Internet Explorer (1995) แสดงผลเรนเดอร์ออกมาต่างกัน
  • ถึงขั้นจำเป็นต้องมีข้อความเตือนระบุเบราว์เซอร์และความละเอียดหน้าจอที่รองรับโดยเฉพาะ
• ถึงอย่างนั้น เว็บในยุคนั้นก็ยังมีพลังดึงดูดอย่างมาก
  • สามารถเผยแพร่สู่คนทั่วโลกได้โดยไม่ต้องมีอุปกรณ์สิ่งพิมพ์หรืออุปกรณ์กระจายเสียง
  • เว็บทำให้ การทำให้การแสดงออกเป็นของมหาชน เกิดขึ้นได้จริงเป็นครั้งแรก
• บริการโฮสติ้งฟรีอย่าง GeoCities (1994) และ Angelfire (1996) มอบพื้นที่สร้างสรรค์ให้ผู้คนนับล้าน
  • เว็บไซต์แฟนคลับและชุมชนต่าง ๆ เชื่อมต่อกันผ่าน web ring
  • ก่อเกิดเป็นระบบนิเวศที่วุ่นวายแต่มีชีวิตชีวา
• ในฝั่งองค์กร แนวคิดเรื่อง “ทีมเว็บ” แทบยังไม่มีอยู่จริง
  • ถ้ามีเว็บไซต์ ก็มักเป็นฝีมือของ “คนที่พอรู้เรื่องคอมพิวเตอร์”
  • เป็นช่วง ก่อนที่นักพัฒนาเว็บจะตั้งหลักเป็นอาชีพอย่างเต็มตัว
• แม้เครื่องมือจะดิบและเว็บไซต์จะดูหยาบ ๆ
  • แต่แนวคิดแกนหลักว่าเป็น พื้นที่ที่ใครก็สร้างและแบ่งปันได้ ได้หยั่งรากลงในช่วงเวลานี้
• ยุคที่ขับเคลื่อนต่อมาได้ด้วยแท็ก <br> และความหลงใหลนี้เอง คือจุดเริ่มต้นของวิวัฒนาการเว็บทั้งหมดในภายหลัง

LAMP stack และ Web 2.0

"Everything was PHP and MySQL"

• แม้หลังจาก ฟองสบู่ดอตคอมแตกในปี 2000 เว็บก็ยังคงเติบโตต่อไป และช่วงเวลานี้ได้กลายเป็น จุดเปลี่ยนที่ลดกำแพงการเข้าถึงลงอย่างรวดเร็ว สำหรับผู้คนที่อยากสร้างอะไรบางอย่าง
• จุดทะลุทะลวงที่ใหญ่ที่สุดของยุคเว็บแบบสแตติกคือ PHP(1995)
  • จากยุคที่ต้องเขียนโค้ด C หรือ Perl หลายร้อยบรรทัดเพื่อใช้ CGI การที่สามารถอ่าน URL parameter ได้ด้วย $_GET['name'] เพียงบรรทัดเดียวถือเป็นความเปลี่ยนแปลงครั้งสำคัญ
  • ไม่ต้องคอมไพล์ ไม่ต้องจัดการหน่วยความจำ ไม่มีข้อความ error ที่เข้าใจยาก แค่บันทึกแล้วรีเฟรชก็ทำงานได้
  • XAMPP(2002) ทำให้สามารถติดตั้ง Apache, MySQL และ PHP ได้พร้อมกันในครั้งเดียว ทำให้การตั้งค่า local development environment ง่ายขึ้นอย่างมาก
  • PHP เป็นตัวแรกที่แก้ปัญหา การใช้เลย์เอาต์ซ้ำ ในยุคเว็บแบบสแตติกได้อย่างจริงจัง
    • แค่ include 'header.php' หนึ่งบรรทัดก็จัดการ header และ footer ร่วมกันได้
    • ประสบการณ์ที่แก้ครั้งเดียวแล้วทั้งเว็บไซต์เปลี่ยนตามสร้างความตื่นเต้นอย่างมาก
  • แม้จะมีข้อบกพร่องในระดับภาษา จุดแข็งของ PHP คือ การเข้าถึงได้ง่าย
    • แม้ HTML กับ logic จะปะปนกัน การตั้งชื่อฟังก์ชันไม่สม่ำเสมอ และ security API จะหยาบมาก
    • แต่ก็สามารถเรียนรู้ในสุดสัปดาห์เดียวแล้วสร้างบริการจริงได้
    • ด้วย shared hosting($5/เดือน) และการมี cPanel(1996), phpMyAdmin(1998) ให้มาเป็นพื้นฐาน ทำให้กำแพงการเริ่มต้นออนไลน์ต่ำที่สุดในประวัติศาสตร์
• ฐานข้อมูลที่แทบจะมาเป็นชุดเดียวกับ PHP คือ MySQL(1995)
  • แทบทุก tutorial, hosting และ CMS ล้วนถูกออกแบบโดยตั้งสมมติฐานว่าต้องใช้ MySQL
  • ด้านฟังก์ชันถือว่าเพียงพอ แต่การจัดการข้อความหลายภาษานั้นเต็มไปด้วยความเจ็บปวด
  • encoding เริ่มต้นคือ latin1 และถ้าจะใช้ UTF-8 ให้ถูกต้อง
    • ก็ต้องตั้งค่า database, connection encoding และประกาศ HTML charset ให้ตรงกันทั้งหมด
  • ปัญหา “ä แทนที่จะเป็น ä” กลายเป็นบาดแผลทางใจที่เป็นสัญลักษณ์ของยุคนี้
• WordPress(2003) เปลี่ยนธรรมชาติของเว็บไปโดยสิ้นเชิง
  • ไม่ต้องรู้โค้ดก็สามารถติดตั้งใน 5 นาทีแล้วเริ่มเผยแพร่ได้ทันที
  • แค่เลือกธีมและเขียนบทความก็สามารถดูแลเว็บไซต์ได้
  • ทำให้การสร้างเว็บไซต์แบบ แมส เกิดขึ้นจริงในทางปฏิบัติ
  • สำหรับผู้ใช้ที่ไม่ใช่สายเทคนิค WordPress คืออิสรภาพ
    • ไม่ว่าจะเป็นบล็อกเกอร์ เจ้าของกิจการรายย่อย ศิลปิน หรือร้านอาหาร ต่างก็มีเว็บไซต์ของตัวเองได้
    • เกิดอัตลักษณ์ใหม่ในชื่อ “บล็อกเกอร์”
    • แพร่หลายถึงระดับที่หน้าแอดมินของ WordPress ถูกมองว่าเป็น “ตัวแก้ไขเว็บไซต์” โดยตรง
  • สำหรับนักพัฒนา WordPress กลายเป็นเครื่องมือสารพัดประโยชน์แทบทุกอย่าง
    • ทั้งบล็อก พอร์ตโฟลิโอ เว็บไซต์องค์กร คอมมูนิตี้ และอีคอมเมิร์ซ ล้วนทำด้วย WordPress
    • รับเอา อีคอมเมิร์ซ เข้ามาด้วย WooCommerce(2011)
    • แต่แลกกับความเร็วในการพัฒนาด้วยการสะสม technical debt จากปลั๊กอินจำนวนมากและการคัสตอมธีม
• เหตุการณ์ที่นิยามความเป็นไปได้ของเว็บขึ้นมาใหม่อย่างรากฐานคือการเปิดตัว Gmail(2004)
  • ในยุคที่ Hotmail และ Yahoo Mail ยังให้พื้นที่เก็บข้อมูลเพียงไม่กี่ MB
  • พื้นที่ฟรี 1GB เป็นตัวเลขที่น่าตกใจมาก
  • ข้อความที่ว่า “อย่าลบ ให้ค้นหาแทน” เสนอวิธีใช้งานแบบใหม่
  • นวัตกรรมที่แท้จริงของ Gmail ไม่ใช่พื้นที่เก็บข้อมูล แต่คือ ประสบการณ์
    • อินเทอร์เฟซที่อ่าน เขียน และสลับอีเมลได้โดยไม่ต้องรีเฟรชหน้า
    • ใช้การสื่อสารแบบ asynchronous บนพื้นฐาน AJAX(XMLHttpRequest) อย่างเต็มรูปแบบ
    • พิสูจน์ว่าเว็บไม่จำเป็นต้องเป็นเอกสาร แต่สามารถเป็น แอปพลิเคชัน ได้
• Google Maps(2005) ยกระดับความเป็นไปได้นี้ขึ้นไปอีกขั้น
  • เลื่อนแผนที่ได้ด้วยการคลิกและลาก
  • อินเทอร์แอ็กชันที่เป็นธรรมชาติจากการโหลด tile แบบพื้นหลัง
  • ณ จุดนี้คำว่า Web 2.0 เริ่มปักหลักอย่างจริงจัง
  • UI แบบไม่ต้องรีเฟรช มุมโค้ง gradient และเงา กลายเป็นภาษาพื้นฐานของเว็บ
• ในด้านสื่อและโซเชียลก็มีการเปลี่ยนแปลงครั้งสำคัญต่อเนื่อง
  • ในฝั่งวิดีโอ YouTube(2005) เปลี่ยนกระดานทั้งหมด
    • ปิดฉากนรกของปลั๊กอินอย่าง RealPlayer, QuickTime และ Windows Media Player
    • แม้จะอยู่บน Flash แต่ก็มอบประสบการณ์แบบ “คลิกแล้วเล่นได้ทันที”
    • วิดีโอไม่ใช่ปัญหาทางเทคนิคอีกต่อไป แต่กลายเป็น เครื่องมือในการสื่อสาร
  • Twitter(2006) นำเสนอรูปแบบการสื่อสารใหม่ผ่านไมโครบล็อก 140 ตัวอักษร
  • Facebook(2006) เปิดให้ผู้ใช้ทั่วไปใช้งาน ทำให้โซเชียลเน็ตเวิร์กกลายเป็นกระแสหลัก
  • เว็บเปลี่ยนจากสื่อเพื่อการบริโภคไปสู่ แพลตฟอร์มแบบมีส่วนร่วม
    • ก่อให้เกิดโครงสร้างที่ทุกคนสามารถเป็นทั้งผู้เผยแพร่และผู้สร้างสรรค์ได้
• แม้จะมีการเปลี่ยนแปลงทั้งหมดนี้ JavaScript ก็ยังคงสร้างความเจ็บปวดอยู่ดี
  • การดีบักไม่รู้จบจากความต่างกันของการทำงาน DOM, event และ AJAX ระหว่างเบราว์เซอร์ รวมถึงปัญหาความเข้ากันได้กับ IE6
  • jQuery(2006) แทบจะยุติความสับสนนี้ได้โดยสิ้นเชิง
    • $('#el').hide() ทำงานเหมือนกันในทุกเบราว์เซอร์
    • $.ajax() ทำให้การสื่อสารแบบ asynchronous ง่ายขึ้น
    • สำหรับนักพัฒนาจำนวนมาก jQuery ก็คือ JavaScript เอง
      • ในขณะเดียวกันมันก็ทำหน้าที่เป็นชั้นกันกระแทกที่ทำให้ไม่ต้องเข้าใจกลไกการทำงานของเบราว์เซอร์โดยตรง
  • ปัญหาในยุคนี้กว่าจะถูกรับรู้ว่าเป็นปัญหาก็ต้องใช้เวลาอีกนาน
    • SQL Injection และ XSS แพร่หลายแม้กระทั่งในระดับ tutorial
    • โค้ดที่นำ input จากผู้ใช้ไปต่อกับ query ตรง ๆ เป็นเรื่องปกติ
• การจัดการเวอร์ชันมี Subversion(2000) เป็นกระแสหลัก
  • การ commit มีน้ำหนักมาก และ branch เป็นสิ่งที่คนหลีกเลี่ยง
  • ชื่อโฟลเดอร์อย่าง final_final_REAL เป็นเรื่องปกติในชีวิตประจำวัน
• ยังไม่มีมาตรฐานของ runtime environment
  • ฝั่ง local คือ Windows + XAMPP
  • ฝั่งเซิร์ฟเวอร์คือ Linux + PHP คนละเวอร์ชัน
  • คำว่า “works on my machine” จึงเกิดขึ้นซ้ำแล้วซ้ำเล่า
• แนวคิดเรื่อง package manager ก็ยังไม่มีเช่นกัน
  • ฝั่ง JS ต้องดาวน์โหลด ZIP แล้วจัดการเองในโฟลเดอร์ /js
  • ไลบรารี PHP ใช้วิธีคัดลอกไฟล์เป็นหลัก
• โครงสร้างทีมและกระบวนการพัฒนายังไม่เป็นทางการอย่างมาก
  • แทบไม่มีบทบาท PM หรือ EM
  • ไม่มี code review
  • อัปโหลดผ่าน FTP แล้วขึ้นใช้งานจริงทันที
  • ถ้าเกิดปัญหาก็แก้สดบน production server ตรงนั้นเลย
• ถึงอย่างนั้น พลังงานของยุคนี้ก็เข้มข้นอย่างมาก
  • ด้วย PHP และ hosting ราคาถูก ทำให้ ใครก็ deploy ได้
  • เกิดความรู้สึกแพร่หลายว่า AJAX ทำให้สร้าง “แอปจริง” ได้
  • แพลตฟอร์มโซเชียล ทำให้ทุกคนมีผู้ชมของตัวเองได้
• นี่คือช่วงที่ การพัฒนาเว็บเริ่มกลายเป็นวิชาชีพและมีโครงสร้างมากขึ้น
  • Ruby on Rails(2004) ส่งสัญญาณถึงยุคถัดไปที่มีโครงสร้างมากกว่าเดิมด้วยแนวคิด “Convention over Configuration”
• นักพัฒนาในยุคนี้สร้างเว็บขึ้นมาท่ามกลาง LAMP stack, ปลั๊กอิน jQuery และ
  • ความคาดหวังว่า “เราจะสร้างบริการใหญ่ตัวถัดไป”

สงครามเฟรมเวิร์ก

"Rails changed everything, then everyone copied it"

• ปลายยุค 2000s (late 2000s) เมื่อเว็บแอปพลิเคชันมีขนาดใหญ่ขึ้น สคริปต์ PHP แบบเดิมและโครงสร้างที่พึ่งงานทำมือก็เริ่มชนเพดานของตัวเอง

• ทางออกในช่วงเวลานั้นคือ แนวทางการพัฒนาแบบยึดเฟรมเวิร์กเป็นศูนย์กลาง และผู้ที่กำหนดทิศทางของกระแสนี้ก็คือ Ruby on Rails(2004)

  • อิทธิพลที่แท้จริงของ RoR เริ่มเด่นชัดอย่างจริงจังราว 2007–2008
  • ด้วยปรัชญา “Convention over Configuration” เฟรมเวิร์กจึงเป็นฝ่ายกำหนดโครงสร้างไฟล์ การตั้งชื่อ และวิธีเชื่อมโยงต่าง ๆ แทน
  • นักพัฒนาเพียงแค่ทำตามกฎ และสิ่งนี้ไม่ได้ถูกมองว่าเป็นข้อจำกัด แต่เป็นอิสรภาพที่ช่วยเพิ่มความเร็ว

• หลังจากนั้น Rails ได้นำเสนอแนวคิดที่กลายเป็นไวยากรณ์พื้นฐานของการพัฒนาเว็บแบบรวมชุดในคราวเดียว

  • migration สำหรับจัดการการเปลี่ยนแปลงฐานข้อมูลด้วยโค้ด
  • ORM ที่ลดการพึ่งพา SQL ลงอย่างมาก
  • เวิร์กโฟลว์การพัฒนาที่มีการทดสอบมาให้เป็นพื้นฐาน
  • การทำให้โครงสร้าง MVC(Model–View–Controller) กลายเป็นมาตรฐานในทางปฏิบัติ
  • เดิม MVC เป็นแนวคิดที่มีรากมาจาก Smalltalk ในยุค 1970s แต่ผ่าน Rails มันจึงถูกทำให้แข็งตัวเป็นรูปแบบพื้นฐานของการพัฒนาเว็บ
  • หลัง Rails ประสบความสำเร็จ แทบทุก ecosystem ของภาษาต่างก็หยิบสูตรนี้ไปใช้
    • Django(2005) ในฝั่ง Python และ Laravel(2011) ในฝั่ง PHP ทำให้โครงสร้างแบบ Rails ฝังราก
    • CakePHP(2005) และ CodeIgniter(2006) ก็เติบโตบนกระแสเดียวกัน
  • การเพิ่มขึ้นของ productivity ไม่ใช่เรื่องพูดเกินจริง
    • สิ่งที่นักพัฒนาเดี่ยวทำได้ในช่วงสุดสัปดาห์ กลับเคยเป็นงานระดับที่ต้องใช้ทั้งทีมในอดีต
    • ในสภาพแวดล้อมของสตาร์ตอัป มันทำหน้าที่เป็นเครื่องมือที่เหมาะอย่างยิ่งสำหรับการทดลองและวนซ้ำอย่างรวดเร็ว
  • ในความเป็นจริง มีหลายบริการชื่อดังที่เติบโตขึ้นบน Rails
    • Basecamp(2004), Twitter(2006), GitHub(2008), Shopify(2006), Airbnb(2008)
    • Rails จึงถูกมองในไม่ช้าว่าเป็น สัญลักษณ์ของความเร็วแบบสตาร์ตอัป

• แม้เฟรมเวิร์กจะยกระดับ productivity ได้ แต่ การ deploy ยังเป็นคอขวดอยู่ดี

  • ในยุค PHP การ deploy ด้วยการอัปโหลดผ่าน FTP เป็นเรื่องปกติ และเป็นโครงสร้างที่แค่พลาดครั้งเดียวก็ทำให้บริการพังได้
  • แม้จะเป็นกรณีที่ดีกว่านั้น ก็ยังต้องจัดการงานอย่าง SSH + SVN pull + รีสตาร์ต Apache แบบ manual
  • ไม่ว่าจะเป็นการแยก release directory หรือการสลับ symbolic link ทุกขั้นตอนล้วน custom และเปราะบาง

• สิ่งที่เปลี่ยนปัญหานี้ในระดับรากฐานคือ Heroku(2007) ซึ่งเริ่มแพร่หลายอย่างจริงจังราว 2009–2010

  • มอบประสบการณ์ที่ deploy เสร็จได้ด้วยคำสั่งบรรทัดเดียว git push heroku main
  • แพลตฟอร์มเป็นผู้จัดการแทนทั้งการตั้งค่าเซิร์ฟเวอร์ การรีสตาร์ตเว็บเซิร์ฟเวอร์ และการสเกล
  • หลังจากนั้น Heroku ก็ทำให้แนวคิดที่ต่อมาถูกเรียกว่า PaaS(Platform as a Service) ตั้งหลักได้จริงในทางปฏิบัติ
    • นักพัฒนาจึงขยับบทบาทจากการสนใจ infrastructure ไปสู่การโฟกัสที่โค้ดเพียงอย่างเดียว
    • พร้อมทั้งทำให้หลักการ Twelve-Factor App(2011) เป็นที่แพร่หลาย และกระจายแนวคิดแบบ cloud-friendly เช่น stateless process, การตั้งค่าด้วย environment variable และการทำ log ให้เป็น stream

• ในช่วงเวลาเดียวกัน ก็เกิด การเปลี่ยนผ่านครั้งใหญ่ของวิธีทำงานร่วมกัน เช่นกัน

  • Git(2005) นำโมเดล version control แบบกระจายมาใช้ ทำให้ commit·branch·merge ได้อย่างอิสระบนเครื่อง local และเพราะ ต้นทุนของ branch แทบไม่มี การทดลองและการย้อนกลับจึงกลายเป็นงานประจำวัน
  • ส่วน Subversion(2000) เดิมนั้นเป็นโครงสร้างแบบรวมศูนย์ branch มีน้ำหนักมาก และ merge เป็นสิ่งที่น่ากลัว ทำให้หลายทีมพึ่งการพัฒนาแบบยึด trunk เป็นศูนย์กลาง
  • Git เป็นนวัตกรรมในระดับเครื่องมือ แต่ GitHub(2008) ที่ผสานการสำรวจ public repository การพัฒนาแบบ fork และการทำงานร่วมกันโดยมี Pull Request เป็นศูนย์กลาง ได้ทำให้มันฝังรากเป็นวัฒนธรรม
  • GitHub ทำให้ วัฒนธรรม code review กลายเป็นมาตรฐาน
    • ก่อน merge PR จะต้องมีใครสักคนเข้ามาดูโค้ดเสมอ
    • กระแสนี้ขยายไปถึงการพัฒนาภายในบริษัทด้วย
    • ยุคที่โค้ดถูกส่งเข้า production โดยตรงจึงสิ้นสุดลง
  • วิธีมีส่วนร่วมกับโอเพนซอร์สก็เปลี่ยนจากการ ส่ง patch ทาง mailing list ไปเป็น กดปุ่มส่ง PR ทำให้กำแพงการเข้าร่วมลดลงอย่างมาก

• ในช่วงปลายของยุคนี้ ยังมีความเปลี่ยนแปลงที่สั่นคลอนอัตลักษณ์ของเว็บด้วย

  • การเปิดตัว iPhone(2007) และ App Store(2008) ทำให้แอปเนทีฟพุ่งขึ้นอย่างรวดเร็ว
  • เว็บบนมือถือในเวลานั้นมีคุณภาพย่ำแย่มาก เป็นประสบการณ์แบบย่อไซต์เดสก์ท็อปลงมาดูอย่างฝืน ๆ พร้อมการเลื่อนแนวนอนและการซูมเข้าออกซ้ำแล้วซ้ำเล่า
    • บางแห่งสร้างไซต์มือถือแยกอย่าง m.example.com แต่ข้อจำกัดก็ชัดเจน
  • แอปเนทีฟทั้งเร็ว รองรับออฟไลน์ มี push notification และคำขวัญ “There’s an app for that” ก็ทำให้มันดูเหมือนอนาคต
  • นักพัฒนาเว็บเริ่มเผชิญ วิกฤตตัวตน : ควรทำเว็บต่อไปไหม? ต้องไปเรียน Objective-C ไหม? เว็บจะหายไปหรือเปล่า?

• คำตอบต่อความสับสนนี้คือการมาของ Responsive Web Design(2010)

  • Ethan Marcotte(2010) เสนอแนวทางใช้ CSS media query เพื่อปรับ layout ตามขนาดหน้าจอ ชี้ทิศทางสู่การรวมมือถือและเดสก์ท็อปไว้ใน codebase เดียว
  • ในช่วงแรกการแพร่หลายยังช้า เพราะเครื่องมือยังไม่สุกงอมและมีภาระงานเพิ่ม แต่ทิศทางที่เว็บควรเดินไปนั้นชัดเจนแล้ว

• Bootstrap(2011) คือจุดเปลี่ยนที่ทำให้ responsive web ถูกใช้งานจริงในภาคสนาม

  • มันเริ่มจากเครื่องมือภายในของ Twitter แล้วมอบทั้ง grid system, typography พื้นฐาน และ style ของฟอร์มในคราวเดียว จนแม้นักพัฒนาที่ไม่มีดีไซเนอร์ก็สามารถใช้ UI ได้ทันที
  • ผลก็คือเว็บเริ่มดูคล้ายกันมากขึ้นเรื่อย ๆ แต่สำหรับนักพัฒนาจำนวนมาก Bootstrap คือทั้ง component library ตัวแรกและประสบการณ์แรกกับ design system
  • กระแสนี้ต่อมายังเชื่อมไปสู่การแพร่หลายของ design system ที่เป็นระบบมากขึ้นอย่าง Material Design(2014)

• Infrastructure ก็เปลี่ยนอย่างรวดเร็วในช่วงเดียวกัน

  • จากแนวทางที่ต้องซื้อหรือเช่า physical server ล่วงหน้า เปลี่ยนไปสู่โครงสร้างที่ยึด virtual server(VPS) เป็นหลัก ทำให้สามารถสร้างทรัพยากรเซิร์ฟเวอร์ได้เมื่อจำเป็น
  • AWS(2006) มาก่อนใคร แต่ด้วยความซับซ้อนและความเป็น enterprise-oriented จึงยังเป็นภาระสำหรับนักพัฒนาเดี่ยว
  • DigitalOcean(2011) ลดกำแพงการเข้าถึง infrastructure อย่างมากด้วย droplet ราคา $5, UI ที่เข้าใจง่าย และประสบการณ์สร้างเซิร์ฟเวอร์ที่รวดเร็ว ทำให้นักพัฒนาเดี่ยวมีความยืดหยุ่นใกล้เคียงบริษัทใหญ่ได้

• ปัญหาเรื่องการเก็บไฟล์นั้น Amazon S3(2006) แทบจะแก้ได้อย่างสิ้นเชิง

  • มันมอบโมเดลที่เรียบง่าย คือ storage ที่สเกลได้โดยไม่ขึ้นกับจำนวนเซิร์ฟเวอร์ และคืน URL ได้ทันทีหลังอัปโหลด
  • ปัญหาเรื่องการอัปโหลดของผู้ใช้ การสำรองข้อมูล และการจัดการไฟล์ในสภาพแวดล้อมหลายเซิร์ฟเวอร์จึงถูกจัดการได้ในคราวเดียว

• Node.js(2009) ก็สร้างแรงกระแทกอีกแบบให้กับนักพัฒนาเว็บ

  • ด้วยการทำให้รัน JavaScript บนเซิร์ฟเวอร์ได้บนพื้นฐานของเอนจิน Chrome V8 มันจึงดูเป็นทางเลือกที่น่าดึงดูดสำหรับนักพัฒนาฝั่งฟรอนต์เอนด์ และเรียกปฏิกิริยาแบบกังขาจากนักพัฒนาฝั่งแบ็กเอนด์
  • โมเดล non-blocking I/O แสดงจุดแข็งกับแอปพลิเคชันแบบเรียลไทม์ และบทเรียนส่วนใหญ่ก็มักลงเอยที่ตัวอย่างแอปแชต
  • อย่างไรก็ตาม ในช่วงนั้น Node ยังใกล้เคียงกับสิ่งชวนสงสัยมากกว่าจะเป็นกระแสหลักของ production โดยบริการจริงยังคงมี Rails·Django·PHP เป็นศูนย์กลาง และ ecosystem ของ npm ก็ยังอยู่ในระยะเริ่มต้น
  • แต่ในเวลาต่อมา อิทธิพลที่แท้จริงของ Node กลับปรากฏก่อนในฐานะรากฐานสำหรับ build tool และสภาพแวดล้อมการพัฒนา มากกว่าตัวเซิร์ฟเวอร์เอง

• ในโลกฐานข้อมูล กระแส NoSQL ก็เริ่มเด่นขึ้น

  • MongoDB(2009) ได้รับความสนใจจากโมเดลข้อมูลแบบ document ความยืดหยุ่นของ schema และโครงสร้างที่เป็นมิตรกับ JSON
  • มันมีจุดแข็งด้านการทำ prototyping อย่างรวดเร็ว ความสามารถในการขยาย และความเข้ากันได้กับ JavaScript stack แต่ก็ไม่ได้เหมาะกับทุกบริการ
  • หลายกรณีเลือกมันเพราะคิดว่า “สักวันอาจต้อง scale” แต่พอถึงระดับผู้ใช้หลักพันกลับเริ่มสัมผัสข้อจำกัดด้าน transaction ก็มีให้เห็นบ่อย

• ระบบนิเวศสตาร์ตอัปก็เข้าสู่ช่วงเติบโตอย่างจริงจังในเวลานี้

  • จากคำประกาศ “Software is eating the world” ของ Marc Andreessen(2011) และการแพร่หลายของวิธีคิด Lean Startup(2011) วงจร MVP → วัดผล → วนซ้ำ จึงเริ่มฝังราก

• เมื่อเครื่องมือพัฒนาจนพร้อมมากขึ้น ความสามารถในการแข่งขันของทีมขนาดเล็กก็เริ่มใช้ได้ผลจริง

• กระบวนการพัฒนาก็เปลี่ยนไปเช่นกัน

  • Agile Manifesto (2001) และ Scrum กลายเป็นที่แพร่หลาย ทำให้การสแตนด์อัป สปรินต์ และรีโทรสเปกทีฟถูกนำมาใช้ราวกับเป็นมาตรฐาน
  • หลายทีมก็เหลือเพียงรูปแบบภายนอกโดยไม่มีหลักการอยู่เบื้องหลัง
  • การรีวิวโค้ดและการทดสอบอัตโนมัติขยับจากสิ่งที่แนะนำไปสู่ความคาดหวังพื้นฐาน และระบบ CI ก็รันทดสอบทุกครั้งที่มีการคอมมิต ทำให้การพัฒนาซอฟต์แวร์มีความเป็นวิชาชีพและความเชี่ยวชาญเฉพาะทางมากขึ้นอย่างรวดเร็ว

• อย่างไรก็ตาม บทบาทที่ทุกวันนี้ถูกมองว่าเป็นเรื่องปกติในตอนนั้นยังไม่ลงหลักปักฐาน

  • ณ ปี 2012 ยังพบได้บ่อยว่าทีมไม่มี engineering manager, product manager, หรือระบบจัดการแบ็กล็อกและตั๋วงานอย่างเป็นระบบ
  • ทีมขนาดเล็กและโครงสร้างองค์กรแบบแบนเป็นเรื่องปกติ และกรณีที่ “นักพัฒนาอาวุโส” มีประสบการณ์เพียง 3 ปีก็ไม่ใช่เรื่องแปลก

• ราวปี 2013 เว็บก็มีหน้าตาเปลี่ยนไปอย่างสิ้นเชิง

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

เรอเนซองส์ของ JavaScript

"Everything is a SPA now"

• ราวปี 2013 เว็บได้พิสูจน์ไปแล้วผ่านกรณีอย่าง Gmail และ Google Maps ว่าสามารถรองรับ “แอปพลิเคชันจริงจัง” ได้ แต่แนวทางแบบ jQuery + server rendering เดิมเริ่มชนข้อจำกัดมากขึ้นเรื่อย ๆ :contentReference[oaicite:0]{index=0}
• ปัญหาหลักคือเรื่อง การจัดการสถานะ (state)
  • ในโครงสร้างที่เซิร์ฟเวอร์สร้าง HTML แล้วค่อยเติมปฏิสัมพันธ์ด้วย jQuery การรักษาความสอดคล้องระหว่างข้อมูลและ UI ในหลายตำแหน่งกลายเป็นเรื่องยากขึ้นอย่างรวดเร็ว
  • ยิ่งสถานะเดียวกันต้องสะท้อนใน UI หลายส่วน เช่น คอมเมนต์ ตัวนับ หรือป้ายแจ้งเตือน โค้ดก็ยิ่งพันกันจนกลายเป็นสปาเกตตี
• ข้อสรุปร่วมกันเพื่อตอบโจทย์นี้คือ ย้ายการเรนเดอร์ทั้งหมดไปไว้ฝั่งไคลเอนต์
  • เซิร์ฟเวอร์ถูกลดบทบาทเหลือเพียง API ที่ส่งคืน JSON
  • โครงสร้างแบบ SPA (Single Page Application) ที่ JavaScript ในเบราว์เซอร์จัดการ UI ทั้งหมดเริ่มได้รับความนิยม
• เฟรมเวิร์ก SPA รุ่นแรก ๆ ปรากฏขึ้นในช่วงนี้
  • Backbone.js (2010) มอบโครงสร้างขั้นต่ำผ่านแนวคิด model และ view
  • Angular (2010) นำ two-way data binding และ dependency injection เข้ามา พร้อมลองใช้แนวทางแบบ enterprise
  • Ember.js (2011) เสนอกรอบที่มีกฎเข้มแข็ง โดยตั้งเป้าเป็น “Rails ของ JavaScript” ที่รวม routing, data และ template ไว้ครบ
  • แม้เฟรมเวิร์กเหล่านี้จะเป็นก้าวสำคัญ แต่ก็ยังไม่ได้แก้ปัญหา ความซับซ้อนของการซิงก์ DOM กับข้อมูล ได้อย่างสมบูรณ์
    • โดยเฉพาะ two-way binding ที่ทำให้ติดตามลำดับการอัปเดตได้ยาก และเพิ่มต้นทุนในการดีบัก
• จุดเปลี่ยนมาถึงเมื่อ React (2013) ปรากฏตัว
  • ตอนที่ Facebook เปิดซอร์ส JSX ดูเหมือนย้อนทางแนวคิดเรื่อง separation of concerns จนทำให้หลายคนต่อต้าน
  • แต่ React เสนอวิธีคิดใหม่ คือไม่แก้ DOM โดยตรง แต่ ประกาศผลลัพธ์ของ UI ตามสถานะแบบ declarative
  • แกนสำคัญของ React คือ โมเดลแบบ declarative และ Virtual DOM
    • เมื่อสถานะเปลี่ยน React จะคำนวณและสะท้อนเฉพาะการเปลี่ยนแปลง DOM ที่จำเป็นขั้นต่ำ
    • นักพัฒนาจึงโฟกัสกับการจัดการสถานะได้ โดยไม่ต้องกังวลกับการแก้ DOM โดยตรง
  • แนวคิดเรื่อง component ก็ถือเป็นปัจจัยชี้ขาดเช่นกัน
    • UI ถูกประกอบจากหน่วยเล็ก ๆ อย่าง Button, UserAvatar, CommentList
    • แต่ละคอมโพเนนต์คิดแยกจากกันได้และนำกลับมาใช้ซ้ำได้
  • React ค่อย ๆ แพร่หลายและ กลายเป็นกระแสหลักราวปี 2015
    • Vue.js (2014) ก็ผงาดขึ้นมาเป็นทางเลือกด้วยแนวคิดคล้ายกันแต่ใช้ไวยากรณ์ที่เข้าถึงง่ายกว่า
    • สงครามเฟรมเวิร์กจึงเข้าสู่ระยะใหม่
• การแพร่หลายของ SPA หมายถึง ปริมาณ JavaScript ที่เพิ่มขึ้นอย่างระเบิดระเบ้อ
  • ปัญหาคือ JavaScript ที่นักพัฒนาอยากเขียน กับ JavaScript ที่เบราว์เซอร์เข้าใจ ยังเป็นคนละเรื่องกัน
• ES6 / ES2015 (2015) นำการปรับปรุงภาษาอย่างใหญ่หลวงเข้ามา เช่น arrow function, class, module และ promise
  • callback hell และแพตเทิร์น var self = this หายไป ทำให้ JavaScript เริ่มให้ความรู้สึกเหมือนภาษาสมัยใหม่อย่างแท้จริง
• แต่การรองรับของเบราว์เซอร์ยังตามไม่ทัน และไม่สามารถ deploy โค้ดแบบนั้นตรง ๆ ได้
• Babel (2014) แก้ปัญหานี้ด้วยการเป็น transpiler ที่แปลง JavaScript รุ่นใหม่ให้เป็น ES5
  • แต่สิ่งที่ต้องแลกมาคือ ขั้นตอน build กลายเป็นส่วนจำเป็นของการพัฒนา JavaScript
  • ยุคที่แก้ไฟล์แล้วรีเฟรชก็จบได้สิ้นสุดลง
• ในกระบวนการนี้ Node.js (2009) เข้ายึดทุกเครื่องนักพัฒนา ไม่ใช่ในฐานะเซิร์ฟเวอร์ แต่เป็น สภาพแวดล้อมสำหรับรันเครื่องมือพัฒนา
  • ต่อให้ไม่ได้ใช้ Node เป็นแบ็กเอนด์ ก็ยังต้องติดตั้งเพราะเครื่องมือ build บังคับให้มี
• สายโซ่เครื่องมือ build ก็พัฒนาอย่างรวดเร็วเช่นกัน
  • Grunt (2012) เป็น task runner ที่จัดการขั้นตอน build อันซับซ้อนผ่านไฟล์คอนฟิก
  • Gulp (2013) พยายามทำให้เรียบง่ายขึ้นด้วย pipeline แบบเขียนเป็นโค้ด แต่ก็ยังซับซ้อนอยู่ดี
• การเปลี่ยนแปลงครั้งชี้ขาดคือ Webpack (2014)
  • มันไม่ใช่แค่ task runner แต่เป็น module bundler ที่เข้าใจกราฟของ dependency
  • ทั้ง JavaScript, CSS, รูปภาพ และฟอนต์ ล้วนถูกปฏิบัติเป็นโมดูล
  • มีการนำแนวคิดอย่าง code splitting และ hot module replacement เข้ามา
  • แต่พลังอันสูงส่งก็มาพร้อมกับคอนฟิกที่ขึ้นชื่อลือชาเรื่องความโหด
    • คอนฟิก Webpack กลายเป็นมีม และแต่ละทีมมักมี “คนคนเดียวที่เข้าใจมัน”
    • ถ้าคนนั้นลาออก คอนฟิกก็จะกลายเป็นโบราณวัตถุที่ไม่มีใครกล้าแตะ
• ในเวลาเดียวกัน ระบบนิเวศ npm ก็เติบโตแบบระเบิด
  • จากเดิมที่ต้องดาวน์โหลดไลบรารีด้วยตัวเอง เปลี่ยนมาเป็นโลกที่มี npm install เป็นศูนย์กลาง
  • ทั้ง moment, lodash แม้กระทั่งยูทิลิตีจิ๋วอย่าง left-pad ก็ถูกทำเป็นแพ็กเกจ
  • เหตุการณ์ left-pad (2016) เผยให้เห็นความเปราะบางของระบบนิเวศนี้
    • เมื่อแพ็กเกจที่มีเพียง 11 บรรทัดถูกลบ โปรเจกต์นับพันก็ build ล้มพร้อมกัน
    • แม้แต่ React และ Babel ก็เข้าสู่ภาวะติดตั้งไม่ได้
    • npm ต้องใช้มาตรการที่ไม่เคยมีมาก่อนด้วยการบังคับกู้คืนแพ็กเกจเพื่อยุติวิกฤต
  • แม้ความสะดวกจะยังคงอยู่ แต่ทุกคนก็เริ่มตระหนักถึง ความจริงของ dependency hell
• ปี 2016 ความซับซ้อนพุ่งถึงจุดสูงสุด
  • บทความเสียดสี “How it feels to learn JavaScript in 2016” แพร่กระจายอย่างกว้างขวาง
  • ความเหนื่อยล้าจากการที่แค่จะทำเว็บเพจธรรมดาก็ต้องใช้เครื่องมือจำนวนมากอย่าง React, Webpack, Babel, Redux เริ่มขยายวง
  • ความเร็วในการเปลี่ยนแปลงของระบบนิเวศสูงจนความรู้ที่เพิ่งเรียนมากลายเป็นของล้าสมัยอย่างรวดเร็ว
  • ถึงอย่างนั้น ผลลัพธ์ก็ชัดเจน
    • สามารถสร้างเว็บแอปแบบ interactive ในระดับที่ก่อนหน้านั้นเป็นไปไม่ได้
    • ความซับซ้อนถูกยอมรับในฐานะ ต้นทุนของความทะเยอทะยาน
• อีกด้านหนึ่ง Docker (2013) เริ่มแก้ปัญหาอีกชุดหนึ่งที่ต่างออกไป
  • ปัญหา “works on my machine” ถูกแก้ด้วยคอนเทนเนอร์
  • สามารถกำหนดสภาพแวดล้อมการรันด้วย Dockerfile และรันแบบเดียวกันได้ทุกที่
  • ในช่วงแรก การนำไปใช้ไม่ง่ายนักเพราะปัญหาประสิทธิภาพบน Mac และความสับสนเรื่องเครือข่าย
    • Docker Compose, Docker Swarm และต่อมาคือ Kubernetes (2014) ทำให้เกิดสงครามด้าน orchestration
    • ราวปี 2017 อย่างน้อยก็ชัดเจนแล้วว่าคอนเทนเนอร์คืออนาคต
• พร้อมกันนั้น เทรนด์ microservices ก็แพร่กระจาย
  • มอบข้อดีเรื่องการแยกบริการและการ deploy ได้อย่างอิสระ
  • แต่ก็สร้างความซับซ้อนใหม่ขึ้นมา เช่น service discovery, load balancing และ distributed tracing
  • หลายทีมเพิ่งมารู้ทีหลังว่าพวกเขาเพียงแค่แลกความซับซ้อนของ monolith ไปเป็นความซับซ้อนของระบบกระจาย
• ในช่วงนี้ ความสมบูรณ์ของเว็บแอปพลิเคชันเพิ่มขึ้นอย่างเห็นได้ชัด
  • Slack (2013) เข้ามาแทนอีเมลด้วยเครื่องมือทำงานร่วมกันที่รวดเร็วและค้นหาได้
  • Figma (2016) รุกล้ำพื้นที่ของเดสก์ท็อปแอปด้วยเครื่องมือออกแบบร่วมกันบนเบราว์เซอร์
  • เมื่อรวมกับ Notion (2016) และรายอื่น ๆ ก็พิสูจน์ว่าเว็บสามารถสร้างซอฟต์แวร์ระดับเดสก์ท็อปได้
  • กรณีเหล่านี้กลายเป็นเหตุผลรองรับความซับซ้อนของ React, Webpack และสายโซ่ build
• โครงสร้างองค์กรก็เข้าสู่ระยะที่เป็นผู้ใหญ่มากขึ้นเช่นกัน
  • ราวปี 2016 ตำแหน่ง product manager และ engineering manager กลายเป็นบทบาทมาตรฐาน
  • โครงสร้างทีมแบบแบนในช่วงแรกค่อย ๆ เปลี่ยนไปสู่การจัดองค์กรที่ขับเคลื่อนด้วยกระบวนการ
  • Scrum และพิธีกรรมแบบ agile แพร่หลายไปทั่ว โดยบางทีมใช้เป็นเครื่องมือ และบางทีมก็ใช้เป็นเพียงพิธีกรรม
• ปี 2017 ระบบนิเวศเริ่มเข้าสู่ช่วงเสถียรมากขึ้นทีละน้อย
  • React กลายเป็นผู้ชนะโดยพฤตินัย
  • ES6 กลายเป็นไวยากรณ์พื้นฐาน
  • Webpack และ Docker แม้จะเจ็บปวด แต่ก็ถูกยอมรับในฐานะมาตรฐาน
• ขั้นต่อไปถูกส่งสัญญาณไว้แล้ว
  • การผงาดขึ้นมาของ TypeScript
  • เมตาเฟรมเวิร์กอย่าง Next.js
  • ประสบการณ์การ deploy ที่เรียบง่ายยิ่งขึ้น
• แต่มีเงื่อนไขหนึ่งข้อ
  • มีเพียง นักพัฒนาที่ผ่านความวุ่นวายของเรอเนซองส์แห่ง JavaScript นี้มาได้ เท่านั้น ที่จะก้าวต่อไปยังขั้นถัดไปได้

ยุคของ TypeScript

"Types are good, actually"

• หลังยุคฟื้นฟูของ JavaScript ความวุ่นวายจากการมีเครื่องมือมากมายก็เริ่มสงบลง และ TypeScript ก็เข้ามาอยู่ตรงจุดเปลี่ยนที่ระบบนิเวศกำลังก้าวสู่ช่วง ความเป็นผู้ใหญ่
• TypeScript (2012) นำ static type เข้ามาสู่ JavaScript แต่ในช่วงแรกกลับถูกเมินอยู่เป็นเวลานาน เพราะขัดกับปรัชญาของภาษาที่เป็นแบบ dynamic และเพิ่มภาระจากขั้นตอน build
  • เมื่อแอปพลิเคชันมีขนาดใหญ่ขึ้น ข้อจำกัดของ dynamic typing ก็ยิ่งชัดเจนขึ้นเรื่อย ๆ
    • หลังเปลี่ยน function signature ต้นทุนในการไล่ตามจุดที่เรียกใช้ก็เพิ่มขึ้น
    • การอ่านโค้ดยากขึ้นเพราะมองรูปทรงของ object ได้ยาก
    • กรณีที่แค่พิมพ์ผิดเล็กน้อยแล้วกลายเป็นปัญหาใน production เกิดซ้ำแล้วซ้ำอีก
  • ตั้งแต่ช่วง 2017–2018 การนำ TypeScript ไปใช้ก็ขยายตัวอย่างรวดเร็ว
    • ได้ความมั่นคงของการ refactor ผ่านระบบ autocomplete และ static analysis
    • interface ทำหน้าที่เป็น เอกสารแบบบังคับ ที่ซิงก์กับโค้ดอยู่เสมอ
  • การยอมรับจากเฟรมเวิร์กหลัก ๆ กลายเป็นจุดเปลี่ยนสำคัญ
    • Angular ใช้กลยุทธ์ TypeScript-first
    • การกำหนด type ของ React สุกงอมขึ้น และการเขียน Vue 3 ใหม่บนพื้นฐาน TypeScript ทำให้มันถูกมองว่าเป็น มาตรฐานโดยพฤตินัย
    • ราว ๆ 2020 โปรเจ็กต์ใหม่ที่ใช้ JavaScript ล้วนแทบจะไม่ถูกเลือกอีกต่อไป
  • TypeScript ช่วย ยกระดับการเข้าถึงโค้ดเบสอย่างมาก
    • สมาชิกใหม่สามารถเข้าใจ domain model ได้เพียงแค่อ่าน type definition
    • การพึ่งพาความรู้ที่ไม่ถูกเขียนไว้ลดลง จึงช่วยบรรเทาต้นทุนการขยายทีม
• การจับคู่กับ VS Code (2015) เปลี่ยนประสบการณ์การพัฒนาอย่างเด็ดขาด
  • มอบ autocomplete อัจฉริยะ, การแสดง error แบบ inline และการ refactor ที่เชื่อถือได้
  • Sublime Text และ Atom ค่อย ๆ ลดอิทธิพลลง
• เกิดชั้น abstraction อีกระดับหนึ่งทับอยู่บน React
  • ในฐานะ UI library นั้น React ไม่มีคำตอบพื้นฐานสำหรับ routing, data fetching และ SSR
• Next.js เข้ามาเติมช่องว่างนี้ในฐานะ meta framework ที่มี file-based routing, server-side rendering, API routes และ automatic code splitting มาให้เป็นค่าเริ่มต้น
  • มีเฟรมเวิร์กที่เข้ามาตอบโต้หลากหลาย เช่น Nuxt, Remix, SvelteKit และ Gatsby
  • ในระบบนิเวศของ React นั้น Next.js กลายเป็นตัวเลือกหลักโดยพฤตินัย
• การแพร่หลายของ meta framework ช่วยบรรเทาความเหนื่อยล้าจาก ความกระจัดกระจายของ tooling ในยุคก่อนหน้าได้มาก
  • กระบวนการที่เคยต้องประกอบการตั้งค่า webpack และ Babel ด้วยตัวเอง ถูกดูดซึมเข้าไปอยู่ในค่าเริ่มต้น
• สภาพแวดล้อมการ deploy ก็เรียบง่ายขึ้นอย่างรวดเร็วเช่นกัน
  • Vercel และ Netlify ให้การ deploy อัตโนมัติและ preview environment ได้เพียงเชื่อมต่อกับ GitHub
  • ดีไซเนอร์, PM และ QA สามารถตรวจสอบการเปลี่ยนแปลงในสภาพแวดล้อมจริงได้ก่อน merge
• อิทธิพลของ Heroku อ่อนตัวลง ขณะที่ PaaS รุ่นใหม่อย่าง Railway และ Render เริ่มโดดเด่นขึ้น
• แนวคิด Serverless แพร่หลายโดยมี AWS Lambda (2014) เป็นศูนย์กลาง
  • มีการคิดค่าบริการตามการใช้งานและรองรับการขยายตัวอัตโนมัติ
  • แต่ก็ไม่ใช่คำตอบอเนกประสงค์ เพราะมีข้อจำกัดเรื่อง cold start, การจัดการ state และการ debug
  • Cloudflare Workers ขยายแนวคิดนี้ต่อด้วยโมเดลการรันบน edge
• ฝั่ง CSS ก็มีการเปลี่ยนผ่านอย่างเงียบ ๆ เช่นกัน
  • หลังจาก Sass และ Less ผ่านยุค CSS-in-JS มาแล้ว Tailwind CSS (2017) ก็ได้รับการยอมรับอย่างแพร่หลาย
  • แนวทางแบบ utility class
    • ช่วยตัดภาระในการตั้งชื่อ class
    • ลดปัญหาเรื่อง cascade และ specificity
    • และท้ายที่สุดนำไปสู่การคง stylesheet ให้มีขนาดเล็ก
• GraphQL (2015) ได้รับความสนใจในฐานะคำตอบที่ทรงพลังสำหรับแอปพลิเคชันที่ต้องจัดการโครงสร้างข้อมูลซับซ้อน
  • ให้ข้อดีทั้งการ query ข้อมูลอย่างแม่นยำ, schema ที่อิง type และระบบนิเวศของเครื่องมือ
  • แต่เพราะความซับซ้อนของ server layer และความยากในการทำ caching มันจึงกลายเป็นตัวเลือกที่เกินจำเป็นสำหรับ CRUD แบบง่าย
  • บางทีมจึงยังคงใช้ REST หรือเลือกทางเลือกที่เรียบง่ายกว่าอย่าง tRPC
• การแข่งขันด้าน container orchestration ได้ข้อสรุปราว 2018 ว่า Kubernetes เป็นผู้ชนะ
  • มันทรงพลัง แต่ก็มาพร้อมต้นทุนการเรียนรู้สูงและความซับซ้อนในการปฏิบัติการ
  • สำหรับหลายทีมมันเป็นคำตอบที่เกินความจำเป็น และกลายเป็นฉากหลังของการกลับมาของ PaaS
• COVID (2020) ทำให้ความต้องการด้านการพัฒนาเว็บขยายตัวอย่างรวดเร็ว
  • การทำงานทางไกล, e-commerce และเครื่องมือทำงานร่วมกันกลายเป็นสิ่งจำเป็น
  • นำไปสู่ความต้องการนักพัฒนาที่พุ่งสูงและการเติบโตอย่างรวดเร็วของบริษัทเครื่องมือสำหรับนักพัฒนา
• ในสภาพแวดล้อมแบบ remote ความสำคัญของการทำงานร่วมกันแบบ asynchronous และการจัดทำเอกสารก็เพิ่มขึ้น
  • code review, คำอธิบาย PR และคุณภาพของเอกสารภายใน กลายเป็นองค์ประกอบหลัก
• ในระดับองค์กรก็เกิดความเป็นผู้ใหญ่มากขึ้นเช่นกัน
  • การจัดระบบระดับวิศวกรเริ่มลงตัว
  • ความชอบธรรมของสาย IC ได้รับการยอมรับ
  • บทบาทของ PM, EM และ tech lead แยกชัดเจนขึ้น
• Developer Experience (DX) ถูกมองว่าเป็นเป้าหมายการลงทุนที่แยกออกมาต่างหาก
  • ทีม internal platform, CI ที่รวดเร็ว และการปรับปรุง onboarding กลายเป็นปัจจัยหลักของผลิตภาพ
• ราว 2022 การพัฒนาเว็บได้ไปถึงจุดที่แม้จะซับซ้อน แต่ก็อยู่ในสถานะที่ จัดการได้
  • TypeScript กลายเป็นค่าเริ่มต้น
  • ระบบนิเวศที่มี Next.js เป็นศูนย์กลาง
  • ระบบ deployment อัตโนมัติและชุดเครื่องมือที่สุกงอม
• แล้วทุกอย่างก็เปลี่ยนไป: บริษัทชื่อ OpenAI เปิดตัวสิ่งที่เรียกว่า ChatGPT

ช่วงเวลาของ AI

"Wait, I can just ask it to write the code?"

• นับจากการเปิดตัว ChatGPT (2022) ประสบการณ์แบบที่เพียงป้อนคำถามแล้วได้ทั้งคำอธิบาย โค้ด และผลการ debug ก็ถือกำเนิดขึ้น และกฎของการพัฒนาก็เปลี่ยนไป
  • มันทำได้ตั้งแต่อธิบายฟิสิกส์ควอนตัมไปจนถึง debug Python และแม้จะไม่สมบูรณ์แบบ แต่ความจริงที่ว่ามัน ใช้งานได้ดีพอ ก็สร้างแรงกระแทกอย่างมาก
  • นักพัฒนาเริ่มทดลองกันทันที และการเขียน React component, วิเคราะห์สาเหตุของ error หรือแปลงโค้ดข้ามภาษา ก็กลายเป็นสิ่งที่ ทำได้ภายในไม่กี่วินาทีโดยไม่ต้องค้นเอกสารหรือไล่หาตามฟอรัม
• GitHub Copilot (2022) นำการสร้างโค้ดในรูปแบบ autocomplete เข้าไปไว้ใน editor และทำให้ประสบการณ์แบบ autocomplete ทรงพลังระดับสูง ที่แค่มี comment ก็เสนอ implementation ได้ แพร่หลายออกไป
  • meta-skill แบบใหม่ ในการประเมิน รับ ปรับแก้ หรือปฏิเสธข้อเสนอจาก AI อย่างรวดเร็ว กลายมาเป็นความสามารถหลักของนักพัฒนา
• งานอย่าง boilerplate ที่ซ้ำ ๆ การเขียน test และการจัดการ edge case เร็วขึ้นอย่างมาก จนเกิดการพัฒนาแบบ ไม่ทำให้ flow สะดุด
• Cursor (2023) เป็น IDE ที่ผสาน AI เข้าไปไม่ใช่ในฐานะฟีเจอร์ แต่เป็นเงื่อนไขตั้งต้น ทำให้สามารถเลือกโค้ดแล้วขอ refactor, แก้หลายไฟล์จากคำอธิบายภาษาธรรมชาติ และสนทนากับโค้ดเบสได้
• การเปลี่ยนแปลงนี้ทำให้ความหมายของ seniority สั่นคลอน แต่ในความเป็นจริง ความสำคัญของ ความสามารถในการตัดสินใจว่าจะสร้างอะไร และประเมิน requirement, constraint และผลข้างเคียง กลับยิ่งเพิ่มขึ้น
  • AI เขียนโค้ดได้ แต่ มันไม่สามารถนิยามปัญหาและเลือกทิศทางที่ถูกต้องได้
• แม้จะมีปฏิกิริยาสุดขั้วตั้งแต่ “จุดจบของการเขียนโปรแกรม” ไปจนถึง “กระแสไร้สาระ” แต่ผลลัพธ์ที่เกิดขึ้นจริงคือ การขยายผลิตภาพของนักพัฒนาที่ใช้ AI
• อุปสรรคในการเริ่มต้นทำโปรเจ็กต์ส่วนตัวและ side project ลดลงอย่างรวดเร็ว จนทำให้พื้นที่ที่เมื่อก่อนอาจไม่กล้าลอง เช่น ML, เกม หรือเฟรมเวิร์กใหม่ ๆ ก็ เข้าถึงได้ผ่านการเรียนรู้แบบสนทนา
• กระแสนี้ทำงานในฐานะขั้นตอนที่เร่งทิศทางเก่าแก่ของเว็บ นั่นคือ การทำให้การสร้างสรรค์เป็นของทุกคน
  • จุดศูนย์กลางกำลังย้ายจากการรู้จักเขียนโค้ด ไปสู่ การรู้ว่าตนเองอยากสร้างอะไร
• แม้แต่คนที่ไม่ใช่นักพัฒนาก็เข้ามามีส่วนร่วมในการสร้าง prototype ได้ และ PM, ดีไซเนอร์ รวมถึงผู้เชี่ยวชาญโดเมนก็สร้างเครื่องมือได้ด้วยตัวเอง ทำให้ เส้นแบ่งระหว่างสายเทคนิคกับไม่ใช่เทคนิคพร่าเลือนลง
• จำนวน indie hacker และ solo builder เพิ่มขึ้น และ สภาพแวดล้อมที่คนคนเดียวก็สร้างผลิตภัณฑ์ที่ใช้งานได้จริงได้ ก็กลายเป็นความจริง
• ในเวลาเดียวกัน React Server Components, htmx, มาตรฐาน CSS และ JavaScript ที่ดีขึ้น รวมถึงเครื่องมืออย่าง Bun ก็ยิ่งเสริมกระแส “มาใช้แพลตฟอร์มโดยตรงกันเถอะ”
• หลังบูมการจ้างงานครั้งใหญ่ในช่วง 2022–2023 ตลาดก็ผันผวนจากการปรับโครงสร้างองค์กร แต่ AI ไม่ได้มาแทนที่นักพัฒนา และ ความสามารถในการใช้ AI กลายเป็นความคาดหวังพื้นฐาน
• ณ ปี 2025 การพัฒนาเว็บอยู่ในสถานะที่ ความเร็วจากไอเดียไปสู่การ deploy เร็วที่สุดในประวัติศาสตร์ และ
  • ในสภาพแวดล้อมที่รวม cloud, framework และ AI เข้าด้วยกันนั้น ปัจเจกบุคคลกลายเป็นผู้สร้างสรรค์ที่ทรงพลังที่สุดเท่าที่เคยมีมา
• คำมั่นสัญญาของเว็บที่เริ่มต้นจากแท็ก <br> ว่า “ใคร ๆ ก็สร้างและแชร์ได้” กำลัง ดำเนินต่อไปในรูปแบบที่แข็งแกร่งยิ่งขึ้นในยุค AI
• ตอนนี้คือ ช่วงเวลาที่ยอดเยี่ยมมากในการทำเว็บดีเวลอปเมนต์

[ethanhur]

อ่านได้อย่างเพลิดเพลินราวกับอ่านหนังสือประวัติศาสตร์

[zihado]

ยุคนั้นที่ผมเช่าเซิร์ฟเวอร์โฮสติ้งจาก Cafe24 สักตัว ลง ZeroBoard แล้วก็ตกแต่งเล่น ๆ ให้ดูเหมือนเป็นคอมมูนิตี้ของตัวเอง 555

[lethee]

อ่านได้อย่างเพลิดเพลินเลยครับ ให้ความรู้สึกเหมือนภาพชีวิตที่ฉายย้อนกลับมาแวบหนึ่งก่อนตายเลย ฮ่าๆ

[edunga1]

อ่านได้อย่างสนุกครับ
ถ้าไปทางสภาพแวดล้อมการพัฒนา ก็จะต่อเนื่องไปถึงการมาของ VS Code และ LSP แล้วก็รวมไปถึงเครื่องมือก่อนยุค AI ของ Tabnine ได้ด้วยครับ

[aer0700]

JavaScript의 간략한 역사
ถ้าอ่านบทความนี้ไปพร้อมกันก็น่าจะดีครับ

[GN⁺]

ความคิดเห็นจาก Hacker News

• คำกล่าวที่ว่าแต่ละหน้าต้องมี header, navigation และ footer แบบเดียวกัน แต่ไม่มีวิธีแชร์นั้นไม่ถูกต้องทั้งหมด
  บนเว็บเซิร์ฟเวอร์มีฟีเจอร์ Server Side Includes(SSI) อยู่แล้ว และถ้าไม่อยากใช้ ก็แก้ได้ง่ายๆ ด้วยคำสั่ง cat header body > file
  เอกสารที่เกี่ยวข้อง: บทช่วยสอน NCSA SSI (1997)

  • เดิมที HTML ถูกสร้างขึ้นมาเป็น ศัพท์เฉพาะที่อิง SGML ดังนั้นใน SGML และ XML จึงมีฟีเจอร์ entity/text macro สำหรับอ้างอิงชิ้นส่วนเอกสารอย่าง header หรือ footer ที่ใช้ร่วมกัน
  • คอมเมนต์ต้นฉบับคงกำลังพูดถึงกรณีของ HTML ล้วนๆ เท่านั้น

• รู้สึกว่าถ้าบทความจบด้วยประโยคประมาณว่า "...และท่ามกลางกระบวนการทั้งหมดนั้น แท็ก <br> อันแสนเรียบง่ายก็ยังคงทำหน้าที่ของมันอยู่" ก็คงจะดี

• บริษัทเก่าที่เคยทำงานใช้ระบบสร้างโฟลเดอร์ใหม่ทุกครั้งที่ deploy แล้วเปลี่ยน symbolic link ไปยังเวอร์ชันล่าสุด
  แม้จะเป็นงานแบบ manual แต่สามารถ สลับแบบ atomic บนแต่ละเซิร์ฟเวอร์ได้ และ rollback ก็ง่าย เลยรู้สึกว่าเป็นวิธีที่ elegant มาก
  ก่อนหน้านั้นต้องคัดลอกไฟล์ไปยังเซิร์ฟเวอร์หลายสิบเครื่องด้วยมือ และรันคำสั่งเอง 10~20 ขั้นตอน เมื่อเทียบกันแล้ววิธีนี้ปลอดภัยและเรียบง่ายกว่ามาก
  หลังจากนั้นเคยลองใช้เครื่องมือ automation แต่การตั้งค่าซับซ้อนและมองเห็นภาพรวมได้ยาก กลับกลายเป็น กระบวนการ deploy ที่เปราะบางกว่าเดิม

• มีประโยคว่า "ถ้าจะใช้ CGI script ก็ต้องเรียน Perl หรือ C" ซึ่งทำให้สงสัยว่าจำเป็นต้องเขียนถึงหลายร้อยบรรทัดจริงหรือ
  ที่จริงแล้วแค่ฟังก์ชัน C ง่ายๆ ก็อ่าน URL parameter ได้
  ไม่นานมานี้ฉันเพิ่งทำ เว็บไซต์แบบสอบถามด้วย C ล้วนๆ และทำได้ค่อนข้างสบายเพราะมีไลบรารีสร้าง HTML ที่เคยทำไว้ก่อนแล้ว
  ฉันรีแฟกเตอร์ CGI library ของระบบปฏิบัติการมาใช้ และลิงก์ SQLite แบบสแตติกเพื่อ deploy เป็น single binary
  ทดสอบผ่าน stdin/stdout ได้โดยไม่ต้องมีเว็บเซิร์ฟเวอร์
  สรุปแล้วเว็บไซต์ CRUD นั้นทำด้วย C ก็ง่ายพอสมควร และเพราะ HTML เป็นโครงสร้างแบบต้นไม้ จึงคิดว่า string interpolation เป็นแนวทางที่ไม่เหมาะ

  • โค้ดนี้จับคู่พารามิเตอร์แรกที่ลงท้ายด้วย <param> จึงอาจไม่ตรงกันแบบเป๊ะๆ และยังไม่จัดการ percent encoding
  • เห็นด้วยกับคำพูดที่ว่า string interpolation ไม่เหมาะ เพราะ HTML ใช้แทนโครงสร้างแบบต้นไม้
    แต่ถึงจะผ่านไป 30 ปีแล้ว ทุกวันนี้ string interpolation ก็ยังดูเหมือนเป็นเครื่องมือที่ใช้กันมากที่สุดอยู่ดี

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

• บทความนี้น่าจะกลายเป็น งานเขียนคลาสสิก ได้เลย
  มันสรุปประวัติศาสตร์ของเทคโนโลยีเว็บที่นักพัฒนายุคนี้พลาดไปได้อย่างกระชับ

• ตอนอ่านส่วน “Virtual private servers changed this…” ก็ทำให้นึกขึ้นได้ว่า
  ที่จริงผู้ให้บริการ VPS รายแรกคือ JohnCompanies ราวปี 2001 และใช้ FreeBSD jail เป็นพื้นฐาน
  ลูกค้าต้องการ remote backup และชอบใช้ rsync
  ดังนั้นอีก 4 ปีต่อมาฉันจึงจดโดเมน rsync.net (โดยได้รับอนุญาตจากผู้เขียน rsync/samba)

• ฉันทำเว็บดีเวลอปเมนต์มาตั้งแต่ปี 1998 ถึง 2012 และการอ่านบทความนี้ก็ให้ความรู้สึกเหมือนได้ ย้อนความทรงจำ
  มันยังเป็นสรุปที่ช่วยให้เห็นการเปลี่ยนแปลงหลังจากนั้นได้ในภาพเดียว

• เนื้อหาในบทความแทบจะตรงกับลำดับการพัฒนาของเทคโนโลยีเว็บที่ฉันจำได้
  CGI ก่อนยุค PHP แม้จะยุ่งยาก แต่ก็ใช้งานได้ดีพอสมควรด้วย mod_perl และ FastCGI
  การเขียน CGI ด้วยภาษาแบบคอมไพล์นั้นแทบจะเข้าขั้น masochism และในแง่นั้น PHP ก็เบาและสนุกดี
  ฉันเลิกทำฟรอนต์เอนด์ไปก่อนที่ jQuery จะเริ่มดัง เสียอีก

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