Mời bạn đọc theo dõi "Featured Post":

Giáo Sư Đào Mộng Nam: Truyện Kiều Và Chữ Nho

9.22.2026

Từ Blời Đến Trời: Hành Trình Bốn Thế Kỷ Của Chữ Quốc Ngữ, Nhìn Từ Một Cuốn Từ Điển Năm 1838

Written by: Claude AI.

Curator/Editor: Học Trò.


Đọc lại cuốn Dictionarium Latino-Anamiticum — từ điển La Tinh–Việt in năm 1838 tại Serampore, Ấn Độ — có một điều khiến người đọc hôm nay phải dừng lại: tiếng Việt trong đó không hề xa lạ. Không phải thứ tiếng Việt của bốn trăm năm trước mà ta vẫn hình dung là "khó đọc, khó hiểu", mà là một thứ tiếng Việt đã mang gần như trọn vẹn hình hài của tiếng Việt hôm nay — cùng cách chia dấu, cùng cách ghép vần, cùng rất nhiều từ vẫn dùng nguyên xi qua gần hai trăm năm. Nếu một cuốn từ điển in năm 1838 đã gần với tiếng Việt hiện đại đến vậy, thì quãng đường từ những ký hiệu La-tinh hóa đầu tiên của các giáo sĩ dòng Tên đầu thế kỷ 17 đến trạng thái ấy đã đi qua những chặng nào? Và từ đó đến chữ Quốc ngữ ta gõ trên bàn phím hôm nay, còn bao nhiêu khúc quanh nữa? Bài viết này lần theo đúng câu hỏi ấy — không phải qua tiểu sử một cá nhân, mà qua chính sự biến đổi của con chữ, thế kỷ này sang thế kỷ khác, đối chiếu trực tiếp với những trang sách gốc.

I. Một câu hỏi bắt đầu từ một cuốn từ điển

Không có gì bảo đảm rằng một hệ chữ viết ra đời sẽ giữ nguyên hình dạng qua thời gian — chữ Anh thế kỷ 14 của Chaucer đọc lên đã xa lạ với người Anh hiện đại, chữ Pháp thời Trung Cổ cũng vậy. Chữ Quốc ngữ, xét về tuổi đời, cũng đã trải qua hơn bốn trăm năm kể từ những ký hiệu La-tinh hóa đầu tiên. Vậy mà một người đọc tiếng Việt hôm nay, mở cuốn Dictionarium Latino-Anamiticum (từ điển La Tinh–Việt, phần thứ hai trong bộ sách song đôi mà Giám mục Jean-Louis Taberd cho in năm 1838 tại Serampore), gần như không cần phải "dịch" cách viết sang tiếng Việt hiện đại. Câu chữ, cách chia dấu, cách ghép vần — tất cả đã ở rất gần với chuẩn chính tả hôm nay.

Đây không phải một cảm giác mơ hồ. Nó có thể kiểm chứng trực tiếp bằng cách mở bất kỳ trang nào trong 918 trang của bộ từ điển ấy, hoặc bất kỳ trang nào trong cuốn từ điển chiều ngược lại — Dictionarium Anamitico-Latinum (Việt–La Tinh) — ra đời cùng lúc. Cả hai cuốn cũng có thể tra cứu trực tiếp theo từng mục từ qua công cụ số hóa của Viện Nghiên cứu Hán Nôm — Nom Foundation, cho phép tìm kiếm toàn văn cuốn từ điển của Taberd. Bài viết này sẽ làm đúng việc đó ở phần VII bên dưới: mở những trang cụ thể, trích ra những từ cụ thể, và đặt chúng cạnh tiếng Việt hôm nay để người đọc tự thấy khoảng cách gần đến mức nào.

Nhưng trước khi đến được thời điểm 1838 ấy, chữ Quốc ngữ đã phải đi một quãng đường hơn hai trăm năm — từ những âm tiết rời rạc được vài giáo sĩ Bồ Đào Nha ghi vội trên lề một cuốn sách giáo lý, qua một cuốn từ điển in tại Roma năm 1651 còn đầy những cụm phụ âm và dấu câu xa lạ với mắt người đọc hiện đại, qua một bản thảo bị thiêu rụi trong lửa, đến ấn bản 1838 đã gần như là tiếng Việt của chúng ta. Và từ 1838 đến hôm nay, con đường còn dài hơn nữa: từ một hệ chữ chỉ dùng trong nhà thờ, nó trở thành công cụ hành chính của một chính quyền thuộc địa, rồi thành vũ khí của phong trào duy tân, rồi thành văn tự chính thức của cả một quốc gia, và cuối cùng là thứ ta gõ bằng ngón tay lên bàn phím điện thoại mỗi ngày mà không còn nhớ có một thời nó từng phải viết bằng ký hiệu ɓ, ml, tl.

Bài viết dựa trên các nghiên cứu ngôn ngữ học và sử học đã công bố — của Roland Jacques, Trang Phan và Luisa M. Paternicò, Vũ Đức Nghiệu, Nguyễn Cung Thông, cùng các mục từ Wikipedia và các bài báo lịch sử đã được kiểm chứng — kết hợp với việc đọc trực tiếp một số trang trong chính hai cuốn từ điển 1838 nói trên.

II. Trước chữ La Tinh: một ngôn ngữ ba tầng chữ viết

Trước khi có bất kỳ ký hiệu La-tinh nào, tiếng Việt đã tồn tại song song trong ba lớp văn tự suốt nhiều thế kỷ. Lớp thứ nhất là chữ Hán (hay chữ Nho) — văn tự chính thức dùng trong khoa cử, hành chính, và văn chương bác học kể từ thời Bắc thuộc, dùng để ghi tiếng Hán cổ điển chứ không trực tiếp ghi âm tiếng Việt. Lớp thứ hai là chữ Nôm — một hệ chữ bản địa, hình thành dần từ khoảng thế kỷ 10–13, dùng lại hoặc phỏng theo các bộ phận chữ Hán để ghi trực tiếp âm và nghĩa tiếng Việt. Nhà nghiên cứu John Phan (Đại học Columbia), trong luận án tiến sĩ Lacquered Words: The Evolution of Vietnamese under Sinitic Influences from the 1st Century BCE through the 17th Century CE (Cornell, 2013) và các công trình sau đó, cho rằng chính quá trình tiếng Việt trở nên "đơn tiết hóa" (monosyllabicization) trong khoảng thời gian này đã tạo ra động lực để giới trí thức bắt đầu chấp nhận một thứ chữ viết bản địa vốn trước đó bị xem là "quê mùa" so với chữ Hán.

Vấn đề của chữ Nôm — điều sẽ trở thành động lực gián tiếp cho sự ra đời của chữ Quốc ngữ hai thế kỷ sau — là nó không bao giờ được chuẩn hóa triệt để. Cùng một âm tiết có thể được ghi bằng nhiều chữ Nôm khác nhau tùy vùng miền, tùy thời kỳ, tùy người chép; và ngược lại, cùng một hình chữ Nôm đôi khi lại đọc được theo nhiều cách khác nhau tùy văn cảnh. Đây là lớp thứ ba của bức tranh: một ngôn ngữ nói phong phú, nhưng bị ràng buộc bởi hai hệ chữ viết — một hệ ngoại lai (chữ Hán) chỉ dành cho tầng lớp có học, một hệ bản địa (chữ Nôm) giàu có về văn chương nhưng thiếu một quy tắc đọc cố định. Chính vào khoảng trống ấy, đầu thế kỷ 17, những giáo sĩ Dòng Tên đến từ Bồ Đào Nha và Ý mang theo một công cụ hoàn toàn khác: bảng chữ cái La Tinh.

III. Mười năm đặt nền móng: Pina, Borri, Amaral, Barbosa (1615–1626)

Người đầu tiên cần được nhắc đến không phải Alexandre de Rhodes — cái tên vẫn thường được nhớ đến nhiều nhất — mà là một giáo sĩ Bồ Đào Nha mất sớm và ít được biết đến hơn nhiều: Francisco de Pina (1585–1625). Theo tiểu sử trên Wikipedia tiếng Anh và bài viết của tạp chí Công giáo Aleteia, Pina theo học tại Học viện Thánh Phaolô ở Macao trong khoảng 1611–1617, nơi ông tiếp xúc với công trình của giáo sĩ Bồ Đào Nha João Rodrigues Tçuzu — người đã đi tiên phong trong việc La-tinh hóa tiếng Nhật theo ngữ âm Bồ Đào Nha. Pina đặt chân đến Đàng Trong (vùng người châu Âu gọi là Cochinchina) năm 1617, và ông là người đầu tiên áp dụng một hệ thống ghi âm tương tự cho tiếng Việt — đồng thời cũng là người đầu tiên mô tả chi tiết sáu thanh điệu của tiếng Việt (khi ấy còn gọi là tiếng Đàng Trong/Đàng Ngoài, hay Tunchinese trong cách gọi của châu Âu).

Pina qua đời năm 1625 tại Đà Nẵng trong một vụ đắm tàu, khi công trình còn dang dở. Nhưng ông đã kịp để lại hai học trò trực tiếp, và chính hai người này mới là tác giả của những cuốn từ điển đầu tiên theo đúng nghĩa — dù cả hai cuốn ấy đều đã thất lạc: Gaspar do Amaral biên soạn một từ điển Việt–Bồ, và António Barbosa biên soạn theo chiều ngược lại, Bồ–Việt. Không có bản sao nào của hai công trình này còn sót lại đến ngày nay; ta chỉ biết đến chúng qua lời kể của người kế tục — người đã dùng cả hai làm nền tảng trực tiếp cho công trình của chính mình: Alexandre de Rhodes.

IV. Alexandre de Rhodes và cuốn từ điển in tại Roma năm 1651

Alexandre de Rhodes (1591–1660), giáo sĩ Dòng Tên gốc Avignon, đến Đàng Trong năm 1624 — chỉ một năm trước khi Pina qua đời — và học tiếng Việt trực tiếp từ chính Pina trong thời gian ngắn ngủi còn lại. Theo mục từ Wikipedia và bài nghiên cứu học thuật "First codification of Vietnamese by 17th-century missionaries" (đăng trên tạp chí Histoire Épistémologie Langage, 2017), de Rhodes dành mười hai năm sống và truyền giáo tại cả Đàng Trong lẫn Đàng Ngoài, kế thừa trực tiếp di sản của Pina, Amaral và Barbosa, rồi hệ thống hóa lại toàn bộ thành một công trình in tại Roma năm 1651 dưới sự bảo trợ của Bộ Truyền Giáo (Propaganda Fide): Dictionarium Annamiticum Lusitanum et Latinum — từ điển ba ngôn ngữ Việt–Bồ–La (bản scan gốc lưu tại Thư viện Quốc gia Pháp, Gallica), kèm theo một cuốn ngữ pháp tóm lược mang tên Linguae Annamiticae seu Tunchinensis Brevis Declaratio.

Theo mục từ Wikipedia về chính cuốn từ điển này, công trình gồm khoảng 8.000 mục từ tiếng Việt, mỗi mục kèm chú giải bằng tiếng Bồ Đào Nha và tiếng La Tinh — và đáng chú ý, "cuốn từ điển thường trình bày song song hai dạng chữ viết cho cùng một âm vị, cho thấy cả dạng cũ lẫn dạng mới của nó" — một chi tiết cho thấy ngay tại thời điểm in ấn, chính de Rhodes cũng đã ý thức được rằng cách viết ông ghi lại không phải là một hệ thống đã ổn định, mà là một hệ thống đang trong quá trình biến đổi, ông chỉ đang chụp lại một lát cắt của nó.

Đây chính là điểm mấu chốt để hiểu vì sao chữ Quốc ngữ năm 1651 lại trông khác xa chữ Quốc ngữ năm 1838, dù khoảng cách chỉ chưa đầy hai trăm năm.

V. Chữ Quốc ngữ năm 1651 trông khác chữ hôm nay thế nào

Nếu đặt một trang trong cuốn từ điển của de Rhodes bên cạnh một trang của Taberd in gần hai thế kỷ sau, sự khác biệt lớn nhất không nằm ở từ vựng, mà nằm ở chính cấu trúc phụ âm đầu của hàng loạt âm tiết. Theo nghiên cứu của nhà ngôn ngữ học Vũ Đức Nghiệu (Đại học Khoa học Xã hội và Nhân văn Hà Nội), đăng tại khoavanhoc-ngonngu.edu.vn, tiếng Việt thế kỷ 17 — đúng như de Rhodes ghi lại — còn tồn tại đầy đủ bốn tổ hợp phụ âm đầu /bl/, /ml/, /mɲ/ (ghi là mnh), /tl/, những tổ hợp hoàn toàn biến mất khỏi tiếng Việt hiện đại. Nhà nghiên cứu độc lập Nguyễn Cung Thông, trong loạt bài dài kỳ "Tiếng Việt từ thế kỷ 17" (một phần đăng tại nghiencuulichsu.com), liệt kê hàng chục ví dụ cụ thể lấy trực tiếp từ từ điển de Rhodes — mỗi ví dụ là một từ vẫn còn dùng nguyên nghĩa hôm nay, chỉ khác đúng phụ âm đầu:

blời (hoặc tlời) → trời (bầu trời) · blăngtrăng (mặt trăng) · blảtrả (trả lại) · blái (hoặc tlái) → trái (trái cây; sai trái) · blaitrai/giai (con trai) · blotro/gio (tro bụi) · blầu (hoặc tlâu) → trầu (lá trầu) · mlẽlẽ (lý lẽ) · mlờilời (lời nói) · tlướctrước (phía trước) · tlẻtrẻ (trẻ con) · tlâutrâu (con trâu) · tlêutrêu (trêu chọc) · tleotreo (treo lên) · tlămtrăm (một trăm) · tlêntrên (phía trên)

Điều thú vị hơn nữa là dấu vết của những tổ hợp này vẫn còn lưu lại ngay trong chính hình chữ Nôm cổ — Nguyễn Cung Thông chỉ ra rằng chữ Nôm ghi "trăng" từng ghép bộ phận 巴 (âm "ba") với 夌 (âm "lăng"): ba + lăng → blăngtrăng; và chữ Nôm ghi "trời" ghép 巴 với 例 (âm "lệ"): ba + lệ → blệ → rồi phân nhánh theo từng vùng miền thành blơilờigiời (cách phát âm vẫn còn nghe được trong khẩu ngữ Hà Nội hôm nay, "giời ơi") – và trời (dạng chuẩn hóa toàn quốc). Nói cách khác: một từ chuẩn mực bậc nhất của tiếng Việt hiện đại — "trời" — mang trong mình dấu vết hóa thạch của một tổ hợp phụ âm đã biến mất gần ba trăm năm, và của một sự phân nhánh phương ngữ vẫn còn nghe được cho đến hôm nay.

Bên cạnh phụ âm đầu, hai chi tiết khác của chữ Quốc ngữ 1651 cũng đã hoàn toàn biến mất. Thứ nhất là ký tự ɓ ("b có móc", tiếng Anh gọi là B with flourish) — theo mục từ Wikipedia, de Rhodes dùng ký tự này để ghi một âm ông mô tả là "gần giống chữ β Hy Lạp... phát âm hơi thô, mở môi như một phụ âm môi". Ký tự này biểu thị âm /β/ (một âm xát môi-môi hữu thanh), tách biệt hẳn với chữ "b" thường; về sau âm này nhập vào âm xát môi-răng, và ký tự ɓ dần được thay bằng chữ v — trong khi bản thân chữ "v" ở thời de Rhodes lại đang biểu thị một âm hoàn toàn khác (bán nguyên âm /w/). Thứ hai là dấu ngã cổ (tiếng Anh gọi the apex, giống hình dấu ngã hiện nay nhưng có công năng khác hẳn) — theo mục từ Wikipedia về dấu ngã tiếng Việt, de Rhodes dùng dấu này đặt trên các nguyên âm o, u ở cuối từ để ghi một âm mũi đặc trưng của phương ngữ Hà Nội; dấu này dần biến mất vào khoảng giữa thế kỷ 18, nhập hẳn vào cách viết "-ng" — ví dụ ao᷃ trở thành ong, ou᷃ trở thành ông. Và theo đúng nguồn này, đến ấn bản Dictionarium Anamitico-Latinum năm 1838 của Pigneau/Taberd, "quá trình chuyển đổi ấy đã hoàn tất" — một xác nhận độc lập, từ một nguồn hoàn toàn khác, cho đúng quan sát đã khởi đầu bài viết này.

Nói ngắn gọn: giữa 1651 và 1838, tiếng Việt viết đã trải qua điều mà các nhà ngôn ngữ học gọi là một cuộc tái cấu trúc phụ âm đầu và hệ thống ghi âm mũi — và theo nghiên cứu của Vũ Đức Nghiệu, phần lớn quá trình ấy diễn ra dồn dập trong thế kỷ 18: tổ hợp /tl/ gần như biến mất hoàn toàn ngay trong thế kỷ 18, còn /bl/ và /ml/ kéo dài thêm đến đầu thế kỷ 19 mới hoàn tất — vẫn còn thấy dạng biến thể trong một số văn bản đầu thế kỷ 19 như Sách sổ sang chép các việc của linh mục Philipphê Bỉnh (1759–1832). Đến khi Pigneau de Béhaine bắt đầu công trình từ điển của mình vào năm 1773, phần lớn cuộc chuyển đổi ấy đã xong.

VI. Một trăm hai mươi hai năm im lặng: từ bản thảo cháy dở đến ấn bản 1838

Sau de Rhodes, chữ Quốc ngữ bước vào một giai đoạn gần như vô hình đối với lịch sử — không biến mất, nhưng cũng không phát triển thành văn tự công khai của xã hội Việt Nam. Trong suốt thế kỷ 17 và phần lớn thế kỷ 18, nó chỉ tồn tại trong phạm vi hẹp của cộng đồng Công giáo: dùng để ghi kinh sách, thư từ giữa giáo sĩ với nhau, và các bản dịch giáo lý — trong khi văn chương, hành chính, khoa cử của toàn xã hội Việt Nam vẫn vận hành hoàn toàn bằng chữ Hán và chữ Nôm, không hề hay biết đến sự tồn tại của hệ chữ La-tinh hóa song song ấy.

Năm 1773, Pierre Pigneau de Béhaine — khi ấy là Giám mục Adran, Đại diện Tông tòa Cochinchina — bắt tay biên soạn một cuốn từ điển Việt–La Tinh mới, với sự cộng tác của tám trí thức người Việt ở miền Nam, tiếp nối trực tiếp truyền thống de Rhodes đã khởi xướng hơn một thế kỷ trước. Nhưng năm 1778, bản thảo ấy — thành quả của năm năm lao động — rơi vào tay ngọn lửa trong vụ hỏa hoạn thiêu rụi trường dòng Anamitic tại tỉnh Cà Mau. Sáu mươi năm sau, chính người kế nhiệm của Pigneau — Giám mục Jean-Louis Taberd — đã kể lại biến cố này bằng chính lời mình trong lá thư MONITUM mở đầu ấn bản 1838, gọi bản thảo gốc là thứ "đáng quý biết bao" đã "rơi vào tay ngọn lửa". Taberd thu thập lại những gì còn sót — theo nghiên cứu văn bản học của Trang Phan và Luisa M. Paternicò (Ca' Foscari/L'Orientale, 2026, đăng tại Journal of the Southeast Asian Linguistics Society), phần cốt lõi từ vựng gần như nguyên vẹn — rồi mở rộng thêm một phần ngữ pháp hoàn toàn do ông tự biên soạn, trước khi cho in toàn bộ công trình tại Serampore, Ấn Độ, năm 1838, dưới sự hỗ trợ của nhà in truyền giáo Tin Lành do William Carey gây dựng.

Chính khoảng thời gian dài giữa 1773 (khi Pigneau bắt đầu) và 1838 (khi Taberd cho in) — cộng thêm cả thế kỷ trước đó nữa kể từ 1651 — là quãng thời gian mà cuộc tái cấu trúc ngữ âm nói ở phần V đã âm thầm hoàn tất. Ấn bản 1838, vì vậy, không phải là điểm khởi đầu của tiếng Việt hiện đại, mà là điểm nó đã đến nơi — một tấm ảnh chụp nhanh của một hệ chữ vừa hoàn tất một cuộc chuyển đổi lớn, dù bản thân tác giả của nó (Taberd) có lẽ không hề ý thức được mình đang đứng ở đúng cái mốc ấy.

VII. Đọc trực tiếp hai cuốn từ điển 1838: bằng chứng nằm ngay trên trang giấy

Phần này là trọng tâm thực sự của bài viết, bởi nó không dựa vào suy luận gián tiếp mà dựa vào chính những gì có thể đọc được trên trang giấy gốc.

7.1. Cuốn Việt–La Tinh (Dictionarium Anamitico-Latinum)

Đây là cuốn từ điển tra theo mục từ tiếng Việt, mỗi mục từ được trình bày theo mô hình ba tầng: một chữ Hán/Nôm gốc đặt trong khung vuông, kế đó là chữ Quốc ngữ tương ứng, rồi đến các từ ghép — mỗi từ ghép lại có chữ Hán/Nôm riêng, chữ Quốc ngữ riêng, và cuối cùng là chú giải La Tinh. Ở trang 89 của ấn bản gốc, mục từ gốc chữ 骨 (đọc "Cốt", nghĩa "amputare; ossa; substantia" — xương, cốt) kéo theo một loạt từ ghép mà bất kỳ người Việt nào hôm nay cũng nhận ra ngay không cần giải nghĩa:

gân cốt ("gân — , omnes artus" — toàn bộ các khớp) · cốt nhục ("— nhục, germani fratres" — anh em ruột thịt) · hài cốt ("hài — , ossa" — xương cốt) · cột nhà ("— nhà, columna domûs" — cột nhà) · cột trụ ("— trụ, columna quæ sustentat ædificium" — cột chống đỡ tòa nhà)

Ở trang 339, mục từ gốc chữ 疑 (đọc "Nghi", "dubitare" — nghi ngờ) cho ra một loạt từ ghép khác, trong đó có một thành ngữ vẫn còn dùng nguyên vẹn từng chữ trong tiếng Việt hôm nay:

hồ nghi ("hồ — , id." — nghi ngờ) · bán tín bán nghi ("bán tín bán — , probabilis" — nửa tin nửa ngờ)

Và ngay bên cạnh, mục từ gốc chữ 儀 (cũng đọc "Nghi", nghĩa "majestas; gravitas" — oai nghiêm, trang trọng) cho ra:

oai nghi ("oai — , majestas; gravitas; augustus" — oai nghiêm) · lễ nghi ("lễ — , ritus; cæremonia" — lễ nghi, nghi thức)

Tất cả những từ trên — gân cốt, cốt nhục, hài cốt, cột nhà, cột trụ, hồ nghi, bán tín bán nghi, oai nghi, lễ nghi — không phải là những từ cổ đã mai một, mà là những từ một người Việt bình thường hôm nay vẫn dùng trong lời ăn tiếng nói hằng ngày, không cần tra từ điển, không cần chú thích. Khoảng cách giữa trang giấy in năm 1838 và miệng người nói tiếng Việt năm 2026 gói gọn trong chín từ này gần như bằng con số không.

7.2. Cuốn La Tinh–Việt (Dictionarium Latino-Anamiticum)

Cuốn thứ hai tra theo mục từ La Tinh, và vì vậy phần chữ Việt xuất hiện dưới dạng câu văn xuôi giải nghĩa — cho phép quan sát không chỉ từ vựng mà cả cú pháp, cách đặt câu. Ở trang 53 của ấn bản gốc, mục từ La Tinh appareo (hiện ra, tỏ ra) được giải nghĩa bằng một câu tiếng Việt hoàn chỉnh, đọc lên không khác gì văn xuôi hiện đại:

"tổ mình ra, hiện ra, ra mặt, bày tỏ, bày ra tổ, bày ra tổ tường, hiện đến, ứng hiện; ... chẳng thấy đặng ... bởi đó thì biết"

Ở trang 303, mục từ illiberalitas (thói keo kiệt, bủn xỉn) được giải nghĩa: "sự hà tiện, bòn đãi, hèn hạ, xấu ruột" — và mục illico (ngay lập tức) cho ra một chuỗi từ đồng nghĩa vẫn dùng nguyên hôm nay: "tức thì, bỗng chúc, liền, tức tốc, tốc tốc, thoát chúc, bổng chốc, phút chốc, xảy". Không một cụm phụ âm bl-/ml-/tl- nào còn sót lại; không một dấu ngã cổ (apex) nào còn xuất hiện; toàn bộ câu chữ đã mang đầy đủ hệ thống sáu thanh điệu và bộ nguyên âm đôi/ba của tiếng Việt hiện đại, viết bằng đúng những con chữ và dấu mà một học sinh tiểu học Việt Nam hôm nay vẫn học.

Điều đáng nói là cả hai trang được trích ở trên đều nằm rải rác, được chọn ngẫu nhiên trong số 918 và 957 trang của hai cuốn sách — không phải những trang được chọn lọc kỹ để chứng minh luận điểm. Đây chính là bằng chứng thuyết phục nhất: độ "hiện đại" của chữ Quốc ngữ năm 1838 không phải là một vài câu ngoại lệ, mà là trạng thái phổ biến, xuyên suốt toàn bộ công trình.

VIII. Từ bản thảo giáo sĩ đến chữ viết của chính quyền: thế kỷ 19 dưới ảnh hưởng Pháp

Trong suốt hai trăm năm kể từ de Rhodes, chữ Quốc ngữ vẫn là một hệ chữ "nội bộ" — dùng trong nhà thờ, không dùng ngoài xã hội. Bước ngoặt khiến nó bước ra khỏi phạm vi tôn giáo đến từ một động lực hoàn toàn khác: chính sách của chính quyền thuộc địa Pháp sau cuộc xâm chiếm Nam Kỳ giữa thế kỷ 19. Theo các nguồn sử học đã tổng hợp, chính quyền Pháp nhận ra chữ Quốc ngữ — dễ học hơn nhiều so với chữ Hán vốn đòi hỏi hàng nghìn giờ khổ luyện — là công cụ lý tưởng để vừa phổ biến hành chính nhanh chóng, vừa cắt đứt mối liên hệ giữa giới trí thức Việt Nam với kho tàng Hán văn và truyền thống khoa cử Nho học.

Ngày 15 tháng 4 năm 1865, tờ báo Quốc ngữ đầu tiên — Gia Định Báo — ra số đầu tiên tại Sài Gòn, theo mục từ Wikipedia, ban đầu do E. Potteaux làm chủ bút, Huỳnh Tịnh Của (Paulus Của) làm giám đốc biên tập. Đến ngày 16 tháng 9 năm 1869, Trương Vĩnh Ký (Petrus Ký) được bổ nhiệm làm chủ bút — và theo bài viết trên Tuổi Trẻ, chính ông là người biến tờ báo thành bệ phóng cho văn xuôi Quốc ngữ hiện đại — dịch truyện dân gian, sáng tác, phổ biến lối viết Quốc ngữ tới độc giả bình dân thay vì chỉ giới hạn trong tầng lớp trí thức Công giáo. Năm 1878, rồi chính thức hơn vào năm 1882, chữ Quốc ngữ trở thành văn tự bắt buộc trong công văn hành chính tại Nam Kỳ.

Nỗ lực chuẩn hóa đầu tiên mang tính học thuật, quy mô quốc tế, diễn ra năm 1902: Hội nghị quốc tế đầu tiên về nghiên cứu Viễn Đông họp tại Hà Nội có một tiểu ban riêng đề xuất cải cách cách viết chữ Quốc ngữ — nhưng đề án này, theo các nguồn đã tra cứu, cuối cùng không được áp dụng, chữ Quốc ngữ vẫn giữ nguyên lối viết đã định hình từ thời Taberd. Ba mươi năm sau, năm 1931, công trình từ điển học quy mô nhất từ trước đến thời điểm đó ra đời: Việt Nam Tự Điển của Hội Khai Trí Tiến Đức, do Phạm Quỳnh làm chủ biên cùng một ban biên tập gồm Nguyễn Văn Vĩnh, Trần Trọng Kim, Bùi Kỷ và nhiều học giả khác — dày 663 trang, thu thập từ vựng của cả ba miền Bắc Trung Nam, và theo ghi nhận trên Wikipedia tiếng Việt, vẫn được xem là một trong những mẫu mực chính tả và từ vựng tham chiếu cho đến tận thế kỷ 21.

IX. Từ trường học đến toàn dân: đầu thế kỷ 20 và cuộc vận động truyền bá

Nếu thế kỷ 19 là giai đoạn chữ Quốc ngữ được chính quyền thuộc địa áp đặt từ trên xuống, thì đầu thế kỷ 20 là giai đoạn nó được chính người Việt Nam chọn lấy làm vũ khí — cho một mục đích hoàn toàn khác với ý định ban đầu của người Pháp. Tháng 3 năm 1907, tại Hà Nội, một nhóm nhà nho duy tân — đứng đầu là Lương Văn Can, với sự tham gia của Phan Bội Châu và Phan Châu Trinh — mở Đông Kinh Nghĩa Thục, một trường học không thu học phí, dạy miễn phí cho mọi lứa tuổi, mọi giới tính. Theo mục từ Wikipedia, trường đặc biệt chủ trương phổ biến chữ Quốc ngữ như một công cụ khai dân trí, canh tân lối sống, tiếp cận tri thức phương Tây — xem việc phổ cập một thứ chữ dễ học là điều kiện tiên quyết để đại đa số dân chúng thoát khỏi tình trạng mù chữ vốn kéo dài suốt thời phong kiến. Chính quyền thuộc địa, nhận ra tính chất "nguy hiểm" của phong trào duy tân núp dưới hình thức một ngôi trường dạy chữ, đã buộc trường phải đóng cửa chỉ tám tháng sau, vào tháng 11 năm 1907.

Ba mươi năm sau, tinh thần ấy được nối lại ở quy mô lớn hơn nhiều. Ngày 25 tháng 5 năm 1938, tại Hà Nội, Hội Truyền Bá Quốc Ngữ chính thức thành lập, với học giả Nguyễn Văn Tố — nguyên thành viên Viện Viễn Đông Bác Cổ — làm hội trưởng, cùng Bùi Kỷ làm phó hội trưởng, và trong ban cố vấn có Trần Trọng KimHoàng Xuân Hãn. Theo bài viết đăng tại trang tin Đại học Quốc gia Hà Nội vnu.edu.vn, hội hoạt động bằng cách vận động quyên góp, biên soạn tài liệu học chữ, đào tạo giáo viên tình nguyện, và mở các lớp học miễn phí ở khắp các vùng nông thôn Bắc Kỳ — cho đến trước Cách mạng Tháng Tám, hội và các thành viên của mình đã giúp hơn bảy mươi nghìn người Việt Nam thoát nạn mù chữ. Đáng chú ý, trong số các cố vấn của hội có Hoàng Xuân Hãn — người sẽ còn xuất hiện một lần nữa, ở một vai trò còn quan trọng hơn, chỉ bảy năm sau.

X. Năm 1945: lần đầu tiên chữ Quốc ngữ trở thành ngôn ngữ giảng dạy ở mọi cấp học

Nếu phải chọn một cột mốc để đánh dấu thời điểm chữ Quốc ngữ hoàn tất việc chuyển mình từ "công cụ của giáo sĩ và báo chí" thành "văn tự chính thức của toàn bộ nền giáo dục quốc gia", đó phải là mùa hè năm 1945. Nội các Trần Trọng Kim — chính phủ Việt Nam đầu tiên thời hiện đại hoàn toàn do người Việt điều hành, tồn tại từ tháng 4 đến tháng 8 năm 1945 — bổ nhiệm Hoàng Xuân Hãn (1908–1996), nhà toán học kiêm sử gia kiêm ngữ học từng là cố vấn Hội Truyền Bá Quốc Ngữ nói ở phần IX, làm Bộ trưởng Giáo dục và Mỹ thuật. Theo mục từ Wikipedia, chính ông là người soạn thảo và ban hành chương trình giáo dục Việt Nam đầu tiên trong lịch sử hiện đại lấy tiếng Việt (ghi bằng chữ Quốc ngữ) làm ngôn ngữ giảng dạy chính thức ở mọi cấp học, kể cả bậc đại học — điều chưa từng có tiền lệ, bởi trước đó giáo dục bậc cao tại Việt Nam vẫn vận hành chủ yếu bằng tiếng Pháp. Đây cũng chính là vị học giả từng "sáng chế phương pháp i-tờ" giúp việc học đọc học viết trở nên dễ dàng hơn, và là sử gia đầu tiên nghiên cứu bài bản các văn bản Nôm do chính các giáo sĩ Dòng Tên thế kỷ 17 để lại — khép lại một vòng tròn kéo dài từ de Rhodes đến chính ông.

Chỉ vài tháng sau, vào mùa thu năm 1945, một chính quyền mới ra đời tại Việt Nam, và ngay từ những văn kiện đầu tiên đã tiếp tục xác nhận chữ Quốc ngữ là văn tự chính thức duy nhất của quốc gia — thay thế hoàn toàn vai trò hành chính của chữ Hán và chữ Nôm vốn đã suy yếu từ khi kỳ thi Hương, thi Hội theo lối Nho học cuối cùng bị bãi bỏ đầu thế kỷ 20. Điều đáng chú ý, và có lẽ là điều hiếm hoi nhất trong toàn bộ lịch sử chính trị đầy chia cắt của Việt Nam suốt nửa sau thế kỷ 20, là bất kể những khác biệt sâu sắc về thể chế và đường lối giữa các chính quyền kế tiếp nhau trên các phần lãnh thổ khác nhau của đất nước trong giai đoạn chiến tranh và chia cắt sau đó, không một chính quyền nào — ở bất kỳ miền nào, bất kỳ giai đoạn nào — từng đặt lại vấn đề vai trò của chữ Quốc ngữ như văn tự quốc gia. Một hệ chữ ra đời từ tay các giáo sĩ nước ngoài, từng bị chính những người yêu nước đầu thế kỷ 20 gọi là "công cụ xâm lược tinh thần", cuối cùng lại trở thành một trong rất ít điểm đồng thuận tuyệt đối, xuyên suốt mọi lằn ranh chính trị của thế kỷ 20 Việt Nam. Bài viết trên tạp chí diacritics.org gọi đúng nghịch lý này là hành trình "từ gông cùm trở thành thanh gươm" (the shackle that became the sword): thứ chữ được thiết kế ban đầu để phục vụ mục đích truyền giáo, rồi bị khai thác để phục vụ mục đích cai trị, cuối cùng lại trở thành công cụ phổ cập tri thức mà chính những phong trào đòi độc lập đã tận dụng triệt để, bởi khả năng học đọc học viết chỉ trong vài tuần thay vì vài năm của nó.

XI. Cuộc chuẩn hóa chưa bao giờ thực sự kết thúc

Trở thành văn tự chính thức không đồng nghĩa với việc chính tả đã được thống nhất tuyệt đối. Trong suốt nửa sau thế kỷ 20, tiếng Việt viết vẫn tồn tại những điểm mập mờ kế thừa từ chính lịch sử hình thành phức tạp của nó — đặc biệt là sự lẫn lộn giữa i và y trong các âm tiết như "kỹ/kỉ", "quý/qúi", và giữa gi và d ở một số phương ngữ. Ngày 30 tháng 11 năm 1980, rồi chính thức hơn qua Quyết định 240/QĐ ngày 5 tháng 3 năm 1984, Bộ Giáo dục ban hành quy định chính tả tiếng Việt và thuật ngữ tiếng Việt áp dụng cho sách giáo khoa — theo tra cứu tại luatvietnam.vn, đây được xem là văn bản quy phạm đầu tiên chính thức hóa các quy tắc chính tả cho toàn ngành giáo dục, dù nó không (và có lẽ không thể) xóa hết mọi khác biệt vùng miền trong thói quen viết của người dùng phổ thông.

Cuộc tranh luận về chính tả tiếp tục sống động cho đến tận gần đây. Năm 2017, Phó Giáo sư Bùi Hiền công bố một đề án cải tiến chữ Quốc ngữ triệt để — giảm số lượng con chữ phụ âm từ 38 xuống 31, lấy phương ngữ Hà Nội làm chuẩn, với mục tiêu mỗi âm chỉ ứng với đúng một con chữ. Theo bài viết trên Saigoneer, đề án gây ra một làn sóng phản ứng dữ dội trên mạng xã hội — phần lớn phản đối vì cho rằng việc thay đổi một hệ chữ đã gắn bó với người Việt suốt hàng thế kỷ là một sự đứt gãy văn hóa không cần thiết, dù về mặt kỹ thuật đề án có cơ sở ngôn ngữ học riêng của nó. Đề án chưa bao giờ được áp dụng chính thức, nhưng sự việc tự nó là một lời nhắc rằng ngay cả sau bốn trăm năm, câu hỏi "chữ Quốc ngữ nên trông ra sao" vẫn chưa bao giờ hoàn toàn khép lại.

XII. Kỷ nguyên số: gõ chữ Quốc ngữ qua bàn phím

Chặng đường cuối cùng của hành trình bốn thế kỷ này không diễn ra trên trang giấy, mà trên bàn phím. Theo mục từ Wikipedia về ngôn ngữ Việt và máy tính, phương pháp gõ Telex — quy tắc biến các tổ hợp phím ASCII thường (như gõ "aa" cho "â", "s" cho dấu sắc) thành chữ cái có dấu — vốn có gốc gác từ hệ thống điện tín (máy telex) những năm 1920–1930, được cải biên lại trong thập niên 1980–1990 để gõ tiếng Việt trên bàn phím máy tính chuẩn tiếng Anh. Năm 1987, kỹ sư người Việt sáng lập bộ gõ VNI — dùng phím số để biểu thị dấu — được thương mại hóa rộng rãi qua một bộ phông chữ và phần mềm soạn thảo cho hệ điều hành MS-DOS, và theo cùng nguồn trên, thậm chí từng được chính Microsoft tích hợp vào Windows 95.

Năm 1993 là một cột mốc kép quan trọng: tổ chức Unicode chính thức đồng ý mã hóa đầy đủ mọi ký tự tiếng Việt, cùng năm đó Bộ Khoa học, Công nghệ và Môi trường Việt Nam ban hành tiêu chuẩn TCVN 5712 (còn gọi VSCII — Vietnam's Standard Code for Information Interchange), bộ mã 8-bit đầu tiên dành riêng cho tiếng Việt. Nhưng phải đến khi Microsoft tích hợp hỗ trợ Unicode gốc cho tiếng Việt vào Windows 2000, các bộ mã riêng như VNI mới thực sự nhường chỗ hoàn toàn cho Unicode và bộ gõ Telex — hiện đã trở thành lựa chọn phổ biến nhất, đặc biệt qua phần mềm mã nguồn mở Unikey, công cụ mà theo bài viết trên Saigoneer, đã trở nên gần như đồng nghĩa với việc gõ tiếng Việt trên máy tính, kể cả trong cộng đồng người Việt hải ngoại.

Có một sự đối xứng đáng chú ý ở đây, dù ít ai để ý: bốn trăm năm trước, các giáo sĩ Dòng Tên phải phát minh ra những ký hiệu hoàn toàn mới — dấu sắc, huyền, hỏi, ngã, nặng, mũ, móc — để bảng chữ cái La Tinh vốn dĩ nghèo nàn có thể ghi lại được sự phong phú thanh điệu của tiếng Việt. Bốn trăm năm sau, bài toán lặp lại y hệt ở một tầng công nghệ khác: làm sao để một bàn phím thiết kế cho tiếng Anh — cũng nghèo nàn ký tự không kém gì bảng chữ cái La Tinh gốc của thế kỷ 17 — có thể gõ ra được đúng những dấu ấy. Giải pháp Telex, xét cho cùng, cũng là một cách "La-tinh hóa lần hai": dùng đúng những con chữ La Tinh thường (a, a, a → â) để đại diện cho một ký hiệu đặc biệt, giống hệt tinh thần mà Pina, Amaral, Barbosa và de Rhodes đã làm khi lần đầu ghi âm tiếng Việt bằng mẫu tự châu Âu.

XIII. Kết luận: một cuốn từ điển, và khoảnh khắc nhận ra bốn trăm năm không hề dài như tưởng

Quay lại câu hỏi mở đầu bài viết: vì sao đọc Dictionarium Latino-Anamiticum năm 1838 lại cho cảm giác gần gũi đến vậy? Câu trả lời, sau khi đi hết chặng đường trên, hóa ra không nằm ở việc tiếng Việt "ít thay đổi" một cách chung chung, mà nằm ở một sự trùng hợp thời điểm rất cụ thể: cuộc biến đổi ngữ âm lớn nhất trong lịch sử chữ Quốc ngữ — sự tan rã của các tổ hợp phụ âm bl-/ml-/tl-, sự biến mất của dấu ngã cổ và ký tự ɓ — đã căn bản hoàn tất ngay trước khi Pigneau bắt đầu công trình từ điển của mình năm 1773, và chắc chắn đã xong hẳn khi Taberd cho in ấn bản cuối cùng năm 1838. Nói cách khác, cuốn sách ấy không tình cờ mà gần với tiếng Việt hôm nay — nó đứng đúng ở điểm cuối của cuộc chuyển đổi lớn nhất, và mọi thứ xảy ra sau đó, từ 1838 đến hôm nay — báo chí Quốc ngữ, phong trào duy tân, cuộc chuẩn hóa chính tả, kỷ nguyên bàn phím — đều là những điều chỉnh trên một nền tảng đã tương đối ổn định, chứ không còn là những đứt gãy ngữ âm sâu như giữa 1651 và 1773.

Điều này cho thấy một cách nhìn khác về "tuổi" của tiếng Việt viết. Nếu tính từ những ký hiệu đầu tiên của Pina năm 1617, chữ Quốc ngữ đã hơn bốn trăm tuổi. Nhưng nếu tính từ thời điểm nó đạt đến hình hài gần như hiện đại — tức khoảng cuối thế kỷ 18, đầu thế kỷ 19 — thì tiếng Việt viết mà ta dùng hôm nay chỉ mới già hơn hai trăm tuổi một chút, một khoảng thời gian không hề dài so với nhiều ngôn ngữ châu Âu có chữ viết đã ổn định từ nhiều thế kỷ trước đó. Điều đáng kinh ngạc không phải là tiếng Việt "ít thay đổi", mà là nó đã hoàn tất một cuộc cách mạng chữ viết — từ chữ Hán, qua chữ Nôm, đến một bảng chữ cái hoàn toàn xa lạ vay mượn từ châu Âu — trong một khoảng thời gian ngắn hơn nhiều so với những gì người ta thường hình dung, và đã làm điều đó đủ triệt để để một cuốn sách in năm 1838, gần hai trăm năm trước, vẫn đọc được trơn tru dưới mắt một người Việt Nam của thế kỷ 21, không cần một cuốn từ điển tra cứu nào đứng giữa.

Đó, có lẽ, là điều đáng nhớ nhất khi gấp lại cuốn Dictionarium Latino-Anamiticum: một cuốn sách được hai vị giám mục người Pháp soạn ra để phục vụ công việc truyền giáo tại một xứ sở xa lạ, cuối cùng lại trở thành tấm gương phản chiếu chính xác nhất khoảnh khắc tiếng Việt viết trở thành tiếng Việt mà ta vẫn nói, vẫn nghĩ, vẫn viết — bằng đúng những con chữ ấy — cho đến tận hôm nay.

Written by: Claude AI.

Curator/Editor: Học Trò.

Mọi trích dẫn đều phải ghi chú với dòng trên và nói rõ bài khảo luận được lấy từ trang https://hoctroviet.blogspot.com/

9.21.2026

Visual Studio Code: Hướng Dẫn Dễ Hiểu

Written by: Claude AI.

Curator/Editor: Học Trò.


Bài này giải thích Visual Studio Code (VS Code) bằng lời văn đơn giản nhất có thể, dành cho những người chưa quen với máy tính, mạng internet, viết chương trình (lập trình), hay trí tuệ nhân tạo (AI). Nếu bạn gặp một từ khó hiểu, hãy xem phần "Từ Điển Giải Thích" ở cuối bài — mọi từ kỹ thuật quan trọng đều được giải thích lại ở đó bằng ngôn ngữ đời thường.

1. Visual Studio Code Là Gì?

Hãy tưởng tượng bạn cần một cuốn sổ tay đặc biệt để viết văn bản — nhưng không phải văn bản bình thường, mà là những "câu lệnh" mà máy tính có thể hiểu và làm theo. Người viết những câu lệnh đó gọi là người viết chương trình (programmer, hay "coder"). Visual Studio Code, thường được gọi tắt là "VS Code," chính là cuốn sổ tay đặc biệt đó — một chương trình máy tính dùng để viết và sửa các câu lệnh cho máy tính khác đọc.

Cái tên chính thức của loại chương trình này là "trình soạn mã" hay "code editor" (bạn có thể hiểu nôm na như một phần mềm Microsoft Word, nhưng dùng để viết mã máy tính thay vì viết văn). VS Code do công ty Microsoft tạo ra, dùng được trên máy Windows, máy Mac (Apple), và máy chạy Linux. Nó cũng có một bản chạy thẳng trên trình duyệt web (browser — phần mềm bạn dùng để lên mạng, ví dụ Chrome hay Edge), không cần cài đặt gì cả.

Một điều dễ nhầm: VS Code không phải là "Visual Studio" — một sản phẩm khác, cũng của Microsoft, nhưng lớn hơn, nặng hơn, ra đời từ những năm 1990 và chủ yếu dành cho máy Windows. Hai sản phẩm này có tên gần giống nhau vì cùng một công ty làm ra, nhưng bên trong hoàn toàn khác nhau — khác nhóm phát triển, khác cách xây dựng, khác đối tượng sử dụng.

Microsoft giới thiệu VS Code lần đầu vào tháng 4 năm 2015, rồi công bố toàn bộ mã nguồn (source code — tức là "công thức" bên trong làm nên phần mềm) cho công khai vào tháng 11 năm 2015, theo một loại giấy phép cho phép ai cũng được xem, sao chép, hay xây dựng lại. Bản chính thức đầu tiên (gọi là "phiên bản 1.0") ra mắt vào tháng 4 năm 2016. Từ đó tới nay, gần như mỗi tháng Microsoft đều phát hành một bản cập nhật mới.

Điều đặc biệt của VS Code là: bản gốc của nó khá đơn giản và nhẹ, giống một cuốn sổ ghi chép tốt hơn là một bộ công cụ khổng lồ. Mọi khả năng "thông minh" khác — như tự động tìm lỗi cho một ngôn ngữ lập trình cụ thể, hay các công cụ chuyên sâu khác — đều được thêm vào sau, thông qua những "phần mở rộng" (extension) mà người dùng tự chọn cài thêm, giống như việc bạn thêm ứng dụng vào điện thoại. Chính vì cách thiết kế "nhẹ ở lõi, thêm gì tùy ý" này mà VS Code phù hợp với rất nhiều kiểu công việc khác nhau — từ người làm web, người phân tích dữ liệu, đến người viết chương trình cho các thiết bị điện tử nhỏ.

2. VS Code Được Xây Dựng Từ Cái Gì?

Phần này hơi kỹ thuật, nhưng ta sẽ đi từng bước chậm.

VS Code được xây trên một bộ khung công nghệ tên là Electron. Đây là bộ khung được nhiều phần mềm nổi tiếng khác dùng, ví dụ Slack hay Discord (hai ứng dụng nhắn tin/họp nhóm phổ biến). Electron làm được một việc thú vị: nó cho phép người ta xây một phần mềm để cài trên máy tính (desktop app), nhưng bên trong lại dùng đúng công nghệ làm ra các trang web (giống như trang web bạn xem trên Chrome). Nhờ vậy, VS Code vừa "trông và hoạt động" giống một trang web, vừa có thể đọc/ghi tệp (file) trên máy, mở các chương trình khác — những việc mà một trang web bình thường mở trong trình duyệt không tự làm được.

Bên trong, VS Code được chia thành nhiều "tiến trình" (process — tức là những phần chạy riêng biệt của phần mềm, giống như các phòng riêng trong một căn nhà): một phần lo việc mở/đóng cửa sổ chương trình, một phần lo hiển thị những gì bạn nhìn thấy và bấm vào, và — quan trọng nhất — mỗi "phần mở rộng" (extension) mà bạn cài thêm sẽ chạy trong một "phòng" riêng của chính nó, tách khỏi phần chính. Lý do thiết kế như vậy: nếu một phần mở rộng nào đó bị lỗi hay "đứng" (crash), nó sẽ không kéo sập luôn cả chương trình chính — giống như một bóng đèn trong nhà bị cháy không làm mất điện cả căn nhà.

Phần "lõi" thật sự làm công việc hiển thị chữ, tô màu cú pháp (syntax highlighting — tức là tô màu khác nhau cho từng loại từ trong câu lệnh để dễ đọc, giống như sách giáo khoa bôi màu từ khóa quan trọng), theo dõi con trỏ (cursor) và vùng bạn đang chọn, gọi là Monaco Editor. Đây là một dự án riêng, cũng công khai mã nguồn, và được nhiều sản phẩm khác "mượn" để có cảm giác soạn mã giống VS Code ngay trên trang web của họ — ví dụ trang GitHub.com cũng dùng Monaco cho phần xem/sửa mã trực tiếp trên web.

Ngôn ngữ lập trình mà chính VS Code được viết ra là TypeScript — một ngôn ngữ do Microsoft phát triển, dựa trên JavaScript (ngôn ngữ làm cho các trang web có thể "động," tương tác được, thay vì chỉ là chữ và hình tĩnh). Người thiết kế chính của TypeScript, ông Anders Hejlsberg, cũng là người từng góp phần thiết kế VS Code — nên hai dự án có quan hệ gần gũi, không phải tình cờ.

Về mặt bản quyền/giấy phép: "công thức" (mã nguồn) làm ra VS Code là mã nguồn mở, ai cũng xem và dùng lại được miễn phí. Nhưng bản chương trình cụ thể mà Microsoft phát hành với tên "Visual Studio Code" (có logo, có biểu tượng riêng, có gửi dữ liệu sử dụng về cho Microsoft, và có kết nối tới "cửa hàng" phần mở rộng chính thức của Microsoft) thì đi kèm một giấy phép riêng của Microsoft. Chính vì sự khác biệt này mà có một phiên bản khác tên là VSCodium — đây là cùng một "công thức" mã nguồn mở đó, nhưng được đóng gói lại, bỏ hết những phần riêng của Microsoft (logo, việc gửi dữ liệu sử dụng, v.v.), cho ai muốn dùng bản "sạch" hơn.

3. Những Việc Cơ Bản VS Code Làm Được Ngay Khi Vừa Cài

Ngay cả khi chưa cài thêm bất cứ phần mở rộng nào, VS Code vẫn làm được rất nhiều việc hữu ích:

  • Gợi ý tự động khi gõ chữ (IntelliSense) — giống như điện thoại gợi ý từ tiếp theo khi bạn đang nhắn tin, VS Code gợi ý câu lệnh, tên biến, hay giải thích ngắn ngay khi bạn đang gõ, dựa trên một bộ máy hiểu ngôn ngữ lập trình thật sự, không phải chỉ đoán theo chữ giống nhau.
  • Nhiều con trỏ cùng lúc — bạn có thể đặt nhiều "điểm gõ chữ" (cursor) ở nhiều nơi khác nhau trong văn bản để sửa cùng lúc, thay vì sửa từng chỗ một.
  • Bảng Lệnh (Command Palette) — bấm một tổ hợp phím là hiện ra một danh sách tìm-kiếm-được của MỌI thao tác mà chương trình (và mọi phần mở rộng đã cài) có thể làm. Đây gần như là "thực đơn" (menu) chính, và nhiều người dùng quen dùng nó thay cho việc bấm chuột vào từng nút.
  • Mở Nhanh (Quick Open) — gõ vài chữ để tìm và mở nhanh một tệp (file) trong cả một dự án lớn, không cần lục từng thư mục.
  • Cửa sổ dòng lệnh gắn sẵn (terminal) — một "khung gõ lệnh trực tiếp cho máy tính" nằm ngay trong cửa sổ VS Code, để bạn không phải mở một chương trình khác riêng khi cần chạy lệnh.
  • Thu gọn đoạn mã, bản đồ nhỏ (minimap), và xem trước (Peek) — các công cụ giúp bạn nhìn tổng quan một tệp dài, hoặc xem nhanh một đoạn khác mà không cần rời khỏi chỗ đang gõ.
  • So sánh và ghép hai bản khác nhau (diff/merge) — có sẵn công cụ để nhìn hai bản văn bản khác nhau cạnh nhau, và tự chọn giữ phần nào khi hai người cùng sửa một tệp mà bị "đụng" nhau (đây thường xảy ra khi dùng Git — xem phần giải thích Git ở mục 5).
  • Chế độ Tập Trung (Zen Mode) và Đồng Bộ Cài Đặt (Settings Sync) — một chế độ làm toàn màn hình không có gì gây phân tâm, và một cách để các thiết lập, phím tắt, và phần mở rộng bạn đã cài tự động "theo" bạn sang một máy tính khác, thông qua tài khoản Microsoft hoặc GitHub.
  • Mở nhiều thư mục dự án cùng lúc — ví dụ một thư mục cho "mặt trước" trang web và một thư mục khác cho "mặt sau" xử lý dữ liệu, xem chung như một dự án.

Ngoài ra còn có đoạn mã mẫu có sẵn (snippet) — những khối chữ soạn sẵn (ví dụ khung một đoạn lặp, hay một dòng ghi chú bản quyền chuẩn) mà bạn chỉ cần gõ vài chữ tắt là nó tự bung ra thành cả đoạn dài, kèm những chỗ trống để bạn điền vào. Và tính năng tìm-và-thay (find and replace) rất mạnh: có thể tìm theo mẫu phức tạp (regular expression — một cách viết "mẫu tìm kiếm thông minh"), và xem trước toàn bộ những chỗ sẽ bị thay đổi trước khi bấm "đồng ý," dù tệp có tới hàng ngàn cái.

4. VS Code Hỗ Trợ Được Bao Nhiêu Ngôn Ngữ Lập Trình?

Bản thân VS Code, ngay từ đầu, chỉ biết "tô màu" chữ cho rất nhiều ngôn ngữ lập trình khác nhau — giống như biết chữ nào là từ khóa để bôi màu, nhưng không thật sự "hiểu" ý nghĩa sâu. Khả năng "hiểu sâu" thật sự — như tự sửa lỗi, tìm nơi một từ được dùng ở đâu trong cả dự án, đổi tên một từ ở khắp mọi nơi một cách an toàn — đến từ một phần mềm riêng gọi là language server ("máy chủ ngôn ngữ" — bạn có thể hiểu như một "chuyên gia" riêng cho từng ngôn ngữ lập trình, chạy nền và trả lời câu hỏi cho VS Code). VS Code nói chuyện với các "chuyên gia" này qua một quy tắc chung tên là Language Server Protocol (LSP) — nghĩa là "giao thức máy chủ ngôn ngữ," một bộ quy tắc chuẩn cho việc hỏi-đáp đó.

Đây được xem là một trong những đóng góp lớn nhất của VS Code cho cả ngành làm phần mềm nói chung. Trước khi có LSP, mỗi chương trình soạn mã muốn "hiểu" một ngôn ngữ lập trình (ví dụ Python) đều phải tự viết lại toàn bộ phần "hiểu" đó từ đầu — rất tốn công, và bị lặp lại ở hàng chục chương trình khác nhau. Nhờ có LSP, người ta chỉ cần viết MỘT "chuyên gia" Python duy nhất, rồi bất kỳ chương trình soạn mã nào tuân theo quy tắc LSP đều dùng được "chuyên gia" đó — không chỉ VS Code, mà cả những chương trình soạn mã khác như Vim, Emacs, Sublime Text.

Có một quy tắc tương tự khác cho việc "gỡ lỗi" (debug — tức là dò từng bước xem chương trình đang chạy sai ở đâu), gọi là Debug Adapter Protocol (DAP). Nó tách phần "giao diện gỡ lỗi" (những gì bạn nhìn thấy: điểm dừng, danh sách biến số...) ra khỏi phần "biết cách điều khiển" một loại chương trình cụ thể đang chạy, để một "bộ điều khiển gỡ lỗi" viết một lần có thể dùng lại ở nhiều nơi.

Nhờ hai quy tắc chung này, VS Code hỗ trợ tốt gần như mọi ngôn ngữ lập trình được dùng rộng rãi hiện nay: JavaScript, TypeScript, Python, C/C++, C#, Java, Go, Rust, PHP, Ruby, Swift, Kotlin, Dart/Flutter, các loại ngôn ngữ truy vấn cơ sở dữ liệu (SQL), và các định dạng khai báo/cấu hình như HTML, CSS, JSON, YAML, Markdown. VS Code cũng hỗ trợ tốt cho công việc "hạ tầng" và dữ liệu: Docker (đóng gói phần mềm để chạy giống nhau ở mọi máy), Kubernetes (quản lý nhiều "gói phần mềm đóng hộp" đó cùng lúc), Terraform (dựng hạ tầng máy chủ bằng câu lệnh), sổ tay Jupyter (một dạng tệp cho phép chạy từng đoạn mã và xem kết quả ngay, hay dùng trong phân tích dữ liệu), và viết lệnh cho dòng lệnh (shell script).

5. Gỡ Lỗi, Tác Vụ, Và Quản Lý Phiên Bản (Git)

Gỡ lỗi (debugging) trong VS Code dùng chung một giao diện cho mọi loại chương trình, nhờ DAP đã nói ở trên: bạn đặt "điểm dừng" (breakpoint — chỗ chương trình sẽ tự dừng lại để bạn xem), rồi chạy từng bước, xem giá trị các biến số lúc đó là gì — dù chương trình đó viết bằng Node.js, Python, hay ngôn ngữ khác, cách dùng vẫn giống nhau. Những thiết lập cho việc gỡ lỗi được lưu trong một tệp riêng, thường được lưu chung với dự án để cả nhóm cùng dùng một cách gỡ lỗi giống nhau.

Tác vụ (Tasks) là cách VS Code cho phép gán một lệnh dài dòng (ví dụ "biên dịch chương trình," "chạy hết các bài kiểm thử") vào MỘT phím tắt duy nhất, để không phải nhớ và gõ lại lệnh đó mỗi lần.

Git được tích hợp sẵn, không phải phần mở rộng. Git là một hệ thống rất phổ biến để "lưu vết" mọi thay đổi của một dự án theo thời gian — giống như "Lịch sử phiên bản" trong Google Docs, nhưng mạnh hơn nhiều, và cho phép nhiều người cùng sửa một dự án mà không đè mất công của nhau. VS Code có sẵn một khung nhìn ("Source Control panel") cho thấy những tệp nào vừa bị đổi, và cho phép bạn "ghi lại" (commit) thay đổi, tạo một "nhánh" (branch — một bản sao riêng để thử nghiệm mà không ảnh hưởng bản chính), gửi/nhận thay đổi với người khác — tất cả không cần rời khỏi VS Code. Có thêm các phần mở rộng như GitLens để xem sâu hơn lịch sử ai đã sửa dòng nào, khi nào; và phần mở rộng chính thức của GitHub để xem và duyệt các "yêu cầu ghép thay đổi" (pull request) ngay trong VS Code.

6. "Cửa Hàng" Phần Mở Rộng Và Cả Một Hệ Sinh Thái Lớn

Chính cơ chế "phần mở rộng" (extension) là thứ biến một chương trình soạn mã gọn nhẹ thành bất cứ loại công cụ chuyên biệt nào mà một người dùng cần. Các phần mở rộng được đăng lên một "cửa hàng" chung gọi là Visual Studio Marketplace, và có thể thêm khả năng hiểu một ngôn ngữ lập trình mới, đổi giao diện màu sắc (theme), thêm bộ gỡ lỗi, hay — như phần 10 dưới đây sẽ nói kỹ — thêm khả năng trợ giúp bằng trí tuệ nhân tạo (AI). "Cửa hàng" này đã lớn tới mức có tới hàng chục ngàn phần mở rộng khác nhau, từ những cái rất nhỏ (tô màu cho một loại tệp cấu hình) tới những bộ công cụ lớn (xem/sửa cả một cơ sở dữ liệu).

Chính khả năng "thêm gì cũng được" này là lý do lớn nhất khiến VS Code luôn đứng đầu trong các cuộc khảo sát người viết chương trình. Trong khảo sát năm 2025 của trang Stack Overflow (một trang hỏi đáp lớn cho người viết chương trình, khảo sát hơn 49.000 người ở 177 quốc gia), VS Code dẫn đầu mọi chương trình soạn mã với 75,9% người dùng — gấp hơn 2,6 lần so với chính "Visual Studio" đầy đủ của Microsoft (29%), và vượt xa Notepad++ (27,4%), IntelliJ IDEA (27,1%), và Vim (24,3%). Ngay cả những chương trình soạn mã mới, được xây riêng để "AI làm trọng tâm" từ đầu, cũng chưa vượt qua được: Cursor đạt 17,9%, Claude Code đạt 9,7%, và Windsurf đạt 4,9% — đều là những đối thủ thật sự và đang phát triển nhanh, nhưng vẫn còn cách rất xa so với VS Code. Microsoft cũng cho biết VS Code đã vượt mốc 36 triệu người dùng hàng tháng vào năm 2024, tăng 20% so với 30 triệu của năm trước.

7. Làm Việc Từ Xa, Dùng "Hộp Chứa" (Container), Và Chạy Ngay Trên Web

Một khả năng khá đặc biệt của VS Code: cửa sổ chương trình bạn nhìn thấy và các tệp thật bạn đang sửa không nhất thiết phải nằm trên cùng một máy. Một bộ phần mở rộng gọi là Remote Development cho phép:

  • Remote - SSH: kết nối tới một máy tính khác ở xa (qua mạng) và sửa/gỡ lỗi ngay trên máy đó, như thể các tệp đang nằm trên máy của chính bạn.
  • Dev Containers: chạy toàn bộ môi trường làm việc bên trong một "hộp chứa" (container — một gói phần mềm đóng sẵn, đảm bảo giống nhau tuyệt đối trên mọi máy chạy nó, tránh tình trạng "trên máy tôi nó chạy được mà"). Ai mở dự án này trên máy nào cũng có đúng một môi trường giống nhau.
  • WSL: cho người dùng Windows chạy các công cụ dành riêng cho Linux mà vẫn cảm giác liền mạch như đang dùng Windows bình thường.
  • GitHub Codespaces: đưa ý tưởng "hộp chứa" đó lên hẳn "mây" (cloud — tức là máy chủ ở đâu đó trên internet, không phải máy tính của bạn). Chỉ cần mở một dự án trên GitHub, bạn có ngay một môi trường làm việc đầy đủ, chạy sẵn, không cần cài đặt gì trên máy mình cả — mở qua trình duyệt hoặc qua chính chương trình VS Code cài trên máy, kết nối tới máy chủ đó.

Cho những nhu cầu nhẹ hơn, VS Code còn có bản chạy thẳng trên trình duyệt web, không cần cài gì: vscode.dev cho một bản VS Code đầy đủ ngay trên web, và github.dev — chỉ cần bấm phím chấm "." trên bất kỳ trang dự án GitHub nào — đưa bạn ngay vào một giao diện soạn mã đầy đủ cho dự án đó trong vài giây.

8. Sổ Tay Jupyter, Kiểm Thử, Hỗ Trợ Người Khuyết Tật, Và Tùy Chỉnh

VS Code hiển thị được trực tiếp các "sổ tay Jupyter" (.ipynb) — một dạng tệp phổ biến trong phân tích dữ liệu, cho phép chạy từng đoạn nhỏ và xem ngay kết quả (bảng số liệu, biểu đồ, hình ảnh) — mà vẫn giữ được các khả năng gợi ý/gỡ lỗi thông thường của VS Code.

Một khung nhìn chung gọi là Test Explorer (bộ khám phá bài kiểm thử) tự tìm ra các "bài kiểm thử" (test — những đoạn mã nhỏ tự động kiểm tra chương trình chính có chạy đúng không) từ nhiều bộ công cụ khác nhau, và cho bạn chạy/xem kết quả đậu-rớt ngay trong một khung, dù dự án dùng ngôn ngữ nào.

Về hỗ trợ người khuyết tật: VS Code được đầu tư nghiêm túc — hỗ trợ đầy đủ cho phần mềm đọc màn hình (screen reader, giúp người khiếm thị nghe được nội dung), cỡ chữ có thể chỉnh riêng cho từng phần, giao diện tương phản cao (dễ nhìn hơn cho người có vấn đề về mắt), và có thể dùng toàn bộ chương trình chỉ bằng bàn phím, không cần chuột.

Việc tùy chỉnh cũng rất sâu: hầu như mọi phím tắt đều đổi được, mọi thiết lập nằm trong một tệp mà bạn có thể tự sửa, Profiles (hồ sơ) cho phép lưu và chuyển đổi qua lại giữa nhiều "bộ thiết lập" khác nhau (ví dụ một bộ cho công việc phân tích dữ liệu bằng Python, một bộ khác cho công việc viết máy chủ bằng Node) trên cùng một máy, và có tới hàng ngàn kiểu giao diện màu/biểu tượng khác nhau để đổi diện mạo mà không ảnh hưởng gì đến cách hoạt động.

Để nói rõ hơn tại sao LSP và DAP quan trọng: trước đây, một công ty làm ra một ngôn ngữ lập trình mới (ví dụ Rust) muốn được nhiều chương trình soạn mã "hiểu" phải chọn một trong hai: tự viết riêng cho từng chương trình soạn mã khác nhau (tốn công khổng lồ, luôn bị lạc hậu), hoặc chấp nhận rằng đa số chương trình soạn mã chỉ tô màu chữ hời hợt cho ngôn ngữ đó. Sau khi có LSP, công ty đó chỉ cần viết MỘT "chuyên gia hiểu Rust" (gọi là rust-analyzer) một lần duy nhất, và bất kỳ chương trình soạn mã nào theo đúng chuẩn LSP đều dùng được ngay, miễn phí về công sức viết lại.

9. Các "Bản Sao/Phát Triển Thêm" Của VS Code Và Vị Trí Của Nó Trên Thị Trường

Vì lõi (core) là mã nguồn mở, nhiều sản phẩm khác dùng VS Code làm nền tảng để xây tiếp, thay vì chỉ dùng nó như một sản phẩm đã xong. VSCodium dựng lại đúng mã nguồn đó nhưng bỏ hết phần riêng của Microsoft. Eclipse Theia là một dự án khác, không liên quan trực tiếp nhưng dùng cùng những "quy tắc chung" (LSP, DAP) để xây một bộ khung IDE (chương trình soạn mã đầy đủ) chạy được cả trên máy và trên "mây," được dùng trong các sản phẩm như Cloud Shell Editor của Google hay Gitpod.

Đáng chú ý hơn: một số chương trình soạn mã "lấy AI làm trọng tâm" đang phát triển rất nhanh — CursorWindsurf là hai ví dụ nổi bật — thật ra chính là những "bản dựng lại" từ mã nguồn mở của VS Code, giữ nguyên phần soạn mã và khả năng dùng lại các phần mở rộng, chỉ thay hoặc thêm đậm phần AI. Đó là lý do một người từng dùng VS Code có thể ngồi vào Cursor hay Windsurf và cảm thấy quen thuộc ngay — bên dưới lớp "áo AI" đó, phần lớn vẫn là cùng một chương trình soạn mã.

10. GitHub Copilot — Trợ Lý AI Được Gắn Chặt Vào VS Code

Không thể nói đầy đủ về VS Code ngày nay mà không nói kỹ về GitHub Copilot, vì với rất nhiều người dùng hiện giờ, hai thứ này gần như không còn được xem là hai sản phẩm tách biệt. Copilot là lớp trợ lý AI đã biến VS Code từ "một chương trình soạn mã rất tốt, rất nhẹ, thêm gì cũng được" thành "nơi mà rất nhiều người viết chương trình bây giờ mặc định có một trợ lý AI ngồi cạnh (và ngày càng nằm ngay bên trong) từng lần gõ chữ." Copilot được phát hành dưới dạng phần mở rộng chính thức của Microsoft/GitHub (thật ra là một cặp phần mở rộng: một cho phần gợi ý viết sẵn, một cho phần trò chuyện và "tự làm việc"), không phải phần bắt buộc có sẵn trong lõi mã nguồn mở của VS Code — nhờ đó bản lõi VS Code vẫn miễn phí và mở, còn lớp AI nằm riêng, phần lớn là trả tiền.

Gợi ý viết sẵn ngay trong dòng chữ (giống "chữ bóng mờ"). Đây là tính năng gốc và nền tảng nhất của Copilot: khi bạn đang gõ, một dòng chữ màu xám mờ hiện ra ngay phía trước con trỏ, đề xuất phần còn lại của dòng đó, hoặc cả vài dòng tiếp theo, dựa trên những gì xung quanh bạn đang viết. Chỉ cần bấm phím Tab là "nhận" gợi ý đó ngay. Một tính năng liên quan, gọi là gợi ý sửa tiếp theo (next-edit suggestions), còn đi xa hơn: nó để ý bạn vừa sửa một chỗ trong tệp, và tự đề xuất luôn CHỖ TIẾP THEO cần sửa cho khớp — ví dụ sau khi bạn đổi tên một tham số trong hàm, nó gợi ý cập nhật luôn những nơi khác đang gọi hàm đó. Theo trang giá dịch vụ chính thức của GitHub năm 2026, hai tính năng gợi ý cơ bản này vẫn miễn phí và gần như không giới hạn ở mọi gói dịch vụ, kể cả gói miễn phí (dù gói miễn phí có giới hạn số lượt dùng mỗi tháng thấp hơn) — khác với các tính năng "trò chuyện" và "tự làm việc" nặng hơn, phải trừ vào một khoản "tín dụng" (credit) được tính theo mức sử dụng.

Trò chuyện với Copilot (Copilot Chat). Có một khung trò chuyện riêng nằm cạnh khung soạn mã (và từ năm 2026, có thể mở thêm một khung trò chuyện phụ để chạy song song nhiều cuộc trò chuyện khác nhau), để bạn hỏi bằng câu văn bình thường về đoạn mã đang mở, xin giải thích một hàm khó hiểu, xin sửa một lỗi cụ thể, hoặc xin viết hẳn một đoạn mã mới. Khung trò chuyện này hiểu được các "đối tượng tham gia" và lệnh tắt để giới hạn phạm vi câu hỏi — chẳng hạn hỏi riêng về cả dự án, về một phần mở rộng cụ thể, hay về câu lệnh dòng lệnh — và bạn có thể chỉ rõ cho nó xem một tệp, một đoạn được chọn, hay cả một thư mục, để câu trả lời sát với đúng dự án của bạn, không chỉ là kiến thức chung nó đã học trước đó.

Chế độ "tự làm việc" (Agent mode). Đây là tính năng thay đổi cách người ta dùng Copilot nhiều nhất trong thực tế, và là một bước xa hơn hẳn so với chỉ gợi ý chữ. Ở chế độ này, bạn chỉ cần mô tả một công việc bằng lời thường — ví dụ "thêm tính năng này," "sửa bài kiểm thử đang bị lỗi," "viết lại module này cho gọn hơn" — và Copilot sẽ TỰ lập ra các bước cần làm, tự sửa nhiều tệp khác nhau trong cả dự án nếu cần, tự chạy lệnh dòng lệnh (cài thêm thư viện, chạy thử, chạy kiểm thử), tự đọc kết quả những lệnh đó, và nếu có gì sai, nó tự sửa lại và thử tiếp — cứ như vậy cho tới khi xong việc hoặc cần bạn quyết định giúp, mà không cần bạn chỉ tay từng bước nhỏ. Từ các bản phát hành năm 2026, "trợ lý tự làm việc" này còn có thể chạy lâu hơn cho những việc phức tạp hơn, và bạn có thể nói chuyện, ngắt lời, hay đổi hướng nó ngay giữa lúc nó đang làm, thay vì chỉ được xem kết quả sau khi nó xong; bạn cũng có thể đặt nó chạy lại theo giờ/ngày/tuần một cách tự động, hoặc bật lên khi cần.

Tùy chọn nhiều "bộ não" AI khác nhau, và khả năng dùng chung. Ở các gói trả tiền, Copilot Chat không bị buộc chỉ dùng một loại AI duy nhất — người dùng có thể chọn giữa nhiều "bộ não" AI khác nhau (từ các công ty khác nhau, bao gồm cả các mô hình Claude của Anthropic), ngay trong một danh sách chọn ở khung trò chuyện. VS Code còn cho phép dùng lại các tệp thiết lập của Claude ngay trong VS Code, và có thể chuyển đổi giữa gói Anthropic riêng và gói Copilot ngay trong một cuộc trò chuyện với Claude, hoặc xem lại một cuộc "làm việc cùng AI" đã bắt đầu ở một chương trình khác từ một danh sách chung trong VS Code. Nói cách khác, ranh giới giữa "đang dùng Copilot" và "đang dùng Claude" bên trong VS Code đã trở nên mềm hơn rất nhiều so với tên sản phẩm gợi ý — chương trình ngày càng coi các trợ lý AI khác nhau như những "bộ máy" có thể thay thế cho nhau, đứng sau cùng một giao diện trò chuyện và "tự làm việc" chung.

Kết nối với công cụ bên ngoài (MCP). Từ giữa năm 2026, chế độ "tự làm việc" của Copilot trong VS Code hỗ trợ Model Context Protocol (MCP) — một quy tắc chung (do Anthropic khởi xướng, sau được nhiều nơi khác trong ngành áp dụng) để kết nối một trợ lý AI với các công cụ, cơ sở dữ liệu, và dịch vụ bên ngoài, theo một cách có tổ chức và dùng lại được. Nói thực tế, điều này cho phép một "trợ lý AI" trong VS Code làm được nhiều hơn là chỉ sửa tệp trong dự án đang mở — như tra một cơ sở dữ liệu đang chạy thật, gọi một dịch vụ nội bộ của công ty, kiểm tra hệ thống theo dõi công việc, hay điều khiển một trình duyệt web — bằng cách kết nối tới bất kỳ "máy chủ MCP" nào một nhóm đã thiết lập sẵn, dùng đúng quy tắc chung mà các chương trình AI khác (kể cả Claude Desktop và Claude Code) cũng nói theo.

Duyệt mã và yêu cầu ghép thay đổi. Copilot còn giúp cả việc hợp tác nhóm: nó có thể tự "duyệt" một yêu cầu ghép thay đổi (pull request — một cách đề xuất "xin ghép phần tôi vừa sửa vào bản chính"), để lại nhận xét ngay trên từng dòng giống một người duyệt thật, và làm việc chung với phần mở rộng chính thức của GitHub để cả việc duyệt, thảo luận, và sửa theo gợi ý của Copilot đều xảy ra mà không cần rời khỏi VS Code.

Giá cả và các gói dịch vụ. Từ ngày 1 tháng 6 năm 2026, GitHub đổi toàn bộ cách tính tiền Copilot sang hình thức "tính theo lượng dùng thật," qua một loại "tín dụng" gọi là GitHub AI Credits (1 tín dụng = 0,01 đô la Mỹ), tính theo lượng AI thật sự dùng, và mỗi gói trả tiền đi kèm một khoản tín dụng hàng tháng tương đương giá gói đó. Theo trang giá năm 2026: các gói cho cá nhân gồm Free (miễn phí), Pro (10 đô/tháng, kèm 15 đô tín dụng), Pro+ (39 đô/tháng, kèm 70 đô tín dụng), và Max (100 đô/tháng, kèm 200 đô tín dụng); các gói cho tổ chức gồm Business (19 đô/người dùng/tháng) và Enterprise (39 đô/người dùng/tháng). Trong cách tính mới này, hai tính năng gợi ý cơ bản (gợi ý viết sẵn và gợi ý sửa tiếp theo) vẫn miễn phí và gần như không giới hạn ở mọi gói kể cả gói miễn phí, còn các tính năng nặng hơn — trò chuyện, "tự làm việc," và duyệt mã — mới trừ vào khoản tín dụng đó.

Nói chung, "GitHub Copilot trong VS Code" vào năm 2026 không còn chỉ là "gợi ý viết chữ có trả tiền" nữa — mà đã trở thành một lớp trợ lý biết dùng nhiều "bộ não" AI khác nhau, biết dùng công cụ bên ngoài, và ngày càng tự chủ hơn, được gắn thẳng vào hệ thống tệp, dòng lệnh, bộ gỡ lỗi, và Git của chính chương trình — mà một người dùng có thể "ra lệnh" ở bất kỳ mức độ nào, từ một dòng chữ nhỏ, đến cả một tính năng lớn, đến cả một công việc bảo trì lặp lại định kỳ.

Cũng cần nói rõ bối cảnh cạnh tranh mà VS Code đang đứng trong đó, không phải VS Code không có đối thủ. Ở phía "truyền thống," các chương trình của công ty JetBrains (như IntelliJ IDEA, PyCharm, WebStorm) vẫn được nhiều người ưa chuộng vì có công cụ chuyên sâu, được thiết kế sẵn riêng cho từng ngôn ngữ ngay từ đầu, thay vì phải tự lắp ráp từ các phần mở rộng — khảo sát Stack Overflow 2025 cho thấy IntelliJ IDEA vẫn có tới 27,1% người dùng, một nền tảng người dùng thật sự chứ không nhỏ. Sublime Text và Vim/Neovim vẫn giữ được lượng người dùng trung thành, những người ưu tiên tốc độ khởi động và cách gõ lệnh bằng bàn phím hơn là các tính năng kiểu IDE đầy đủ. Ở phía "mới," các chương trình "lấy AI làm trọng tâm" như Cursor, Windsurf cạnh tranh không phải bằng cách soạn mã (phần này họ hầu như "mượn" từ VS Code) mà bằng việc gắn AI vào công việc hàng ngày mạnh và mặc định hơn. Đáp lại, VS Code, qua các bản phát hành năm 2026, chọn cách "hấp thụ" luôn những phần hấp dẫn nhất của các đối thủ đó vào chính sản phẩm gốc và phần mở rộng Copilot chính thức của mình, thay vì nhường lại thị phần đó.

11. Kết Luận

Visual Studio Code thành công nhờ một "cú đặt cược" khá bất thường vào thời điểm nó ra đời: giữ phần lõi nhỏ, nhanh, và miễn phí; để hầu như mọi thứ khác đều có thể "lắp thêm" tùy ý; và công khai đủ nhiều mã nguồn để cả một cộng đồng lớn — người làm ngôn ngữ lập trình, người làm công cụ, và sau này cả những sản phẩm "dựng lại từ nó" — có lý do để xây dựng THÊM VÀO nó, thay vì xây một thứ khác cạnh nó. Sau một thập niên, cú đặt cược đó rõ ràng đã thành công, chỉ nhìn vào số liệu người dùng cũng đủ thấy. Sự xuất hiện của AI được gắn sâu vào chương trình, dẫn đầu bởi GitHub Copilot nhưng không chỉ giới hạn ở đó, là thay đổi lớn nhất kể từ lúc VS Code ra mắt năm 2015 — không phải vì nó thay thế những gì VS Code đã làm tốt từ trước, mà vì nó được xây THÊM VÀO đúng cái kiến trúc "thêm gì cũng được" đã làm nên toàn bộ sự phát triển của VS Code từ trước tới giờ.


Từ Điển Giải Thích (Glossary)

Danh sách này giải thích lại, bằng lời đơn giản, mọi từ kỹ thuật xuất hiện trong bài — xếp theo thứ tự xuất hiện.

  • Trình soạn mã (code editor) — một chương trình máy tính chuyên dùng để viết và sửa các "câu lệnh" cho máy tính khác đọc, giống Microsoft Word nhưng dành cho viết mã thay vì viết văn.
  • Người viết chương trình / lập trình viên (programmer, coder, developer) — người viết những câu lệnh đó để tạo ra phần mềm.
  • Mã nguồn (source code) — toàn bộ "công thức" chữ viết bên trong làm nên một phần mềm.
  • Mã nguồn mở (open source) — khi công thức đó được công khai cho ai cũng xem, sao chép, hay sửa lại được, thường kèm những điều kiện nhất định (giấy phép).
  • Giấy phép (license) — bộ quy định pháp lý cho biết ai được dùng một sản phẩm ra sao, có phải trả tiền không, có được sửa/phân phối lại không.
  • Extension (phần mở rộng) — một "gói thêm" nhỏ mà người dùng tự cài vào chương trình chính để thêm khả năng mới, giống việc thêm ứng dụng vào điện thoại.
  • Electron — một bộ khung công nghệ cho phép xây một chương trình cài trên máy tính nhưng dùng công nghệ làm trang web bên trong.
  • Trình duyệt (browser) — phần mềm dùng để xem các trang web, ví dụ Chrome, Edge, Safari.
  • Chromium — công nghệ nền cho nhiều trình duyệt (kể cả Chrome), dùng để hiển thị nội dung giống trang web.
  • Node.js — một công nghệ cho phép chạy ngôn ngữ JavaScript ở bên ngoài trình duyệt, ví dụ ngay trên máy tính hoặc trên một máy chủ.
  • Tiến trình (process) — một phần chạy tách biệt của một chương trình, giống một "phòng riêng" trong một căn nhà lớn; nếu một phòng có sự cố, các phòng khác không bị ảnh hưởng ngay.
  • Extension host (nơi chạy phần mở rộng) — "phòng riêng" mà mỗi phần mở rộng chạy trong đó, tách khỏi phần chính của chương trình.
  • Monaco Editor — phần "lõi" thật sự vẽ ra chữ, tô màu, và theo dõi con trỏ khi bạn gõ trong VS Code; cũng được nhiều sản phẩm khác dùng lại.
  • Tô màu cú pháp (syntax highlighting) — việc tô màu khác nhau cho từng loại từ trong một câu lệnh, để dễ đọc hơn, giống việc sách giáo khoa bôi màu từ khóa quan trọng.
  • Con trỏ (cursor) — điểm nhấp nháy cho biết bạn đang gõ chữ ở đâu.
  • TypeScript — một ngôn ngữ lập trình do Microsoft tạo ra, dựa trên JavaScript, có thêm khả năng kiểm tra "loại dữ liệu" chặt chẽ hơn để tránh lỗi.
  • JavaScript — ngôn ngữ lập trình làm cho các trang web có thể "động" và tương tác được, thay vì chỉ hiện chữ và hình cố định.
  • VSCodium — một bản dựng lại từ đúng mã nguồn mở của VS Code, nhưng bỏ hết những phần riêng của Microsoft (logo, gửi dữ liệu sử dụng, v.v.).
  • IntelliSense — tính năng gợi ý tự động khi gõ chữ, giống điện thoại gợi ý từ tiếp theo khi nhắn tin, nhưng hiểu sâu về ngôn ngữ lập trình.
  • Command Palette (Bảng Lệnh) — một danh sách tìm-kiếm-được của mọi thao tác chương trình có thể làm, giống một "thực đơn" tổng.
  • Terminal (dòng lệnh / cửa sổ lệnh) — một khung để gõ lệnh trực tiếp cho máy tính làm theo, không qua giao diện có nút bấm.
  • Diff / merge (so sánh / ghép) — công cụ so sánh hai bản văn bản khác nhau, và ghép chúng lại khi hai người cùng sửa một chỗ mà bị "đụng" nhau.
  • Snippet (đoạn mã mẫu) — một khối chữ soạn sẵn, bung ra đầy đủ chỉ bằng vài chữ gõ tắt.
  • Regular expression — một cách viết "mẫu tìm kiếm thông minh" để tìm những đoạn chữ theo một khuôn dạng nhất định, không chỉ tìm đúng nguyên văn.
  • Language server (máy chủ ngôn ngữ) — một phần mềm riêng, chạy nền, đóng vai trò "chuyên gia" hiểu sâu một ngôn ngữ lập trình cụ thể, trả lời câu hỏi cho trình soạn mã.
  • Language Server Protocol — LSP (giao thức máy chủ ngôn ngữ) — bộ quy tắc chung để trình soạn mã và "chuyên gia ngôn ngữ" đó nói chuyện được với nhau, dùng chung được ở nhiều chương trình khác nhau.
  • Debug Adapter Protocol — DAP (giao thức bộ điều khiển gỡ lỗi) — bộ quy tắc chung tương tự LSP, nhưng cho việc gỡ lỗi (dò từng bước xem chương trình sai ở đâu).
  • Gỡ lỗi (debugging) — quá trình dò tìm và sửa lỗi trong một chương trình đang chạy, thường bằng cách chạy từng bước nhỏ.
  • Điểm dừng (breakpoint) — một chỗ được đánh dấu để chương trình tự dừng lại khi chạy tới đó, cho người xem kiểm tra tình trạng lúc đó.
  • Docker / container (hộp chứa) — một cách đóng gói một phần mềm cùng mọi thứ nó cần để chạy, đảm bảo nó chạy giống nhau trên mọi máy.
  • Kubernetes — một hệ thống để quản lý và vận hành nhiều "hộp chứa" (container) cùng lúc.
  • Terraform — một công cụ để "dựng" hạ tầng máy chủ (ví dụ tạo máy chủ mới trên mây) bằng cách viết ra các câu lệnh mô tả, thay vì bấm tay từng bước.
  • Jupyter notebook (sổ tay Jupyter) — một dạng tệp phổ biến trong phân tích dữ liệu, cho phép chạy từng đoạn nhỏ của mã và xem kết quả (bảng, biểu đồ) ngay lập tức.
  • Git — một hệ thống lưu vết mọi thay đổi của một dự án theo thời gian, cho phép nhiều người cùng sửa mà không mất công của nhau, và có thể "quay lại" một bản cũ khi cần.
  • Commit (ghi lại) — hành động "lưu" một nhóm thay đổi cụ thể vào lịch sử của dự án trong Git.
  • Branch (nhánh) — một bản sao riêng của dự án để thử nghiệm, không ảnh hưởng tới bản chính cho tới khi được ghép lại.
  • Pull request (yêu cầu ghép thay đổi) — một đề xuất chính thức "xin ghép phần tôi vừa sửa vào bản chính," thường được người khác xem và nhận xét trước khi đồng ý.
  • Marketplace (cửa hàng phần mở rộng) — trang web nơi các phần mở rộng được đăng lên để người dùng tìm và cài vào chương trình của họ.
  • Remote (làm việc từ xa) — khả năng làm việc với các tệp và môi trường nằm trên một máy khác, không phải máy đang ngồi trước mặt.
  • SSH — một cách kết nối an toàn tới một máy tính khác qua mạng, để điều khiển hoặc sửa tệp trên máy đó từ xa.
  • WSL (Windows Subsystem for Linux) — một tính năng của Windows cho phép chạy các công cụ dành riêng cho hệ điều hành Linux ngay trên máy Windows.
  • Cloud (mây / điện toán mây) — máy chủ hay dịch vụ nằm ở đâu đó trên internet, không phải trên máy tính của chính bạn, mà bạn truy cập qua mạng.
  • Test / kiểm thử — một đoạn mã nhỏ, tự động, dùng để kiểm tra xem chương trình chính có chạy đúng như mong đợi không.
  • Screen reader (phần mềm đọc màn hình) — phần mềm hỗ trợ người khiếm thị, đọc thành tiếng nội dung hiện trên màn hình.
  • Profile (hồ sơ thiết lập) — một "bộ" các thiết lập, phím tắt, và phần mở rộng đã lưu sẵn, để chuyển đổi nhanh giữa các cách làm việc khác nhau trên cùng một máy.
  • Fork (bản dựng lại / tách nhánh sản phẩm) — khi ai đó lấy nguyên mã nguồn của một sản phẩm để xây tiếp thành một sản phẩm riêng, khác của mình.
  • Trí tuệ nhân tạo — AI (Artificial Intelligence) — công nghệ máy tính được huấn luyện để làm những việc trước đây cần con người "hiểu" và "suy nghĩ," như trả lời câu hỏi hay viết mã.
  • GitHub Copilot — trợ lý AI của Microsoft/GitHub, được gắn vào VS Code (và các chương trình khác) để gợi ý và tự viết mã giúp người dùng.
  • Ghost text (chữ bóng mờ) — chữ gợi ý màu xám mờ hiện ra khi đang gõ, biến mất nếu không bấm nhận.
  • Agent mode (chế độ "tự làm việc") — một cách dùng AI trong đó bạn chỉ mô tả công việc cần làm, còn AI tự lập kế hoạch, tự sửa nhiều tệp, tự chạy lệnh, và tự sửa lại nếu có lỗi, ít cần con người chỉ tay từng bước.
  • Model Context Protocol — MCP — một quy tắc chung để một trợ lý AI kết nối với các công cụ, cơ sở dữ liệu, hay dịch vụ bên ngoài một cách có tổ chức.
  • Credit (tín dụng) — một đơn vị được dùng để tính "lượng AI đã dùng," giống như tiền ảo được trừ dần khi bạn dùng dịch vụ AI nặng.
  • IDE (Integrated Development Environment — môi trường phát triển tích hợp) — một chương trình soạn mã đầy đủ tính năng, thường đã có sẵn nhiều công cụ chuyên sâu ngay từ đầu, không cần cài thêm nhiều phần mở rộng.

Nguồn Tham Khảo


Written by: Claude AI.

Curator/Editor: Học Trò.

Mọi trích dẫn đều phải ghi chú với dòng trên và nói rõ bài khảo luận được lấy từ trang https://hoctroviet.blogspot.com/

Visual Studio Code: A Complete Guide

Written by: Claude Sonnet AI.

Curator/Editor: Học Trò.


Visual Studio Code is a free, open-source-core code editor built by Microsoft that has, in about a decade, gone from a surprise announcement at Build 2015 to the tool the largest share of professional developers reach for every day. This guide covers what it is, how it is built, what it can do out of the box, how far its language support really reaches, how its extension ecosystem works, and — in real depth, since the two are now almost inseparable in practice — how GitHub Copilot is woven into it.

1. What Visual Studio Code Is

Visual Studio Code (commonly shortened to "VS Code" or just "Code") is a source-code editor developed by Microsoft for Windows, macOS, and Linux, with a browser-based version available at vscode.dev and github.dev. It is not the same product as Visual Studio, Microsoft's much older, heavier, Windows-first full IDE — the naming is a frequent point of confusion, but VS Code was built from scratch as a lightweight, cross-platform, extensible text editor rather than a slimmed-down Visual Studio.

Microsoft first showed VS Code publicly at the Build developer conference in April 2015 as a preview, released it broadly (still in preview) a few months later, and made it fully open source under the MIT license in November 2015, with the source hosted on GitHub. Version 1.0 shipped in April 2016. Since then it has followed a monthly release cadence — a new numbered version (1.10x) ships essentially every month, each with its own detailed public release notes on code.visualstudio.com.

By design, VS Code out of the box is closer to a very capable text editor than a full IDE: it starts fast, opens folders instead of requiring formal "projects," and keeps its core small. Everything that makes it feel IDE-like — debugging a specific language, linting, refactoring tools, database browsers, deployment tooling — is added through extensions rather than baked into the core. That architectural choice is the single biggest reason VS Code can credibly serve web developers, Python data scientists, C++ embedded engineers, and DevOps engineers writing YAML all with the same editor.

2. Architecture: What It's Actually Built From

VS Code is built on Electron, the same framework used by Slack, Discord, and many other cross-platform desktop apps. Electron bundles a Chromium rendering engine together with a Node.js runtime, which is why VS Code looks and behaves like a web application (because, under the hood, much of it is one) while still being able to read and write files on disk, spawn processes, and talk to a real filesystem the way a web page in a browser tab cannot.

The application itself follows a multi-process model inherited from Chromium's own architecture: a main process handles application lifecycle and window management, a renderer process handles the UI you actually see and interact with, and — critically for stability — extensions run in their own separate "extension host" process rather than inside the UI process. This means a badly behaved or crashing extension does not, in the normal case, take the whole editor down with it.

The text-editing surface itself — the component that actually renders code, handles syntax highlighting, cursors, selections, folding, and the editing gestures you feel when typing — is called Monaco Editor. Monaco is written entirely in TypeScript and is itself a separate open-source project that Microsoft ships as a standalone, embeddable web component; it's the same editor that powers the code-editing panes inside GitHub.com, Azure DevOps, and many third-party products that want "the VS Code editing feel" in a browser without shipping all of VS Code (microsoft/monaco-editor on GitHub). In other words, VS Code the application is a shell — window chrome, panels, command palette, extension host, settings system — wrapped around Monaco as its editing core.

The language VS Code itself is written in is overwhelmingly TypeScript, Microsoft's own statically-typed superset of JavaScript (a language whose lead architect, Anders Hejlsberg, also helped design VS Code — the connection between the two projects is not a coincidence). A smaller amount of native code exists at the edges (platform integration, some performance-sensitive pieces), but the editor, the UI, the extension host, and Monaco are all TypeScript/JavaScript running on Node.js inside Electron (overview of the architecture).

On licensing: the code in the microsoft/vscode repository is genuinely open source, released under the MIT license, and anyone can read it, fork it, or build their own editor from it. The specific binary Microsoft distributes as "Visual Studio Code," however, ships under a separate Microsoft product license because it adds a small number of proprietary touches on top of the open-source core — the official product branding and icons, telemetry/usage reporting, and integration with the official Visual Studio Marketplace (the closed marketplace that hosts extensions like the C# and Python language support). This split is exactly why a project called VSCodium exists: it builds the same MIT-licensed source with the Microsoft branding, telemetry, and marketplace ties stripped out, for people who want the identical editor without those pieces (license/architecture discussion).

The name "Visual Studio Code" is also sometimes shortened carelessly to just "Visual Studio" in casual conversation, which is worth untangling once and for all: Visual Studio proper long predates VS Code (its roots go back to the 1990s), is far heavier, is historically much more Windows- and .NET-centric, and targets large enterprise and game-development teams working in C++, C#, and related Microsoft-stack languages. VS Code, by contrast, was conceived from day one as cross-platform, lightweight, and language-agnostic, and the two products, despite sharing a corporate parent and a family name, have almost entirely separate codebases, separate teams, and separate release cadences. A developer who has only used one should not assume much about the other beyond a shared visual design language and the Microsoft account/Marketplace plumbing they both plug into.

3. Core Editing Features

Stripped of any extension, VS Code already behaves like a serious editor rather than a bare text box:

  • IntelliSense — context-aware code completion, parameter hints, and quick documentation, which for many languages is powered by a real language analysis engine rather than simple word-matching.
  • Multi-cursor and multi-select editing — placing several cursors at once (by Alt/Option-click or by selecting all occurrences of a word) to edit multiple locations simultaneously.
  • Command Palette (Ctrl/Cmd+Shift+P) — a searchable list of literally every command the editor and its installed extensions expose, which doubles as VS Code's de facto menu system and is often the fastest way to do anything once you're used to it.
  • Quick Open (Ctrl/Cmd+P) — fuzzy-search file opening across an entire project folder.
  • Integrated terminal — a real shell (PowerShell, bash, zsh, cmd, WSL, etc.) docked inside the editor window, so you never have to alt-tab to a separate terminal app for git commands, builds, or test runs.
  • Code folding, minimap, breadcrumbs, and a Peek view for jumping to (and previewing) a definition or reference without leaving your current file.
  • Built-in diff and merge editors, including a three-way merge editor for resolving Git conflicts visually.
  • Zen Mode and Settings Sync — a distraction-free full-screen mode, and a system for syncing settings, keybindings, snippets, and installed extensions across machines via a Microsoft or GitHub account.
  • Multi-root workspaces — opening several unrelated folders (e.g., a frontend repo and a backend repo) as one logical workspace with shared search and settings.

A related but less-discussed feature is snippets — small, reusable blocks of boilerplate code (a for loop skeleton, a React component template, a license header) that expand from a short trigger prefix into full code, with tab-stops that let you jump between the placeholders that need filling in. VS Code ships a set of default snippets per language and lets any extension or any individual user define their own in a simple JSON format, and teams frequently check a shared .vscode/*.code-snippets file into a repository so everyone on the project gets the same boilerplate shortcuts. Search is similarly full-featured out of the box: a global find-and-replace panel supports regular expressions, whole-word and case-sensitive matching, and include/exclude glob patterns, letting you rewrite a pattern across an entire multi-thousand-file repository in one operation with a live preview of every match before committing to the replacement.

4. Language Support: How Broad, and How

VS Code does not "know" any programming language natively in a deep sense — its core ships with only basic syntax highlighting for a large list of common languages via TextMate-style grammars. Real, deep language intelligence — accurate autocomplete, go-to-definition, find-all-references, inline error checking, safe renaming/refactoring — comes from a separate piece of software called a language server, which VS Code talks to over the Language Server Protocol (LSP).

LSP is arguably VS Code's most consequential contribution to the wider developer-tools world. Before it existed, every editor that wanted good support for, say, Python, had to write and maintain its own Python-understanding logic from scratch — an enormous duplicated effort repeated across every text editor for every language. The VS Code team, building on ideas already used inside Visual Studio's own tooling and taking the TypeScript language server's design as a starting point, defined a standard JSON-RPC-based protocol so that a single language server (say, one Python analysis engine) could be written once and plugged into any compliant editor — VS Code, but also Vim, Emacs, Eclipse, Sublime Text, and others (LSP protocol history). That standardization effort is a large part of why the modern editor landscape looks the way it does: dozens of editors now share the same underlying language intelligence instead of reinventing it.

A parallel protocol, the Debug Adapter Protocol (DAP), does the same job for debugging: it decouples the debugger UI (breakpoints, call stacks, variable inspection) from the language- or runtime-specific logic needed to actually control a debuggee process, so a debug adapter written once can be reused by any DAP-compliant client (DAP overview).

Practically, this means VS Code has first-class or near-first-class support — via official or community extensions built on LSP/DAP — for essentially every language in wide professional use: JavaScript and TypeScript (built in, since the extension is maintained by the same team), Python, C/C++, C#/.NET, Java, Go, Rust, PHP, Ruby, Swift, Kotlin, Dart/Flutter, SQL dialects, and markup/config languages like HTML, CSS, JSON, YAML, and Markdown. Beyond general-purpose languages, there is equally strong support for infrastructure and data work: Dockerfiles, Kubernetes manifests, Terraform, Jupyter notebooks (rendered and editable directly inside VS Code, cell by cell, with the same kernel model as classic Jupyter), and shell scripting.

5. Debugging, Tasks, and Version Control

Debugging in VS Code is unified behind the Debug Adapter Protocol described above: you set breakpoints, step through code, inspect the call stack and variables, and watch expressions using the same UI regardless of whether the underlying process is Node.js, Python, a compiled C++ binary via GDB/LLDB, or a remote process over SSH. Launch configurations live in a project's .vscode/launch.json file, which is itself just JSON and is commonly checked into source control so a whole team shares the same debug setup.

Tasks are VS Code's built-in way to wire up build systems, test runners, linters, or any other shell command as a first-class, keyboard-triggerable action (tasks.json), so "build" or "run tests" becomes one keystroke instead of remembering and retyping a command.

Git integration is built in, not an extension: the Source Control panel shows changed files, staged/unstaged diffs, and lets you commit, branch, push, and pull without leaving the editor, and inline "gutter" indicators show which lines changed relative to the last commit as you type. On top of that built-in baseline, extensions such as GitLens add much deeper history exploration (blame annotations inline, commit graphs, comparing branches), and the official GitHub Pull Requests and Issues extension lets you review, comment on, and even check out a pull request entirely inside the editor.

6. The Extension Marketplace and Ecosystem

The extension model is the mechanism that turns a lean core editor into whatever kind of IDE a given developer needs. Extensions are published to the Visual Studio Marketplace and can add language support, themes, debuggers, linters, snippet packs, entirely new UI panels, or — as covered in depth below — AI assistance. The marketplace has grown into one of the largest software extension ecosystems in existence, with tens of thousands of published extensions covering essentially every corner of software development, from .env file syntax highlighting to full database GUI clients to Kubernetes cluster explorers.

This extensibility is also the top reason VS Code shows up repeatedly at the top of developer surveys. In the 2025 Stack Overflow Developer Survey — drawing more than 49,000 responses from 177 countries — Visual Studio Code led all code editors and IDEs with 75.9% usage share, more than 2.6 times the usage of Microsoft's own full Visual Studio IDE at 29%, and well ahead of Notepad++ (27.4%), IntelliJ IDEA (27.1%), and Vim (24.3%) (2025 Stack Overflow Developer Survey; coverage of the results). Even the newer wave of AI-native forked editors hasn't dethroned it: the same survey found Cursor at 17.9%, Claude Code at 9.7%, and Windsurf at 4.9% — all real, fast-growing competitors, but each still far below VS Code's own share. Separately, Microsoft has reported VS Code passing 36 million monthly active users in 2024, up 20% year over year from 30 million the prior year (usage statistics summary).

7. Remote Development, Containers, and the Web

One of VS Code's more distinctive capabilities is that the editor's UI and the code it's editing don't have to be on the same machine. The Remote Development extension pack lets the VS Code window you see run locally while the actual file system, terminal, and language servers run somewhere else entirely:

  • Remote - SSH connects to any remote Linux, macOS, or Windows machine over SSH and edits/debugs there directly, as if the files were local.
  • Dev Containers runs your entire development environment inside a Docker container defined by a checked-in devcontainer.json, so "it works on my machine" becomes "it works in the exact same container on every machine," including CI.
  • WSL integration lets Windows users edit and run Linux-native tooling through the Windows Subsystem for Linux with the same seamless feel.
  • GitHub Codespaces takes this further into the cloud: a full dev container, provisioned on GitHub's infrastructure and accessible either through a browser tab or through the desktop VS Code app connecting to it remotely, so a contributor can go from "open this repo" to a fully configured, running dev environment with no local setup at all.

For lighter needs, VS Code also runs as a genuine web application with no install at all: vscode.dev loads a browser-only version of the editor (backed by the File System Access API for local files or GitHub's API for repos), and github.dev does the same but is reachable by pressing the . key on any GitHub repository page, dropping you straight into a full editing UI for that repo in seconds.

8. Notebooks, Testing, Accessibility, and Customization

VS Code's Notebooks support renders .ipynb Jupyter notebooks natively, cell by cell, with the same rich output rendering (plots, tables, images) as classic Jupyter, while still giving you VS Code's IntelliSense, debugging, and source control inside the notebook. A unified Testing view (the Test Explorer) discovers tests from frameworks like pytest, Jest, or the .NET test runners and lets you run, debug, and see pass/fail status per test, per file, or for the whole suite, from one panel regardless of language.

Accessibility has had sustained, dedicated investment: full screen-reader support, an accessible view for chat and terminal content, adjustable and independently scalable UI/editor font sizes, high-contrast themes, and keyboard-only navigation for essentially the entire application.

Customization runs deep by design: virtually every keybinding can be rebound, settings.json exposes hundreds of fine-grained options as plain JSON (with full IntelliSense while you edit it), Profiles let you save and switch between entire configurations (extensions, settings, keybindings, UI layout) — useful for keeping, say, a "Python data science" profile cleanly separate from a "Node backend" profile on the same machine — and thousands of color and icon themes are available to change the editor's look without touching functionality at all.

It's worth being concrete about what these protocols mean for a working developer rather than leaving it abstract. Before LSP, a company maintaining, say, a Rust compiler toolchain that wanted good editor support had a choice between writing bespoke plugins for every popular editor separately (an enormous, perpetually out-of-date maintenance burden) or accepting that most editors would only ever offer shallow syntax coloring for the language. After LSP, that same team writes one Rust language server once (in this case, rust-analyzer), and any LSP-compliant editor — VS Code, Neovim, Helix, Zed, Emacs with the right plugin — gets real autocomplete, real error checking, and real refactoring support for free, simply by speaking the same protocol. This is also why a language server written for VS Code by one vendor is routinely reused, unmodified, inside completely unrelated commercial products; the protocol, not the specific editor, is the actual point of leverage.

9. Forks, Derivatives, and Where VS Code Sits in the Market

Because the core is open source, VS Code has become a common foundation for other products rather than only a finished end-user tool. VSCodium rebuilds the same source without Microsoft's branding, telemetry, or marketplace ties. Eclipse Theia, an unrelated but philosophically similar open-source project, reuses many of the same protocols (LSP, DAP) to build a cloud- and desktop-capable IDE framework used by products like Google Cloud's Cloud Shell Editor and Gitpod (Eclipse Theia). More notably for the current moment, several of the fastest-growing "AI-native" code editors — Cursor and Windsurf chief among them — are themselves forks of VS Code's open-source core, reusing its editor, extension compatibility, and general UI while replacing or deeply augmenting the AI layer. That lineage is a large part of why an experienced VS Code user can sit down at Cursor or Windsurf and feel at home within minutes: underneath the AI-specific chrome, it is substantially the same editor.

10. GitHub Copilot Integration in VS Code

No account of modern VS Code is complete without a close look at GitHub Copilot, because for a very large share of today's users the two are no longer really experienced as separate products — Copilot is the layer that turned VS Code from "an excellent, fast, extensible editor" into "the default place a great many developers now write code with an AI collaborator sitting next to (and increasingly inside) every keystroke." Copilot ships as an official Microsoft/GitHub extension (actually a pair of extensions — GitHub Copilot for completions, and GitHub Copilot Chat for the conversational and agentic features) rather than as a built-in part of VS Code's MIT-licensed core, which keeps the base editor free and open while the AI layer sits on top as a separate, primarily paid, product.

Inline (ghost-text) completions. The original and still-foundational Copilot feature is inline code suggestion: as you type, gray "ghost text" appears ahead of your cursor proposing the rest of the current line, or the next several lines, based on the surrounding code, open files, and (depending on settings and plan) broader repository context. Accepting a suggestion is a single Tab press; VS Code also exposes commands to cycle between alternative suggestions or accept just the next word rather than the whole block. A closely related feature, next-edit suggestions, goes further than simple completion: it watches the edit you just made elsewhere in the file and proactively suggests the next logical edit needed to keep the code consistent — for example, updating a second call site after you rename a function's parameter. According to GitHub's own 2026 pricing documentation, these baseline completion and next-edit features remain free and effectively unlimited across every paid plan, and are also available (with reduced monthly limits) on the free tier — unlike the heavier chat and agent features described next, which draw down a metered credit allowance (GitHub Copilot plans & pricing).

Copilot Chat. A dedicated chat panel lives alongside the editor (and, as of 2026, can also open as a separate "side chat" so you can run more than one conversation thread at once) for asking questions in natural language about the currently open code, getting an explanation of a confusing function, requesting a fix for a specific error, or asking for a whole new piece of code to be drafted. Chat understands "participants" and slash commands that scope a request — for instance directing a question specifically at the workspace, at a particular extension's own Copilot integration, or at a terminal command — and it can be given explicit context (a file, a selection, a whole folder, terminal output, or the current set of compiler errors) so its answers are grounded in your actual project rather than generic training knowledge.

Agent mode. This is the feature that has done the most to change how Copilot is actually used day to day, and it is a genuine step beyond autocomplete-style assistance. In agent mode, you describe a task in plain language — implement a feature, fix a failing test, refactor a module — and Copilot autonomously plans a sequence of steps, edits multiple files across the codebase as needed, runs terminal commands (installing a dependency, running a build, running the test suite), reads the output of those commands, and if something fails or an error appears, it iterates and self-corrects, continuing until the task is complete or it needs your input, all without you manually directing each individual step (Copilot agent mode overview). As of the 2026 releases, agents can also run for longer, more complex tasks with more visibility and control given back to the user mid-run: you can talk to a running agent and interrupt or redirect it while it's working rather than only reviewing its output after the fact, you can schedule agent tasks to run recurringly (hourly, daily, or weekly) or trigger them on demand, and a "prompt timeline" control lets you navigate back through a long agent transcript to a specific earlier prompt and review exactly what file changes happened around it (VS Code January 2026 / v1.109 release notes; GitHub Copilot in VS Code, August 2026 changelog).

Model choice and interoperability. On paid plans, Copilot Chat is not locked to a single underlying model — users can switch between model providers, including recent GPT, Gemini, and Anthropic Claude models (GitHub's own 2026 changelog specifically mentions choosing between Claude Opus and other models depending on subscription and plan tier), directly from a dropdown in the chat UI. Interoperability has gone further still: VS Code's January 2026 release added the ability to reuse Claude configuration files directly inside VS Code, and the August 2026 release lets a user switch model providers within a Claude session in VS Code between their Anthropic subscription and their Copilot subscription, and view or continue a recent Copilot or Claude agent session that was originally started in a different application from a shared "Sessions" list inside VS Code (VS Code February 2026 / v1.110 release notes). In practice this means the boundary between "using Copilot" and "using Claude" inside VS Code has become much softer than the product names alone would suggest — the editor increasingly treats different AI coding assistants as interchangeable backends behind one shared chat and agent interface, including a common Agent Plugins 1.0 standard, introduced in 2026, for portable agent extensions that work across VS Code and other compatible clients.

MCP support. Since mid-2026, Copilot's agent mode in VS Code supports the Model Context Protocol (MCP), an open standard (originated by Anthropic and since adopted broadly across the industry) for connecting an AI agent to external tools, databases, and services in a structured, reusable way. Practically, this lets a Copilot agent in VS Code do things well beyond editing files in the open workspace — querying a live database, calling an internal company API, checking a ticket tracker, or driving a browser — by connecting to any MCP server a team has configured, using the same protocol other MCP-compatible clients (including Claude Desktop and Claude Code) already speak (Copilot agent mode and MCP guide).

Code review and pull requests. Copilot's reach extends past the local editing session into collaboration: it can perform automated code review on a pull request, leaving inline comments the way a human reviewer would, and it integrates with the GitHub Pull Requests extension so review, discussion, and even Copilot-suggested fixes can happen without leaving VS Code.

Pricing and plans. GitHub restructured Copilot's billing on June 1, 2026, moving every plan — individual and organizational — onto usage-based billing through GitHub AI Credits (1 credit = $0.01), metered by token usage at each underlying model's own rate, with every paid plan bundling a monthly credit allowance roughly equal to its price. As of the 2026 pricing page, individual plans run Free ($0), Pro ($10/month, including $15 of monthly credits), Pro+ ($39/month, including $70 of credits), and Max ($100/month, including $200 of credits); organizational plans run Business ($19/seat/month) and Enterprise ($39/seat/month) (GitHub Copilot plans & pricing; usage-based billing announcement). Under this model, the lightweight inline completions and next-edit suggestions remain free and effectively unlimited on every plan including Free, while heavier features — chat, agent mode, and code review — draw down the credit allowance, which is the mechanism GitHub uses to let a single subscription flex across cheaper and more expensive underlying models rather than charging a flat fee regardless of which model does the work.

Taken together, these pieces mean that "GitHub Copilot in VS Code" in 2026 is no longer accurately described as "autocomplete with a subscription." It is a multi-model, tool-using, increasingly autonomous agent layer, natively wired into the editor's file system, terminal, debugger, and source control, that a developer can direct at the level of a single line, a whole feature, or a whole recurring maintenance task — while VS Code itself has been steadily reshaped, release by release through 2026, around the assumption that a session now regularly includes one or more AI agents working alongside the human, not just a human typing alone.

It's also worth naming the competitive picture VS Code sits inside rather than treating it as unchallenged. On the traditional side, JetBrains's family of IDEs (IntelliJ IDEA, PyCharm, WebStorm, and siblings) remains the preferred choice for many developers who want deep, opinionated, language-specific tooling built in from the start rather than assembled from extensions — the 2025 Stack Overflow survey put IntelliJ IDEA at 27.1% usage, a real and durable base rather than a rounding error. Sublime Text and Vim/Neovim retain loyal followings among developers who prioritize raw startup speed and keyboard-driven editing over IDE-style features. On the newer side, the AI-native forks discussed above — Cursor, Windsurf, and others — compete less on the editing experience itself (which they mostly inherited from VS Code) and more on how aggressively and by default they weave AI into the core workflow, sometimes offering a more opinionated or more unified agent experience than VS Code's extension-based approach provides. VS Code's response, visible across the 2026 release notes cited throughout this guide, has effectively been to absorb the most compelling parts of that competition directly into the base product and its official Copilot extension rather than cede that ground — multi-agent session management, model switching, MCP support, and Claude interoperability all arrived within a matter of months of each other through 2026, a release cadence aimed squarely at keeping the free, open core editor competitive with paid, AI-first forks built from its own source code.

11. Conclusion

Visual Studio Code succeeded by making an unusual bet for its time: keep the core small, fast, and free; make almost everything else pluggable; and open-source enough of it that the wider ecosystem — language maintainers, tool vendors, and eventually entire forked products — would have a reason to build on top of it rather than around it. A decade on, that bet looks vindicated by the numbers alone, let alone by how completely "open VS Code" has become a default reflex across the industry — the phrase itself, uttered dozens of times a day in standups and screen-shares worldwide, is a small piece of evidence for how thoroughly the editor won the mindshare battle it entered as an underdog in 2015. The arrival of deeply integrated AI assistance, led by GitHub Copilot but no longer limited to it, is the biggest change to that story since the original 2015 launch — not because it replaced anything VS Code already did well, but because it was layered on top of exactly the extensible architecture that made all of VS Code's earlier growth possible in the first place.


Sources


Written by: Claude AI.

Curator/Editor: Học Trò.

Mọi trích dẫn đều phải ghi chú với dòng trên và nói rõ bài khảo luận được lấy từ trang https://hoctroviet.blogspot.com/