Chọn một thư viện hoặc khung JavaScript

Umar Hansa

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 cuộc thảo luận ở đây sẽ giúp bạn cân nhắc ưu và nhược điểm trong việc 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 này 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 ra mắt sản phẩm ban đầu, thay vì phải viết tất cả các mã từ đầu, việc này có thể tốn 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 chưa hiểu rõ về các hàm giảm tốc độ ảnh động, thì mã nguồn của thư viện có thể cho bạn biết cách thức hoạt động của các tốc độ này.

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 lại gặp rắc rối khi có thể sử dụng phần mềm (nguồn mở) miễn phí hoặc mua một giải pháp mà về lâu dài có thể tiết kiệm thời gian và tiền bạc? 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ụ:

  • 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 tập hợp các công việc phức tạp, giúp bạn tiết kiệm rất 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 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ư thế này có thể làm chậm quá trình tải trang đáng kể do 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:

  • Đố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ớ lập hồ sơ cho mọi hành vi trang web gọi ra mã từ thư viện hữu quan — hiệu suất tải trang không cho biết được đầy đủ 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 chính là điểm toả sáng 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ặp 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 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.

Sau đâ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.
  • 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 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 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ể tăng hoặc giảm khả năng truy cập trang web của bạn. 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ó cung cấp trải nghiệm phù hợp trên trình đọc màn hình không?

Tôi rất hợp lý khi cho rằng bạn (nhà phát triển web) cần có mức độ tham gia để đá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 vẫn tiếp tục sử dụng thư viện 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. 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ị 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

Một thư viện phần mềm sử dụng các 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 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 lượt 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ụ: việc 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 những bản cập nhật đó không được "phát hành" hoặc "phát hành" tương ứng, thì bạn có thể gặp khó khăn khi 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. Việc này cho phép người dùng thư viện dùng phiên bản thư viện mới nhất mà không cần thay đổi mã nguồn nhiều.

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 tìm kiếm lời 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 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. 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 phong phú nếu liên tục bổ sung tính năng. Thư viện bị làm rối có thể gây hại cho hiệu suất của 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ó sự hỗ trợ phù hợp có thể bắt đầu cho thấy dấu hiệu của 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 hành vi kiểm soát.

Tài liệu

Bất kể thư viện hoặc khung JavaScript đơn giản hay phức tạp đến mức nào, tài liệu phần mềm luôn có thể trợ giúp bạn. 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 đó.

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 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? Nhữ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 chỉ được xem là một vấn đề sau đó. 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 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ụ: nếu có, thư viện 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 rất 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? Đó là nguồn mở hay có thể mua được?
  • 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.