Một sự thật thú vị về tôi là sinh nhật của tôi trùng với Ngày lễ tình nhân. Năm nay, tôi muốn ăn mừng bằng cách ra mắt một trang web đơn giản cho phép mọi người nhận được thư ẩn danh thông qua liên kết cá nhân. Ý tưởng này nảy ra với tôi vào đầu tháng 2, vì vậy tôi muốn hoàn thành dự án càng sớm càng tốt vì thời gian là yếu tố cốt lõi.
Với suy nghĩ đó, tôi quyết định không thực hiện SSR/SSG với Gatsby cho dự án mà thay vào đó là sử dụng ứng dụng một trang (SPA) sử dụng Vite và React — một quyết định khá khó khăn khi xét đến kinh nghiệm sâu rộng của tôi với Gatsby. Nhiều năm trước, khi tôi bắt đầu sử dụng React và tìm hiểu ngày càng nhiều về bối cảnh web phức tạp ngày nay, tôi đã chọn Gatsby.js làm khung kết xuất của mình vì SSR/SSG là cần thiết cho mọi trang web, đúng không?
Tôi đã sử dụng nó cho mọi thứ, từ trang web cơ bản nhất đến dự án được thiết kế quá mức. Tôi hoàn toàn yêu thích nó và nghĩ rằng đó là công cụ tốt nhất, và tôi vô cùng tự tin vào quyết định của mình vì tôi đã đạt được điểm Lighthouse hoàn hảo trong quá trình này.
Nhiều năm trôi qua, tôi thấy mình liên tục phải vật lộn với các plugin Gatsby, phải dùng đến các giải pháp hacky cho chúng và thậm chí còn dành nhiều thời gian hơn để chờ máy chủ khởi động. Cảm giác như tôi đang sửa nhiều hơn là tạo ra. Tôi thậm chí còn bắt đầu một loạt bài cho tạp chí này về tất cả những "cơn đau đầu của Gatsby" mà tôi gặp phải nhiều nhất và cách vượt qua chúng.
Gatsby giống như ngày càng khó sử dụng hơn theo thời gian vì nhiều vấn đề chưa được giải quyết: các phụ thuộc lỗi thời, khởi động nguội, bản dựng chậm và các plugin cũ, để kể tên một vài vấn đề. Việc bắt đầu một dự án Gatsby trở nên nhàm chán đối với tôi và điểm Lighthouse hoàn hảo không thể bù đắp được điều đó.
Vì vậy, tôi đã quyết định ngừng sử dụng Gatsby làm khuôn khổ của mình.
Thật ngạc nhiên, sự kết hợp Vite + React mà tôi đã đề cập trước đó hóa ra lại hiệu quả hơn nhiều so với những gì tôi mong đợi trong khi vẫn duy trì gần như cùng các biện pháp hiệu suất tuyệt vời như Gatsby. Đây là một kết luận khó có thể chấp nhận sau nhiều năm trung thành với Gatsby.
Ý tôi là, tôi vẫn nghĩ Gatsby cực kỳ hữu ích cho nhiều dự án và tôi dự định sẽ nói về những dự án đó sau một chút. Nhưng Gatsby đã trải qua một loạt các sự kiện đáng tiếc gần đây sau khi Netlify mua lại công ty này, những tác động của chúng có thể được thấy trong kết quả giảm dần từ cuộc khảo sát State of JavaScript gần đây nhất. Khả năng một nhà phát triển tiếp tục sử dụng Gatsby sau khi đã sử dụng nó cho các dự án khác đã giảm mạnh từ 89% xuống còn 38% chỉ trong khoảng thời gian từ năm 2019 đến năm 2022.
Mặc dù Gatsby vẫn là khuôn khổ kết xuất được sử dụng nhiều thứ hai cho đến tận năm 2022 — chúng tôi vẫn đang mong đợi kết quả từ cuộc khảo sát năm 2023 — nhưng tôi dự đoán rằng sự suy giảm sẽ tiếp tục và giảm xuống dưới mức 38%.
Vì đây là lời tạm biệt cá nhân của tôi với Gatsby, nên tôi muốn viết về những điểm mà theo tôi, nó đã sai, những điểm vẫn hữu ích và cách tôi xử lý các dự án trong tương lai của mình.
Vậy thì… mọi chuyện đã sai ở đâu?
Tôi cho rằng đó là sự ra mắt của Gatsby Cloud vào năm 2019, khi Gatsby đặt mục tiêu tạo ra doanh thu liên tục và củng cố mô hình kinh doanh của mình. Nhiều người (kể cả tôi) chỉ ra sự sụp đổ của Gatsby đối với Gatsby Cloud, vì nó sẽ cắt giảm tài nguyên từ khuôn khổ chính và thậm chí khiến việc lưu trữ trên các nhà cung cấp đám mây khác trở nên khó khăn hơn.
Khung cốt lõi đã được tối ưu hóa theo cách mà việc sử dụng Gatsby và Gatsby Cloud cùng nhau không yêu cầu cấu hình lưu trữ bổ sung, do đó, khiến việc triển khai trên các nền tảng khác trở nên khó khăn hơn nhiều, cả bằng cách bỏ qua việc cung cấp tài liệu cho các triển khai của bên thứ ba và bằng cách phát hành các tính năng độc quyền, như bản dựng gia tăng, chỉ khả dụng cho người dùng Gatsby đã cam kết sử dụng Gatsby Cloud. Tóm lại, việc lưu trữ các dự án trên bất kỳ thứ gì ngoài Gatsby Cloud đều giống như một hình phạt.
Là một khung, Gatsby đã mất người dùng vào tay Next.js, như thể hiện trong cả các cuộc khảo sát và xu hướng npm, trong khi Gatsby Cloud phải vật lộn để cạnh tranh với những đối thủ như Vercel và Netlify; cựu mua lại Gatsby vào tháng 2 năm 2023.
Điều đó không để lại lý do quan trọng nào để tiếp tục sử dụng Gatsby. Và tôi nghĩ bình luận này trên cùng một chủ đề tóm tắt hoàn hảo tình cảm chung của cộng đồng:
Việc mua lại Netlify cũng dẫn đến một cuộc tái cấu trúc công ty làm giảm đáng kể số lượng nhân viên trong nhóm kỹ sư của Gatsby, tiếp theo là dừng hoàn toàn các hoạt động cam kết. Một báo cáo trong một dòng tweet đáng ngại của nhà đồng sáng lập Astro Fred Schott càng làm trầm trọng thêm mối lo ngại về tương lai của Gatsby.
Lennart Jörgens, cựu lập trình viên full-stack tại Gatsby và Netlify, đã trả lời, ám chỉ rằng chỉ còn một người ở lại sau đợt sa thải:
Bạn có thể thấy tất cả các yếu tố này góp phần vào sự sụt giảm sử dụng Gatsby trong khảo sát Stack Overflow năm 2023.
Biilmann đã giải quyết mối quan ngại của cộng đồng về khả năng tồn tại của Gatsby trong vấn đề mở từ kho lưu trữ Gatsby:
Theo tôi, trải nghiệm của nhà phát triển Gatsby (DX) trở thành gánh nặng nhiều hơn là sự trợ giúp và có hai thủ phạm chính mà tôi đổ lỗi: địa ngục phụ thuộc và đóng gói chậm times.
Sau khi chờ đợi một vài phút, bạn sẽ nhận được trang web Gatsby hoàn toàn mới của mình. Bạn có thể mong đợi có một trang web sạch sẽ không có lỗ hổng bảo mật nào và các phụ thuộc đã lỗi thời với thiết lập sẵn này, nhưng đây là những gì bạn sẽ tìm thấy trong thiết bị đầu cuối sau khi chạy
Điều đó có vẻ đáng lo ngại — và đúng là như vậy — không hẳn là từ góc độ bảo mật mà là dấu hiệu của DX đang suy yếu. Là một trình tạo trang web tĩnh (SSG), không có gì ngạc nhiên khi Gatsby sẽ cung cấp một trang web tĩnh và an toàn (thường thì) không có quyền truy cập vào cơ sở dữ liệu hoặc máy chủ, khiến trang web này miễn nhiễm với hầu hết các cuộc tấn công mạng. Ngoài ra, rất nhiều lỗ hổng đó nằm trong các công cụ dành cho nhà phát triển và không bao giờ đến được với người dùng cuối. Than ôi, việc dựa vào
Tuy nhiên, những lỗ hổng đó cho thấy một vấn đề cơ bản: số lượng lớn các phụ thuộc mà Gatsby sử dụng là 168(!) tại thời điểm tôi viết bài này. Để so sánh, Next.js sử dụng 16 phụ thuộc. Nhiều phụ thuộc của Gatsby đã lỗi thời, do đó có cảnh báo, nhưng việc cố gắng cập nhật chúng lên phiên bản mới nhất có thể sẽ giải phóng một địa ngục phụ thuộc đầy cảnh báo và lỗi npm bổ sung.
Trong subreddit liên quan từ năm 2022, một người dùng đã hỏi, "Liệu có thể có một trang web Gatsby không có lỗ hổng không?"
Câu trả lời thực sự thì đáng thất vọng, nhưng tính đến tháng 3 năm 2024, thì câu trả lời đó vẫn đúng.
Một trang web Gatsby sẽ hoạt động hoàn toàn tốt, ngay cả với nhiều phụ thuộc như vậy và việc mở rộng dự án của bạn sẽ không phải là vấn đề, cho dù thông qua hệ sinh thái plugin hay các gói khác. Tuy nhiên, khi cố gắng nâng cấp bất kỳ phụ thuộc hiện có nào, bạn sẽ thấy rằng mình không thể! Hoặc ít nhất là bạn không thể làm điều đó mà không đưa ra những thay đổi đột ngột cho một trong 168 phụ thuộc, nhiều phụ thuộc trong số đó dựa trên các phiên bản lỗi thời của các thư viện khác cũng không thể cập nhật được.
Đó là vòng xoay phụ thuộc giống như khởi đầu mà tôi gọi là địa ngục phụ thuộc.
Với suy nghĩ đó, việc lựa chọn một framework phụ thuộc vào mức độ hiệu quả mà bạn có thể sử dụng nó. Nếu máy chủ phát triển của bạn liên tục gặp sự cố khởi động nguội và sập và không thể phản ánh nhanh các thay đổi, thì đó là một DX kém và là tín hiệu cho thấy có thể có một lựa chọn tốt hơn.
Đó là lý do chính khiến tôi sẽ không tự động sử dụng Gatsby từ đây trở đi. Việc cài đặt không còn là một nhiệm vụ đơn giản nữa; các phụ thuộc sẽ phát ra cảnh báo và máy chủ phát triển mất hơn 30 giây để khởi động. Tôi thậm chí còn thấy rằng máy chủ chạy càng lâu thì càng chậm; điều này xảy ra liên tục với tôi, mặc dù tôi thừa nhận rằng tôi chưa nghe thấy những lời phàn nàn tương tự từ các nhà phát triển khác. Dù sao đi nữa, tôi rất tức giận khi phải liên tục khởi động lại máy chủ phát triển của mình mỗi khi thực hiện thay đổi đối với các tệp
Thực tế mới này đặc biệt đau đớn, khi biết rằng thiết lập Vite.js + React có thể khởi động máy chủ trong vòng 500ms nhờ sử dụng esbuild.
Chạy
Khoảnh khắc Gatsby Cloud ngừng hoạt động cùng với các bản dựng gia tăng, động lực để tiếp tục sử dụng Gatsby gần như không còn nữa. Thời gian xây dựng chậm đơn giản là quá tốn kém cho quy trình phát triển.
Đây là nơi tôi thấy Gatsby vẫn dẫn đầu cuộc cạnh tranh:
Hãy nghĩ xem, tại sao chúng ta lại sử dụng bất kỳ loại khung kết xuất nào ngay từ đầu? Tôi cho rằng đó là vì hai lý do chính: bot thu thập dữ liệu và thời gian tải ban đầu.
Trên các mạng chậm, người dùng có thể thấy màn hình trắng trước khi trang thực sự được kết xuất, điều này chỉ gây khó chịu nhẹ (nhưng tệ nhất là gây tổn hại).
Tuy nhiên, các công cụ tìm kiếm như Google và Bing triển khai các bot chỉ nhìn thấy một trang trống và quyết định không thu thập nội dung. Hoặc, nếu bạn đang liên kết một bài đăng trên phương tiện truyền thông xã hội, bạn có thể không nhận được các lợi ích của OpenGraph như bản xem trước liên kết.
Đây là trường hợp cách đây nhiều năm, khiến SSR/SSG trở nên cần thiết để được các bot của Google chú ý. Ngày nay, Google có thể chạy JavaScript và hiển thị nội dung để thu thập dữ liệu trang web của bạn. Mặc dù sử dụng SSR hoặc SSG giúp quá trình này nhanh hơn, nhưng không phải tất cả các bot đều có thể chạy JavaScript. Đây là sự đánh đổi mà bạn có thể thực hiện cho nhiều dự án và là sự đánh đổi mà bạn có thể giảm thiểu trên nhà cung cấp dịch vụ đám mây của mình bằng cách kết xuất trước nội dung của bạn.
Điều này đặc biệt hữu ích khi tải các trang được xác thực; trong trang được kết xuất phía máy khách (CSR), chúng ta sẽ cần hiển thị trạng thái đang tải trong khi kiểm tra xem người dùng đã đăng nhập hay chưa, trong khi trang SSR có thể thực hiện kiểm tra trên máy chủ và gửi lại nội dung tĩnh chính xác. Tuy nhiên, tôi thấy rằng sự đánh đổi này là một lập luận không thuyết phục để sử dụng một khuôn khổ kết xuất thay vì ứng dụng CSR React.
Trong mọi trường hợp, SPA của tôi được xây dựng trên React + Vite.js đã mang lại cho tôi điểm Lighthouse hoàn hảo cho trang đích. Các trang lấy dữ liệu sau khi xác thực dẫn đến điểm Core Web Vitals gần như hoàn hảo.
Tuy nhiên, đừng thất vọng nếu nó không phải là công cụ phù hợp đối với mọi trường hợp sử dụng, vì điều đó giống như đổ lỗi cho một chiếc tua vít không phải là một chiếc búa tốt. Nó vẫn có những công dụng tốt, mặc dù ít hơn so với những gì nó có thể có do tất cả những lý do mà chúng ta đã thảo luận trước đó.
Nhưng Gatsby vẫn là một công cụ hữu ích. Nếu bạn là một nhà phát triển Gatsby, lý do chính khiến bạn sử dụng nó là vì bạn biết Gatsby. Không sử dụng nó có thể được coi là chi phí cơ hội về mặt kinh tế:
Là một nhà phát triển Gatsby, tôi có thể bắt đầu một dự án mới bằng cách sử dụng một khuôn khổ kết xuất khác như Next.js. Ngay cả khi Next.js có tốc độ khởi động máy chủ nhanh hơn, tôi vẫn cần tính đến đường cong học tập của mình để sử dụng nó hiệu quả như Gatsby. Đó là lý do tại sao, đối với dự án mới nhất của mình, tôi quyết định tránh hoàn toàn các khung kết xuất và sử dụng Vite.js + React — Tôi muốn tránh chi phí cơ hội đi kèm với việc dành thời gian học cách sử dụng một khung "không quen thuộc".
Tôi rất có thể sẽ gắn bó với Vite.js + React cho các nỗ lực trong tương lai của mình và chỉ sử dụng các khung kết xuất khi tôi thực sự cần chúng. Những đánh đổi là gì? Hy sinh hiệu suất trang không đáng kể để đổi lấy DX nhanh hơn và dễ chịu hơn, giúp tôi tỉnh táo? Tôi sẽ chấp nhận thỏa thuận đó mỗi ngày.
Và tất nhiên, đây là kinh nghiệm của tôi với tư cách là người trung thành lâu năm với Gatsby. Kinh nghiệm của bạn có thể khác, vì vậy hiệu quả của mọi thứ tôi nói có thể khác nhau tùy thuộc vào nền tảng sử dụng Gatsby của bạn trong các dự án của riêng bạn.
Đó là lý do tại sao tôi rất muốn bạn bình luận bên dưới: nếu bạn thấy khác, vui lòng cho tôi biết! Trải nghiệm hiện tại của bạn khi sử dụng Gatsby có khác, tốt hơn hay tệ hơn so với một năm trước không? Bạn thấy có gì khác biệt không, nếu có? Thật tuyệt vời khi có được những góc nhìn khác ở đây, có thể là từ một người đã tham gia duy trì khuôn khổ.
Với suy nghĩ đó, tôi quyết định không thực hiện SSR/SSG với Gatsby cho dự án mà thay vào đó là sử dụng ứng dụng một trang (SPA) sử dụng Vite và React — một quyết định khá khó khăn khi xét đến kinh nghiệm sâu rộng của tôi với Gatsby. Nhiều năm trước, khi tôi bắt đầu sử dụng React và tìm hiểu ngày càng nhiều về bối cảnh web phức tạp ngày nay, tôi đã chọn Gatsby.js làm khung kết xuất của mình vì SSR/SSG là cần thiết cho mọi trang web, đúng không?
Tôi đã sử dụng nó cho mọi thứ, từ trang web cơ bản nhất đến dự án được thiết kế quá mức. Tôi hoàn toàn yêu thích nó và nghĩ rằng đó là công cụ tốt nhất, và tôi vô cùng tự tin vào quyết định của mình vì tôi đã đạt được điểm Lighthouse hoàn hảo trong quá trình này.
Nhiều năm trôi qua, tôi thấy mình liên tục phải vật lộn với các plugin Gatsby, phải dùng đến các giải pháp hacky cho chúng và thậm chí còn dành nhiều thời gian hơn để chờ máy chủ khởi động. Cảm giác như tôi đang sửa nhiều hơn là tạo ra. Tôi thậm chí còn bắt đầu một loạt bài cho tạp chí này về tất cả những "cơn đau đầu của Gatsby" mà tôi gặp phải nhiều nhất và cách vượt qua chúng.
Gatsby giống như ngày càng khó sử dụng hơn theo thời gian vì nhiều vấn đề chưa được giải quyết: các phụ thuộc lỗi thời, khởi động nguội, bản dựng chậm và các plugin cũ, để kể tên một vài vấn đề. Việc bắt đầu một dự án Gatsby trở nên nhàm chán đối với tôi và điểm Lighthouse hoàn hảo không thể bù đắp được điều đó.
Vì vậy, tôi đã quyết định ngừng sử dụng Gatsby làm khuôn khổ của mình.
Thật ngạc nhiên, sự kết hợp Vite + React mà tôi đã đề cập trước đó hóa ra lại hiệu quả hơn nhiều so với những gì tôi mong đợi trong khi vẫn duy trì gần như cùng các biện pháp hiệu suất tuyệt vời như Gatsby. Đây là một kết luận khó có thể chấp nhận sau nhiều năm trung thành với Gatsby.
Ý tôi là, tôi vẫn nghĩ Gatsby cực kỳ hữu ích cho nhiều dự án và tôi dự định sẽ nói về những dự án đó sau một chút. Nhưng Gatsby đã trải qua một loạt các sự kiện đáng tiếc gần đây sau khi Netlify mua lại công ty này, những tác động của chúng có thể được thấy trong kết quả giảm dần từ cuộc khảo sát State of JavaScript gần đây nhất. Khả năng một nhà phát triển tiếp tục sử dụng Gatsby sau khi đã sử dụng nó cho các dự án khác đã giảm mạnh từ 89% xuống còn 38% chỉ trong khoảng thời gian từ năm 2019 đến năm 2022.
Mặc dù Gatsby vẫn là khuôn khổ kết xuất được sử dụng nhiều thứ hai cho đến tận năm 2022 — chúng tôi vẫn đang mong đợi kết quả từ cuộc khảo sát năm 2023 — nhưng tôi dự đoán rằng sự suy giảm sẽ tiếp tục và giảm xuống dưới mức 38%.
Vì đây là lời tạm biệt cá nhân của tôi với Gatsby, nên tôi muốn viết về những điểm mà theo tôi, nó đã sai, những điểm vẫn hữu ích và cách tôi xử lý các dự án trong tương lai của mình.
Gatsby: Một hồi tưởng
Kyle Mathews bắt đầu làm việc trên thứ sau này trở thành Gatsby vào cuối năm 2015. Nhờ lớp dữ liệu độc đáo và cách tiếp cận SSG, nó đã được thổi phồng thành công và đạt được vòng hạt giống tài trợ 3,8 triệu đô la vào năm 2018. Bất chấp những nghi ngờ ban đầu, Gatsby vẫn kiên định với cam kết của mình và trở thành người đi đầu trong cộng đồng Jamstack bằng cách liên tục cải tiến khuôn khổ nguồn mở của mình và mang đến những thay đổi mới và tốt hơn với mỗi phiên bản.Vậy thì… mọi chuyện đã sai ở đâu?
Tôi cho rằng đó là sự ra mắt của Gatsby Cloud vào năm 2019, khi Gatsby đặt mục tiêu tạo ra doanh thu liên tục và củng cố mô hình kinh doanh của mình. Nhiều người (kể cả tôi) chỉ ra sự sụp đổ của Gatsby đối với Gatsby Cloud, vì nó sẽ cắt giảm tài nguyên từ khuôn khổ chính và thậm chí khiến việc lưu trữ trên các nhà cung cấp đám mây khác trở nên khó khăn hơn.
Khung cốt lõi đã được tối ưu hóa theo cách mà việc sử dụng Gatsby và Gatsby Cloud cùng nhau không yêu cầu cấu hình lưu trữ bổ sung, do đó, khiến việc triển khai trên các nền tảng khác trở nên khó khăn hơn nhiều, cả bằng cách bỏ qua việc cung cấp tài liệu cho các triển khai của bên thứ ba và bằng cách phát hành các tính năng độc quyền, như bản dựng gia tăng, chỉ khả dụng cho người dùng Gatsby đã cam kết sử dụng Gatsby Cloud. Tóm lại, việc lưu trữ các dự án trên bất kỳ thứ gì ngoài Gatsby Cloud đều giống như một hình phạt.
Là một khung, Gatsby đã mất người dùng vào tay Next.js, như thể hiện trong cả các cuộc khảo sát và xu hướng npm, trong khi Gatsby Cloud phải vật lộn để cạnh tranh với những đối thủ như Vercel và Netlify; cựu mua lại Gatsby vào tháng 2 năm 2023.
Việc mua lại Netlify là giọt nước tràn ly trong một đống cỏ khô khung vốn đã đổ. Việc di chuyển từ Gatsby Cloud sang Netlify cũng không mấy dễ chịu đối với khách hàng; một số nhóm bị tính thêm 120% — hoặc phải phát sinh thêm các khoản phí — sau khi chuyển đổi từ Gatsby Cloud sang Netlify, ngay cả khi họ sử dụng cùng gói Gatsby Cloud! Nhiều tính năng chính của Gatsby Cloud, cụ thể là các bản dựng gia tăng giúp giảm thời gian dựng các thay đổi nhỏ từ vài phút xuống còn vài giây, đơn giản là không còn khả dụng trong Netlify nữa, mặc dù Kyle Mathews nói rằng chúng sẽ được chuyển sang Netlify:
Tuy nhiên, trong một chủ đề trên diễn đàn Netlify có ngày tháng là tháng 8 năm 2023, chỉ sáu tháng sau khi mua lại, một kỹ sư hỗ trợ của Netlify đã phản bác lại tuyên bố của Mathews, nói rằng có không có kế hoạch bổ sung các tính năng gia tăng trong Netlify.
Điều đó không để lại lý do quan trọng nào để tiếp tục sử dụng Gatsby. Và tôi nghĩ bình luận này trên cùng một chủ đề tóm tắt hoàn hảo tình cảm chung của cộng đồng:
Việc mua lại Netlify cũng dẫn đến một cuộc tái cấu trúc công ty làm giảm đáng kể số lượng nhân viên trong nhóm kỹ sư của Gatsby, tiếp theo là dừng hoàn toàn các hoạt động cam kết. Một báo cáo trong một dòng tweet đáng ngại của nhà đồng sáng lập Astro Fred Schott càng làm trầm trọng thêm mối lo ngại về tương lai của Gatsby.
Lennart Jörgens, cựu lập trình viên full-stack tại Gatsby và Netlify, đã trả lời, ám chỉ rằng chỉ còn một người ở lại sau đợt sa thải:
Bạn có thể thấy tất cả các yếu tố này góp phần vào sự sụt giảm sử dụng Gatsby trong khảo sát Stack Overflow năm 2023.
Biilmann đã giải quyết mối quan ngại của cộng đồng về khả năng tồn tại của Gatsby trong vấn đề mở từ kho lưu trữ Gatsby:
Ông cũng làm sáng tỏ trọng tâm tương lai của Gatsby:
Vì vậy, Gatsby đã từ bỏ việc cạnh tranh với Next.js về mặt đổi mới và thay vào đó, họ sẽ tập trung vào việc giữ cho khuôn khổ hiện tại sạch sẽ và ổn định ở trạng thái hiện tại. Thành thật mà nói, đây có vẻ là hướng hành động hợp lý nhất khi xem xét tình hình hiện tại.
Tại sao mọi người ngừng sử dụng Gatsby?
Đúng vậy, Gatsby Cloud đã kết thúc đột ngột, nhưng với tư cách là một khuôn khổ độc lập với nhà cung cấp đám mây, các khía cạnh khác đã khuyến khích các nhà phát triển tìm kiếm các giải pháp thay thế cho Gatsby.Theo tôi, trải nghiệm của nhà phát triển Gatsby (DX) trở thành gánh nặng nhiều hơn là sự trợ giúp và có hai thủ phạm chính mà tôi đổ lỗi: địa ngục phụ thuộc và đóng gói chậm times.
Dependency Hell
Tiếp tục và bắt đầu một dự án Gatsby mới:
Mã:
gatsby newnpm audit:
Mã:
18 lỗ hổng bảo mật (11 trung bình, 6 cao, 1 nghiêm trọng)npm audit để đánh giá tính bảo mật của trang web của bạn là một lựa chọn ngây thơ nhất.Tuy nhiên, những lỗ hổng đó cho thấy một vấn đề cơ bản: số lượng lớn các phụ thuộc mà Gatsby sử dụng là 168(!) tại thời điểm tôi viết bài này. Để so sánh, Next.js sử dụng 16 phụ thuộc. Nhiều phụ thuộc của Gatsby đã lỗi thời, do đó có cảnh báo, nhưng việc cố gắng cập nhật chúng lên phiên bản mới nhất có thể sẽ giải phóng một địa ngục phụ thuộc đầy cảnh báo và lỗi npm bổ sung.
Trong subreddit liên quan từ năm 2022, một người dùng đã hỏi, "Liệu có thể có một trang web Gatsby không có lỗ hổng không?"
Câu trả lời thực sự thì đáng thất vọng, nhưng tính đến tháng 3 năm 2024, thì câu trả lời đó vẫn đúng.
Một trang web Gatsby sẽ hoạt động hoàn toàn tốt, ngay cả với nhiều phụ thuộc như vậy và việc mở rộng dự án của bạn sẽ không phải là vấn đề, cho dù thông qua hệ sinh thái plugin hay các gói khác. Tuy nhiên, khi cố gắng nâng cấp bất kỳ phụ thuộc hiện có nào, bạn sẽ thấy rằng mình không thể! Hoặc ít nhất là bạn không thể làm điều đó mà không đưa ra những thay đổi đột ngột cho một trong 168 phụ thuộc, nhiều phụ thuộc trong số đó dựa trên các phiên bản lỗi thời của các thư viện khác cũng không thể cập nhật được.
Đó là vòng xoay phụ thuộc giống như khởi đầu mà tôi gọi là địa ngục phụ thuộc.
Thời gian xây dựng và phát triển chậm
Đối với tôi, một trong những khía cạnh quan trọng nhất khi lựa chọn một công cụ phát triển là mức độ thoải mái khi sử dụng công cụ đó và tốc độ đưa dự án vào hoạt động. Như tôi đã nói trước đây, người dùng không quan tâm hoặc không biết "tech stack" là gì hoặc framework nào đang được sử dụng; họ muốn một trang web đẹp mắt giúp họ hoàn thành nhiệm vụ mà họ đến để làm. Nhiều nhà phát triển thậm chí không thắc mắc về tech stack nào được sử dụng trên mỗi trang web họ truy cập; ít nhất, tôi hy vọng là không.Với suy nghĩ đó, việc lựa chọn một framework phụ thuộc vào mức độ hiệu quả mà bạn có thể sử dụng nó. Nếu máy chủ phát triển của bạn liên tục gặp sự cố khởi động nguội và sập và không thể phản ánh nhanh các thay đổi, thì đó là một DX kém và là tín hiệu cho thấy có thể có một lựa chọn tốt hơn.
Đó là lý do chính khiến tôi sẽ không tự động sử dụng Gatsby từ đây trở đi. Việc cài đặt không còn là một nhiệm vụ đơn giản nữa; các phụ thuộc sẽ phát ra cảnh báo và máy chủ phát triển mất hơn 30 giây để khởi động. Tôi thậm chí còn thấy rằng máy chủ chạy càng lâu thì càng chậm; điều này xảy ra liên tục với tôi, mặc dù tôi thừa nhận rằng tôi chưa nghe thấy những lời phàn nàn tương tự từ các nhà phát triển khác. Dù sao đi nữa, tôi rất tức giận khi phải liên tục khởi động lại máy chủ phát triển của mình mỗi khi thực hiện thay đổi đối với các tệp
gatsby-config.js, gatsby-node.js hoặc bất kỳ nguồn dữ liệu nào khác.Thực tế mới này đặc biệt đau đớn, khi biết rằng thiết lập Vite.js + React có thể khởi động máy chủ trong vòng 500ms nhờ sử dụng esbuild.
Chạy
gatsby build trở nên tệ hơn. Thời gian xây dựng cho các dự án lớn hơn thường mất một số phút, điều này dễ hiểu khi chúng ta xem xét tất cả các trang, nguồn dữ liệu và tối ưu hóa mà Gatsby thực hiện ở chế độ nền. Tuy nhiên, ngay cả một chỉnh sửa nội dung nhỏ trên một trang cũng kích hoạt toàn bộ quy trình xây dựng và triển khai, và việc chờ đợi vô tận không chỉ mệt mỏi mà còn gây mất tập trung khi hoàn thành công việc. Đó là lý do tại sao các bản dựng gia tăng được thiết kế để giải quyết và là lý do khiến nhiều người chuyển từ Netlify sang Gatsby Cloud khi sử dụng Gatsby. Thật đáng tiếc khi chúng ta không còn tùy chọn đó nữa.Khoảnh khắc Gatsby Cloud ngừng hoạt động cùng với các bản dựng gia tăng, động lực để tiếp tục sử dụng Gatsby gần như không còn nữa. Thời gian xây dựng chậm đơn giản là quá tốn kém cho quy trình phát triển.
Những gì Gatsby đã làm rất tốt
Tôi vẫn tin rằng Gatsby có những điều tuyệt vời mà các khuôn khổ kết xuất khác không có, và đó là lý do tại sao tôi sẽ tiếp tục sử dụng nó, mặc dù chỉ trong những trường hợp cụ thể, chẳng hạn như trang web cá nhân của tôi. Nó không phải là khuôn khổ phù hợp với tôi cho mọi thứ, chủ yếu là vì Gatsby (và Jamstack) không dành cho mọi dự án, ngay cả khi Gatsby được tiếp thị là một khuôn khổ đa năng.Đây là nơi tôi thấy Gatsby vẫn dẫn đầu cuộc cạnh tranh:
- Lớp dữ liệu GraphQL.
Trong Gatsby, tất cả dữ liệu được cấu hình đều có sẵn ở cùng một nơi, một lớp dữ liệu dễ dàng truy cập bằng các truy vấn GraphQL ở bất kỳ phần nào trong dự án của bạn. Đây là tính năng tốt nhất của Gatsby và nó đơn giản hóa quy trình xây dựng các trang tĩnh từ dữ liệu, ví dụ: blog từ API hệ thống quản lý nội dung hoặc tài liệu từ các tệp Markdown. - Hiệu suất của máy khách.
Mặc dù trải nghiệm của nhà phát triển đối với Gatsby còn đáng ngờ, nhưng tôi tin rằng nó mang lại một trong những trải nghiệm người dùng tốt nhất để điều hướng trang web. Các trang và tài sản tĩnh mang lại thời gian tải nhanh nhất có thể và việc sử dụng React Router với chức năng hiển thị trước các liên kết gần mang lại một trong những trải nghiệm mượt mà nhất khi điều hướng giữa các trang. Chúng ta cũng phải lưu ý đến API hình ảnh tuyệt vời của Gatsby, chức năng tối ưu hóa hình ảnh ở mọi mức độ. - Hệ sinh thái plugin (loại đó).
Thông thường, có một plugin Gatsby cho mọi thứ. Điều này thật tuyệt khi sử dụng CMS làm nguồn dữ liệu vì bạn chỉ cần cài đặt plugin cụ thể của nó và có tất cả dữ liệu cần thiết trong lớp dữ liệu của mình. Tuy nhiên, rất nhiều plugin không được bảo trì và trở nên lỗi thời, gây ra các vấn đề phụ thuộc không thể giải quyết được đi kèm với địa ngục phụ thuộc.
Chúng ta có cần SSR/SSG cho mọi thứ không?
Tôi sẽ ghi nhận rằng tôi không thay thế Gatsby bằng một khuôn khổ kết xuất khác, như Next.js hoặc Remix, mà chỉ tránh chúng hoàn toàn. Tôi thấy rằng chúng thực sự không cần thiết trong nhiều trường hợp.Hãy nghĩ xem, tại sao chúng ta lại sử dụng bất kỳ loại khung kết xuất nào ngay từ đầu? Tôi cho rằng đó là vì hai lý do chính: bot thu thập dữ liệu và thời gian tải ban đầu.
SEO và Bot thu thập dữ liệu
Hầu hết các ứng dụng React đều bắt đầu bằng một phần thân rỗng, chỉ có Trên các mạng chậm, người dùng có thể thấy màn hình trắng trước khi trang thực sự được kết xuất, điều này chỉ gây khó chịu nhẹ (nhưng tệ nhất là gây tổn hại).
Tuy nhiên, các công cụ tìm kiếm như Google và Bing triển khai các bot chỉ nhìn thấy một trang trống và quyết định không thu thập nội dung. Hoặc, nếu bạn đang liên kết một bài đăng trên phương tiện truyền thông xã hội, bạn có thể không nhận được các lợi ích của OpenGraph như bản xem trước liên kết.
Mã:
Thời gian tải ban đầu
Các trang được kết xuất trước tải nhanh hơn vì chúng cung cấp nội dung tĩnh giúp trình duyệt không phải chạy JavaScript tốn kém.Điều này đặc biệt hữu ích khi tải các trang được xác thực; trong trang được kết xuất phía máy khách (CSR), chúng ta sẽ cần hiển thị trạng thái đang tải trong khi kiểm tra xem người dùng đã đăng nhập hay chưa, trong khi trang SSR có thể thực hiện kiểm tra trên máy chủ và gửi lại nội dung tĩnh chính xác. Tuy nhiên, tôi thấy rằng sự đánh đổi này là một lập luận không thuyết phục để sử dụng một khuôn khổ kết xuất thay vì ứng dụng CSR React.
Trong mọi trường hợp, SPA của tôi được xây dựng trên React + Vite.js đã mang lại cho tôi điểm Lighthouse hoàn hảo cho trang đích. Các trang lấy dữ liệu sau khi xác thực dẫn đến điểm Core Web Vitals gần như hoàn hảo.
Những dự án nào Gatsby vẫn phù hợp
Gatsby và các khuôn khổ kết xuất rất tuyệt vời để lập trình tạo các trang từ dữ liệu và đặc biệt là cho blog, thương mại điện tử và tài liệu.Tuy nhiên, đừng thất vọng nếu nó không phải là công cụ phù hợp đối với mọi trường hợp sử dụng, vì điều đó giống như đổ lỗi cho một chiếc tua vít không phải là một chiếc búa tốt. Nó vẫn có những công dụng tốt, mặc dù ít hơn so với những gì nó có thể có do tất cả những lý do mà chúng ta đã thảo luận trước đó.
Nhưng Gatsby vẫn là một công cụ hữu ích. Nếu bạn là một nhà phát triển Gatsby, lý do chính khiến bạn sử dụng nó là vì bạn biết Gatsby. Không sử dụng nó có thể được coi là chi phí cơ hội về mặt kinh tế:
Hãy tưởng tượng một sinh viên dành một giờ và 30 đô la để tham gia lớp học yoga vào buổi tối trước thời hạn. Chi phí cơ hội bao gồm thời gian có thể dành để hoàn thành dự án và 30 đô la có thể được sử dụng cho các chi phí trong tương lai.
Là một nhà phát triển Gatsby, tôi có thể bắt đầu một dự án mới bằng cách sử dụng một khuôn khổ kết xuất khác như Next.js. Ngay cả khi Next.js có tốc độ khởi động máy chủ nhanh hơn, tôi vẫn cần tính đến đường cong học tập của mình để sử dụng nó hiệu quả như Gatsby. Đó là lý do tại sao, đối với dự án mới nhất của mình, tôi quyết định tránh hoàn toàn các khung kết xuất và sử dụng Vite.js + React — Tôi muốn tránh chi phí cơ hội đi kèm với việc dành thời gian học cách sử dụng một khung "không quen thuộc".
Kết luận
Vậy, Gatsby đã chết chưa? Hoàn toàn không, hoặc ít nhất là tôi không nghĩ Netlify sẽ sớm để nó biến mất. Việc mua lại và những thay đổi tiếp theo đối với Gatsby Cloud có thể đã gây ra thiệt hại lớn cho khung cốt lõi, nhưng Gatsby vẫn còn hoạt động, ngay cả khi các cam kết chậm hiện tại được đẩy lên kho lưu trữ trông giống như nó hầu như không còn hoạt động hoặc đang ngủ đông.Tôi rất có thể sẽ gắn bó với Vite.js + React cho các nỗ lực trong tương lai của mình và chỉ sử dụng các khung kết xuất khi tôi thực sự cần chúng. Những đánh đổi là gì? Hy sinh hiệu suất trang không đáng kể để đổi lấy DX nhanh hơn và dễ chịu hơn, giúp tôi tỉnh táo? Tôi sẽ chấp nhận thỏa thuận đó mỗi ngày.
Và tất nhiên, đây là kinh nghiệm của tôi với tư cách là người trung thành lâu năm với Gatsby. Kinh nghiệm của bạn có thể khác, vì vậy hiệu quả của mọi thứ tôi nói có thể khác nhau tùy thuộc vào nền tảng sử dụng Gatsby của bạn trong các dự án của riêng bạn.
Đó là lý do tại sao tôi rất muốn bạn bình luận bên dưới: nếu bạn thấy khác, vui lòng cho tôi biết! Trải nghiệm hiện tại của bạn khi sử dụng Gatsby có khác, tốt hơn hay tệ hơn so với một năm trước không? Bạn thấy có gì khác biệt không, nếu có? Thật tuyệt vời khi có được những góc nhìn khác ở đây, có thể là từ một người đã tham gia duy trì khuôn khổ.
Đọc thêm trên SmashingMag
- Gatsby Headaches And How To Cure Them: i18n (Phần 1)
- Gatsby Headaches And How To Cure Them: i18n (Phần 2)
- Gatsby Headaches: Working With Media (Phần 1)
- Gatsby Headaches: Working With Media (Phần 2)
