สรุปสารคดี The Story of VS Code

เมื่อต้นเดือนกันยายน 2026 ทีม Visual Studio Code ปล่อยสารคดีตัวเต็มชื่อ The Story of VS Code ยาว 1 ชั่วโมง 38 นาที เล่าตั้งแต่วันที่ยังเป็นโปรเจกต์ทดลองเล็กๆ ในซูริก จนกลายเป็น editor ที่ผลสำรวจของ Stack Overflow บอกว่าเดฟราว 70% ใช้อยู่

ยาวขนาดนี้หลายคนคงไม่มีเวลานั่งดู โพสต์นี้เลยสรุปมาให้ว่ามีอะไรที่ควรรู้บ้าง เน้นส่วนที่เอาไปคิดต่อกับงานตัวเองได้จริง (ภาพประกอบทั้งหมดแคปมาจากตัวสารคดี)

ทำไม Microsoft ถึงต้องมี VS Code

ช่วงที่ Steve Ballmer เป็น CEO ฝ่าย Developer Division ของ Microsoft ทำเครื่องมือเพื่อ Windows เป็นหลัก ถ้าไม่ได้รันบน Windows หรือไม่ได้เขียนด้วย C# กับ C++ ก็แทบไม่สนใจ

แต่โลกเปลี่ยนไปแล้ว เบราว์เซอร์กลายเป็นที่ที่สร้างแอปเต็มรูปแบบได้ (อย่าง Google Docs) เดฟรุ่นใหม่ไม่ได้มองหา Windows อีกต่อไป ถ้าไม่ปรับตัวก็หลุดจากสายตาเดฟไปเลย

Microsoft เลยต้องกลับลำครั้งใหญ่ จากที่รอให้เดฟมาหา กลายเป็นต้องไป “หาเดฟในที่ที่เขาอยู่”

คนที่ถูกดึงมาทำเรื่องนี้คือ Erich Gamma หนึ่งใน “Gang of Four” ที่เขียนหนังสือ Design Patterns และเคยสร้าง IDE มาแล้ว 6 ถึง 7 ตัว Microsoft ตั้ง Dev Center ที่ซูริกให้เลย แล้วทีมเก่าของเขาจากสมัย IBM ก็ตามมาสมัครกันเพียบ

Monaco: editor บนเบราว์เซอร์ที่คนไม่เชื่อว่าจะเร็วพอ

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

ผลงานชิ้นแรกคือ Monaco ซึ่งทุกวันนี้ยังเป็นแกนกลางของ VS Code และถูกเอาไปใช้ในอีกหลายผลิตภัณฑ์ ทีมแซวว่าถ้าเจอ editor บนเว็บที่ลากคลุมโค้ดแล้วแถบไฮไลต์มีมุมโค้งมน เดาไว้ก่อนเลยว่าเป็น Monaco

ส่วนที่ผมว่าคุ้มสุดของช่วงนี้คือ กฎด้าน performance ที่ทีมยึดมาตั้งแต่วันแรก:

• ห้ามทำงานหนักบน UI thread เธรดนี้มีไว้วาดจอกับทำให้เคอร์เซอร์กะพริบ ถ้าไปยัดงานคำนวณไว้ตรงนั้น จอจะค้างทันที
• เสียแรงเท่ากับสิ่งที่ผู้ใช้ทำ ต่อให้ไฟล์ยาวเป็นล้านบรรทัด พิมพ์ตัวเดียว ก็ควรเสียแรงประมวลผลแค่กับตัวอักษรตัวนั้น
• วาดเฉพาะที่มองเห็น เลื่อนจอเห็นอยู่ 50 บรรทัด ก็วาดแค่ 50 บรรทัด

กฎพวกนี้ไม่ได้ใหม่ แต่พอยึดเป็นหลักตั้งแต่ต้น editor ที่เขียนด้วยเทคโนโลยีเว็บเลยลื่นพอให้คนใช้ทั้งวันได้

อีกเรื่องที่น่าสนใจคือ TypeScript โตมาพร้อมกันพอดี ทีม VS Code เป็นผู้ใช้กลุ่มแรกของ TypeScript ตอนที่โค้ดเบสเริ่มใหญ่ระดับแสนบรรทัด แล้วคอยส่ง feedback จนแทบเป็นคนออกแบบภาษาร่วมกัน

เบราว์เซอร์ยังไม่พร้อม เลยย้ายไป desktop

ทีมเอา Monaco ไปทำเป็น IDE บนเว็บชื่อ Visual Studio Online “Monaco” แต่ใช้ได้เฉพาะคนที่แก้เว็บบน Azure ซึ่งเป็นกลุ่มที่แคบเกินไป เลยแทบไม่มีคนหันมาสนใจ

ทางออกมาในจังหวะพอดี ตอนนั้นเริ่มมีเครื่องมืออย่าง node-webkit และต่อมาคือ Electron ที่เอาโค้ดเว็บไปห่อเป็นแอป desktop ได้ ทีมแทบไม่ต้องเขียนใหม่ แค่เอาของเดิมไปรันในนั้น

ในสารคดีมีภาพเปรียบเทียบที่เห็นชัดมาก ลองนึกถึงเดฟที่นั่งเขียนโค้ดบน Mac ในร้านกาแฟ ใช้ Sublime กับ Git อยู่ ถ้า Microsoft จะเข้าไปคุย ก็ต้องบอกให้ปิด Mac ไปซื้อเครื่อง Windows แล้วโหลด Visual Studio หลายกิกะ ซึ่งไม่มีใครฟังแน่นอน

VS Code เลยต้องเป็นของที่ลงเครื่องไหนก็ได้ ทุกระบบ และเป็น open source

ไฮไลต์ของทีมคือตอนเดโม VS Code ดีบักแอป .NET บน Ubuntu ที่งาน Build ปี 2015 (งานสัมมนานักพัฒนาประจำปีของ Microsoft) เพราะยุคนั้นการเอา Mac หรือ Linux ขึ้นเวทีของ Microsoft เองเป็นเรื่องที่ไม่เคยเกิดขึ้นมาก่อน

ชื่อก็กล้า เรียกมันสั้นๆ ว่า “Code” เลย วันเปิดตัวกระทู้บน Hacker News ร้อนแรงมาก ทีมเลยไปนั่งบาร์ แล้วตั้งกติกาว่าทุก 100 upvote ดื่มเบียร์หนึ่งแก้ว จนแตะ 1,400 upvote ก็ต้องยอมพอ

เปิด open source และระบบ extension

พอเปิดตัว ผู้ใช้ขอสองเรื่องเร็วมาก คือขอ extension กับขอให้ เปิด open source ทีมทำทั้งสองอย่างภายในราวหกเดือน

commit แรกใน repo สาธารณะคือ “Hello Code” ในชื่อของ Erich ส่วน pull request แรกจากชุมชนมาภายในเจ็ดนาทีหลังเปิด repo เป็นการแก้คำว่า “running” ที่สะกดผิดเป็นสาม n

การตัดสินใจเรื่อง extension สองข้อต่อไปนี้ ผมว่าเป็นบทเรียนด้านสถาปัตยกรรมที่ดีมาก

1. extension รันแยก process ถ้า extension ตัวไหนเขียนพลาดจนค้างอยู่ใน loop ตัว editor ก็ยังพิมพ์ได้ เซฟได้ตามปกติ

Erich ยกตัวอย่างเทียบกับ Windows ที่มักพังเพราะ driver ของบริษัทอื่น แล้วถามกลับว่าผิดที่ driver หรือผิดที่ระบบยอมให้พังได้ขนาดนั้น

คู่แข่งยุคนั้นอย่าง Atom เลือกทางตรงข้าม คือให้ extension ทำได้ทุกอย่างที่ core ทำได้ แบบนั้นยืดหยุ่นกว่าก็จริง แต่ก็เสี่ยงกว่า ส่วน VS Code ยอมโดนบ่นว่าจำกัดเกินไป แลกกับความเสถียรในระยะยาว

2. API ห้ามพังเด็ดขาด หลักคิดคือ อะไรที่คนเรียกใช้ได้ ก็นับเป็น API ทันที ไม่มีคำว่า “internal API” เพราะถ้าเรียกได้ คนก็จะเรียก แล้ววันหนึ่ง extension ดังๆ จะจับเราเป็นตัวประกัน

ทีมเลยสัญญาว่า extension ที่เขียนไว้เมื่อสิบปีก่อน ทุกวันนี้ก็ยังติดตั้งและรันได้

ผลคือเกิด ecosystem ขนาดใหญ่ เพราะทำ extension ง่ายและขึ้น marketplace ได้ในไม่กี่วินาที อย่างคนทำ GitLens ก็เล่าว่าทุ่มทั้งกลางคืนและวันหยุดให้มันจนภรรยาแซวว่า GitLens เป็นเมียน้อย

LSP: ทำครั้งเดียวใช้ได้ทุก editor

พอมี extension แล้วก็เจอปัญหาใหม่ ภาษาส่วนใหญ่ใน VS Code ได้แค่ไฮไลต์สีกับ snippet ยังไม่ได้ความฉลาดจริงๆ อย่าง autocomplete หรือ go to definition

ทีมรู้ตัวว่ายังไม่ได้เป็นเจ้าตลาด จะไปขอให้คนทำภาษาเขียน integration เฉพาะ VS Code คงไม่มีใครทำ เลยคิด Language Server Protocol (LSP) ขึ้นมาเป็นมาตรฐานกลาง

ไอเดียคือแยกความฉลาดของภาษาออกไปเป็น language server โปรแกรมแยกที่รู้จักภาษานั้นลึกๆ แล้วคอยบอก editor ว่าตรงไหน error หรือควร autocomplete อะไร

ข้อดีที่ทำให้ LSP ติดตลาดคือ:

• ทีมภาษาเขียนความฉลาดของภาษา ครั้งเดียว แล้วใช้ได้ทั้ง VS Code, Vim และ editor อื่น
• เขียนด้วย ภาษาของตัวเองได้ ทีม C++ เขียนด้วย C++ ทีม Java เขียนด้วย Java ไม่ต้องเขียนใหม่เป็น TypeScript
• ถ้า language server พัง ก็ไม่ลากตัว editor พังไปด้วย

Red Hat เอาไปทำ Java support ส่วนทีม Go เล่าว่าช่วงหนึ่งผู้ใช้ Go ราว 75% ใช้ VS Code และยอมรับว่าถ้าไม่มี VS Code ภาษา Go คงไม่แพร่หลายขนาดนี้ ทุกวันนี้มี language server มากกว่า 100 ภาษาแล้ว

Remote development: สถาปัตยกรรมเก่าที่คืนทุน

ต่อมาทีมเห็นผู้ใช้หลายกลุ่มที่ใช้ VS Code ไม่ได้ ทั้ง data scientist ที่รันโมเดลบนเครื่องแรงๆ อีกเครื่องผ่าน SSH คนที่ใช้ WSL คนที่พัฒนาใน Docker และบริษัทอย่าง Meta ที่ไม่ให้โค้ดอยู่บนแล็ปท็อปพนักงาน

ทุกกลุ่มเจอปัญหาเดียวกัน คือเครื่องมือกับไฟล์อยู่อีกเครื่อง แต่ editor อยู่เครื่องเรา

จุดที่ผมชอบที่สุดของช่วงนี้คือ ทางแก้มาจากการตัดสินใจเมื่อหลายปีก่อน VS Code แยก UI กับ extension host (process ที่รัน extension) เป็นคนละ process อยู่แล้ว คำถามเลยกลายเป็นว่า “ทำไมสอง process นี้ต้องอยู่เครื่องเดียวกันด้วย”

จากตรงนั้นเกิด Remote SSH, Dev Containers, WSL, GitHub Codespaces จนสุดท้ายคือ vscode.dev ที่เปิด VS Code บนเบราว์เซอร์ได้เลย ซึ่งก็คือความฝันแรกของทีมตั้งแต่วันเริ่มโปรเจกต์

Accessibility ไม่ใช่ช่องให้ติ๊ก

ทีมเคยมอง accessibility เป็นแค่ checkbox จนได้นั่งดูนักพัฒนาผู้พิการทางสายตาใช้ VS Code ผ่าน screen reader แล้วถึงรู้ว่าของที่ทำไว้แย่แค่ไหน

เพราะของที่เราเห็นกันง่ายๆ อย่างเส้นหยักใต้โค้ดที่ error ไอคอนหลอดไฟ quick fix หรือ breakpoint คนที่ใช้ screen reader แทบเข้าไม่ถึงเลย

หลังจากนั้นทีมก็ดัน accessibility ขึ้นเป็นข้อแรกของทุก iteration plan (แผนงานแต่ละรอบ) Megan คนในทีมคุยกับผู้ใช้ screen reader ทุกสัปดาห์ แล้วยังมีเทสต์อัตโนมัติที่ตีกลับ pull request ถ้าผิดข้อกำหนดด้าน accessibility

Megan บอกว่า accessibility ไม่ใช่ของประดับ สำหรับผู้ใช้บางคน มันคือเส้นแบ่งระหว่าง ใช้งานได้ กับ ใช้ไม่ได้เลย

ยุค AI: จาก Copilot ถึง Agent Mode

Copilot เริ่มจากช่วงต้นปี 2020 ที่ Oege de Moor ได้ลองโมเดลที่ต่อมากลายเป็น GPT-3 เขาเอาโจทย์สัมภาษณ์ 50 ข้อที่เคยใช้ตอนสอนที่ Oxford มาให้ลอง โมเดลตอบผิดหมดทุกข้อ

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

Oege บอกว่า Copilot ติดตลาดเพราะโมเดลเก่งก็ส่วนหนึ่ง อีกส่วนคือ ถ้า AI เดาผิด เราแทบไม่เสียอะไร คำแนะนำไม่ตรงใจก็พิมพ์ต่อไปเฉยๆ มันไม่ขวางทาง

ทีมอธิบายพัฒนาการของ AI ในเครื่องมือเป็นสไลเดอร์ ปรับว่าจะปล่อยให้ AI ทำเองแค่ไหน เริ่มจาก Ask (ถาม) ไปเป็น Edits (ให้มันแก้ไฟล์ให้) แล้วไปสุดที่ Agent Mode ที่ให้มันเลือกเรียกเครื่องมือเองได้

มีคนในทีมเทียบกับรถยนต์ไว้ชัดดี extension หรือ language server ดีๆ ก็เหมือนได้พวงมาลัยอุ่นหรือเครื่องแรงขึ้น คือแค่สะดวกขึ้น AI ยุคแรกเหมือน cruise control ที่เรายังต้องจับพวงมาลัยเอง แต่ AI agent คือรถที่ขับเองได้ ซึ่งเปลี่ยนนิยามงานของเดฟไปเลย

ตอนนี้ทีมกำลังขยับจากปล่อยอัปเดตรายเดือนไปเป็นรายสัปดาห์ และยอมรับตรงๆ ว่าวางโรดแมปหนึ่งปีแทบทำไม่ได้แล้ว เพราะไม่รู้ด้วยซ้ำว่าอีกหกเดือนจะเป็นยังไง

เรื่อง fork: Cursor, Windsurf, Antigravity

editor สาย AI อย่าง Cursor, Windsurf และ Antigravity ล้วน fork มาจาก VS Code ในสารคดีมีคนตั้งข้อสังเกตว่า UI คือสิ่งที่ทำให้ VS Code ชนะ และข้อจำกัดของ UI ก็คือเหตุผลที่คนต้อง fork ไปทำเอง เพราะยังไม่มีใครรู้ว่าหน้าตาการเขียนโค้ดในอนาคตควรเป็นแบบไหน

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

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

บทเรียนที่ผมว่าเดฟควรเก็บไว้

1. จังหวะเวลากับคนสำคัญพอๆ กับไอเดีย VS Code เกิดได้เพราะมาตอนที่เว็บ Node และ TypeScript พร้อมพอดี และมีทีมที่ทำงานด้วยกันมานาน
2. ตัดสินใจเรื่องโครงสร้างให้ดีตั้งแต่แรก ทั้งกฎ performance การแยก process และ API ที่ไม่ยอมให้พัง ล้วนคืนทุนในอีกหลายปีต่อมา
3. มาตรฐานเปิดพาไปได้ไกลกว่าทำเองคนเดียว LSP กับ dev container spec ทำให้ VS Code เข้าถึงคนได้มากกว่าที่ทีมเดียวจะทำไหว
4. ไม่ปล่อยของ ก็เหมือนไม่มีของ ทีมโตมาด้วยการปรับทีละนิดแต่ปล่อยต่อเนื่อง ไม่ได้รื้อทำใหม่ครั้งใหญ่
5. งานของเดฟกำลังขยับจากเขียนโค้ด ไปเป็นกำกับ agent และเครื่องมือก็ต้องเปลี่ยนตาม แต่ไม่ควรแลกคุณภาพกับกระแส

ถ้าจะดูแค่บางช่วง

ใครอยากดูเองแต่มีเวลาน้อย ช่วงพวกนี้คุ้มสุด (เวลาเป็นค่าประมาณ)

ประมาณนาทีที่	ช่วง	ทำไมน่าดู
21:00	Monaco และกฎ performance	บทเรียนเรื่อง UI thread ใช้ได้กับแอปทุกประเภท
30:00	เดโมบน Ubuntu และวันเปิดตัว	เห็นว่าการกลับลำของ Microsoft ใหญ่แค่ไหน
36:00	extension แยก process และ API ห้ามพัง	สถาปัตยกรรมที่ควรจำไปใช้
48:00	Language Server Protocol	ตัวอย่างที่ดีของการใช้มาตรฐานเปิดชนะตลาด
1:16:00	จุดเริ่มต้นของ Copilot	เบื้องหลังของ AI coding ที่เราใช้กันทุกวันนี้
1:29:00	เรื่อง fork	มุมมองของทีมต่อ Cursor, Windsurf และ Antigravity

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