30 năm của web nhìn từ thẻ `<br>`

• Bài viết tổng hợp cách phát triển web đã tiến hóa như thế nào, lần theo những thay đổi từ web tĩnh của thập niên 1990, web xoay quanh JavaScript của thập niên 2010 đến web trong kỷ nguyên AI của thập niên 2020
• Web khởi đầu với thẻ <br> và FTP đã nhanh chóng mở rộng thành nền tảng ai cũng có thể tạo ra khi đi qua PHP·MySQL
• Từ cột mốc Rails, Git, Heroku trong những năm 2000, phát triển web được tái cấu trúc thành một ngành công nghiệp xoay quanh cấu trúc hóa, tự động hóa và cộng tác, đặt nền móng cho thời đại cloud và mobile
• Sự xuất hiện của React, build chain, Docker và hệ sinh thái Node trong những năm 2010 đã cố định web như một nền tảng ứng dụng thực thụ chứ không còn chỉ là tài liệu
• Trong thập niên 2020, ChatGPT và Copilot thay đổi cách viết mã, trở thành bước ngoặt mới khi AI khuếch đại năng suất phát triển
• Tất cả những thay đổi này, đánh đổi bằng sự phức tạp, đã dẫn đến quá trình đại chúng hóa của web giúp nhiều người hơn có thể tạo ra những thứ lớn hơn

---

The Static Web - thời đại web tĩnh

"View Source was how you learned"

• Vào cuối những năm 1990 (late 90s), web là một vùng khai phá mà chưa ai biết nó sẽ trở thành gì, và chính sự bất định đó lại tạo nên sức hấp dẫn
• Website cá nhân khởi đầu không phải ở công ty hay tổ chức mà ở máy chủ cá nhân và từng thư mục riêng lẻ
  • Chỉ cần một thư mục cá nhân trên máy chủ Unix, các tệp HTML và một FTP client là đã có thể sở hữu một không gian trên Internet
  • Chỉ với trình soạn thảo văn bản đơn giản như Notepad cũng có thể viết nội dung và đăng công khai ngay lập tức
• Web thời kỳ này là không gian sáng tạo không có kiểm duyệt hay quy trình phê duyệt
  • Tự do đăng tải theo sở thích như nấu ăn, khủng long, bài hát
  • Cấu trúc cho phép đưa ngay lên mạng “những gì mình quan tâm trong tuần này”
• Cách học khi đó hoàn toàn là tự nhìn và làm theo trực tiếp
  • Chưa có tutorial trên YouTube hay Stack Overflow
  • Nếu tò mò một trang khác làm thế nào thì nhấp chuột phải → View Source là công cụ học tập mặc định
  • Nội dung chuyên sâu hơn thì học từ sách giấy thực tế
• Việc học với những cuốn sách kỹ thuật dày hàng trăm trang như Core Java đặt bên cạnh, vừa nhìn mã vừa đối chiếu với sách, là điều rất phổ biến
  • Chậm nhưng là kiểu trải nghiệm học tập giúp kiến thức bám lâu
• HTML khi đó ở trạng thái trộn lẫn giữa cấu trúc và kiểu dáng
  • Các thẻ <table>, <font>, <center> đồng thời đảm nhiệm cả bố cục lẫn phong cách
  • Dùng GIF trong suốt 1x1 (spacer GIF) để căn khoảng trắng
  • Thô ráp và kém hiệu quả, nhưng vẫn chạy được
• CSS có tồn tại nhưng gần như chưa phải dòng chính
  • Phần lớn style được xử lý bằng thuộc tính inline hoặc chính các thẻ HTML
  • Layout được giải quyết bằng các bảng lồng nhau
• Tính năng động có rào cản gia nhập cực cao
  • Ngay cả các chức năng cơ bản như sổ lưu niệm hay bộ đếm lượt truy cập cũng cần CGI script
  • Phải viết bằng Perl hoặc C, và chỉ để xử lý một URL parameter thôi cũng cần rất nhiều mã
  • Sự phức tạp này đã hạn chế mạnh mẽ sự lan rộng của web động
• Vấn đề layout dùng chung gần như không có lời giải
  • Header, navigation, footer phải copy/paste vào mọi tệp HTML
  • Khi thay đổi thì phải sửa toàn bộ tệp
  • Cũng có cách chèn thành phần chung bằng <iframe>, nhưng tác dụng phụ rất lớn
• Tương thích trình duyệt khi đó đã là một vấn đề nghiêm trọng
  • Netscape Navigator (1994) và Internet Explorer (1995) cho kết quả render khác nhau
  • Việc ghi rõ cảnh báo chỉ dành cho một trình duyệt hay độ phân giải cụ thể thực sự là cần thiết
• Dù vậy, web của thời kỳ này vẫn có sức hút rất mạnh
  • Có thể công khai với cả thế giới mà không cần thiết bị in ấn hay phát sóng
  • Web lần đầu tiên hiện thực hóa sự đại chúng hóa của phương tiện biểu đạt
• Các dịch vụ hosting miễn phí như GeoCities (1994) và Angelfire (1996) đã cung cấp không gian sáng tạo cho hàng triệu người
  • Các fan site và cộng đồng được kết nối qua web ring
  • Hình thành một hệ sinh thái hỗn loạn nhưng sống động
• Ở doanh nghiệp, khái niệm “web team” gần như vẫn chưa tồn tại
  • Nếu có website thì phần lớn là do “người biết máy tính” làm
  • Đó là giai đoạn ngay trước khi lập trình viên web trở thành một nghề nghiệp thực thụ
• Công cụ còn nguyên thủy và website còn thô sơ, nhưng
  • Ý tưởng cốt lõi về một không gian nơi ai cũng có thể tạo ra và chia sẻ đã bén rễ trong giai đoạn này
• Thời đại được chống đỡ bằng thẻ <br> và đam mê ấy đã trở thành điểm khởi đầu cho mọi tiến hóa của web về sau

Ngăn xếp LAMP và Web 2.0

"Mọi thứ đều là PHP và MySQL"

• Ngay cả sau vụ sụp đổ bong bóng dot-com năm 2000, web vẫn tiếp tục phát triển, và giai đoạn này trở thành bước ngoặt khiến rào cản gia nhập giảm mạnh đối với những người muốn tạo ra thứ gì đó
• Bước đột phá lớn nhất của thời kỳ web tĩnh là PHP (1995)
  • Từ thời phải viết hàng trăm dòng bằng C hay Perl cho CGI, việc có thể đọc tham số URL chỉ bằng một dòng $_GET['name'] là một thay đổi mang tính quyết định
  • Không cần biên dịch, quản lý bộ nhớ hay vật lộn với các thông báo lỗi khó hiểu; chỉ cần lưu rồi tải lại là chạy
  • XAMPP (2002) cho phép cài Apache·MySQL·PHP cùng lúc, đơn giản hóa mang tính đột phá việc thiết lập môi trường phát triển cục bộ
  • PHP là công cụ đầu tiên thực sự giải quyết đúng đắn bài toán tái sử dụng layout của thời web tĩnh
    • Chỉ với một dòng include 'header.php' là có thể quản lý chung header·footer
    • Trải nghiệm sửa một lần mà toàn bộ trang đều thay đổi mang lại sự phấn khích lớn
  • Bất chấp những khiếm khuyết của ngôn ngữ, điểm mạnh của PHP là tính dễ tiếp cận
    • Dù HTML và logic trộn lẫn, cách đặt tên hàm không nhất quán và API bảo mật còn thô sơ
    • Người ta vẫn có thể học vào cuối tuần và tạo ra một dịch vụ thật sự
    • Shared hosting (5 USD/tháng) cùng cPanel (1996) và phpMyAdmin (1998) được cung cấp sẵn theo mặc định, khiến rào cản lên online xuống mức thấp nhất trong lịch sử
• Cơ sở dữ liệu gần như luôn đi thành một bộ với PHP là MySQL (1995)
  • Gần như mọi tutorial·hosting·CMS đều được xây dựng với giả định dùng MySQL
  • Về mặt tính năng thì đã đủ dùng, nhưng trong xử lý văn bản quốc tế hóa thì là chuỗi đau liên tục
  • Mã hóa mặc định là latin1, và để dùng UTF-8 đúng cách thì
    • phải khớp cả cấu hình cơ sở dữ liệu, mã hóa kết nối và khai báo charset trong HTML
  • Vấn đề “ä thay vì ä” vẫn là một chấn thương mang tính biểu tượng của thời kỳ này
• WordPress (2003) đã thay đổi chính bản chất của web
  • Không cần biết code vẫn có thể cài trong 5 phút rồi đăng bài ngay
  • Chỉ cần chọn theme và viết bài là có thể vận hành website
  • Thực sự hiện thực hóa sự đại chúng hóa của việc làm website
  • Với người dùng không chuyên kỹ thuật, WordPress là một sự giải phóng
    • Từ blogger, chủ doanh nghiệp nhỏ, nghệ sĩ cho đến nhà hàng, ai cũng có thể sở hữu website
    • Một bản sắc mới mang tên “blogger” xuất hiện
    • Giao diện quản trị WordPress lan rộng đến mức được nhận thức như chính “trình chỉnh sửa website”
  • Với lập trình viên, WordPress gần như trở thành công cụ vạn năng
    • Blog, portfolio, website doanh nghiệp, cộng đồng, thương mại điện tử — tất cả đều là WordPress
    • Với WooCommerce (2011), nó còn hấp thụ cả e-commerce
    • Cái giá của việc triển khai nhanh là sự bùng nổ plugin và khoản nợ kỹ thuật tích lũy dựa trên việc tùy biến theme
• Sự kiện tái định nghĩa tận gốc khả năng của web là màn ra mắt Gmail (2004)
  • Trong thời kỳ Hotmail và Yahoo Mail chỉ cung cấp vài MB dung lượng lưu trữ
  • 1GB dung lượng miễn phí là một con số gây sốc
  • Thông điệp “đừng xóa, hãy tìm kiếm” đã đề xuất một cách sử dụng hoàn toàn mới
  • Đổi mới thật sự của Gmail không phải dung lượng lưu trữ mà là trải nghiệm
    • Giao diện cho phép đọc·soạn·chuyển đổi thư mà không cần tải lại trang
    • Tận dụng toàn diện giao tiếp bất đồng bộ dựa trên AJAX (XMLHttpRequest)
    • Chứng minh rằng web có thể trở thành ứng dụng, chứ không chỉ là tài liệu
• Google Maps (2005) đưa khả năng đó tiến thêm một bước
  • Di chuyển bản đồ bằng click và kéo thả
  • Tương tác tự nhiên với các tile được tải ở chế độ nền
  • Từ thời điểm này, thuật ngữ Web 2.0 bắt đầu được định hình rõ rệt
  • UI không cần tải lại, góc bo tròn, gradient và bóng đổ trở thành ngôn ngữ mặc định của web
• Những thay đổi mang tính quyết định cũng tiếp diễn ở mảng media và social
  • Trong lĩnh vực video, YouTube (2005) đã làm thay đổi cuộc chơi
    • Kết thúc địa ngục plugin như RealPlayer·QuickTime·Windows Media Player
    • Dù dựa trên Flash, nó mang lại trải nghiệm “click là phát ngay”
    • Video không còn là vấn đề kỹ thuật mà trở thành phương tiện biểu đạt
  • Twitter (2006) đưa ra một cách giao tiếp mới với microblogging 140 ký tự
  • Facebook (2006) mở cửa cho người dùng phổ thông, đưa mạng xã hội vào dòng chính
  • Web chuyển từ phương tiện tiêu thụ sang nền tảng có tính tham gia
    • Hình thành cấu trúc nơi bất kỳ ai cũng có thể trở thành người đăng tải và người sáng tạo
• Bất chấp mọi thay đổi đó, JavaScript vẫn rất đau khổ
  • Gỡ lỗi không hồi kết do khác biệt trong triển khai DOM·event·AJAX giữa các trình duyệt và vấn đề tương thích với IE6
  • jQuery (2006) trên thực tế đã chấm dứt sự hỗn loạn này
    • $('#el').hide() hoạt động giống nhau trên mọi trình duyệt
    • $.ajax() giúp đơn giản hóa giao tiếp bất đồng bộ
    • Với nhiều lập trình viên, jQuery gần như chính là JavaScript
      • Đồng thời nó cũng đóng vai trò lớp đệm khiến người ta không còn trực tiếp hiểu nguyên lý hoạt động của trình duyệt
  • Các vấn đề của thời kỳ này chỉ về sau mới được nhận ra là vấn đề
    • SQL Injection, XSS tràn lan ngay ở cấp độ tutorial
    • Kiểu code nối thẳng input của người dùng vào truy vấn là chuyện rất phổ biến
• Quản lý phiên bản khi đó chủ yếu là Subversion (2000)
  • Commit thì nặng nề, branch thì bị né tránh
  • Những tên thư mục như final_final_REAL là chuyện thường ngày
• Thiếu vắng sự chuẩn hóa môi trường chạy
  • Local là Windows + XAMPP
  • Server là Linux + phiên bản PHP khác
  • “works on my machine” cứ lặp đi lặp lại
• Khái niệm package manager cũng chưa tồn tại
  • JS được tải ZIP về rồi quản lý thủ công trong thư mục /js
  • Thư viện PHP được dùng theo kiểu sao chép file
• Cấu trúc nhóm và quy trình phát triển rất phi chính thức
  • Gần như không có vai trò PM·EM
  • Không có code review
  • Upload qua FTP xong là triển khai thẳng lên production
  • Khi có sự cố thì sửa nóng ngay trên server production
• Dù vậy, năng lượng của thời kỳ này vẫn rất mãnh liệt
  • Với PHP và hosting giá rẻ, ai cũng có thể triển khai
  • Cảm giác rằng có thể tạo ra “ứng dụng thật sự” bằng AJAX lan rộng
  • Với các nền tảng social, ai cũng có thể có khán giả của riêng mình
• Đây là thời điểm sự chuyên nghiệp hóa và cấu trúc hóa của phát triển web vừa mới bắt đầu
  • Ruby on Rails (2004) với “Convention over Configuration” báo hiệu một thời đại kế tiếp có cấu trúc hơn
• Các lập trình viên của thời kỳ này đã xây dựng web bằng ngăn xếp LAMP, các plugin jQuery, và,
  • trong niềm kỳ vọng “sẽ tạo ra dịch vụ lớn tiếp theo”

Cuộc chiến framework

"Rails changed everything, then everyone copied it"

• Cuối thập niên 2000 (late 2000s), khi quy mô ứng dụng web ngày càng lớn, các script PHP truyền thống và cấu trúc thiên về làm thủ công đã chạm tới giới hạn

• Như một lời giải cho giai đoạn này, cách phát triển xoay quanh framework bắt đầu trỗi dậy, và cái tên định hình dòng chảy đó là Ruby on Rails (2004)

  • Ảnh hưởng thực sự của RoR chỉ bùng nổ từ khoảng 2007–2008
  • Với triết lý “Convention over Configuration”, framework sẽ tự quyết định cấu trúc file, cách đặt tên và phương thức kết nối
  • Lập trình viên chỉ cần làm theo quy ước, và điều đó được nhìn nhận không phải như sự gò bó mà là một sự giải phóng giúp tăng tốc độ

• Sau đó, Rails đã gói lại và giới thiệu cùng lúc những khái niệm trở thành cú pháp nền tảng của phát triển web

  • Migration để quản lý thay đổi cơ sở dữ liệu bằng code
  • ORM giúp giảm mạnh sự phụ thuộc vào SQL
  • Quy trình phát triển có tích hợp kiểm thử ngay từ mặc định
  • Chuẩn hóa trên thực tế cấu trúc MVC (Model–View–Controller)
  • MVC vốn là khái niệm bắt nguồn từ Smalltalk thập niên 1970, nhưng thông qua Rails đã được cố định như dạng cơ bản của phát triển web
  • Sau thành công của Rails, gần như mọi hệ sinh thái ngôn ngữ đều vay mượn công thức này
    • Django (2005) trong Python và Laravel (2011) trong PHP đã giúp định hình cấu trúc kiểu Rails trong hệ sinh thái của mình
    • CakePHP (2005) và CodeIgniter (2006) cũng phát triển trên cùng dòng chảy đó
  • Việc tăng năng suất không phải là lời phóng đại
    • Phạm vi mà một lập trình viên cá nhân có thể làm trong một cuối tuần trước đây tương đương công việc của cả một nhóm
    • Trong môi trường startup, đây là công cụ tối ưu cho thử nghiệm nhanh và lặp lại liên tục
  • Trên thực tế, nhiều dịch vụ tiêu biểu đã phát triển trên nền Rails
    • Basecamp (2004), Twitter (2006), GitHub (2008), Shopify (2006), Airbnb (2008)
    • Rails nhanh chóng được xem như biểu tượng của tốc độ startup

• Framework đã kéo năng suất đi lên, nhưng triển khai vẫn là nút thắt cổ chai

  • Trong thời PHP, triển khai qua FTP upload là điều phổ biến, và chỉ một sai sót cũng có thể làm dịch vụ hỏng hoàn toàn
  • Ngay cả trong trường hợp tốt hơn, người ta vẫn phải xử lý thủ công những bước như SSH + SVN pull + khởi động lại Apache
  • Từ việc tách thư mục release đến đổi symbolic link, toàn bộ quy trình đều tùy biến và mong manh

• Thứ thay đổi tận gốc vấn đề này là Heroku (2007), bắt đầu lan rộng mạnh mẽ từ khoảng 2009–2010

  • Mang lại trải nghiệm triển khai chỉ với một dòng git push heroku main
  • Nền tảng thay lập trình viên xử lý cấu hình server, khởi động lại web server và scaling
  • Sau đó Heroku đã gần như xác lập trên thực tế khái niệm PaaS (Platform as a Service)
    • Lập trình viên chuyển sang vai trò tập trung vào code thay vì hạ tầng
    • Đồng thời phổ biến các nguyên tắc Twelve-Factor App (2011), lan tỏa tư duy thân thiện với cloud như tiến trình stateless, cấu hình dựa trên biến môi trường và log dưới dạng stream

• Cùng thời điểm đó, cách thức cộng tác cũng trải qua một cuộc chuyển đổi lớn

  • Git (2005) đưa vào mô hình quản lý phiên bản phân tán, cho phép commit·branch·merge tự do trên máy local, và vì chi phí tạo branch gần như bằng không nên thử nghiệm và hoàn tác trở thành công việc thường ngày
  • Subversion (2000) trước đó có cấu trúc tập trung, branch nặng nề và merge là nỗi ám ảnh, khiến nhiều đội phụ thuộc vào phát triển xoay quanh trunk
  • Git là một đổi mới ở cấp độ công cụ, nhưng chính GitHub (2008) đã biến nó thành văn hóa khi kết hợp duyệt kho lưu trữ công khai, phát triển dựa trên fork và cộng tác xoay quanh Pull Request
  • GitHub đã chuẩn hóa văn hóa code review
    • Trước khi merge PR, phải có ai đó xem code
    • Dòng chảy này cũng lan sang phát triển nội bộ trong công ty
    • Kỷ nguyên code đi thẳng lên production chấm dứt
  • Cách đóng góp cho mã nguồn mở cũng chuyển từ gửi patch qua mailing list sang bấm nút để gửi PR, làm giảm mạnh rào cản tham gia

• Ở nửa sau của giai đoạn này, cũng xuất hiện những thay đổi làm rung chuyển bản sắc của web

  • Sự ra mắt của iPhone (2007) và App Store (2008) khiến ứng dụng native bùng nổ
  • Web di động khi đó rất tệ: trải nghiệm co nhỏ site desktop để xem cho đỡ, phải cuộn ngang và phóng to thu nhỏ liên tục
    • Một số nơi dựng site di động riêng như m.example.com, nhưng giới hạn là rất rõ ràng
  • Ứng dụng native nhanh hơn, hỗ trợ offline, có push notification, và với khẩu hiệu “There’s an app for that” chúng trông như chính là tương lai
  • Các lập trình viên web bắt đầu rơi vào khủng hoảng bản sắc: có nên tiếp tục làm web không? Có nên học Objective-C không? Web sẽ biến mất sao?

• Như một lời giải cho sự hỗn loạn đó, Responsive Web Design (2010) xuất hiện

  • Ethan Marcotte (2010) đã đề xuất cách dùng CSS media query để điều chỉnh layout theo kích thước màn hình, từ đó đưa ra hướng hợp nhất mobile và desktop trong cùng một codebase
  • Ban đầu, do công cụ còn non và gánh nặng công việc tăng thêm nên tốc độ lan rộng khá chậm, nhưng hướng đi mà web cần tới thì đã trở nên rõ ràng

• Bootstrap (2011) là bước ngoặt khiến responsive web thực sự được dùng ngoài thực tế

  • Bắt đầu từ công cụ nội bộ của Twitter, nó cung cấp trọn gói grid system, typography cơ bản và style cho form, giúp cả những lập trình viên không có designer cũng có thể dùng ngay một UI tươm tất
  • Kết quả là web dần trông giống nhau hơn, nhưng với nhiều lập trình viên, Bootstrap là thư viện component đầu tiên và cũng là lần đầu họ trải nghiệm design system
  • Dòng chảy này sau đó dẫn tới sự lan rộng của các design system bài bản như Material Design (2014)

• Hạ tầng cũng thay đổi chóng mặt trong cùng giai đoạn

  • Từ cách mua hoặc thuê sẵn server vật lý, thế giới chuyển sang cấu trúc xoay quanh server ảo (VPS), cho phép tạo tài nguyên máy chủ khi cần
  • AWS (2006) xuất hiện sớm nhất, nhưng vì tính phức tạp và thiên về enterprise nên vẫn là gánh nặng với lập trình viên cá nhân
  • DigitalOcean (2011) với droplet giá $5, UI trực quan và trải nghiệm tạo server nhanh đã hạ thấp đáng kể rào cản tiếp cận hạ tầng, giúp cả lập trình viên cá nhân cũng có được độ linh hoạt tương tự doanh nghiệp lớn

• Vấn đề lưu trữ file gần như đã được Amazon S3 (2006) giải quyết trên thực tế

  • Nó cung cấp mô hình đơn giản: kho lưu trữ có thể mở rộng bất kể số lượng server, và trả về URL ngay sau khi upload
  • Các vấn đề về upload của người dùng, backup và quản lý file trong môi trường nhiều server được xử lý gọn trong một lần

• Node.js (2009) mang đến một cú sốc khác cho các lập trình viên web

  • Dựa trên engine V8 của Chrome, nó cho phép chạy JavaScript ở phía server, là một lựa chọn hấp dẫn với lập trình viên frontend nhưng lại khiến backend developer phản ứng hoài nghi
  • Mô hình non-blocking I/O cho thấy thế mạnh trong các ứng dụng thời gian thực, và phần lớn tutorial khi đó đều kết thúc bằng ví dụ ứng dụng chat
  • Tuy vậy ở giai đoạn này, Node vẫn gần với một đối tượng gây tò mò hơn là dòng chính trong production; dịch vụ thực tế vẫn chủ yếu xoay quanh Rails, Django và PHP, còn hệ sinh thái npm cũng mới ở giai đoạn đầu
  • Dù vậy, ảnh hưởng thực sự của Node về sau lại bộc lộ trước hết không phải ở server mà ở build tool và nền tảng chạy môi trường phát triển

• Trong mảng cơ sở dữ liệu, làn sóng NoSQL bắt đầu nổi lên

  • MongoDB (2009) thu hút chú ý với mô hình dữ liệu dạng tài liệu, tính linh hoạt của schema và cấu trúc thân thiện với JSON
  • Nó có lợi thế ở khả năng prototype nhanh, tiềm năng mở rộng và độ tương thích với stack JavaScript, nhưng không phù hợp với mọi dịch vụ
  • Cũng thường có những trường hợp được chọn chỉ vì “biết đâu sau này sẽ scale”, rồi đến mức vài nghìn người dùng mới cảm nhận rõ giới hạn về transaction

• Hệ sinh thái startup bước vào giai đoạn tăng trưởng thực sự trong thời kỳ này

  • Với tuyên ngôn “Software is eating the world” của Marc Andreessen (2011) và sự lan rộng của phương pháp Lean Startup (2011), chu trình MVP → đo lường → lặp lại đã được thiết lập

• Nhờ công cụ đã trưởng thành hơn, năng lực cạnh tranh của các đội ngũ ít người bắt đầu thực sự phát huy hiệu quả

• Quy trình phát triển cũng thay đổi

  • Agile Manifesto (2001) và Scrum trở nên phổ biến, khiến standup, sprint và retrospective được đưa vào như một chuẩn mực
  • Cũng xuất hiện nhiều đội ngũ chỉ còn hình thức mà không còn nguyên tắc
  • Code review và kiểm thử tự động chuyển từ mức được khuyến nghị thành kỳ vọng mặc định, còn hệ thống CI chạy kiểm thử với mỗi lần commit, từ đó đẩy nhanh quá trình nghề nghiệp hóa và chuyên môn hóa trong phát triển phần mềm

• Tuy vậy, những vai trò ngày nay được xem là hiển nhiên khi đó vẫn chưa thực sự định hình

  • Tính đến năm 2012, những đội ngũ không có engineering manager, product manager, hay quy trình quản lý backlog hoặc ticket bài bản là chuyện khá phổ biến
  • Các nhóm nhỏ và cấu trúc tổ chức phẳng là điều thường thấy, và việc “senior developer” mới chỉ có 3 năm kinh nghiệm cũng không hề hiếm

• Vào khoảng năm 2013, web đã trở thành một thứ hoàn toàn khác

  • Các framework mạnh mẽ, triển khai dễ dàng, cộng tác code qua mạng xã hội, hỗ trợ mobile, hạ tầng giá rẻ và sự phổ cập toàn diện của JavaScript cùng lúc hội tụ
  • Sau khi vượt qua khủng hoảng mobile, web thậm chí còn mạnh hơn, và đã sẵn sàng bước vào giai đoạn tiếp theo: thời đại JavaScript thống trị mọi thứ

Thời kỳ Phục hưng của JavaScript

"Giờ mọi thứ đều là SPA"

• Khoảng năm 2013, web đã chứng minh rằng mình có thể đảm đương các “ứng dụng thực thụ” qua những ví dụ như Gmail và Google Maps, nhưng cách làm jQuery + render phía máy chủ truyền thống ngày càng chạm tới giới hạn :contentReference[oaicite:0]{index=0}
• Vấn đề cốt lõi là quản lý trạng thái (state)
  • Trong cấu trúc mà máy chủ tạo HTML rồi jQuery bổ sung tương tác, việc duy trì dữ liệu và UI một cách nhất quán ở nhiều nơi trở nên cực kỳ khó khăn
  • Càng nhiều UI cùng phản ánh một trạng thái như bình luận, bộ đếm, huy hiệu thông báo, mã nguồn càng rối và biến thành cấu trúc spaghetti
• Kết luận chung khi đó là hãy chuyển toàn bộ việc render sang phía client
  • Máy chủ thu gọn lại thành vai trò API trả về JSON
  • Cấu trúc SPA (Single Page Application), trong đó JavaScript trên trình duyệt quản lý toàn bộ UI, bắt đầu nổi lên
• Các framework SPA đời đầu xuất hiện trong giai đoạn này
  • Backbone.js (2010) cung cấp cấu trúc tối thiểu với khái niệm model và view
  • Angular (2010) thử cách tiếp cận kiểu enterprise bằng cách đưa vào data binding hai chiều và dependency injection
  • Ember.js (2011) đưa ra những quy ước chặt chẽ với mục tiêu trở thành “Rails của JavaScript”, bao gồm cả routing, dữ liệu và template
  • Các framework này là một bước tiến, nhưng nhìn chung vẫn chưa giải quyết triệt để vấn đề độ phức tạp của việc đồng bộ DOM và dữ liệu
    • Đặc biệt, binding hai chiều khiến luồng cập nhật khó theo dõi hơn và làm tăng chi phí debug
• Bước ngoặt đến với sự xuất hiện của React (2013)
  • Khi Facebook công bố mã nguồn mở, cú pháp JSX tạo cảm giác như đang đảo ngược việc tách biệt các mối quan tâm nên vấp phải nhiều phản ứng dè dặt
  • Nhưng React đưa ra một cách tư duy mới: không thao tác trực tiếp với DOM mà mô tả một cách khai báo kết quả UI theo trạng thái
  • Cốt lõi của React là mô hình khai báo và Virtual DOM
    • Khi trạng thái thay đổi, React tính toán rồi chỉ áp dụng những thay đổi DOM tối thiểu cần thiết
    • Lập trình viên có thể tập trung vào quản lý trạng thái mà không phải bận tâm đến thao tác DOM
  • Khái niệm component cũng mang tính quyết định
    • UI được cấu thành bằng cách kết hợp những đơn vị nhỏ như Button, UserAvatar, CommentList
    • Mỗi component có thể được tư duy độc lập và tái sử dụng
  • React dần lan rộng rồi trở thành dòng chính vào khoảng năm 2015
    • Vue.js (2014) nổi lên như một lựa chọn thay thế khi cung cấp các khái niệm tương tự bằng cú pháp thân thiện hơn
    • Cuộc chiến framework bước sang một giai đoạn mới
• Sự lan rộng của SPA đồng nghĩa với lượng JavaScript tăng bùng nổ
  • Vấn đề là JavaScript mà lập trình viên muốn viết và JavaScript mà trình duyệt hiểu lại khác nhau
• ES6 / ES2015 (2015) mang tới hàng loạt cải tiến ngôn ngữ như arrow function, class, module, promise
  • Callback hell và mô thức var self = this biến mất, khiến JavaScript cuối cùng cũng bắt đầu cho cảm giác như một ngôn ngữ hiện đại
• Tuy nhiên, hỗ trợ từ trình duyệt bị chậm hơn và không thể triển khai nguyên trạng
• Babel (2014) giải quyết vấn đề này bằng một transpiler chuyển JavaScript mới sang ES5
  • Cái giá phải trả là bước build trở thành yếu tố bắt buộc trong phát triển JavaScript
  • Kỷ nguyên chỉ cần sửa file rồi refresh là xong đi đến hồi kết
• Trong quá trình đó, Node.js (2009) không phải với vai trò máy chủ mà với vai trò môi trường chạy công cụ phát triển đã chiếm lĩnh mọi máy của lập trình viên
  • Ngay cả khi không dùng Node cho backend, việc cài Node vẫn trở thành bắt buộc vì các công cụ build
• Chuỗi công cụ build cũng tiến hóa rất nhanh
  • Grunt (2012) quản lý các bước build phức tạp bằng file cấu hình như một task runner
  • Gulp (2013) cố gắng đơn giản hóa điều đó bằng pipeline dựa trên mã, nhưng vẫn còn phức tạp
• Thay đổi mang tính quyết định là Webpack (2014)
  • Không chỉ là task runner đơn thuần mà là một module bundler có thể hiểu đồ thị phụ thuộc
  • JavaScript, CSS, hình ảnh, font đều được coi là module
  • Giới thiệu các khái niệm như code splitting và hot module replacement
  • Cái giá của sức mạnh đó là cấu hình trở nên nổi tiếng là khó nhằn
    • Cấu hình Webpack trở thành meme, và ở mỗi team đều có “một người hiểu thứ này”
    • Khi người đó rời đi, cấu hình ấy bị bỏ lại như một di vật khiến ai cũng ngại chạm vào
• Đồng thời, hệ sinh thái npm tăng trưởng bùng nổ
  • Từ cách tải thư viện trực tiếp, mọi thứ chuyển sang xoay quanh npm install
  • moment, lodash, thậm chí cả những utility cực nhỏ như left-pad cũng được đóng gói thành package
  • Sự cố left-pad (2016) bộc lộ tính mong manh của hệ sinh thái
    • Chỉ một package dài 11 dòng bị xóa đã khiến bản build của hàng nghìn dự án cùng thất bại
    • Ngay cả React và Babel cũng rơi vào tình trạng không thể cài đặt
    • npm phải phục hồi package theo cách chưa từng có tiền lệ để dập sự cố
  • Sự tiện lợi vẫn được giữ lại, nhưng ai cũng nhận ra thực tế của địa ngục phụ thuộc
• Năm 2016, độ phức tạp đạt đỉnh
  • Bài châm biếm “How it feels to learn JavaScript in 2016” lan truyền mạnh
  • Cảm giác mệt mỏi lan rộng khi để tạo một trang web đơn giản cũng cần tới vô số công cụ như React, Webpack, Babel, Redux
  • Tốc độ thay đổi của hệ sinh thái quá nhanh khiến kiến thức vừa học đã nhanh chóng lỗi thời
  • Dù vậy, thành quả tạo ra là rất rõ ràng
    • Có thể xây dựng các ứng dụng web tương tác ở mức độ trước đây không thể làm được
    • Độ phức tạp được chấp nhận như cái giá của tham vọng
• Trong khi đó, Docker (2013) bắt đầu giải quyết một vấn đề hoàn toàn khác
  • Giải quyết vấn đề “works on my machine” bằng container
  • Dùng Dockerfile để định nghĩa môi trường chạy và có thể chạy giống hệt ở bất cứ đâu
  • Thời gian đầu, việc áp dụng không hề dễ do vấn đề hiệu năng trên Mac và sự rối rắm của networking
    • Docker Compose, Docker Swarm, rồi Kubernetes (2014) xuất hiện, kéo theo cuộc chiến orchestration
    • Khoảng năm 2017, ít nhất có một điều đã rõ ràng: container là tương lai
• Cùng với đó, xu hướng microservices lan rộng
  • Nó mang lại lợi thế tách dịch vụ và triển khai độc lập
  • Đổi lại là những độ phức tạp mới như service discovery, load balancing, distributed tracing
  • Nhiều team chỉ nhận ra quá muộn rằng họ đã đổi độ phức tạp của monolith lấy độ phức tạp của hệ thống phân tán
• Trong giai đoạn này, mức độ hoàn thiện của ứng dụng web tăng lên rõ rệt
  • Slack (2013) thay thế email bằng một công cụ cộng tác nhanh và có thể tìm kiếm
  • Figma (2016) xâm lấn lãnh địa của ứng dụng desktop bằng một công cụ thiết kế cộng tác chạy trên trình duyệt
  • Cùng với Notion (2016) và các sản phẩm khác, chúng chứng minh rằng web có thể hiện thực hóa phần mềm cấp độ desktop
  • Các ví dụ này trở thành cơ sở để biện minh cho độ phức tạp của React, Webpack và chuỗi build
• Cấu trúc tổ chức cũng chuyển sang giai đoạn trưởng thành hơn
  • Khoảng năm 2016, product manager và engineering manager trở thành những vai trò tiêu chuẩn
  • Cấu trúc team phẳng thời kỳ đầu dần chuyển thành tổ chức xoay quanh quy trình
  • Scrum và các nghi thức agile lan rộng, tùy từng team mà chúng trở thành công cụ hoặc chỉ còn là hình thức
• Năm 2017, hệ sinh thái dần bước vào giai đoạn ổn định
  • React gần như trở thành kẻ chiến thắng thực tế
  • ES6 trở thành cú pháp mặc định
  • Webpack và Docker dù đau đầu vẫn được chấp nhận là tiêu chuẩn
• Giai đoạn tiếp theo đã được báo trước
  • Sự trỗi dậy của TypeScript
  • Các meta-framework như Next.js
  • Trải nghiệm triển khai đơn giản hơn
• Nhưng tiền đề chỉ có một
  • Chỉ những lập trình viên đã đi qua sự hỗn loạn của thời kỳ Phục hưng JavaScript này mới có thể tiến tới giai đoạn tiếp theo

Kỷ nguyên TypeScript

"Types are good, actually"

• Sau thời kỳ phục hưng của JavaScript, khi sự hỗn loạn của các công cụ dần lắng xuống và hệ sinh thái bước vào giai đoạn trưởng thành, TypeScript đã chiếm một vị trí trung tâm ở bước ngoặt đó
• TypeScript (2012) đưa kiểu tĩnh vào JavaScript, nhưng ban đầu bị thờ ơ trong thời gian dài do đi ngược triết lý ngôn ngữ động và làm tăng gánh nặng với bước build bổ sung
  • Khi quy mô ứng dụng ngày càng lớn, giới hạn của kiểu động dần trở nên rõ ràng hơn
    • Chi phí lần theo các điểm gọi tăng lên sau khi thay đổi chữ ký hàm
    • Vấn đề về khả năng đọc mã khi khó nắm bắt cấu trúc của đối tượng
    • Nhiều trường hợp lỗi gõ sai đơn giản dẫn đến sự cố production lặp đi lặp lại
  • Lấy mốc 2017–2018, việc chấp nhận TypeScript lan rộng rất nhanh
    • Đảm bảo độ an toàn khi refactor nhờ tự động hoàn thành và phân tích tĩnh
    • Interface đóng vai trò như tài liệu bắt buộc được đồng bộ với mã nguồn
  • Việc các framework lớn chấp nhận nó đã trở thành bước ngoặt
    • Angular chọn chiến lược ưu tiên TypeScript
    • Khi định nghĩa kiểu cho React trưởng thành và Vue 3 được viết lại dựa trên TypeScript, nó được nhìn nhận là tiêu chuẩn trên thực tế
    • Từ khoảng năm 2020, các dự án mới thuần JavaScript gần như không còn được chọn nữa
  • TypeScript đã cải thiện đáng kể khả năng tiếp cận của codebase
    • Người mới tham gia chỉ cần đọc định nghĩa kiểu cũng có thể nắm được mô hình miền
    • Giảm phụ thuộc vào tri thức ngầm, từ đó làm nhẹ chi phí mở rộng đội ngũ
• Sự kết hợp với VS Code (2015) đã thay đổi mang tính quyết định trải nghiệm phát triển
  • Cung cấp tự động hoàn thành thông minh, hiển thị lỗi nội tuyến và refactor đáng tin cậy
  • Sublime Text và Atom dần suy giảm ảnh hưởng
• Một tầng trừu tượng khác lại được hình thành bên trên React
  • React là thư viện UI nên không có lời giải mặc định cho routing, data fetching và SSR
• Next.js lấp đầy khoảng trống này như một meta framework mặc định cung cấp file-based routing, server-side rendering, API routes và automatic code splitting
  • Nhiều framework đối ứng như Nuxt, Remix, SvelteKit, Gatsby cũng lần lượt xuất hiện
  • Trong hệ sinh thái React, Next.js trở thành lựa chọn mặc định trên thực tế
• Sự phổ biến của meta framework đã làm giảm đáng kể sự mệt mỏi vì phân mảnh tooling của thời kỳ trước
  • Quá trình tự lắp ghép cấu hình webpack và Babel được hấp thụ vào các giá trị mặc định
• Môi trường triển khai cũng được đơn giản hóa nhanh chóng
  • Vercel và Netlify cung cấp triển khai tự động và môi trường preview chỉ bằng cách kết nối GitHub
  • Designer, PM và QA có thể kiểm tra thay đổi trong môi trường thực tế trước khi merge
• Ảnh hưởng của Heroku suy yếu, còn các PaaS thế hệ mới như Railway và Render nổi lên
• Khái niệm Serverless lan rộng với AWS Lambda (2014) là trung tâm
  • Cung cấp tính phí theo mức sử dụng và tự động mở rộng
  • Nhưng không phải lời giải phổ dụng vì tồn tại giới hạn về cold start, quản lý trạng thái và gỡ lỗi
  • Cloudflare Workers mở rộng điều này bằng mô hình thực thi ở edge
• Trong lĩnh vực CSS cũng diễn ra một sự chuyển mình âm thầm
  • Sau Sass và Less, rồi đến CSS-in-JS, Tailwind CSS (2017) được chấp nhận rộng rãi
  • Cách tiếp cận dựa trên utility class
    • Loại bỏ gánh nặng đặt tên class
    • Giảm vấn đề cascade và specificity
    • Kết quả là giúp duy trì stylesheet nhỏ hơn
• GraphQL (2015) được chú ý như một lời giải mạnh mẽ cho các ứng dụng xử lý cấu trúc dữ liệu phức tạp
  • Mang lại lợi thế về truy vấn dữ liệu chính xác, schema dựa trên kiểu và hệ sinh thái công cụ
  • Nhưng vì độ phức tạp ở tầng server và độ khó của việc caching, nó trở thành lựa chọn quá mức cho CRUD đơn giản
  • Một số đội ngũ chọn tiếp tục dùng REST hoặc các lựa chọn đơn giản hơn như tRPC
• Cuộc cạnh tranh trong điều phối container đi đến kết cục Kubernetes chiến thắng vào khoảng năm 2018
  • Mạnh mẽ nhưng đi kèm chi phí học tập cao và độ phức tạp vận hành lớn
  • Với nhiều đội ngũ, đó là lời giải quá mức, và điều này trở thành nền cho sự trở lại của PaaS
• COVID (2020) làm nhu cầu phát triển web tăng vọt
  • Làm việc từ xa, thương mại điện tử và công cụ cộng tác trở thành thiết yếu
  • Dẫn đến nhu cầu tuyển dụng lập trình viên bùng nổ và các công ty công cụ phát triển tăng trưởng nhanh
• Trong môi trường từ xa, tầm quan trọng của cộng tác bất đồng bộ và tài liệu hóa tăng lên
  • Code review, mô tả PR và chất lượng tài liệu nội bộ nổi lên như những yếu tố cốt lõi
• Ở cấp độ tổ chức cũng diễn ra sự trưởng thành
  • Hệ thống cấp bậc kỹ sư được định hình
  • Tính chính đáng của lộ trình IC được khẳng định
  • Vai trò PM, EM và tech lead được phân hóa
• Developer Experience (DX) được nhìn nhận là một đối tượng đầu tư độc lập
  • Đội ngũ nền tảng nội bộ, CI nhanh và onboarding tốt hơn nổi lên như các yếu tố cốt lõi của năng suất
• Khoảng năm 2022, phát triển web đã đạt tới trạng thái phức tạp nhưng có thể quản lý được
  • TypeScript trở thành mặc định
  • Hệ sinh thái xoay quanh Next.js
  • Tự động hóa triển khai và bộ công cụ trưởng thành
• Và rồi mọi thứ thay đổi hoàn toàn: một công ty tên OpenAI phát hành thứ được gọi là ChatGPT

Khoảnh khắc của AI

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

• Kể từ khi ChatGPT (2022) ra mắt, trải nghiệm chỉ cần nhập câu hỏi là nhận được giải thích, mã nguồn và kết quả gỡ lỗi đã xuất hiện, làm thay đổi các quy tắc phát triển
  • Nó có thể xử lý từ giải thích vật lý lượng tử đến gỡ lỗi Python, và cú sốc nằm ở chỗ dù không hoàn hảo, nó vẫn đủ hữu dụng để dùng được
  • Lập trình viên ngay lập tức bắt đầu thử nghiệm, và việc viết component React, phân tích nguyên nhân lỗi hay chuyển đổi mã giữa các ngôn ngữ đã trở nên khả thi trong vài giây mà không cần tra tài liệu hay lục tìm diễn đàn
• GitHub Copilot (2022) cung cấp sinh mã dưới dạng tự động hoàn thành ngay trong editor, phổ biến hóa một trải nghiệm tự động hoàn thành cực mạnh có thể đề xuất triển khai chỉ từ chú thích
  • Kỹ năng meta mới là nhanh chóng đánh giá, chấp nhận, chỉnh sửa hoặc từ chối đề xuất của AI đã nổi lên như năng lực cốt lõi của lập trình viên
• Các công việc như boilerplate lặp đi lặp lại, viết test hay xử lý edge case được tăng tốc mạnh, cho phép phát triển không bị ngắt mạch dòng chảy
• Cursor (2023) là IDE tích hợp AI không phải như một tính năng mà như điều kiện tiên quyết, cho phép chọn đoạn mã rồi yêu cầu refactor, chỉnh sửa nhiều file dựa trên mô tả ngôn ngữ tự nhiên và trò chuyện với codebase
• Sự thay đổi này làm lung lay ý nghĩa của thâm niên, nhưng trên thực tế lại khiến tầm quan trọng của khả năng quyết định nên tạo ra cái gì, và đánh giá yêu cầu, ràng buộc cùng tác dụng phụ còn lớn hơn
  • AI có thể viết mã, nhưng không thể định nghĩa vấn đề và chọn đúng hướng đi
• Đã có những phản ứng cực đoan ở cả hai đầu như “cái chết của lập trình” và “một trào lưu vô dụng”, nhưng kết quả thực tế là sự khuếch đại năng suất của những lập trình viên biết dùng AI
• Rào cản gia nhập cho các dự án cá nhân và side project giảm mạnh, khiến cả những lĩnh vực trước đây không dám thử như ML, game hay framework mới cũng có thể tiếp cận bằng học tập dựa trên đối thoại
• Dòng chảy này hoạt động như một giai đoạn đẩy nhanh hướng đi lâu dài của web là dân chủ hóa sáng tạo
  • Trọng tâm chuyển từ biết viết mã sang biết mình muốn tạo ra điều gì
• Ngay cả người không phải lập trình viên cũng tham gia làm prototype, còn PM, designer và chuyên gia lĩnh vực trực tiếp tạo công cụ, khiến ranh giới giữa kỹ thuật và phi kỹ thuật trở nên mờ đi
• Indie hacker và solo builder gia tăng, biến môi trường mà một người cũng có thể tạo ra sản phẩm thực chất thành hiện thực
• Đồng thời, React Server Components, htmx, các tiêu chuẩn CSS và JavaScript được cải thiện cùng các công cụ như Bun cũng củng cố xu hướng “hãy dùng chính nền tảng”
• Sau làn sóng tuyển dụng quy mô lớn giai đoạn 2022–2023, thị trường bị chao đảo khi đi kèm các đợt tái cơ cấu, nhưng AI không thay thế lập trình viên và năng lực tận dụng AI đã trở thành kỳ vọng cơ bản
• Tính đến năm 2025, phát triển web đang ở trạng thái tốc độ từ ý tưởng đến triển khai nhanh nhất trong lịch sử, và
  • Trong môi trường kết hợp cloud, framework và AI, cá nhân trở thành người sáng tạo mạnh mẽ hơn bao giờ hết
• Lời hứa của web bắt đầu từ thẻ <br>, rằng “ai cũng có thể tạo ra và chia sẻ”, đang tiếp tục mạnh mẽ hơn trong kỷ nguyên AI
• Bây giờ là một thời điểm thực sự tuyệt vời để làm web

[ethanhur]

Tôi đã đọc rất thú vị, như đọc một cuốn sử.

[zihado]

Hồi đó thuê một gói hosting server ở Cafe24, cài Zeroboard lên rồi tự trang trí cho ra dáng một cộng đồng để nghịch ngợm chơi, haha

[lethee]

Tôi đọc rất thú vị. Cảm giác như thước phim tua nhanh cuộc đời lướt qua trước khi chết vậy haha

[edunga1]

Tôi đã đọc rất thú vị.
Nếu chuyển sang môi trường phát triển, sẽ có sự xuất hiện của VS Code và LSP. Và còn có thể nối tiếp đến cả những công cụ của thời kỳ trước kỷ nguyên AI của Tabnine nữa.

[aer0700]

JavaScript의 간략한 역사
Nếu đọc cùng với bài này thì sẽ rất hay.

[GN⁺]

Ý kiến Hacker News

• Nói rằng mọi trang đều cần cùng một header, điều hướng và footer nhưng không có cách nào để chia sẻ là không hoàn toàn đúng
  Trên web server đã có tính năng Server Side Includes (SSI), và nếu không muốn dùng nó thì đơn giản chỉ cần lệnh cat header body > file là cũng giải quyết được
  Tài liệu liên quan: NCSA SSI tutorial (1997)

  • HTML vốn được tạo ra như một từ vựng dựa trên SGML, nên SGML và XML có tính năng entity/text macro để tham chiếu các mảnh tài liệu như header hoặc footer dùng chung
  • Có lẽ bình luận gốc đang nói dựa trên HTML thuần túy

• Tôi đã nghĩ giá mà bài viết kết thúc bằng một câu kiểu như “...và trong toàn bộ quá trình đó, thẻ <br> khiêm tốn vẫn tiếp tục làm đúng phần việc của mình”

• Ở công ty tôi từng làm, mỗi lần triển khai đều tạo một thư mục mới rồi đổi symlink sang bản mới nhất
  Dù là thủ công, đây vẫn là một cách rất tao nhã vì có thể chuyển đổi nguyên tử trên từng máy chủ và cũng dễ rollback
  Trước đó, chúng tôi phải tự chép file lên hàng chục máy chủ và tự tay chạy 10–20 bước lệnh, nên so với vậy thì cách này an toàn và đơn giản hơn nhiều
  Về sau tôi có dùng các công cụ tự động hóa, nhưng cấu hình phức tạp và thiếu minh bạch đến mức lại trở thành một quy trình triển khai mong manh hơn

• Có câu “muốn dùng CGI script thì phải học Perl hoặc C”, nhưng tôi từng tự hỏi liệu có thật sự cần đến hàng trăm dòng hay không
  Thực tế, chỉ với một hàm C đơn giản cũng có thể đọc URL parameter
  Gần đây tôi đã làm một website khảo sát bằng C thuần, và nhờ thư viện tạo HTML tôi viết từ trước nên làm khá suôn sẻ
  Tôi refactor thư viện CGI của hệ điều hành để dùng lại, rồi link tĩnh SQLite để triển khai dưới dạng một binary duy nhất
  Thậm chí có thể kiểm thử qua stdin/stdout mà không cần web server
  Tóm lại, website CRUD cũng đủ dễ để làm bằng C, và vì HTML là cấu trúc cây nên string interpolation là một cách tiếp cận sai

  • Vì mã khớp tham số đầu tiên kết thúc bằng <param>, nên có thể không khớp chính xác và cũng không xử lý percent-encoding
  • Tôi đồng ý với ý rằng string interpolation không phù hợp vì HTML biểu diễn một cấu trúc cây
    Nhưng cả sau 30 năm, nó vẫn có cảm giác là công cụ phổ biến nhất

• Đây thực sự là một bài viết toàn diện và được viết rất tốt
  Tác giả khá lạc quan, nhưng tôi lại thấy phát triển web giống như một tòa tháp chông chênh được dựng nên từ sự chắp vá tạm bợ tích lũy qua thời gian
  Khi việc chuẩn hóa web bị một số ít browser vendor chi phối, kết quả là người ta chỉ vá thêm lớp mới thay vì giải quyết vấn đề gốc rễ
  Các công cụ AI tạo sinh gần đây cũng chỉ là giải pháp tạm thời để lách qua sự phức tạp ấy
  Cuối cùng tôi nghĩ tòa tháp này rồi sẽ sụp đổ

• Bài này có lẽ sẽ trở thành một bài viết kinh điển
  Nó gói gọn lịch sử công nghệ web mà các lập trình viên ngày nay đã bỏ lỡ

• Khi đọc đoạn “Virtual private servers changed this…”, tôi chợt nhớ ra
  Thực ra nhà cung cấp VPS đầu tiên là JohnCompanies vào khoảng năm 2001, dựa trên FreeBSD jail
  Khách hàng muốn backup từ xa và thích dùng rsync
  Vì vậy bốn năm sau tôi đã đăng ký domain rsync.net (có xin phép các tác giả rsync/samba)

• Tôi làm web từ năm 1998 đến 2012, và khi đọc bài này tôi có cảm giác như đang du hành qua ký ức
  Đồng thời đây cũng là một bản tóm tắt giúp nhìn toàn cảnh những thay đổi sau đó

• Nội dung bài viết gần như trùng khớp với dòng chảy công nghệ web mà tôi nhớ
  CGI trước thời PHP thì phiền thật, nhưng nhờ mod_perl và FastCGI nên vẫn dùng được
  Viết CGI bằng ngôn ngữ biên dịch gần như là khổ dâm, và PHP ở điểm đó thì nhẹ nhàng và vui hơn
  Tôi rời frontend development ngay trước khi jQuery bùng nổ

• Một bài viết thực sự đáng kinh ngạc
  Nó không chỉ liệt kê niên biểu kỹ thuật mà còn truyền tải sống động zeitgeist của từng thời kỳ
  Điều gây ấn tượng là bài viết ghi lại được bối cảnh con người vốn thường chỉ được truyền miệng
  Thay vì chỉ trích “tại sao thế giới cloud lại trở nên phức tạp như vậy”, nó giúp ta hiểu đó là kết quả lịch sử do những lựa chọn hợp lý ở từng thời điểm tích lũy lại
  Có thể cảm nhận được sự mỉa mai của lịch sử loài người ngay trong lịch sử công nghệ