Tại sao tôi dừng phát triển framework JavaScript sau 1.500 dòng đặc tả

Tác giả chia sẻ câu chuyện về việc xây dựng một framework JavaScript mới với ý tưởng tối giản chỉ cần hai lần import, dùng trình biên dịch làm phần lớn công việc và mô hình islands giữ cho chi phí JavaScript hợp lý. Tuy nhiên, sau khi hoàn thành một bản đặc tả dài 1.500 dòng, tác giả quyết định dừng dự án, rút ra những bài học quan trọng về sự khác biệt giữa thiết kế ý tưởng và xây dựng một sản phẩm thực sự có thể sử dụng.

Bảng tính "ác mộng" và thực tế phát triển framework

Tác giả liệt kê chi tiết các thành phần cần phát triển để có một MVP framework hoàn chỉnh:

• Trình biên dịch đa module (2 lượt phân tích): 4-6 tháng
• Runtime tín hiệu reactive (signal, derived, effect): 2-3 tháng
• Cơ chế .mut() tương tự Immer: 1-2 tháng
• Hydration engine: 2-3 tháng
• Pipeline Server-Side Rendering (SSR): 2-3 tháng
• Proxy hàm server và bảo vệ CSRF: 1-2 tháng
• Router tập tin + layout + middleware: 1-2 tháng
• Biến đổi DOM cho navigation: 1-2 tháng
• CSS scoping + dead code elimination: 1-2 tháng
• HMR giữ trạng thái signal: 1-2 tháng
• CLI + server phát triển + overlay lỗi: 1 tháng
• Kiểu TypeScript không plugin: 1 tháng

Tổng cộng ước tính khoảng 18-29 tháng làm việc toàn thời gian, tức với người có công việc chính sẽ mất từ 3-5 năm nếu làm ngoài giờ.

Câu chuyện đằng sau các framework nổi tiếng

Tác giả kể lại ví dụ thành công của nhiều framework hiện nay:

• Svelte: Rich Harris và đội ngũ hơn 5 người, được Vercel tài trợ, phát triển suốt 7 năm.
• Solid: Ryan Carniato phát triển 5 năm ngoài giờ với sự hỗ trợ của Netlify.
• Astro: Được xây dựng bởi Fred K. Schott cùng nhóm 10+ kỹ sư, với vốn đầu tư mạo hiểm.
• Qwik: Sáng lập bởi Misko Hevery (người tạo Angular), cùng đội ngũ chuyên nghiệp.

Điểm chung là mỗi framework thành công đều có tổ chức, đội nhóm, nguồn lực tài chính và cộng đồng hỗ trợ mạnh mẽ.

Cạm bẫy của “80% tính năng”

Tác giả cảnh báo rằng chỉ làm được 80% tính năng thử nghiệm không có nghĩa là framework có thể dùng được. Các framework không thể “giảm cấp” linh hoạt mà hoặc chạy tốt hoặc không. Mỗi dự án đều có những trường hợp biên mà nếu không xử lý kỹ sẽ khiến framework không khả dụng.

Vấn đề hệ sinh thái

Một framework “trống rỗng” về hệ sinh thái sẽ không thể sống sót vì:

• Không có thư viện xác thực, UI, hoặc backend tích hợp sẵn
• Không có adapter triển khai trên các nền tảng phổ biến như Vercel, Netlify
• Thiếu công cụ theo dõi lỗi, phân tích sử dụng

Vòng lặp “không có người dùng nên không có library, không có library nên không có người dùng” chính là rào cản lớn.

Các bài học sâu sắc từ trải nghiệm thực tế

1. Mỗi API “phức tạp” đều có lý do
   Ví dụ như Svelte dùng $derived() để biểu thị rõ ràng các giá trị phụ thuộc thay vì tự động, nhằm tránh lỗi khó hiểu và giúp lập trình viên, công cụ hiểu rõ hành vi.

2. Các trường hợp biên mới là sản phẩm thực sự
   Framework được đánh giá không chỉ qua chức năng tiêu chuẩn mà quan trọng là cách xử lý các edge case phức tạp như DOM bị sửa đổi ngoài luồng, vòng lặp phụ thuộc, khác biệt môi trường server/client…

3. Compiler là con dao hai lưỡi
   Framework dựa trên compiler đem lại hiệu năng và trải nghiệm dev tốt, nhưng tăng đáng kể độ khó trong gỡ lỗi, tương thích tooling, khả năng đóng góp từ cộng đồng.

4. Thiết kế API dễ dàng, phát triển cộng đồng và duy trì khó hơn gấp bội
   Cộng đồng, tài liệu, hướng dẫn, giải pháp bảo mật, quản lý lỗi là phần lớn công việc phía sau thành công.

5. Hiểu cách hoạt động của framework không lãng phí
   Việc khảo sát, viết đặc tả giúp tác giả hiểu sâu hơn các trade-off của React, Svelte hay Astro, từ đó nâng cao trình độ và cách dùng framework hiện có.

6. Đôi khi đặc tả chính là sản phẩm
   Phân tích kỹ lưỡng các cân bằng giữa hiệu năng và trải nghiệm lập trình là bài học quý hơn rất nhiều so với việc dừng dự án để tránh rủi ro lớn.

Những lời khuyên cho người muốn làm framework

• Bắt đầu bằng một bằng chứng ý tưởng (proof-of-concept) đơn giản trước khi viết đặc tả chi tiết.
• Giới hạn scope cho MVP chỉ với một ý tưởng cốt lõi thay vì quá nhiều tính năng cùng lúc.
• Tìm ít nhất một người đồng hành để thử nghiệm và góp ý.
• Viết blog, chia sẻ ý tưởng và nhận phản hồi từ cộng đồng sớm thay vì giữ riêng đặc tả.

Kết luận

Dù dự án không bao giờ thành framework hoàn chỉnh, tác giả đã thu được kiến thức quý báu về kỹ thuật web nâng cao, giúp nhìn nhận các framework hiện tại sâu sắc và sử dụng chúng hiệu quả hơn.

Ẩn sau mỗi dòng code chưa viết là một hành trình học hỏi, và có thể, mã nguồn tốt nhất chính là mã mà bạn biết khi nào nên không đưa ra sản phẩm.

---

Bài viết gốc đăng trên maryanmats.com, đây là phần 3 trong chuỗi 3 phần trình bày tầm quan trọng của việc hiểu rõ framework trước khi phát triển.