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 để thực hiện 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 áp dụng được 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ã ứ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 sẽ 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 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 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ò là 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 các công ty lớn hỗ trợ, những công ty này đầu tư thời gian và tiền bạc để đảm bảo thư viện luôn được cập nhật và an toà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 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? 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ụ:
- Thư viện có thể được viết và duy trì nội bộ thay vì 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.
Như bạn có thể ngờ, 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 cân nhắc 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í 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ì hiệu suất càng ảnh hưởng nhiều đến người dùng.
Khi đánh giá hoặc sử dụng 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:
- 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ố tuỳ chọn khác.
- Tiếp nối ví dụ về date-fns trước, hãy chỉ nhập các hàm 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 thử hiệu suất như Lighthouse để quan sát hiệu quả về hiệu suất khi sử dụng một thư viện JavaScript nhất định. Nếu một thư viện thêm độ trễ một giây vào thời gian tải trang (đừng quên hạn chế 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à mình 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 các quan sát, đề xuất và thậm chí là nội dung đóng góp của bạn về hiệu suất 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. Việc bổ sung tính năng, sửa lỗi, xử lý các trường hợp đặc biệt và các hoạt động 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ây ra vấn đề hơn và có thể không gây ra vấn đề nào. Đâ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 bộ chọn màu, nhờ đó bạn không cần phải 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 có một số rủi ro bảo mật vốn có. 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.
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 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.
- 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 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 cho 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 nào. 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 sử dụng trong nhiều môi trường, nhưng trong bối cảnh thư viện dựa trên JavaScript phía máy khách, khả năng hỗ trợ tiếp cận web là rất quan trọng.
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ợ người dùng thu phóng 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ợ 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?
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 những video đó thuộc 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 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 của mình 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 sử dụng quy ước lập trình chưa từng nghe đế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 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, bạ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 hiệu quả 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ã một cách đột ngột 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 không chắc chắn, hãy cân nhắc việc tham khảo ý kiến tư vấn pháp lý chuyên nghiệp hoặc tham khảo ý kiến của nhóm pháp lý trong công ty.
Cộng đồng
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 phải là đả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 mang lại lợi ích. Hãy cân nhắc những ưu và khuyết điểm sau đây khi tham gia 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 khả năng phát hiện sớm và thường xuyên các lỗi.
- 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 sự 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. Các nhà phát triển 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ì 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 tích cực và gắn bó có thể gây áp lực cho tác giả và người duy trì, đồng thời có thể cần phải kiểm duyệt cộng đồng chặt chẽ.
- 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ụ: nhà phát triển web mới bắt đầu hoặc cấp dưới có thể cảm thấy không được chào đón trong một cộng đồng nhất định do tình trạng kiểm soát.
Tài liệu
Bất kể 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ả các nhà phát triển rất già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 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ó bao gồm tài liệu không? Nếu không, bạn cần phải tự tìm hiểu mọi thứ.
- Tài liệu có rõ ràng, dễ hiểu và không gây nhầm lẫn không? Nhiều nhà phát triển dành nhiều thời gian cho việc lậ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ó được cập 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à những định dạng tài liệu có giá trị có thể giúp bạn thành công trong việc sử dụng thư viện hoặc khung.
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 hỗ trợ tiếp cận trên web không?
Có một số khía cạnh khác của thư viện và khung mà bạn nên cân nhắc và 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, 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.