Một website tốt giống một thành phố được quy hoạch tử tế: người mới đến vẫn tìm được đường, người sống lâu trong đó không bị lạc, còn người sửa chữa có thể đào một con đường mà không làm sập cả khu phố. Mình từng nghĩ xây dựng web hiện đại chủ yếu là chọn đúng framework và biết thật nhiều thư viện. Sau vài lần làm dự án, mình nhận ra phần khó nhất là giữ cho sản phẩm còn dễ hiểu sau ngày thứ một trăm.

Với mình, Next.js, TypeScript và Tailwind CSS không phải bộ công cụ thần kỳ. Chúng chỉ thật sự hữu ích khi đi cùng một cách tư duy rõ ràng: hiểu sản phẩm cần gì, dữ liệu đi qua đâu, phần nào cần tương tác và phần nào không nên đưa xuống trình duyệt. Mỗi lựa chọn kỹ thuật đều nên giải quyết một vấn đề cụ thể, thay vì chỉ được thêm vào vì đang phổ biến.

Đừng xây thành phố trước khi biết người ta cần đi đâu

Trước khi tạo thư mục hay cài thêm package, mình thường viết ra vài câu hỏi rất đơn giản. Người dùng đến trang này để làm gì? Họ cần xem dữ liệu nào trước? Hành động quan trọng nhất là gì? Nếu mạng chậm hoặc dữ liệu chưa sẵn sàng thì giao diện nên phản ứng ra sao? Những câu hỏi này giúp mình tránh tình trạng xây một giao diện trông đẹp nhưng không giải quyết được nhu cầu thật.

App Router của Next.js cho phép mình tổ chức ứng dụng theo cấu trúc gần với cách người dùng di chuyển qua sản phẩm. Route, layout, loading state và error state có vị trí rõ ràng hơn. Server Components cũng giúp mình không phải gửi toàn bộ logic xuống trình duyệt khi một phần giao diện chỉ cần lấy dữ liệu và hiển thị. Nhưng điều đó không có nghĩa mọi thứ đều phải chạy ở server. Những phần cần tương tác, quản lý state hoặc truy cập API trình duyệt vẫn cần được thiết kế như client component một cách có chủ đích.

Mỗi dòng dữ liệu cũng có một chuyến đi

Trong quá trình làm dự án, mình từng đưa quá nhiều component xuống client chỉ vì đó là cách nhanh nhất để hết lỗi. Kết quả là bundle lớn hơn, việc theo dõi state khó hơn và có những dữ liệu lẽ ra chỉ cần xử lý ở server lại bị đẩy ra trình duyệt. Sau đó mình tập thói quen giữ phần hiển thị tĩnh và truy vấn dữ liệu ở server, chỉ tách client component ở nơi thực sự cần click, nhập liệu, animation hay tương tác theo thời gian thực.

TypeScript hỗ trợ mình rất nhiều ở ranh giới này. Khi kiểu dữ liệu của bài viết, người dùng hay kết quả API được định nghĩa rõ, mình phát hiện sai lệch sớm hơn thay vì đợi đến lúc mở một màn hình cụ thể mới thấy lỗi. TypeScript không ngăn mọi bug, nhưng nó buộc mình trả lời những câu hỏi mà JavaScript thường cho phép bỏ qua: dữ liệu này có thể không tồn tại không, giá trị này có những trạng thái nào, và component này thực sự cần nhận những thuộc tính gì?

Một giao diện đẹp là nơi người dùng không phải suy nghĩ quá nhiều

Tailwind CSS giúp mình thử giao diện nhanh, nhưng điều mình thích hơn là khả năng nhìn thấy các quyết định thiết kế ngay trong code. Khoảng cách, kích thước chữ, màu sắc và trạng thái responsive có thể được thống nhất nếu mình giữ một số quy ước từ đầu. Mình cố tránh việc mỗi màn hình dùng một sắc xám khác nhau hoặc mỗi nút có một cách bo góc khác nhau chỉ vì viết ở những thời điểm khác nhau.

Mình cũng học được rằng responsive không chỉ là thêm vài tiền tố md: và lg:. Trên màn hình nhỏ, thứ tự nội dung, kích thước vùng chạm, độ dài tiêu đề và cách hiển thị bảng dữ liệu đều cần được suy nghĩ lại. Một giao diện tốt không làm người dùng cảm thấy họ đang dùng bản thu nhỏ của desktop; nó nên được thiết kế để phù hợp với hoàn cảnh sử dụng thật.

Đừng để người dùng nghe tiếng máy móc quay bên trong

Ảnh quá nặng, truy vấn lặp lại, component hiển thị quá nhiều dữ liệu hoặc một hiệu ứng chạy liên tục đều có thể khiến sản phẩm chậm đi. Mình thường kiểm tra từng vấn đề một thay vì tối ưu theo cảm giác. Dùng đúng công cụ hiển thị ảnh, chỉ tải dữ liệu khi cần, thêm trạng thái loading rõ ràng và đo bằng công cụ trình duyệt thường đem lại kết quả thực tế hơn việc tối ưu mù quáng.

Điều quan trọng nhất sau mỗi dự án là khả năng quay lại đọc code của chính mình. Tên biến nên nói đúng ý nghĩa, component nên có phạm vi vừa phải, phần xử lý dữ liệu không nên trộn lẫn với markup quá nhiều. Khi có lỗi, mình ưu tiên tìm nguyên nhân thay vì che lỗi bằng một điều kiện tạm thời. Một hệ thống tốt không phải hệ thống không bao giờ có lỗi; đó là hệ thống cho phép mình tìm và sửa lỗi mà không sợ làm sụp cả phần còn lại.