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ác 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à khuyết điểm khi 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. Việc hiểu rõ ưu và nhược điểm của từng thư viện JavaScript trong các tình huống khác nhau là yếu tố then chốt để kiểm tra 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 để đạt được một tác 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 có thể áp dụng cho các khung làm việc. 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ã ứng dụng của bạn sẽ gọi mã thư viện.
- Đối với khung, mã ứ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 sẽ 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 được thực thi, phương thức lodash.capitalize
sẽ gọi mã JavaScript viết sẵn để viết hoa ký tự đầu tiên của 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 tạo 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ã ứng dụng tuỳ chỉnh, sau đó khung sẽ gọi mã ứ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ã.
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, điều này có thể mất nhiều thời gian.
Một số thư viện JavaScript phía máy khách giúp tóm tắt các đặc điểm kỳ quặc của nền tảng web. Thư viện cũng có thể đóng vai trò như một công cụ học tập. Ví dụ: nếu bạn không quen với các hàm làm giảm độ trễ ả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 giảm độ trễ ảnh động đó.
Một số thư viện được hỗ trợ bởi các công ty lớn đầu tư thời gian và tiền bạc vào việc đảm bảo thư viện luôn được cập nhật và bảo mật. 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 mứ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 gặp rắc rối 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ể tiết kiệm thời gian và tiền bạc về lâu dài? Hiện có rất nhiều thư viện và khung JavaScript, mỗi thư viện và khung lại có một phương pháp riêng để giải quyết vấn đề và có các đặc điểm khác nhau. Ví dụ:
- Một thư viện có thể do bên thứ ba viết và duy trì trong nội bộ thay vì một bên thứ ba.
- 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 các tác vụ phức tạp và giúp bạn tiết kiệm nhiều thời gian và tiền bạc.
- Thư viện có thể được sử dụng rộng rãi trong cộng đồng và có thể được các nhà phát triển biết đến rộng rãi.
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 này không quá phức tạp và bạn có thể hoán đổi một 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, do đó, bạn có thể cần phải áp dụng một phương pháp thông tin 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, bạn có thể cần điều chỉnh các tiêu chí dùng để kiểm tra thư viện và khung.
Hiệu suất
Bạn không nên bỏ qua hiệu suất của thư viện JavaScript đối với ứ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 trang; hãy nhớ rằng mili giây tạo ra hàng triệu giây.
Hãy xem xét một trường hợp trong đó 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í hàng trăm kilobyte. Các tài nguyên JavaScript như vậy có thể làm chậm đáng kể quá trình 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ì ảnh hưởng về hiệu suất đối với người dùng của bạn càng lớn.
Khi đánh giá hoặc sử dụng thư viện hoặc khung JavaScript, hãy xem xét các đề xuất sau để cải thiện hiệu suất:
- Đối với thư viện JavaScript 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 ở kích thước hợp lý hơn so với một số lựa chọn khác.
- Tiếp nối ví dụ về date-fns trước, hãy 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 tính năng rút gọn cây để tạo và gửi tải trọng JavaScript tối thiểu đến người dùng. - Sử dụng các công cụ kiểm tra hiệu suất như Lighthouse để quan sát hiệu quả hoạt động khi sử dụng một thư viện JavaScript nhất định. Nếu thư viện làm cho thời gian tải trang của bạn bị trễ một giây (đừng quên điều tiết mạng và CPU trong quá trình thử nghiệm), thì bạn có thể phải đánh giá lại thư viện mà mình lựa chọn. Ngoài việc kiểm tra tải trang, hãy nhớ phân tích mọi hành vi của trang web gọi mã từ thư viện có liên quan – hiệu suất tải trang không cho biết toàn bộ thông tin.
- Nếu tác giả thư viện hoan nghênh nhận xét, hãy gửi quan sát về hiệu suất, đề xuất và thậm chí là đóng góp cho dự án. Đây là điểm mạnh của cộng đồng nguồn mở! Nếu quyết định đóng góp, trước tiên, bạn nên hỏi ý kiến của người sử dụng lao động.
- 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ư viện JavaScript thường phát triển theo thời gian. Các tính năng bổ sung, bản sửa lỗi, các trường hợp hiếm gặp và những nội dung khác đều có thể làm tăng kích thước tệp của thư viện. Khi bạn/nhóm của bạn đã đồng ý sử dụng thư viện, việc cập nhật thư viện có thể ít thành vấn đề hơn và có thể đặt ra các câu hỏi ít hoặc không dễ. Đây là lúc bạn nên sử dụng tính năng tự động hoá.
- Xem xét các yêu cầu của bạn đối với thư viện và đánh giá xem nền tảng web có cung cấp chức năng tương tự hay không. Ví dụ: nền tảng web đã cung cấp một công cụ chọn màu, giúp bạn không cần phải sử dụng thư viện JavaScript của bên thứ ba để triển khai chức năng tương tự.
Bảo mật
Việc sử dụng mô-đun của bên thứ ba có một số rủi ro bảo mật cố hữu. Một gói độc hại trong cơ sở mã ứng dụng web có thể làm tổn hại đến 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.
Dưới đây là một số mẹo bảo mật mà bạn nê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 cân nhắc sử dụng các dịch vụ thay thế để quét lỗ hổng trong mã của bạn, chẳng hạn như snyk.io.
- Hãy cân nhắc việc sử dụng các dịch vụ kiểm tra mã. Đây là một nhóm kỹ sư có thể kiểm tra mã của bên thứ ba theo cách thủ công mà bạn đang sử dụng.
- Đánh giá xem bạn nên khoá các phần phụ thuộc với một phiên bản cụ thể hay cam kết mã của bên thứ ba trong phạm vi kiểm soát phiên 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 coi là an toàn. Trớ trêu thay, điều này có thể gây ra tác dụng ngược trong 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 đây đã được giải quyết trong khung thời gian hợp lý hay chưa.
- Mã của bên thứ ba sử dụng mã của bên thứ ba khác có thể gây ra nhiều rủi ro hơn so với thư viện có 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 trê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 ngữ cảnh thư viện dựa trên JavaScript phía máy khách, thì khả năng hỗ trợ tiếp cận web có tầm quan trọng cao.
Thư viện (hoặc khung) dựa trên JavaScript phía máy khách có thể làm tăng hoặc giảm khả năng hỗ trợ tiếp cận của trang web. Hãy cân nhắc một thư viện JavaScript bên thứ ba thêm một thanh trượt hình ảnh vào trang. Nếu thanh trượt hình ảnh không tính đến khả năng hỗ trợ tiếp cận trên web, thì với tư cách là nhà phát triển web, bạn 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ợ những người dùng phóng to hoặc thu nhỏ trang không?
- Trình bổ trợ trình tải tệp lên có hỗ trợ tính năng tải tệp lên từ thiết bị hỗ trợ tiếp cận không?
- Thư viện ảnh động có hỗ trợ những người dùng thích giảm chuyển động không?
- Trình bổ trợ bản đồ tương tác có hỗ trợ việc sử dụng chỉ bằ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?
Là nhà phát triển web, bạn cần phải có một mức độ tham gia nhất định để đáp ứng các yêu cầu về khả năng hỗ trợ tiếp cận như vậy. 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 cơ sở mã của mình, ngay cả khi tiếp tục sử dụng thư viện có liên quan.
- Với sự hỗ trợ của nhà tuyển dụng, bạn có thể đóng góp tính năng bị thiếu đó 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 cuộc trò chuyện với tác giả thư viện. Ví dụ: những 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 các tệp này thuộc thư viện này 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 tuỳ chọn thư viện thay thế dễ tiếp cận hơn; các tuỳ chọn này 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ị giảm sút khi sử dụng lần đầu và bạn cần huỷ bỏ nhiều nội dung mà thư viện hoặc khung đó được cho là cung cấp miễn phí cho bạn.
Quy ước
Thư viện phần mềm sử dụng quy ước lập trình đã thiết lập sẽ dễ sử dụng hơn. Nếu một thư viện dùng quy ước lập trình chưa được nghe đến, thì có thể bạn và nhóm của bạn sẽ gặp khó khăn khi làm việc với một thư viện như vậy.
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ì để khắc phục ngay lập tức. Tuy nhiên, vẫn có một vài lựa chọn:
- Hãy nhớ phân biệt giữa mã nguồn thư viện và API 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 cơ sở mã. Sau đó, proxy có thể cung cấp API trực quan hơn cho các phần khác của mã trong cơ sở mã.
Các quy ước đóng vai trò quan trọng trong việc dễ sử dụng. Một thư viện có API trực quan có thể giúp tiết kiệm nhiều giờ hoặc thậm chí là nhiều ngày so với một API phản trực quan cần nhiều thử nghiệm để tìm hiểu.
Nội dung cập nhật
Ví dụ: đối với một thư viện hoạt động đầy đủ thực hiện một số phép tính toán học, thư viện như vậy hiếm khi cần cập nhật. Trên thực tế, rất hiếm khi bạn tìm thấy một thư viện có đầy đủ tính năng trong thế giới phát triển web luôn thay đổi! Tuy nhiên, đôi khi bạn muốn tác giả thư viện phản hồi và sẵn sàng cập nhật. Nghiên cứu và phát hiện mới có thể cho thấy những cách làm tốt hơn, vì vậy, các kỹ thuật được sử 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ý 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ụ: các bản cập nhật cho kho lưu trữ mã nguồn có thể diễn ra 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" cho phù hợp, 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ã bất ngờ 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 ban đầu của việc sử dụng thư viện đó. Đôi khi, bạn không thể tránh khỏi các thay đổi có thể gây lỗi, nhưng trong trường hợp lý tưởng, các thay đổi sẽ không thường xuyên và không bắt buộc người dùng thư viện phải thực hiện.
- Thư viện có đầu tư vào khả năng tương thích ngược không? Đôi khi, bản cập nhật phần mềm có thể đi kèm với các 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 với ít thay đổi nhất cho mã của họ.
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. Đây có thể là một lựa chọn tuyệt vời cho dự án sở thích cá nhân. 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 sử dụng giấy phép doanh nghiệp.
Khi nghi ngờ, hãy cân nhắc việc xin ý kiến tư vấn pháp lý chuyên nghiệp hoặc phục vụ theo 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ó một cộng đồng lớn gồm nhiều người dùng/cộng tác viên có thể mang lại lợi ích, nhưng điều này không đảm bảo sẽ xảy ra. 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 mang lại lợi ích. Hãy cân nhắc các ư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 đồng nghĩa với việc bạn sẽ có nhiều khả năng 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 động có thể có nhiều hướng dẫn, bài viết hướng dẫn, video và thậm chí là các khoá học hơn về thư viện hoặc khung đó.
- Một cộng đồng lớn và tích cực có thể mang lại nhiều dịch vụ hỗ trợ hơn trên các diễn đàn và trang web hỏi đáp, tăng khả năng câu hỏi hỗ trợ được trả lời.
- Một cộng đồng có sự tương tác cao có thể thu hút thêm nhiều cộng tác viên bên ngoài cho thư viện hoặc khung. Họ có thể giúp phân phối các tính năng chưa có trong lộ trình phát triển của tác giả.
- Khi một thư viện hoặc khung phổ biến trong một cộng đồng, thì khả năng đồng nghiệp của bạn đã nghe nói hoặc thậm chí đã quen thuộc với thư viện hoặc khung đó sẽ tăng lên.
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 cồng kềnh có thể làm giảm hiệu suất của trang web.
- Một dự án có cộng đồng năng động và gắn kết có thể gây căng thẳng cho các tác giả và người duy trì, đồng thời có thể đòi hỏi nhiều công sức kiểm duyệt cộng đồng.
- Một dự án phát triển nhanh chóng nhưng không có biện pháp hỗ trợ phù hợp có thể bắt đầu cho thấy dấu hiệu có một cộng đồng độc hại. Ví dụ: các nhà phát triển web mới bắt đầu hay các nhà phát triển web chưa có kinh nghiệm có thể khiến họ cảm thấy không thoải mái trong một cộng đồng nhất định do "tách biệt" của tổ chức.
Tài liệu
Cho dù thư viện hoặc khung JavaScript có đơn giản hay phức tạp đến đâu, tài liệu phần mềm luôn có thể giúp ích. Ngay cả những nhà phát triển dày dạn kinh nghiệm cũng sử dụng tài liệu thay vì tự tìm hiểu mã. Tài liệu làm rõ API bạn nên sử dụng và cách sử dụng API đó.
Thậm chí, tài liệu còn có thể cung cấp mã mẫu, giúp bạn bắt đầu nhanh chóng và dễ dàng hơn. 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ó bao gồm tài liệu không? Nếu không, bạn cần phải thoải mái tự tìm hiểu mọi thứ.
- 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 rất nhiều thời gian cho việc ghi chép tài liệu. Điều này có vẻ nhỏ, nhưng sự rõ ràng trong tài liệu dạng 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ó mới nhất không? Đôi khi, việc bảo trì tài liệu được coi là việc làm sau cùng. Nếu thư viện được cập nhật nhưng tài liệu không được cập nhật, thì điều này có thể dẫn đến lãng phí thời gian phát triển.
- Tài liệu có toàn diện 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à các định dạng tài liệu có giá trị có thể giúp bạn sử dụng thành công thư viện hoặc khung chương trình.
Không phải lúc nào tài liệu cũng có thể hoàn chỉnh và điều đó là bình thường. 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 những thông tin đó để xác định mức độ tài liệu bạn cần.
Kết luận
Việc cảm thấy choáng ngợp khi chọn một thư viện hoặc khung lần đầu tiên là điều bình thường. Giống như mọi thứ khác, bạn càng tìm hiểu và thực hành một nhiệm vụ thì bạn càng giỏi hơn. Bạn nên tham khảo bài đăng này vào lần tiếp theo chọn thư viện hoặc khung để sử dụng. 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 truy cập web không?
Có những khía cạnh khác về thư viện và khung mà bạn nên cân nhắc nhưng chưa được thảo luận nhiều trong bài đăng này:
- Khả năng mở rộng: bạn có thể dễ dàng mở rộng thư viện bằng logic và/hoặc hành vi tuỳ chỉnh không?
- Công cụ: thư viện có công cụ (nếu 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à 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 mà bộ kiểm thử đang chuyển sang thay đổi 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? Đó có phải là mã nguồn mở hay có thể mua được không?
- Chỉ số phù phiếm: chỉ số này nên nằm ở cuối danh sách tiêu chí hoặc thậm chí là bị bỏ qua hoàn toàn. Tuy nhiên, bạn có thể cân nhắc "số lượt bình chọn" của dự án, các 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 giải quyết trên trang dự án.