Bài viết này chia sẻ thông tin chi tiết về cách bạn có thể chọn một thư viện hoặc khung để sử dụng trong ứng dụng web của mình. Nội dung thảo luận trong bài viết này sẽ giúp bạn cân nhắc ưu và nhược điểm để tìm thư viện hoặc khung JavaScript phù hợp với vấn đề kinh doanh mà bạn đang cố gắng giải quyết. Hiểu rõ ưu và nhược điểm áp dụng trong các tình huống khác nhau là chìa khoá để xem xét số lượng lớn các lựa chọn thư viện JavaScript hiện có.
Thư viện và khung JavaScript là gì?
Thư viện JavaScript là gì? Ở dạng đơn giản nhất, thư viện JavaScript là mã được viết sẵn mà bạn có thể gọi trong mã của dự án để thực hiện một nhiệm vụ cụ thể.
Bài đăng này chủ yếu đề cập đến "thư viện". Tuy nhiên, nhiều nội dung thảo luận cũng áp dụng cho các khung. Về cơ bản, sự khác biệt giữa hai loại này có thể được tóm tắt như sau:
- Đối với thư viện, mã xử lý ứng dụng sẽ gọi mã thư viện.
- Đối với khung, mã xử lý ứng dụng của bạn được khung gọi.
Các ví dụ thực tế sau đây giúp minh hoạ sự khác biệt.
Ví dụ về lệnh gọi đến thư viện JavaScript
Thư viện JavaScript thực hiện một tác vụ cụ thể rồi trả lại quyền kiểm soát cho ứng dụng của bạn. Khi sử dụng thư viện, bạn kiểm soát luồng ứng dụng và chọn thời điểm gọi thư viện.
Trong ví dụ sau, mã xử lý ứng dụng nhập một phương thức từ thư viện lodash. Sau khi hàm hoàn tất, quyền kiểm soát sẽ được trả về ứng dụng của bạn.
import capitalize from 'lodash.capitalize';
capitalize('hello'); // Hello
Khi phương thức lodash.capitalize được thực thi, phương thức này sẽ gọi mã JavaScript được viết sẵn để viết hoa ký tự đầu tiên của một chuỗi.
Ví dụ về cách sử dụng khung JavaScript
Khung JavaScript là một mẫu mã được xác định trước, trong đó bạn xây dựng hành vi của ứng dụng. Tức là khi bạn sử dụng một khung, khung đó sẽ kiểm soát luồng ứng dụng. Để sử dụng một khung, bạn viết mã xử lý ứng dụng tuỳ chỉnh, sau đó khung sẽ gọi mã xử lý ứng dụng của bạn.
Ví dụ sau đây cho thấy một đoạn mã sử dụng khung JavaScript Preact:
import { createElement } from 'preact';
export default function App() {
return (
<p class="big">Hello World!</p>
)
}
Trong ví dụ này, hãy lưu ý rằng khung có nhiều quyền kiểm soát hơn đối với mã bạn viết và trong một số trường hợp, khung thậm chí còn kiểm soát thời điểm thực thi mã của bạn.
Tại sao nên sử dụng thư viện?
Việc sử dụng thư viện JavaScript có thể giúp tránh lặp lại mã không cần thiết. Thư viện có thể tóm tắt logic phức tạp, chẳng hạn như thao tác với ngày hoặc tính toán tài chính. Thư viện cũng có thể giúp bạn phát hành sản phẩm ban đầu thay vì phải viết tất cả mã từ đầu, việc này có thể mất thời gian.
Một số thư viện JavaScript phía máy khách giúp loại bỏ những điểm khác biệt của nền tảng web. Thư viện cũng có thể đóng vai trò là một công cụ học tập. Ví dụ: nếu bạn không quen thuộc với hàm làm mượt ảnh động, thì mã nguồn của thư viện có thể hướng dẫn bạn cách hoạt động của các hàm làm mượt đó.
Một số thư viện được các công ty lớn hỗ trợ, đầu tư thời gian và tiền bạc để luôn cập nhật và bảo mật thư viện. Nhiều thư viện đi kèm với tài liệu chi tiết, giúp bạn và nhóm của bạn nhanh chóng làm quen với cách sử dụng thư viện.
Cuối cùng, việc sử dụng thư viện JavaScript sẽ giúp bạn tiết kiệm thời gian.
Tại sao bạn nên quan tâm đến việc sử dụng thư viện?
Về mặt kỹ thuật, bạn có thể phát triển ứng dụng web từ đầu, nhưng tại sao phải làm vậy khi bạn có thể sử dụng phần mềm miễn phí (mã nguồn mở) hoặc mua một giải pháp có thể giúp bạn tiết kiệm thời gian và tiền bạc về lâu dài? Có rất nhiều thư viện và khung JavaScript, mỗi thư viện và khung đều có cách tiếp cận riêng để giải quyết vấn đề và có các đặc điểm khác nhau. Ví dụ:
- Thư viện có thể được viết và duy trì nội bộ thay vì do bên thứ ba thực hiện.
- Một thư viện có thể có các giấy phép pháp lý cụ thể khiến thư viện đó phù hợp hoặc không phù hợp với ứng dụng web của bạn.
- Thư viện có thể đã lỗi thời hoặc không được duy trì.
- Thư viện có thể đơn giản hoá một loạt nhiệm vụ phức tạp, giúp bạn tiết kiệm nhiều thời gian và tiền bạc.
- Một thư viện có thể được sử dụng rộng rãi trong cộng đồng và được các nhà phát triển biết đến.
Như bạn có thể đoán, các đặc điểm khác nhau có thể ảnh hưởng đến ứng dụng web của bạn theo nhiều cách. Đôi khi, quyết định không quá phức tạp và bạn có thể yên tâm hoán đổi thư viện nếu không thích. Tuy nhiên, đôi khi một thư viện có thể ảnh hưởng đáng kể đến công việc và ứng dụng web của bạn, cho thấy rằng bạn có thể cần một phương pháp tiếp cận sáng suốt hơn.
Có một số môi trường JavaScript không phải phía máy khách, chẳng hạn như trên máy chủ (chạy trong môi trường đám mây) hoặc trên Raspberry Pi, nơi bạn có thể cần điều chỉnh tiêu chí dùng để kiểm tra thư viện và khung.
Hiệu suất
Không nên bỏ qua ảnh hưởng của thư viện JavaScript đối với hiệu suất của ứng dụng web phía máy khách. Thư viện JavaScript lớn có thể làm gián đoạn hiệu suất tải của trang; hãy nhớ rằng mili giây tạo nên hàng triệu.
Hãy xem xét trường hợp bạn sử dụng thư viện JavaScript cho ảnh động. Một số thư viện có thể dễ dàng thêm hàng chục kilobyte và trong một số trường hợp, thậm chí là hàng trăm kilobyte. Các tài nguyên JavaScript như thế này có thể làm tăng đáng kể thời gian tải trang vì trình duyệt cần tải xuống, phân tích cú pháp, biên dịch và thực thi mã.
Thư viện JavaScript càng lớn thì hiệu suất càng ảnh hưởng đến người dùng.
Khi đánh giá hoặc sử dụng một thư viện hoặc khung JavaScript, hãy cân nhắc các đề xuất sau để cải thiện hiệu suất:
- Nếu thư viện JavaScript có kích thước lớn, hãy cân nhắc sử dụng một thư viện thay thế nhỏ hơn. Ví dụ: date-fns cung cấp nhiều chức năng với kích thước hợp lý hơn so với một số lựa chọn khác.
- Tiếp tục từ ví dụ về date-fns trước đó, chỉ nhập các hàm bạn cần, chẳng hạn như:
import { format } from 'date-fns'. Hãy nhớ kết hợp phương pháp này với tree shaking (loại bỏ mã không dùng đến) để tải trọng JavaScript tối thiểu được tạo và gửi đến người dùng. - Sử dụng các công cụ kiểm thử hiệu suất như Lighthouse để quan sát hiệu suất khi sử dụng một thư viện JavaScript nhất định. Nếu một thư viện làm tăng thêm một giây vào thời gian tải trang (đừng quên điều tiết mạng và CPU trong quá trình kiểm thử), thì bạn có thể cần phải đánh giá lại thư viện mà bạn chọn. Ngoài việc kiểm tra thời gian tải trang, hãy nhớ lập hồ sơ mọi hành vi của trang web gọi mã từ thư viện đang được đề cập. Hiệu suất tải trang không phản ánh toàn bộ vấn đề.
- Nếu tác giả thư viện hoan nghênh ý kiến đóng góp, hãy gửi ý kiến quan sát, đề xuất và thậm chí là đóng góp về hiệu suất cho dự án. Đây là nơi cộng đồng nguồn mở toả sáng! Nếu quyết định đóng góp, bạn có thể cần phải kiểm tra trước với công ty của mình.
- Sử dụng công cụ theo dõi gói tự động, chẳng hạn như bundlesize, để theo dõi các bản cập nhật lớn bất ngờ cho thư viện. Thông thường, thư viện JavaScript sẽ phát triển theo thời gian. Việc bổ sung tính năng, bản sửa lỗi, xử lý trường hợp hiếm gặp và các trường hợp khác đều có thể làm tăng kích thước tệp của thư viện. Sau khi bạn/nhóm của bạn đồng ý sử dụng một thư viện, việc cập nhật thư viện có thể ít gặp vấn đề hơn và có thể không có câu hỏi nào. Đây là lúc bạn nên dựa vào tính năng tự động hoá.
- Hãy xem xét các yêu cầu của bạn đối với một thư viện và đánh giá xem nền tảng web có cung cấp chức năng tương tự theo cách gốc hay không. Ví dụ: nền tảng web đã cung cấp công cụ chọn màu, giúp bạn không cần sử dụng thư viện JavaScript của bên thứ ba để triển khai cùng một chức năng.
Bảo mật
Việc sử dụng mô-đun của bên thứ ba tiềm ẩn một số rủi ro bảo mật. Một gói độc hại trong toàn bộ mã nguồn của ứng dụng web có thể xâm phạm tính bảo mật của cả nhóm phát triển và người dùng.
Hãy xem xét một thư viện được phát hành cho hệ sinh thái NPM. Gói như vậy có thể là hợp lệ. Tuy nhiên, theo thời gian, gói này có thể bị xâm phạm.
Sau đây là một số mẹo bảo mật cần cân nhắc khi sử dụng hoặc đánh giá mã của bên thứ ba:
- Nếu bạn sử dụng GitHub, hãy cân nhắc các dịch vụ bảo mật của mã, chẳng hạn như Dependabot. Hoặc, hãy cân nhắc các dịch vụ thay thế quét tìm lỗ hổng bảo mật trong mã của bạn, chẳng hạn như snyk.io.
- Hãy cân nhắc sử dụng dịch vụ kiểm tra mã, một nhóm kỹ sư có thể kiểm tra thủ công mã của bên thứ ba mà bạn đang sử dụng.
- Đánh giá xem bạn có nên khoá các phần phụ thuộc vào một phiên bản cụ thể hay không, hoặc cam kết mã của bên thứ ba trong hệ thống quản lý phiên bản của bạn. Điều này có thể giúp khoá phần phụ thuộc của bạn vào một phiên bản cụ thể (được cho là an toàn). Trớ trêu thay, điều này có thể gây ra tác dụng ngược về mặt bảo mật, vì bạn có thể bỏ lỡ các bản cập nhật quan trọng cho thư viện.
- Quét trang chủ của dự án hoặc trang GitHub (nếu có). Nghiên cứu xem có vấn đề bảo mật nào chưa được giải quyết hay không và liệu các vấn đề bảo mật trước đó có được giải quyết trong khung thời gian hợp lý hay không.
- Mã của bên thứ ba sử dụng mã khác của bên thứ ba có thể mang lại nhiều rủi ro hơn so với thư viện không có phần phụ thuộc. Hãy lưu ý đến rủi ro này.
Hỗ trợ tiếp cận
Bạn có thể thắc mắc về mối liên hệ giữa thư viện phần mềm và khả năng hỗ trợ tiếp cận web. Mặc dù thư viện phần mềm có thể được dùng trong nhiều môi trường, nhưng trong bối cảnh của thư viện dựa trên JavaScript phía máy khách, khả năng hỗ trợ tiếp cận web có tầm quan trọng cao.
Thư viện dựa trên JavaScript phía máy khách (hoặc khung, cho vấn đề đó) có thể tăng hoặc giảm khả năng hỗ trợ tiếp cận của trang web. Hãy xem xét một thư viện JavaScript của bên thứ ba thêm thanh trượt hình ảnh vào một trang. Nếu thanh trượt hình ảnh không tính đến khả năng hỗ trợ tiếp cận web, thì bạn (với tư cách là nhà phát triển web) có thể bỏ qua một tính năng quan trọng như vậy và phát hành một sản phẩm thiếu các tính năng quan trọng, chẳng hạn như thanh trượt có thể điều hướng bằng bàn phím!
- Trình bổ trợ kiểu chữ thích ứng có hỗ trợ người dùng phóng to hoặc thu nhỏ trang không?
- Trình bổ trợ tải tệp lên có hỗ trợ tải tệp lên từ thiết bị hỗ trợ không?
- Thư viện ảnh động có hỗ trợ người dùng muốn giảm chuyển động không?
- Trình bổ trợ bản đồ tương tác có hỗ trợ việc chỉ sử dụng bàn phím không?
- Thư viện trình phát âm thanh có mang lại trải nghiệm phù hợp trên trình đọc màn hình không?
Bạn, với tư cách là nhà phát triển web, cần phải tham gia ở một mức độ nhất định để đáp ứng các yêu cầu về hỗ trợ tiếp cận đó. Ví dụ:
- Đối với mọi tính năng còn thiếu, bạn có thể triển khai các tính năng đó trong toàn bộ mã nguồn của mình, ngay cả khi tiếp tục sử dụng thư viện đang đề cập.
- Với sự hỗ trợ của nhà tuyển dụng, bạn có thể đóng góp một tính năng còn thiếu như vậy cho thư viện, nếu tác giả thư viện cho phép đóng góp như vậy.
- Bạn có thể mở một hộp thoại với tác giả thư viện. Ví dụ: các tính năng hỗ trợ tiếp cận cụ thể này có nằm trong lộ trình của bạn không? Bạn có đồng ý rằng những bức ảnh này nên được đưa vào thư viện không?
- Đối với các trường hợp sử dụng phổ biến, bạn có thể khám phá các lựa chọn thư viện thay thế dễ tiếp cận hơn; chúng có thể tồn tại nhưng khó tìm hơn.
- Trong trường hợp cực đoan, bạn có thể cần phải loại bỏ hoàn toàn một thư viện và triển khai các tính năng từ đầu. Điều này có thể xảy ra khi một thư viện hoặc khung có trải nghiệm hỗ trợ tiếp cận bị suy giảm trong lần sử dụng đầu tiên và bạn cần huỷ nhiều nội dung mà thư viện hoặc khung đó được cho là cung cấp miễn phí cho bạn.
Hội nghị
Thư viện phần mềm sử dụng quy ước lập trình đã thiết lập sẽ dễ làm việc hơn. Nếu một thư viện sử dụng quy ước lập trình chưa từng được biết đến, thì bạn và nhóm của bạn có thể gặp khó khăn khi làm việc với thư viện đó.
Nếu một thư viện không tuân theo các quy ước lập trình phổ biến (ví dụ: hướng dẫn về kiểu phổ biến), thì bạn không thể làm gì nhiều để khắc phục ngay lập tức. Tuy nhiên, bạn vẫn có một số lựa chọn:
- Hãy nhớ phân biệt giữa mã nguồn thư viện và API được hiển thị cho bạn, người dùng thư viện. Mặc dù mã nguồn nội bộ có thể sử dụng các quy ước không quen thuộc, nhưng nếu API (phần thư viện mà bạn tương tác) sử dụng các quy ước quen thuộc, thì bạn có thể không cần lo lắng.
- Nếu API thư viện không tuân theo các quy ước lập trình phổ biến, bạn có thể sử dụng mẫu thiết kế JavaScript, chẳng hạn như mẫu proxy, để gói và chứa tất cả các hoạt động tương tác với thư viện vào một tệp duy nhất trong toàn bộ mã nguồn. Sau đó, proxy của bạn có thể cung cấp một API trực quan hơn cho các phần khác của mã trong toàn bộ mã nguồn.
Quy ước đóng vai trò quan trọng trong việc giúp người dùng dễ sử dụng. Một thư viện có API trực quan có thể tiết kiệm nhiều giờ, thậm chí là nhiều ngày công so với một API không trực quan cần nhiều thử nghiệm để tìm ra.
Nội dung cập nhật
Ví dụ: một thư viện hoạt động đầy đủ và thực hiện một vài phép tính toán học có thể hiếm khi cần cập nhật. Trên thực tế, một thư viện có đầy đủ tính năng là một điều hiếm thấy trong thế giới phát triển web không ngừng thay đổi! Tuy nhiên, có những lúc bạn muốn tác giả thư viện phản hồi nhanh và sẵn sàng cập nhật. Nghiên cứu và kết quả mới có thể cho thấy những cách làm hiệu quả hơn, vì vậy, các kỹ thuật dùng trong thư viện và khung luôn có thể thay đổi.
Khi chọn một thư viện hoặc khung, hãy chú ý đến cách xử lý các bản cập nhật và lưu ý rằng những quyết định như vậy có thể ảnh hưởng đến bạn:
- Thư viện có lịch phát hành hợp lý không? Ví dụ: kho lưu trữ mã nguồn có thể được cập nhật thường xuyên, nhưng nếu các bản cập nhật đó không được "phát hành" hoặc "phát hành" tương ứng, bạn sẽ thấy khó tải các bản cập nhật đó xuống.
- Thư viện có phát hành bản cập nhật theo một lược đồ tạo phiên bản phần mềm hợp lý không? Thư viện sẽ giúp bạn tiết kiệm thời gian. Nếu bạn phải thay đổi mã ngoài dự kiến mỗi khi cập nhật phiên bản thư viện, thì điều này có thể làm mất đi mục đích sử dụng thư viện đó ngay từ đầu. Đôi khi, bạn không thể tránh khỏi những thay đổi có thể gây lỗi, nhưng trong trường hợp lý tưởng, những thay đổi này không thường xuyên xảy ra và không bắt buộc đối với người dùng thư viện.
- Thư viện có nỗ lực hướng tới khả năng tương thích ngược không? Đôi khi, các bản cập nhật phần mềm có thể đi kèm với những thay đổi có thể gây lỗi, nhưng cũng cung cấp một lớp tương thích ngược. Điều này cho phép người dùng thư viện sử dụng phiên bản thư viện mới nhất mà không cần thay đổi nhiều mã.
Cấp phép
Cấp phép phần mềm là một khía cạnh quan trọng khi sử dụng thư viện phần mềm của bên thứ ba. Tác giả thư viện có thể chỉ định giấy phép cho thư viện của họ. Nếu bạn đang cân nhắc sử dụng thư viện, thì lựa chọn giấy phép của họ có thể ảnh hưởng đến bạn.
Ví dụ: một thư viện JavaScript có thể có giấy phép phần mềm cho phép bạn sử dụng thư viện đó trong môi trường phi thương mại. Đối với một dự án cá nhân theo sở thích, đây có thể là một lựa chọn tuyệt vời. Nếu dự án của bạn có yếu tố thương mại, thì bạn có thể cần cân nhắc giấy phép doanh nghiệp.
Nếu bạn còn băn khoăn, hãy cân nhắc việc tham khảo ý kiến tư vấn pháp lý của chuyên gia hoặc tham khảo ý kiến của nhóm pháp lý trong công ty của bạn.
Cộng đồng
Một thư viện hoặc khung có cộng đồng người dùng/người đóng góp lớn có thể mang lại lợi ích, nhưng điều này không được đảm bảo. Nhìn chung, thư viện hoặc khung càng có nhiều người dùng thì càng có nhiều khả năng hưởng lợi. Hãy cân nhắc những ưu và nhược điểm sau đây khi tham gia vào một cộng đồng phát triển:
Ưu điểm:
- Cơ sở người dùng lớn có thể đồng nghĩa với việc có nhiều cơ hội phát hiện lỗi sớm và thường xuyên hơn.
- Một cộng đồng lớn và năng nổ có thể mang đến nhiều bài hướng dẫn, tài liệu hướng dẫn, video và thậm chí là các khoá học về thư viện hoặc khung đang được đề cập.
- Một cộng đồng lớn và hoạt động tích cực có thể mang lại nhiều sự hỗ trợ hơn trên các diễn đàn và trang web hỏi và đáp, giúp tăng khả năng các câu hỏi hỗ trợ được giải đáp.
- Một cộng đồng gắn kết có thể thu hút thêm nhiều người đóng góp bên ngoài cho thư viện hoặc khung. Họ có thể giúp cung cấp các tính năng không có trong lộ trình của tác giả.
- Khi một thư viện hoặc khung phổ biến trong một cộng đồng, thì nhiều khả năng đồng nghiệp của bạn sẽ biết đến hoặc thậm chí quen thuộc với thư viện hoặc khung đó.
Nhược điểm:
- Một dự án có cơ sở người dùng lớn và đa dạng có thể trở nên cồng kềnh do liên tục bổ sung tính năng. Thư viện quá tải có thể gây hại cho hiệu suất của trang web.
- Một dự án có cộng đồng tích cực và gắn kết có thể gây áp lực cho tác giả và người duy trì, đồng thời có thể cần đến hoạt động kiểm duyệt cộng đồng nghiêm ngặt.
- Một dự án phát triển nhanh chóng nhưng không có sự hỗ trợ thích hợp có thể bắt đầu có dấu hiệu của một cộng đồng độc hại. Ví dụ: nhà phát triển web mới vào nghề hoặc mới bắt đầu có thể cảm thấy không được chào đón trong một cộng đồng nhất định do hành vi kiểm soát quyền truy cập.
Tài liệu
Dù thư viện hoặc khung JavaScript đơn giản hay phức tạp đến đâu, tài liệu về phần mềm luôn có thể giúp ích. Ngay cả những nhà phát triển có nhiều kinh nghiệm cũng sử dụng tài liệu thay vì tự tìm hiểu mã. Tài liệu này làm rõ API bạn nên sử dụng và cách sử dụng API đó.
Tài liệu thậm chí có thể cung cấp mã mẫu, giúp bạn dễ dàng bắt đầu nhanh chóng. Khi đánh giá một thư viện hoặc khung, bạn có thể đặt một số câu hỏi sau:
- Thư viện có tài liệu hướng dẫn không? Nếu không, bạn cần phải tự tìm hiểu.
- Tài liệu có rõ ràng, dễ hiểu và không mơ hồ không? Nhiều nhà phát triển dành nhiều thời gian cho tài liệu. Điều này có vẻ nhỏ, nhưng sự rõ ràng trong tài liệu văn bản có thể ảnh hưởng lớn đến năng suất của bạn.
- Tài liệu có được tạo hoàn toàn tự động không? Tài liệu như vậy có thể khó hiểu hơn và không phải lúc nào cũng cung cấp hướng dẫn rõ ràng về cách sử dụng API.
- Tài liệu có được cập nhật không? Việc duy trì tài liệu đôi khi bị xem nhẹ. Nếu thư viện được cập nhật nhưng tài liệu thì không, thì điều này có thể khiến bạn lãng phí thời gian phát triển.
- Tài liệu có đầy đủ và có nhiều định dạng không? Hướng dẫn sử dụng, mã mẫu, tài liệu tham khảo, bản minh hoạ trực tiếp và hướng dẫn đều là những định dạng tài liệu hữu ích có thể giúp bạn sử dụng thành công thư viện hoặc khung.
Tài liệu không phải lúc nào cũng đầy đủ và điều đó không sao cả. Bạn cần đánh giá nhu cầu của tổ chức, yêu cầu của dự án và độ phức tạp của phần mềm, sau đó sử dụng thông tin đó để xác định mức độ tài liệu cần thiết.
Kết luận
Việc cảm thấy choáng ngợp khi chọn thư viện hoặc khung lần đầu tiên là điều bình thường. Cũng giống như mọi thứ khác, bạn càng học hỏi và thực hành nhiều thì bạn càng giỏi. Bạn nên tham khảo bài đăng này khi chọn thư viện hoặc khung để sử dụng vào lần tới. Bạn có thể sử dụng các tiêu đề trong bài đăng này làm danh sách kiểm tra. Ví dụ: Thư viện này có hiệu suất cao không? Thư viện này có đáp ứng các tiêu chuẩn kinh doanh của tôi về khả năng hỗ trợ tiếp cận trên web không?
Có những khía cạnh khác của thư viện và khung mà bạn có thể muốn xem xét và chưa được thảo luận nhiều trong bài đăng này:
- Khả năng mở rộng: việc mở rộng thư viện bằng logic và/hoặc hành vi tuỳ chỉnh có dễ dàng không?
- Công cụ: nếu có, thư viện có các công cụ như trình bổ trợ trình soạn thảo mã, công cụ gỡ lỗi và trình bổ trợ hệ thống xây dựng không?
- Cấu trúc: mã sạch là điều quan trọng, nhưng cấu trúc tổng thể của thư viện có hợp lý không?
- Kiểm thử: dự án có bộ kiểm thử không? Trang web của dự án có sử dụng huy hiệu hoặc chỉ báo cho biết bộ kiểm thử đang vượt qua cam kết mới nhất không?
- Khả năng tương thích: thư viện có hoạt động tốt với các thư viện và/hoặc khung khác mà bạn đang sử dụng không?
- Chi phí: chi phí của một khung là bao nhiêu? Đó là mã nguồn mở hay có thể mua được?
- Chỉ số ảo: chỉ số này nên nằm ở vị trí thấp trong danh sách tiêu chí của bạn, hoặc thậm chí bị bỏ qua hoàn toàn, nhưng bạn có thể cân nhắc "phiếu bầu" của dự án, tài khoản mạng xã hội đại diện cho dự án và/hoặc số lượng lỗi/vấn đề chưa được giải quyết trên trang dự án.