Xây dựng 21 công cụ phát triển chỉ với HTML/CSS/JS thuần: Những bài học từ dự án DevCrate

Khoảng ba tuần trước, tôi đã ra mắt DevCrate — một bộ sưu tập gồm 21 tiện ích dành cho lập trình viên (developer utilities) chạy hoàn toàn trên trình duyệt. Không cần đăng nhập, không có backend (máy chủ), không dùng bất kỳ framework nào. Chỉ là HTML, CSS và vanilla JavaScript thuần túy.

Tôi muốn chia sẻ một cách trung thực về quá trình này, bởi hầu hết các bài viết kiểu "tôi đã xây dựng thứ này" thường làm mọi thứ nghe có vẻ suôn sẻ hơn thực tế rất nhiều.

Tại sao tôi lại xây dựng nó?

Tôi liên tục phải sử dụng cùng một công cụ mỗi ngày. Một trình định dạng JSON. Một công cụ debug JWT. Một trình tạo biểu thức Cron. Và mỗi khi tôi truy cập vào một trang web nào đó mà lại bắt tôi nhập email, hiển thị quảng cáo, hoặc gửi tải liệu API của tôi qua máy chủ của họ, tôi lại thấy bực mình và đóng tab ngay lập tức.

Vì vậy, tôi đã xây dựng phiên bản mà tôi thực sự muốn. Chạy trên trình duyệt thôi. Nhanh. Không cần tài khoản. Không theo dõi dữ liệu.

Những gì tôi nghĩ sẽ chỉ mất một cuối tuần cuối cùng lại mất đến ba tuần. Dưới đây là những thứ đã làm chậm tiến độ của tôi.

Thách thức thực sự: Tính nhất quán CSS trên 21 công cụ

Tôi expected rằng phần khó nhất sẽ là JavaScript — phân tích cú pháp JWT, engine regex, thuật toán so sánh diff. Những thứ đó đều ổn. Cái thực sự làm mòn kiên nhẫn tôi lại là việc giữ cho giao diện của 21 trang web nhất quán về mặt thị giác.

Mỗi công cụ là một tệp HTML riêng biệt. Không có hệ thống component. Không có template chia sẻ. Chỉ là một thẻ <link> tới shared.css và niềm tin rằng tôi sẽ giữ kỷ luật.

Và tôi đã không giữ được kỷ luật.

Đến công cụ thứ 8 hoặc 9, tôi bắt đầu sao chép từ bất kỳ trang nào đang mở, chỉnh sửa một chút và chuyển sang việc khác. Đến công cụ thứ 15, tôi có ba phiên bản của breadcrumb (đường dẫn) hơi khác nhau. Hai khoảng cách (spacing) khác nhau trên banner Pro. Một trang mà biến --text3 là #a07840 thay vì #ad7146. Một quy tắc nav lại bắt được phần tử breadcrumb vì cả hai đều dùng thẻ <nav> và tôi không xác định phạm vi (scope) bộ chọn CSS đúng cách.

Không có cái nào trong số này là rõ ràng cả. Chúng chỉ xuất hiện khi tôi chụp màn hình mọi trang và đặt cạnh nhau để so sánh.

Cách khắc phục không hề "hoành tráng" chút nào. Tôi chọn một trang làm tiêu chuẩn vàng, viết một script kiểm tra bằng Python để so sánh mọi trang khác với nó, và xử lý từng lỗi một. Nó còn mất nhiều thời gian hơn là xây dựng ba công cụ thực sự.

Điều tôi sẽ làm khác đi: Thiết lập một tệp mẫu (template) được khóa ngay từ ngày đầu tiên. Sao chép nó cho mọi trang mới. Không bao giờ "mượn" từ một trang đã bị lệch sang. Hãy coi nó như một component dù bạn có dùng framework hay không.

Xây dựng gói đăng ký Pro trên trang web tĩnh

DevCrate có cấp độ Pro — giá 19$/tháng thông qua Lemon Squeezy. Không có máy chủ, không có cơ sở dữ liệu, không có tài khoản người dùng. Khóa cấp phép được lưu trữ trong localStorage và giới hạn một số tính năng ở phía máy khách (client-side).

Đây không phải là kiểu bảo mật kiên cố như Fort Knox. Một người quyết tâm có thể mở DevTools và đổi giá trị đó. Tôi chấp nhận điều đó. Những người sẵn sàng làm vậy thì dù sao cũng sẽ không chịu trả tiền. Những người trả tiền chỉ muốn nó hoạt động mà thôi.

Việc kết nối với Lemon Squeezy khá đơn giản. Phần khó hơn là về UX (trải nghiệm người dùng) — điều gì sẽ xảy ra khi ai đó trả tiền trên điện thoại, sau đó mở trang web trên laptop của họ? Tôi đã xây dựng quy trình khôi phục nơi bạn nhập lại email mua hàng và khóa cấp phép để kích hoạt lại trên trình duyệt mới. Đơn giản và hiệu quả.

Từ chối Framework một cách có chủ đích

Mọi người hỏi tại sao tôi không dùng React hay một trình tạo trang tĩnh (static site generator). Câu trả lời trung thực là tôi muốn zero build tooling (không công cụ build nào). Không npm. Không webpack. Không thư mục node_modules nặng đến 300MB cho một trang web không có dependency nào.

Sự đánh đổi là có thật — tính nhất quán khó duy trì hơn khi không có component, như tôi đã học một cách đau đớn. Nhưng kết quả là một trang web có thể triển khai (deploy) chỉ bằng cách đẩy các tệp HTML lên Cloudflare Pages, tải trong dưới một giây và có điểm số Lighthouse khiến tôi tự hào.

Đối với một dự án kiểu này — nhiều công cụ nhỏ biệt lập, mỗi cái có giao diện riêng — vanilla thực sự rất phù hợp. Gánh nặng của một framework sẽ được cảm nhận trên mọi trang.

Tổng kết sau ba tuần

Trang web đã được lập chỉ mục (indexed). Nó có những đường liên kết ngược (backlink) bên ngoài đầu tiên. Một số người đang sử dụng hàng ngày dựa trên số lượt đăng ký Pro.

Vẫn còn rất nhiều việc để xây dựng — video demo YouTube, cấu hình đã lưu được đồng bộ hóa với tài khoản, một public API. Tất cả đều đã có trong lộ trình.

Nếu bạn là một lập trình viên mệt mỏi vì những công cụ dev luôn muốn lấy dữ liệu của bạn, hãy thử dùng DevCrate. Mọi thứ đều miễn phí để bắt đầu. Nếu nó giúp bạn tiết kiệm thời gian, gói Pro luôn sẵn sàng khi bạn cần.