Port JustHTML từ Python sang JavaScript: hoàn thành trong 4,5 giờ với Codex CLI và GPT-5.2

 (simonwillison.net)
7 điểm bởi GN⁺ 2025-12-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trường hợp trình phân tích HTML5 JustHTML được port hoàn toàn từ Python sang JavaScript, được triển khai trong khoảng 4,5 giờ bằng Codex CLI và GPT-5.2
  • Thư viện mới JustJSHTML là một trình phân tích HTML5 không có phụ thuộc, vượt qua 9.200 bài kiểm thử của html5lib-tests và tái hiện nguyên vẹn thiết kế API gốc
  • Toàn bộ quá trình được thực hiện bằng 8 prompt và một vài lệnh tiếp theo, trong đó GPT-5.2 tự động tạo 9.000 dòng mã và 43 commit
  • Dự án được hoàn thiện dưới dạng mã nguồn mở đầy đủ, bao gồm tự động commit, kiểm thử, tài liệu hóa và tạo trang playground
  • Thí nghiệm này đồng thời đặt ra lại các vấn đề về năng suất thực tiễn của coding agent dựa trên LLM, cũng như bản quyền, đạo đức và độ tin cậy

Tổng quan dự án

  • JustHTML là một trình phân tích HTML5 tuân thủ tiêu chuẩn do Emil Stenström phát triển, được viết bằng Python và là một triển khai vượt qua toàn bộ bộ kiểm thử html5lib-tests
    • html5lib-tests là tiêu chuẩn kiểm thử khả năng tương tác giữa các trình phân tích HTML5, được dùng trong nhiều dự án như html5ever của Servo
  • Simon Willison quyết định tự port dự án này sang JavaScript, tận dụng Codex CLI và GPT-5.2 để thực hiện với mức thao tác thủ công tối thiểu
  • Thành phẩm JustJSHTML có thể chạy trên cả trình duyệt lẫn môi trường Node.js, đồng thời được viết bằng JavaScript thuần không phụ thuộc bên ngoài

Quá trình phát triển

  • Clone các kho justhtml và html5lib-tests trên môi trường cục bộ, rồi tạo thư mục mới justjshtml
  • Chạy Codex CLI với tùy chọn --yolo (bỏ qua phê duyệt và sandbox) để kích hoạt mô hình GPT-5.2
  • Ở prompt đầu tiên, hệ thống được chỉ thị phân tích mã Python hiện có để viết đặc tả API JavaScript mới (spec.md)
    • Ở giai đoạn đầu (Milestone 0.5), triển khai phiên bản có thể vượt qua bài kiểm thử phân tích một tài liệu HTML đơn giản
  • Sau đó, quá trình phát triển tự động được tiếp tục theo từng bước bằng các lệnh như “Implement Milestone 0.5”, “** commit and push often**”
    • Thiết lập GitHub Actions để chạy kiểm thử trên mọi commit
    • Kết quả tạo ra tổng cộng 43 commit, 9.000 dòng mã và vượt qua 9.200 bài kiểm thử

Kết quả và sản phẩm đầu ra

  • Codex CLI đã sử dụng tổng cộng 2.089.858 token, và được thực hiện mà không phát sinh chi phí bổ sung ngoài gói đăng ký hàng tháng ChatGPT Plus
  • Thư viện hoàn thiện bao gồm các tính năng sau
    • Mở rộng API như stream(), query()/matches(), toMarkdown()
    • Script kiểm thử đơn vị không phụ thuộc và tích hợp CI
    • Khắc phục các lỗi chi tiết như lỗi xử lý thẻ <br>
  • playground.html được tạo tự động để có thể thử nghiệm trực tiếp trong trình duyệt
  • README.md bao gồm cách sử dụng, quy trình build, cùng ví dụ cho môi trường Node.js và HTML

Hàm ý từ việc sử dụng LLM

  • GPT-5.2 đã hoàn thành hàng trăm lần gọi công cụ và nhiều giờ làm việc liên tục với mức giám sát tối thiểu
  • Khi có thể định nghĩa bài toán theo hướng kiểm thử dẫn dắt, coding agent có thể tự động tạo ra mã với mức độ hoàn thiện cao
  • Những tác vụ có cấu trúc như port giữa các ngôn ngữ là loại công việc mà LLM thực hiện rất hiệu quả
  • Chi phí tạo mã trên thực tế đã giảm xuống mức “gần như miễn phí”, dù chi phí duy trì mã đã được xác minh vẫn còn tồn tại

Những câu hỏi đạo đức và pháp lý được đặt ra

  • Khả năng vi phạm bản quyền đối với mã nguồn Rust và Python gốc
  • Vấn đề quyền sở hữu bản quyền đối với mã do LLM tạo ra
  • Tác động của kiểu phát triển này đối với hệ sinh thái mã nguồn mở
  • Độ tin cậy của mã sinh tự động và trách nhiệm khi dùng trong production
  • Khả năng so sánh chất lượng với mã do chuyên gia con người phát triển trong nhiều tháng

Kết luận

  • Trường hợp này cho thấy một giai đoạn mới của tự động hóa lập trình, đồng thời chứng minh tiềm năng ứng dụng thực tiễn của AI coding agent
  • Đồng thời, nó cũng để lại bài toán về sự cần thiết phải thiết lập chuẩn mực pháp lý và đạo đức, cũng như định nghĩa lại cách cộng tác trong mã nguồn mở

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-12-19
Ý kiến trên Hacker News

  • Điểm thú vị nhất trong trường hợp này là các dự án port thư viện dựa trên test độc lập với ngôn ngữ nay đã trở nên khả thi hơn nhiều trong thực tế
    Cốt lõi là bộ hơn 9.000 bài kiểm tra parser HTML5 có tên html5lib-tests. html5ever của Servo (Rust), JustHTML của Emil (Python), và cả phiên bản JavaScript của tôi đều dùng bộ test này
    Có thể dùng coding agent để port mã Python sang JavaScript rồi tự động lặp lại cho đến khi vượt qua toàn bộ test
    Những bộ test chuẩn hóa như vậy không phổ biến, nhưng ở nơi chúng tồn tại, chúng cho thấy tiềm năng rất lớn

    • Khi kết hợp đặc tả WHATWG với html5lib test thì còn mạnh hơn nhiều
      Hôm qua tôi đã tạo được một phiên bản có kiểu tường minh bằng OCaml chỉ trong vài giờ, và đang để agent tự động build một validator HTML5 thuần OCaml
      Tôi đang kết hợp html5lib test với validator test để tạo một HTML5 validator OCaml ít phụ thuộc
      Cảm giác này giống như kiểm chứng hình thức ngược — hội tụ từ những dữ kiện rời rạc (test) thành một đặc tả có cấu trúc
    • Hôm qua khi port từ Python sang Rust, LLM hoàn toàn không bắt được vấn đề. Cuối cùng, chỉ cần sao chép bản gốc Python vào dự án Rust để so sánh là giải quyết được ngay
      Có vẻ nó khá mạnh ở đối sánh mẫu giữa các ngôn ngữ. Nhìn từ góc độ latent space thì điều này cũng hợp lý
    • Bước tiếp theo có lẽ sẽ là chuyển các test phụ thuộc vào dự án sang định dạng độc lập, xác minh với bản gốc rồi mới port
    • LLM rất mạnh trong việc port giữa các ngôn ngữ. Ở những benchmark như MLE-Bench, agent đã đạt mức có thể giải các cuộc thi Kaggle trong nhóm đoạt huy chương trong vòng 24 giờ
      Với các bài như AI4AI, có cảm giác thời đại AI tạo ra AI đã thực sự bắt đầu
    • Vì lý do đó, hiện tại tôi quyết định không công khai test của dự án này. Bình thường tôi vẫn phát hành mã nguồn mở, nhưng lần này đang cân nhắc lại

  • Thực ra parser HTML5 của Firefox ban đầu được viết bằng Java, rồi sau đó được chuyển bán tự động sang C++ cho Gecko
    Việc port JustHTML tự nó là một thử nghiệm hay, nhưng cá nhân tôi nghĩ chuyển mã Java sang TypeScript có lẽ sẽ hiệu quả hơn

    • Điều đáng ngạc nhiên là parser Java của Firefox vẫn còn được duy trì
      Nhìn vào thư mục liên quan và các commit gần đây, có thể thấy vẫn có cập nhật cả trong tháng 11
    • Có nhiều cách tốt hơn, nhưng tôi thích thiết kế API của Emil nên đã lấy JustHTML làm nền tảng
      Thật thú vị khi thử port sang Python trong một buổi tối một thư viện mà anh ấy đã xây dựng qua hơn 1.000 commit
    • Xét từ góc độ pháp lý, mã đã được port sang ngôn ngữ khác vẫn là tác phẩm phái sinh
      Nếu là giấy phép MIT thì vẫn phải giữ nguyên thông báo bản quyền và nội dung giấy phép của bản gốc
      Nói cách khác, đúng ra nên thêm thông tin bản quyền của mình bên dưới dòng bản quyền của tác giả gốc
    • Về mặt debug và audit, tôi cho rằng viết bằng JavaScript sẽ tốt hơn
      Ưu điểm của TypeScript là cải thiện trải nghiệm lập trình viên, nhưng với mã do máy tạo ra thì nhu cầu đó giảm đi

  • Về câu nói “code gần như miễn phí”, chi phí thực sự nằm ở việc con người có thể hiểu và sửa được mã đó hay không
    Ngay cả mã do LLM tạo ra, khi gặp bug phức tạp hay vấn đề ngữ cảnh thì cuối cùng vẫn cần con người can thiệp

    • Nhưng cũng có thể một ngày nào đó sẽ đến thời điểm việc làm mới rẻ và nhanh hơn bảo trì

  • Kết quả test trong kho lưu trữ gốc cho thấy nó đã vượt qua toàn bộ 9.000 bài test của html5lib-tests
    Tuy nhiên mỗi trình duyệt lại xử lý khác nhau. Ví dụ, selectolax chỉ đạt 68% theo chuẩn html5lib, nhưng nếu so với Chrome thì lại khớp hơn 90%

    • Đây là vấn đề xử lý namespace. <svg title> là một thẻ dành riêng cho SVG, nên parser phải nhận diện được điều đó
      Có lẽ cũng sẽ rất thú vị nếu chạy test ngay trên Chrome

  • Điều này cũng liên hệ về mặt bối cảnh với bài viết gần đây trên HN "Chi phí phần mềm đã giảm 90%"

    • Tuy vậy, bài đó là một lập luận đã được đơn giản hóa. Thí nghiệm của Simon khả thi được là nhờ có 9.000 test độc lập với ngôn ngữ và thiết kế API sẵn có
      Phần lớn dự án không có các điều kiện như vậy nên rất khó khái quát hóa

  • Về vấn đề bản quyền và đạo đức, tôi đang dùng Claude Code để port các dự án giấy phép MIT sang bản Rust/Python
    Tôi nghĩ tinh thần của mã nguồn mở là cải tiến mã có sẵn để phát triển hệ sinh thái
    Tuy vậy, tôi tuyệt đối không port dự án GPL

    • Dù là giấy phép nào thì bản quyền vẫn phải được tôn trọng, và bản port do LLM tạo ra cũng được xem là tác phẩm phái sinh
    • Các lập trình viên chọn GPL là có chủ đích rõ ràng, nên việc dùng LLM để lách giấy phép là làm tổn hại đến tinh thần đó

  • Cũng có ý kiến chỉ trích rằng “sau khi làm bằng cách này rồi mới hỏi về vấn đề pháp lý và đạo đức thì thật vô trách nhiệm”

    • Nhưng tôi đã cố ý chấp nhận rủi ro phần nào để khơi mào cuộc thảo luận này
      Hiện tại, tôi nghĩ điều quan trọng là cho thấy chuyện này “không chỉ khả thi mà còn dễ đến đáng kinh ngạc”

  • Dùng cách tiếp cận oracle thì vẫn thực dụng ngay cả khi không có test chuẩn
    Có thể ghi lại input/output của chương trình gốc để dùng làm test, rồi dùng các công cụ như Hypothesis để tự động sinh ra hàng nghìn trường hợp
    Giờ đây dường như chúng ta đang bước vào thời kỳ mà thay vì codebase, chính test suite mới là tài sản cốt lõi

    • Thậm chí tôi còn nghĩ liệu có thể xây cả ứng dụng chỉ từ test hay không

  • GPT-5.2 tốn $28.31 để sinh ra 9.000 dòng mã JavaScript hoàn chỉnh
    Với mức hiệu quả này, có lẽ trong 5–10 năm tới vai trò của lập trình viên junior và mid-level sẽ giảm đi đáng kể
    Xem liên kết tính chi phí

    • Tuy nhiên đây là một trường hợp lý tưởng của việc port một dự án sẵn có. Tạo một thư viện mới từ đầu vẫn là chuyện khác
      Dù vậy, với những ngôn ngữ có hệ sinh thái nhỏ, thay đổi kinh tế sẽ rất lớn
    • Khái niệm “software engineer” sẽ không biến mất, chỉ là vai trò và kỳ vọng sẽ thay đổi
    • Cũng có phản bác rằng “đâu phải cả ngày chúng ta chỉ làm việc port ngôn ngữ”. Thực tế phức tạp hơn nhiều

  • Không phải mọi ca port bằng AI đều thành công. Cũng có các trường hợp thất bại → The port I couldn’t ship

    • Thành công hay thất bại phụ thuộc rất lớn vào tỷ lệ giữa mã nguồn và test
      Nếu tích lũy được dữ liệu về dự án nào dễ hơn, cách tiếp cận nào nhanh hơn, thì đó sẽ là một phân tích rất thú vị
      Nếu Simon làm những thí nghiệm so sánh như vậy thì sẽ thực sự rất đáng xem