วิธีที่ JavaScript เข้าครอบครองเว็บ แบ็กเอนด์ และทั้งบริษัท

แผนที่สั้น ๆ ของการครอบครองโดย JavaScript

JavaScript เกิดขึ้นเพื่อเพิ่มปฏิสัมพันธ์เล็ก ๆ ให้กับหน้าเว็บ—สคริปต์ขนาดเล็กที่ตรวจฟอร์ม สลับภาพ หรือแสดงเมนูแบบเลื่อนลง แนวทางนี้ติดตามว่า "ภาษาช่วยเหลือเล็ก ๆ" นั้นกลายเป็นแพลตฟอร์มระดับบริษัทได้อย่างไร: เทคโนโลยีแกนเดียวกันตอนนี้รันทั้งอินเทอร์เฟซผู้ใช้ เซิร์ฟเวอร์ ระบบบิลด์ ออโตเมชัน และเครื่องมือภายใน

ความหมายของ “ภาษามาตรฐานของเว็บ” คืออะไร

ในแง่ปฏิบัติ JavaScript คือภาษาที่เบราว์เซอร์หลักทุกตัวรันได้โดยตรง หากคุณส่งโค้ดไปยังผู้ใช้โดยไม่ต้องให้พวกเขาติดตั้งอะไร JavaScript คือทางเลือกสากล ภาษาอื่น ๆ อาจเข้ามามีบทบาท—แต่โดยปกติจะคอมไพล์เป็น JavaScript หรือรันบนเซิร์ฟเวอร์—ขณะที่ JavaScript รันที่ปลายทางโดยค่าเริ่มต้น

ยุคสามช่วงที่คุณจะเห็น

ช่วงแรกคือ ยุคเบราว์เซอร์ ที่ JavaScript กลายเป็นมาตรฐานในการควบคุมหน้า: ตอบสนองคลิก จัดการ DOM และท้ายที่สุดช่วยขับเคลื่อนประสบการณ์ที่เข้มข้นขึ้นเมื่อเว็บพ้นจากเอกสารนิ่ง ๆ

ช่วงที่สองคือ ยุคแบ็กเอนด์ ที่เอนจินเร็วขึ้นและ Node.js ทำให้การรัน JavaScript บนเซิร์ฟเวอร์เป็นไปได้จริง นั่นเปิดให้ภาษาร่วมกันระหว่าง frontend และ backend รวมถึงระบบแพ็กเกจที่เร่งการนำกลับมาใช้ซ้ำ

ช่วงที่สามคือ ยุคปฏิบัติการธุรกิจ ที่เครื่องมือ JavaScript กลายเป็น "กาว": ไพพ์ไลน์บิลด์ การทดสอบ ระบบดีไซน์ แดชบอร์ด สคริปต์ออโตเมชัน และการผสานระบบ แม้ทีมที่ไม่คิดว่าตัวเองเป็น "ทีม JavaScript" ก็มักพึ่งพาเครื่องมือที่สร้างด้วย JavaScript ในชีวิตประจำวัน

ควรคาดหวังอะไรจากไกด์นี้

เราจะเน้นจุดเปลี่ยนสำคัญ—การมาตรฐาน ความก้าวหน้าด้านประสิทธิภาพ Node.js, npm และการเปลี่ยนไปสู่แอปที่ขับเคลื่อนด้วยเฟรมเวิร์ก—มากกว่าการนับทุกรายการไลบรารีหรือเทรนด์

จุดเริ่มต้น: สคริปต์ในเบราว์เซอร์

JavaScript ถูกสร้างขึ้นในปี 1995 ที่ Netscape เพื่อเป็นวิธีง่าย ๆ ในการเพิ่มปฏิสัมพันธ์ให้หน้าเว็บโดยไม่ต้องวนรอบไปยังเซิร์ฟเวอร์หรือการติดตั้งโปรแกรม Brendan Eich สร้างเวอร์ชันแรกอย่างรวดเร็ว และจุดมุ่งหมายเดิมค่อนข้างเรียบง่าย: ให้ผู้สร้างเว็บตรวจฟอร์ม ตอบสนองคลิกปุ่ม และทำให้หน้าเว็บไม่ดูนิ่งเฉย

เว็บยุคหน้าเล็กและเครื่องช้ากว่า

ข้อจำกัดของเว็บในยุคแรกกำหนดสิ่งที่ JavaScript ทำได้ คอมพิวเตอร์ช้ากว่า เบราว์เซอร์พื้นฐาน และเว็บไซต์ส่วนใหญ่เป็นข้อความกับภาพไม่กี่ภาพ สคริปต์ต้องเบาและยืดหยุ่น—ชิ้นโค้ดเล็ก ๆ ที่รันได้โดยไม่ทำให้หน้าแฮงก์

เพราะหน้าเว็บเรียบง่าย JavaScript ยุคแรกมักดูเหมือน "ตรรกะเล็ก ๆ" ฝังใน HTML: ตรวจว่าอีเมลมี @ หรือไม่ แสดง alert หรือสลับภาพเมื่อเลื่อนเมาส์ผ่านลิงก์

“เขียนโค้ดในหน้า” คือการเปลี่ยนแปลงครั้งใหญ่

ก่อนหน้านั้น หน้าเว็บส่วนใหญ่แสดงเนื้อหาเป็นหลัก เมื่อฝัง JavaScript ลงในหน้า มันสามารถตอบสนองต่อการกระทำของผู้ใช้ได้ทันที แม้แต่สคริปต์เล็ก ๆ ก็สามารถ:

• หยุดการส่งฟอร์มจนกว่าฟิลด์จำเป็นจะถูกกรอก
• อัปเดตข้อความบนหน้าหลังจากคลิก
• ทำการคำนวณเล็ก ๆ โดยไม่ต้องติดต่อเซิร์ฟเวอร์

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

ความเจ็บปวดในยุคแรก: พฤติกรรมไม่สอดคล้องกัน

ข้อเสียคือความไม่แน่นอน เบราว์เซอร์ไม่ค่อยตีความ JavaScript เหมือนกัน และ API สำหรับโต้ตอบกับหน้า (พฤติกรรม DOM ยุคแรก, โมเดลเหตุการณ์ และเมธอดขององค์ประกอบ) แตกต่างกันมาก นักพัฒนาจึงต้องเขียนเส้นทางโค้ดต่างกันตามเบราว์เซอร์ ทดสอบบ่อย ๆ และยอมรับว่าสิ่งที่ทำงานบนเครื่องหนึ่งอาจพังบนอีกเครื่องได้

การแข่งขันเบราว์เซอร์และแรงผลักดันสู่การมาตรฐาน (ECMAScript)

“สงครามเบราว์เซอร์” แบบง่าย ๆ

ปลายทศวรรษ 1990 ถึงต้น 2000 เบราว์เซอร์แข่งขันกันอย่างดุเดือดโดยส่งฟีเจอร์ใหม่เร็วที่สุดเท่าที่จะทำได้ Netscape และ Internet Explorer ไม่ได้แข่งแค่ความเร็ว—พวกเขาแข่งเรื่องพฤติกรรม JavaScript, API ของ DOM และส่วนขยายเฉพาะของบริษัทด้วย

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

ECMAScript: สัญญาที่อยู่เบื้องหลัง JavaScript

เพื่อลดความยุ่งเหยิง JavaScript ต้องการคำนิยามร่วมที่ไม่ถูกควบคุมโดยผู้ขายเบราว์เซอร์เดียว คำนิยามนั้นกลายเป็น ECMAScript—มาตรฐานที่บรรยายแกนกลางของภาษา (ไวยากรณ์ ประเภท ฟังก์ชัน ออบเจ็กต์ ฯลฯ)

แบบจำลองทางความคิดที่ใช้ได้:

• JavaScript คือสิ่งที่เบราว์เซอร์ (และต่อมาเป็นเซิร์ฟเวอร์) รันได้
• ECMAScript คือหนังสือกฎที่เอนจิน JavaScript พยายามทำตาม

การมาตรฐานช่วยอย่างไร (ทีละน้อย)

เมื่อผู้ขายปรับให้เข้ากับเวอร์ชัน ECMAScript ภาษาก็เริ่มมีความคาดเดาได้มากขึ้นในหลายเบราว์เซอร์ ความไม่เข้ากันยังไม่หายไปทันที—API นอกแกนกลางของภาษายังคงต่างกัน—แต่พื้นฐานมีเสถียรภาพมากขึ้น เมื่อเวลาผ่านไป ชุดทดสอบที่ดีขึ้นและความคาดหวังร่วมกันทำให้ "ใช้งานบนเบราว์เซอร์ของฉัน" น้อยลงเป็นคำแก้ตัว

ทำไมรูปแบบเก่าไม่หายไปหมด

แม้ ECMAScript จะพัฒนา แต่ ความเข้ากันย้อนหลัง กลายเป็นคำสัญญาที่ไม่อาจแตกได้: เว็บไซต์เก่าต้องยังทำงานอยู่ นั่นคือเหตุผลที่รูปแบบเก่า—var, กฎการเทียบเคียงที่แปลก ๆ และการแก้ปัญหาก่อนโมดูล—ยังอยู่ในระบบนิเวศ เว็บไม่สามารถทำการรีเซ็ตครั้งใหญ่ได้ ดังนั้น JavaScript จึงเติบโตด้วยการเพิ่มฟีเจอร์ใหม่แทนการลบของเก่า

Ajax และการเกิดของเว็บแอปจริงจัง

ก่อน Ajax เว็บไซต์ส่วนใหญ่ทำงานเหมือนฟอร์มบนกระดาษ: คุณคลิกหรือส่งฟอร์ม เบราว์เซอร์โหลดหน้าใหม่ทั้งหมด แล้วรอให้เซิร์ฟเวอร์ส่งเอกสาร HTML ใหม่กลับมา

Ajax (ย่อมาจาก “Asynchronous JavaScript and XML”, แม้ JSON จะกลายเป็นดาวเด่นจริง ๆ) เปลี่ยนรูปแบบนั้น ด้วย JavaScript หน้าเว็บสามารถขอข้อมูลจากเซิร์ฟเวอร์ในพื้นหลังและอัปเดตเฉพาะส่วนที่ต้องเปลี่ยน—ไม่ต้องโหลดหน้าใหม่ทั้งหน้า

อัปเดตบางส่วนของหน้าโดยไม่รีโหลด

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

นี่ไม่ใช่แค่ UI ที่สวยขึ้น—มันลด摩擦 คนเริ่มไม่ทนกับ "คลิก → รอ → รีโหลด" สำหรับทุกการกระทำเล็ก ๆ

ประสบการณ์แบบ Gmail เปลี่ยนมาตรฐาน

ผลิตภัณฑ์อย่าง Gmail แสดงให้เห็นว่าเบราว์เซอร์จัดการการโต้ตอบเหมือนแอปได้: อัปเดตกล่องจดหมายอย่างรวดเร็ว การติดป้ายทันที การนำทางราบรื่น และการรบกวนน้อยลง เมื่อผู้ใช้ได้สัมผัสความรวดเร็วแบบนั้น มันกลายเป็นมาตรฐานสำหรับเว็บไซต์อื่น ๆ ด้วย

API + JSON เปลี่ยนเบราว์เซอร์ให้เป็นไคลเอนต์จริงจัง

Ajax ผลักทีมให้แยก "ข้อมูล" ออกจาก "หน้า" แทนที่จะส่ง HTML ทั้งหน้าเซิร์ฟเวอร์เริ่มเปิด API ที่ส่งข้อมูลเป็นโครงสร้าง (มักเป็น JSON) เบราว์เซอร์ที่ขับเคลื่อนด้วย JavaScript กลายเป็นไคลเอนต์จริงที่รับผิดชอบการเรนเดอร์ การโต้ตอบ และสถานะ

การแลกเปลี่ยน: โลจิกมากขึ้นย้ายไปที่ frontend

ข้อเสียคือความซับซ้อน โลจิกแอปมากขึ้นย้ายไปอยู่ในเบราว์เซอร์: การตรวจสอบ สถานะ UI แคช การจัดการข้อผิดพลาด และปัญหาด้านประสิทธิภาพ สิ่งนี้วางรากฐานให้กับเครื่องมือ frontend ที่หนักขึ้นและในที่สุดคือ single-page applications ที่เซิร์ฟเวอร์เป็นแหล่ง API เป็นหลักและ frontend ทำหน้าที่เหมือนแอปจริง