Hiện trạng của React và cộng đồng trong năm 2025

 (blog.isquaredsoftware.com)
26 điểm bởi GN⁺ 2025-06-16 | 16 bình luận | Chia sẻ qua WhatsApp
  • React vẫn là framework UI được dùng rộng rãi nhất, nhưng trong vài năm gần đây sự hỗn loạn, tranh cãi và mất niềm tin trong cộng đồng đã gia tăng; việc thiếu giao tiếp giữa đội ngũ chính thức và các lập trình viên bên ngoài, cộng với marketing sai lệch, đã khiến lo ngại bị khuếch đại
  • React 19 đã chính thức phát hành, bổ sung nhiều tính năng lớn như Server Components, hook use mới, tích hợp biểu mẫu..., nhưng chính sách “chỉ khuyến nghị framework” và cấu trúc xoay quanh Next.js đã làm nhiều người dùng bất mãn
  • Những hiểu lầm và FUD như “giờ React chỉ có thể dùng đúng cách trong Next.js” hay “sắp ngừng hỗ trợ chỉ client” đã lan rộng, nhưng trên thực tế không bao giờ có chuyện khả năng render phía client biến mất, và các tính năng RSC hay server đều chỉ là tùy chọn
  • Chính sách lấy framework làm trung tâm của đội React nhằm mục tiêu chuẩn hóa hiệu năng/cấu trúc và cải thiện trải nghiệm người dùng, nhưng sự thiếu tôn trọng với SPA và các kiến trúc đa dạng, cùng tài liệu không chính thức/khó tiếp cận đã làm cộng đồng thêm rối loạn
  • Gần đây nhiều cách tiếp cận đa dạng như SPA dựa trên Vite·Parcel mới được đưa vào tài liệu chính thức, nhưng việc thiếu giải thích chính thức về server components (RSC) và giao tiếp chưa đầy đủ vẫn còn tồn tại

Giới thiệu và mục tiêu

  • Tính đến năm 2025, cộng đồng React đang ở trong một giai đoạn phức tạp, nơi thành công, mất niềm tin và tranh cãi đan xen
  • Mục tiêu của bài viết này là sắp xếp lại quá trình phát triển của React, định hướng phát triển và bối cảnh đằng sau các quyết định chính, đồng thời giải tỏa FUD và sự hỗn loạn

Bối cảnh của tác giả và lịch sử tham gia cộng đồng

  • Không phải thành viên của đội React, nhưng đã tham gia sâu vào hệ sinh thái React từ năm 2015
  • Người bảo trì các thư viện thuộc họ Redux (đặc biệt là Redux Toolkit) và là một nhân vật hoạt động tích cực trong cộng đồng
  • Tham gia vào vô số tutorial, blog, bài nói chuyện và podcast về React/Redux
  • Giữ vai trò quản trị viên và điều phối viên tại các cộng đồng lớn như Reactiflux Discord, subreddit /r/reactjs
  • Có kinh nghiệm hợp tác với đội React (ví dụ: alpha tester của hook useSyncExternalStore), tham gia nhiều nhóm phản hồi nội bộ khác nhau
  • Đóng góp kỹ thuật cho React DevTools, sourcemaps, Replay DevTools và nhiều mảng khác

  • Thông báo về thiên kiến và giới hạn

    • Bản thân tác giả có thể không phải lúc nào cũng đúng, và thừa nhận rằng do giới hạn thông tin, hiểu nhầm hoặc quá trình tóm lược, có thể tồn tại một số mô tả chưa chính xác
    • Là người bảo trì Redux, và kinh nghiệm sử dụng React cũng chủ yếu thiên về công cụ nội bộ và dạng SPA
    • Kinh nghiệm thực tế với SSR, RSC, lưu lượng cực lớn, i18n... còn hạn chế
    • Dù quen thuộc với những chủ đề được thảo luận sâu trong cộng đồng, góc nhìn này vẫn có thể phần nào lệch khỏi đời sống hằng ngày của lập trình viên ứng dụng phổ thông
    • Cả trải nghiệm cá nhân tích cực lẫn tiêu cực với đội React đều ảnh hưởng đến quan điểm
    • Tác giả cố gắng truyền đạt sự thật một cách trung thực nhất có thể khi giải thích bối cảnh lịch sử/cấu trúc

Lịch sử ngắn gọn của React

  • Được phát triển nội bộ tại Facebook (nay là Meta) trong giai đoạn 2011~2012, và mã nguồn mở vào năm 2013
  • Cho đến gần đây, mọi phát triển cốt lõi đều do đội React của Facebook/Meta dẫn dắt
  • Các khái niệm cốt lõi (component, props, state, data flow) vẫn được giữ nguyên, nhưng phần triển khai, API và phạm vi ứng dụng đã liên tục mở rộng và thay đổi
    • createClass → ES6 class → component hàm (có hỗ trợ Hooks)
    • Mở rộng sang nhiều nền tảng như di động với React Native, WebGL với react-reconciler (react-three-fiber), CLI (ink)...
    • Nội bộ được refactor toàn diện sang kiến trúc “Fiber” (đổi mới lớn về hiệu năng/cấu trúc)
    • Năm 2018, Hooks được giới thiệu để mang state/effect vào component hàm
  • Với chiến lược “thư viện UI tối giản (V trong MVC)”, kiến trúc, framework cấp cao, build, state management... được giao cho cộng đồng
    • Vì vậy đã xuất hiện vô số thư viện bên thứ ba và công cụ build như Redux/Mobx/Zustand (state), Styled-Components/Emotion/CSS Modules (style), React Query/Apollo/SWR(RTK Query) (data), Webpack/Vite/Parcel...
  • Tính linh hoạt là ưu điểm, nhưng cũng đồng nghĩa với việc mỗi dự án buộc phải tự chọn các thư viện cần thiết → kéo theo vấn đề đa dạng codebase, mệt mỏi khi lựa chọn và thiếu tiêu chuẩn

  • Công cụ build và CRA

    • Ban đầu, cấu hình phức tạp với Webpack/Babel... là điều bắt buộc
    • Create React App (CRA): CLI dựa trên Webpack+Babel, ẩn đi sự phức tạp, cho phép tạo dự án bằng một lệnh duy nhất (mô hình black box)
    • Data fetching và state management vẫn phụ thuộc vào công cụ bên thứ ba riêng biệt
    • Tính năng SSR (server-side rendering) đã tồn tại từ sớm, nhưng phải tự triển khai thủ công
    • Sau đó, các framework như Next.js (SSR/routing dựa trên file system, data fetching), Gatsby (static site, GraphQL), Remix (server data loader) lần lượt xuất hiện

  • React Server Components (RSC) và sự chuyển dịch sang framework

    • Cuối năm 2020, prototype của React Server Components (RSC) được công bố, đánh dấu một thay đổi kiến trúc nhằm chuẩn hóa async component và server data fetching trong React
    • Trong quá trình phát triển, một số thành viên đội React chuyển sang Vercel và hợp tác với Next.js để tạo ra App Router cùng triển khai RSC đầu tiên
    • Giai đoạn 2020~2023, tài liệu chính thức của React (react.dev) được đại tu toàn diện, tăng cường tutorial tương tác và API reference

  • Sự thay đổi trong cách dùng được khuyến nghị chính thức

    • Trong tài liệu chính thức trước đây, React khuyến nghị bắt đầu với SPA dựa trên CRA, và nếu cần SSR/static site thì gợi ý các lựa chọn như Next/Gatsby
    • Trong bộ tài liệu mới (react.dev), việc dùng framework được khuyến nghị mạnh mẽ (routing, data fetching, tích hợp build), và chỉ nhắc đến Next.js như một triển khai RSC
    • CRA từ khoảng năm 2022 gần như rơi vào trạng thái ngừng bảo trì trên thực tế (dù chưa bị deprecated chính thức), và dần bị cộng đồng thay thế
    • Cả trong tài liệu chính thức lẫn cộng đồng, các quan điểm như “Next.js mới là React 18 thực thụ” làm nổi bật sự gắn kết mạnh với Next.js

React và mối quan hệ với công ty sở hữu (nhà tài trợ)

  • Meta (Facebook)

    • Ngay từ đầu, React là dự án do Facebook/Meta sở hữu và dẫn dắt
    • Dù là mã nguồn mở, việc phát triển thực chất do đội React của Meta đảm nhiệm; các cuộc họp cốt lõi và roadmap cũng chủ yếu xoay quanh nội bộ
    • Các tính năng mới đều được kiểm chứng và thử nghiệm thực tế trên nhiều đội ứng dụng nội bộ của Meta trước khi công bố ra ngoài
    • Đội React có mức độ tự do phát triển cao và chủ động dẫn dắt việc xây roadmap cũng như tầm nhìn
    • Nội bộ vẫn cần chứng minh thành quả và dự án đóng góp như thế nào cho hoạt động kinh doanh của Meta
    • Meta tích cực sử dụng hạ tầng server riêng, GraphQL, Relay và các công nghệ tự phát triển, nên cách dùng React trong routing, state management... khác với cộng đồng bên ngoài
    • Vì vậy, trong nội bộ Meta, tần suất dùng thư viện bên thứ ba từ bên ngoài là thấp hơn

  • Vercel, Next.js và React

    • Vercel là nền tảng hosting web app, đồng thời là công ty phát triển framework Next.js
    • Mô hình kinh doanh là phổ biến các framework như Next → dẫn người dùng lên hosting trên nền tảng Vercel
    • CEO (Guillermo Rauch) từ sớm đã đặt niềm tin và đầu tư sâu vào triết lý render của React
    • Năm 2021, trưởng nhóm React Sebastian Markbage rời Meta sang Vercel, cùng với các nhân sự chủ chốt như Andrew Clark, Tom Occhino gia nhập
    • Những thành viên chuyển sang Vercel này đã triển khai các tính năng lõi như React Server Components (RSC) và Next.js App Router ở cả hai phía React và Next.js
    • Các kỹ sư thuộc Vercel cũng có đóng góp thực chất vào React core và các tính năng server rendering
    • Tính đến năm 2025, đội React đang hoạt động phân tán giữa Meta và Vercel (Meta vẫn là lực lượng chính, nhưng Vercel cũng tham gia vào nhiều triển khai lõi quan trọng), ngoài ra còn có một số contributor bên ngoài

Các kiểu sử dụng React

  • Kiến trúc tiêu chuẩn

    • Bản thân React hỗ trợ nhiều cách khác nhau như SPA, SSR, SSG, hybrid...
      • SPA: render toàn bộ cây React ở phía client trong một trang HTML rỗng
      • SSR: tạo HTML động theo từng request ở phía server
      • SSG: tạo sẵn HTML tĩnh tại build time
      • Có thể kết hợp với nhiều ngôn ngữ hoặc framework như Python/Django, Ruby/Rails, PHP/WordPress...
    • Từ khoảng năm 2015, SPA (client rendering) là chuẩn phổ biến, nhưng đi kèm các đánh đổi như tốc độ tải ban đầu, kích thước JS bundle và khác biệt với hành vi native của trình duyệt
    • Trước đây, data fetching thường được tự viết logic trong Redux...; về sau xuất hiện các hook/thư viện chuyên dụng như React Query/Apollo/SWR/RTK Query giúp đơn giản hóa
    • Các framework như Next.js, Remix mở rộng phạm vi ứng dụng của React bằng cách chuẩn hóa SSR, SSG, routing theo file system và cấu trúc hóa data fetching
    • Có xu hướng dịch chuyển sang kiến trúc dựa trên SSR (server rendering, prefetch, code splitting...)
    • Đội React tránh mô hình “data fetching waterfall” và khuyến nghị các pattern cải thiện hiệu năng như prefetch theo route

  • Tình hình sử dụng công cụ build và framework

    • Các công cụ/framework chính:
      • Next.js (SSR/SSG/RSC/SPA)
      • Remix / React-Router v7 (SSR/SSG/SPA)
      • Vite (SPA, công cụ build, hỗ trợ plugin cho nhiều framework khác nhau)
      • Create React App (SPA)
    • Vite khởi nguồn từ hệ sinh thái Vue nhưng hỗ trợ nhiều nền tảng như React, Svelte... → có plugin React chính thức và trở thành chuẩn build tool cho nhiều framework
    • Remix/React-Router gần đây cũng chuyển sang cấu trúc hỗ trợ SSR/SSG dựa trên Vite
    • Tóm tắt thống kê download:
      • Next.js đứng số 1 áp đảo về mức sử dụng
      • Plugin React của Vite tăng trưởng rất nhanh, là lựa chọn được dùng nhiều thứ hai
      • CRA (react-scripts) giảm từ sau năm 2023 nhưng vẫn còn lượng sử dụng đáng kể
      • Remix nổi tiếng nhờ truyền miệng nhưng quy mô tổng thể còn hạn chế; React Router chuyển sang framework mode với tốc độ khá chậm
      • Gatsby thấp hơn khá xa so với Next/Vite/CRA, và gần đây còn bị Astro (static site đa framework) vượt qua
      • Astro không chuyên cho React nhưng có quy mô tương tự Remix
      • Nếu cộng Vite+CRA lại thì ngang ngửa Next → nhu cầu cho mô hình SPA vẫn còn rất cao

Bên trong React Server Components (RSC) và mối quan hệ với framework

  • Bối cảnh phát triển RSC và hợp tác với Vercel

    • Hạ tầng nội bộ của Meta vốn đã có cấu trúc server riêng, nên việc phát triển và thử nghiệm RSC (React Server Components) có những giới hạn nhất định
    • RSC là thiết kế mang tính định hướng tương lai do chính đội React trực tiếp dẫn dắt, không phải xuất phát từ chỉ đạo hay yêu cầu của Meta hoặc Vercel mà từ tầm nhìn độc lập của đội React
    • Đội React đề xuất tầm nhìn RSC với Vercel, và Vercel tham gia như môi trường thử nghiệm cũng như bên hỗ trợ phát triển
    • Các thành viên React core như Sebastian Markbage, Andrew Clark... chuyển từ Meta sang Vercel, và đội Next.js xây dựng App Router (trường hợp áp dụng RSC thực tế đầu tiên)
    • Trong quá trình này, Next.js gần như được thiết kế và triển khai lại từ đầu
    • Các framework khác như Shopify (Hydrogen), Remix... cũng từng thử nghiệm và hợp tác ban đầu, nhưng chưa tham gia mạnh mẽ
    • Kết quả là chỉ Next.js App Router trở thành triển khai RSC “cấp production” thực sự; các framework khác (React Router, Parcel, Waku...) hiện vẫn đang trong quá trình tích hợp, còn mức độ sử dụng đại chúng thì Next gần như độc chiếm

  • Cấu trúc tích hợp giữa RSC với framework/bundler

    • Có rất nhiều câu hỏi như “vì sao RSC lại nhất thiết phải cần framework hay bundler?”
    • SSR truyền thống (renderToString, renderToPipeableStream) có thể chạy ở bất kỳ đâu, nhưng RSC về mặt cấu trúc phức tạp hơn rất nhiều
      • Cần diễn giải các directive 'use client', 'use server' trong code
      • Cần tự động tách và đăng ký client/server component
      • Bắt buộc phải tích hợp chặt với bundler có khả năng phân tích và biên dịch toàn bộ module graph (ví dụ: Webpack, Vite...)
    • React core chỉ cung cấp logic cốt lõi của RSC và API tuần tự hóa dữ liệu; việc vận hành thực tế, routing, gọi endpoint... là trách nhiệm của framework
    • Mỗi framework có cách tận dụng, kiến trúc và triển khai RSC khác nhau
      • Next.js App Router áp dụng các quy tắc riêng về layout, routing...
      • Parcel, Waku, React Router... đang đưa vào các thiết kế khác nhau
    • Tóm lại:
      • RSC là tính năng hybrid được tích hợp trong React core, nhưng để dùng thực tế thì bắt buộc phải có tích hợp từ bundler/framework
      • Chỉ khi framework hỗ trợ, các lợi thế của RSC mới có thể được khai thác trong thực tế

Lo ngại và sự hỗn loạn trong cộng đồng

  • 1. Lo ngại rằng “Vercel đã kiểm soát React”

    • Việc Vercel tuyển dụng các thành viên chủ chốt của đội React, cùng với việc Next.js được nhấn mạnh trong tài liệu và ví dụ, đã làm lan rộng nghi ngờ rằng “Vercel đang dẫn dắt sự phát triển của React”
    • Trên thực tế, đội React mới là bên dẫn dắt tầm nhìn RSC và cấu trúc của Next App Router, còn Vercel đóng vai trò hỗ trợ và môi trường thử nghiệm
    • Thay vì nói Vercel “kiểm soát” React, chính xác hơn là một phần đội React core đã chuyển sang Vercel để hiện thực hóa tầm nhìn đó

  • 2. Hiểu lầm rằng “giờ React chỉ chạy được trong Next”

    • Vì Next.js được nhấn mạnh như triển khai RSC production duy nhất, nên hiểu lầm này đã xuất hiện
    • Tài liệu chính thức của React ngoài Next vẫn nhắc tới nhiều framework khác, cũng như cách dùng không cần framework
    • Next chỉ là một framework dựa trên React; React vẫn có thể được dùng độc lập hoặc với các công cụ khác

  • 3. Nỗi lo rằng “React có thể biến mất khỏi các ứng dụng client”

    • Việc nhấn mạnh các tính năng server (RSC, SSR...) khiến xuất hiện những lo ngại về việc dừng hỗ trợ SPA/client
    • Khả năng render phía client của React sẽ không bao giờ biến mất
      • Các codebase lớn như của Meta vẫn dùng rất nhiều mô hình client
      • Đội React rất nghiêm ngặt về khả năng tương thích và hỗ trợ migration

  • 4. “Vì sao React ép buộc phải dùng framework?”

    • Đội React mặc định khuyến nghị framework vì các lợi thế về năng suất và hiệu năng trong việc tích hợp data fetching, routing, SSR...
    • Quan điểm của họ là “tự cấu hình (SPA tùy biến) kém hiệu quả về dài hạn, còn framework mới là chuẩn của ngành”
    • Nhưng trên thực tế có rất nhiều kiểu sử dụng khác nhau, nên khuyến nghị này trở nên quá đồng loạt
      • SPA vẫn còn hợp lý vì nhiều lý do thực tế như rào cản nhập môn cho người mới, doanh nghiệp bị giới hạn về hosting server, hay sự đơn giản trong hosting SPA
    • Việc tài liệu chính thức xem hướng dẫn “không framework” như nội dung thứ yếu khiến cộng đồng có cảm giác bị gạt ra ngoài

  • 5. Giới hạn của tài liệu chính thức và tranh cãi quanh cải tiến

    • CRA (react-scripts) đã deprecated trên thực tế; việc nhắc đến công cụ thay thế như Vite quá muộn càng làm tăng hỗn loạn
    • Các cách làm “không framework” như SPA hiện cũng đã được công nhận chính thức và bổ sung hướng dẫn (tài liệu mới nhất năm 2025)
    • Việc React chính thức nhắc đến các công cụ build lớn như Vite quá chậm cũng bị cộng đồng và các nhân vật trong hệ sinh thái (như Evan You) chỉ ra là vấn đề
    • Trong bộ tài liệu mới đã được cải thiện, SPA, Vite/Parcel/RSPack... cũng được khuyến nghị, đồng thời có hướng dẫn lựa chọn router và data fetching

  • 6. Thiếu tài liệu và giải thích chính thức về RSC

    • So với tài liệu bên ngoài từ Next.js, Vercel..., phần giải thích và giới thiệu khái niệm RSC trong tài liệu React chính thức còn thiếu
    • Chỉ có thông tin rời rạc trong API Reference, còn hướng dẫn tổng thể về khái niệm/ứng dụng vẫn chưa đầy đủ
    • Dù cộng đồng và các nhân vật chủ chốt (như Dan Abramov...) đang tích cực bổ sung giải thích, việc thiếu chính thức hóa vẫn tiếp tục gây rối loạn
    • Đang có nhu cầu bổ sung các mục tài liệu về khái niệm, kiến trúc, trường hợp áp dụng, FAQ... cho RSC

Tổng hợp về các mối lo ngại chính

  • Hiểu lầm rằng việc nhấn mạnh framework và tính năng server là “vì lợi ích của Vercel” đã ăn sâu vào cộng đồng, nhưng thực tế không đúng
    • Cách giao tiếp của đội React và cách diễn đạt trong tài liệu chính thức đúng là đã góp phần làm hiểu lầm nghiêm trọng hơn
  • Khả năng render phía client của React vẫn sẽ tiếp tục được duy trì; các tính năng server (RSC/SSR...) chỉ là tùy chọn, và các cách làm hiện tại như SPA vẫn có thể tiếp tục sử dụng
  • Lo ngại và hỗn loạn trong cộng đồng cũng một phần đến từ sự thiếu giao tiếp của đội React và hoạt động DevRel còn yếu
    • Cần có tuyên bố chính thức rõ ràng hơn, giải tỏa hiểu lầm, và công nhận cũng như hướng dẫn cho nhiều pattern đa dạng
  • Khuyến nghị “dùng framework” xuất phát từ thiện ý, nhưng trên thực tế bị cảm nhận là quá đồng nhất và khiến nhiều kiểu sử dụng khác bị bỏ quên
  • Sau năm 2025, tài liệu chính thức đã được cải thiện để công nhận và bổ sung hướng dẫn cho SPA/cách build tùy biến, nhưng mất rất nhiều thời gian mới phản ánh được phản hồi từ cộng đồng
  • Cần tăng cường tài liệu chính thức về những nội dung cốt lõi như khái niệm và trade-off của RSC (React Server Components)
    • Điều này sẽ giúp cộng đồng hiểu đúng hơn và tránh các tranh cãi không cần thiết

Kết luận

  • Bài viết đưa ra câu trả lời cho nhiều câu hỏi về cách React đã phát triển như thế nào, được xây dựng dưới những ảnh hưởng và mục tiêu nào, cũng như các pattern sử dụng hiện đang định hình ra sao trong hệ sinh thái
  • Mục tiêu là giải tỏa sự hỗn loạn và FUD (sợ hãi, bất định, nghi ngờ) đã phát sinh quanh định hướng và những thay đổi của đội React
    • Dù có thể không đồng ý với định hướng kỹ thuật đó hoặc không thấy cần thiết phải dùng RSC/framework lớn, ý định và định hướng của đội React vẫn hoàn toàn có cơ sở hợp lý
  • Chính sách của đội React bắt nguồn từ thiện ý muốn chuẩn hóa hiệu năng và cải thiện UX cho cộng đồng, nhưng giao tiếp và tài liệu thiếu thân thiện đã làm gia tăng hỗn loạn không cần thiết
  • Nhu cầu tôn trọng sự đa dạng của các pattern sử dụng thực tế như SPA, framework, nhiều công cụ build khác nhau cùng với việc cải thiện tài liệu chính thức ngày càng lớn
  • Trong tương lai, việc phản ánh feedback từ cộng đồng, cải thiện tài liệu theo hướng bao quát nhiều kiến trúc hơn, và giao tiếp cởi mở sẽ là chìa khóa cho sự phát triển lành mạnh của React

Bài viết liên quan

16 bình luận

 
ahwjdekf 2025-06-19

React cho cảm giác như một thư viện dở dang, có gì đó thiếu hoàn thiện... Ví dụ nhìn mớ thứ được liệt kê dài dòng trong tài liệu chính thức về useEffect thì chỉ thấy ngán ngẩm... Cứ tạo ra ngần ấy hang thỏ rồi lại có thái độ kiểu "hãy tự dùng cho tốt" là sao không hiểu nổi... Tôi khá thường có cảm giác nó xử lý theo kiểu vá víu, không suy nghĩ gì nhiều.
 
ahwjdekf 2025-10-23

Nhìn vụ sự cố của AWS xảy ra, tôi lại nghĩ đúng là...
 
geek12356 2025-06-18

Nếu không thể đưa ra đề xuất cải thiện thì bạn chỉ là junior
 
woonki 2025-06-17

React Native cũng có bầu không khí tương tự. Nếu với React là Next.js thì với React Native là Expo. Tài liệu chính thức cũng khuyến nghị sử dụng framework Expo, còn cách dùng CLI trước đây giờ đã bị đẩy vào chỗ khó tìm.
 
preserde 2025-06-16

Thực ra ở đây các chủ đề về phát triển frontend web được đăng lên khá ít... Dù vậy, việc gần đây nextjs bị nhắc đến quá nhiều vẫn khiến tôi cảm thấy không hề bình thường.
Có cảm giác như chỉ có Server Components là vấn đề thôi, còn lại thì đều ổn~
 
ahwjdekf 2025-06-16

Bên mảng js fe này, mong hệ sinh thái sụp đổ sạch rồi reset lại một lần đi. Và cả mấy thứ như quản lý trạng thái nữa, hãy gộp hết vào để làm một framework luôn. Quá nhiều lựa chọn ư? Đó không phải là tự do, mà chỉ đơn thuần là vô trách nhiệm.
 
passerby 2025-06-16

Việc framework tiện lợi và việc chính React từ bỏ CRA dường như là hai vấn đề hoàn toàn khác nhau. Mình đã thấy hơi gượng gạo khi tài liệu React mới vừa vào đã bảo cài Next ngay, hóa ra không chỉ mình mới cảm thấy vậy.
 
dohyun682 2025-06-16

Tôi cứ tưởng Vercel và đội ngũ phát triển React là tách biệt, nhưng hóa ra thực tế họ có liên hệ sâu hơn nhiều.
 
quilt8703 2025-06-16

Tôi đang làm prototype game chỉ cần dùng React cho tương tác UI, tính toán trạng thái nội bộ và hiển thị trạng thái. So với vài năm trước, vào thời điểm create-react-app gần như bị loại khỏi tài liệu chính thức, gần đây tôi cảm thấy việc xem tài liệu chính thức để thiết lập còn rắc rối hơn một chút. Có lẽ bài viết tôi đã viết hồi đó cũng có phần liên quan.
 
click 2025-06-16

Có vẻ như bản thân việc RSC ngay từ đầu đã được phát triển dựa trên Next.js thì không khác gì mấy.
Nếu kết hợp thêm chuyện Next.js ngày càng vận hành trục trặc ở những môi trường ngoài Vercel
thì dù tôi không biết nội bộ đội React thực sự nghĩ gì, dòng logic sẽ thành ra kiểu: RSC là tương lai! Nhưng để chạy RSC thì chúng tôi khuyên dùng Next.js, và Next.js thì hãy dùng trên Vercel. Nếu hỏi điều đó có thật sự không liên quan đến lợi ích của Vercel không thì hmm...
Dù có khẳng định đó chỉ là hiểu lầm đi nữa, rốt cuộc mọi người vẫn khó tránh khỏi cảm giác rằng Vercel đã dần thâu tóm React, và chẳng phải họ cũng đã không phản ứng đủ nhanh để giải tỏa hiểu lầm đó sao?
 
spp00 2025-06-17

Ngay lúc này, trang web chính thức của React đang chạy trên Vercel chứ không phải trên máy chủ phía Meta.
 
moderna 2025-06-16

Tôi đồng ý.
 
click 2025-06-16

Mình cảm thấy Svelte cũng được Vercel đầu tư như nhau nhưng có lẽ vì quy mô nhỏ hơn nên không gặp những trường hợp bị vendor lock-in như thế này, nên cũng tò mò không biết điểm khác biệt là gì.
 
spp00 2025-06-17

Svelte chỉ được Vercel tài trợ chứ không phải do Vercel dẫn dắt. Ngược lại, Next thì hoàn toàn do Vercel dẫn dắt.

Ngay cả ở kho lưu trữ GitHub, Next cũng thuộc tổ chức của Vercel, còn Svelte thì không.

Và trên Next.js, phần ghi bản quyền ở footer trang chủ chính thức có Vercel, còn Svelte thì không.
 
click 2025-06-17

Hóa ra việc Vercel tuyển dụng Rich Harris mang tính chất tài trợ nhỉ
 
spp00 2025-06-17

https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte Vâng, đây là một dạng tuyển dụng mang tính tài trợ là chính. Tức là trả lương để anh ấy có thể toàn thời gian tập trung vào việc phát triển Svelte. Phía Vercel cũng đã làm rõ rằng Svelte vẫn là một dự án độc lập.