Kondisi Terkini React dan Komunitas pada 2025

 (blog.isquaredsoftware.com)
26 poin oleh GN⁺ 2025-06-16 | 16 komentar | Bagikan ke WhatsApp
  • React masih menjadi framework UI yang paling banyak digunakan, tetapi dalam beberapa tahun terakhir kebingungan, perdebatan, dan ketidakpercayaan di komunitas meningkat, dan kekhawatiran membesar akibat perpaduan kurangnya komunikasi antara tim resmi dan pengembang eksternal serta pemasaran yang keliru
  • React 19 telah dirilis resmi, membawa fitur besar seperti Server Components, hook use baru, integrasi form, dan lain-lain, tetapi kebijakan "hanya merekomendasikan framework" dan struktur yang berpusat pada Next.js memicu ketidakpuasan banyak pengguna
  • Kesalahpahaman dan FUD seperti "React sekarang hanya bisa dipakai dengan benar di Next.js" atau "dukungan khusus client akan segera dihentikan" menyebar, tetapi kenyataannya fitur client rendering tidak akan pernah dihapus, dan fitur RSC maupun server sepenuhnya bersifat opsional
  • Kebijakan tim React yang berpusat pada framework bertujuan menstandarkan performa/arsitektur dan meningkatkan pengalaman pengguna, tetapi kurangnya penghormatan terhadap SPA dan beragam arsitektur, serta dokumentasi yang tidak resmi/tidak ramah memperbesar kebingungan komunitas
  • Baru belakangan ini berbagai pendekatan seperti SPA berbasis Vite·Parcel dimasukkan ke dokumentasi resmi, tetapi kurangnya penjelasan resmi tentang server components (RSC) dan lemahnya komunikasi masih tersisa

Pendahuluan dan tujuan

  • Per 2025, komunitas React berada dalam situasi kompleks yang mencampurkan kesuksesan, ketidakpercayaan, dan perdebatan
  • Tujuan tulisan ini adalah merangkum proses perkembangan React, arah pengembangan, dan latar belakang keputusan-keputusan utama, serta mengurai FUD dan kebingungan

Latar belakang penulis dan riwayat keterlibatan di komunitas

  • Bukan anggota tim React, tetapi telah terlibat mendalam dalam ekosistem React sejak 2015
  • Maintainer keluarga library Redux, terutama Redux Toolkit, sekaligus tokoh aktif komunitas
  • Terlibat dalam banyak tutorial, blog, presentasi, dan podcast tentang React/Redux
  • Berperan sebagai admin dan moderator di komunitas utama seperti Reactiflux Discord dan subreddit /r/reactjs
  • Memiliki pengalaman kolaborasi dengan tim React (misalnya alpha tester hook useSyncExternalStore) dan ikut dalam berbagai grup feedback internal
  • Memberi kontribusi teknis pada React DevTools, sourcemaps, Replay DevTools, dan lainnya

  • Pemberitahuan bias dan keterbatasan

    • Penulis mengakui tidak selalu benar, dan mungkin ada penjelasan yang kurang akurat akibat keterbatasan informasi, salah paham, atau proses peringkasan
    • Menjadi maintainer Redux, dan pengalaman memakai React juga lebih banyak condong ke tool internal dan bentuk SPA
    • Pengalaman praktis pada SSR, RSC, traffic besar, i18n, dan lain-lain terbatas
    • Akrab dengan topik-topik yang dibahas mendalam di komunitas, tetapi ada jarak tertentu dari keseharian pengembang aplikasi pada umumnya
    • Pengalaman pribadi yang positif maupun negatif dengan tim React memengaruhi sudut pandang
    • Berupaya menyampaikan fakta sejujur mungkin saat menjelaskan latar belakang historis/struktural

Sejarah singkat React

  • Dikembangkan secara internal di Facebook (kini Meta) pada 2011~2012, lalu di-open-source-kan pada 2013
  • Hingga belakangan ini, seluruh pengembangan inti dipimpin oleh tim React di Facebook/Meta
  • Konsep inti (component, props, state, data flow) tetap dipertahankan, sementara implementasi, API, dan cakupan penggunaan terus meluas dan berubah
    • createClass → ES6 class → functional component (dengan dukungan Hooks)
    • Ekspansi ke berbagai platform seperti mobile lewat React Native, WebGL lewat react-reconciler (react-three-fiber), CLI (ink), dan lain-lain
    • Refactor total internal ke arsitektur "Fiber" (inovasi performa/struktur)
    • Pengenalan Hooks pada 2018 untuk memberi state/effect pada functional component
  • Dengan strategi "library UI minimal (V dalam MVC)", arsitektur, framework tingkat atas, build, state management, dan lain-lain diserahkan ke komunitas
    • Akibatnya muncul banyak library pihak ketiga dan build tool seperti Redux/Mobx/Zustand (state), Styled-Components/Emotion/CSS Modules (style), React Query/Apollo/SWR(RTK Query) (data), Webpack/Vite/Parcel, dan lain-lain
  • Fleksibilitas adalah kelebihan, tetapi memilih library yang dibutuhkan untuk tiap proyek menjadi keharusan → menimbulkan keragaman codebase, kelelahan, dan ketiadaan standar

  • Build tool dan CRA

    • Pada masa awal, konfigurasi rumit seperti Webpack/Babel bersifat wajib
    • Create React App (CRA): CLI berbasis Webpack+Babel yang menyembunyikan kompleksitas dan memungkinkan pembuatan proyek dengan satu command (pendekatan black box)
    • Data fetching dan state management tetap bergantung pada tool pihak ketiga terpisah
    • Fitur SSR (server-side rendering) sudah ada sejak awal, tetapi perlu diimplementasikan manual
    • Setelah itu muncul framework seperti Next.js (SSR/file-system based routing, data fetching), Gatsby (situs statis, GraphQL), Remix (server data loader)

  • React Server Components (RSC) dan peralihan ke framework

    • Pada akhir 2020, prototipe React Server Components (RSC) diperkenalkan, sebagai perubahan arsitektural untuk menstandarkan async component dan server data fetching di React
    • Dalam proses pengembangan, sebagian tim React pindah ke Vercel dan bekerja sama dengan Next.js untuk implementasi pertama App Router dan RSC
    • Pada 2020~2023, dokumentasi resmi React (react.dev) dirombak total, memperkuat tutorial interaktif dan referensi API

  • Perubahan pada cara pakai yang direkomendasikan secara resmi

    • Di dokumentasi resmi sebelumnya, memulai dengan SPA berbasis CRA direkomendasikan, dan alternatif seperti Next/Gatsby disarankan bila membutuhkan SSR/situs statis
    • Dokumentasi baru (react.dev) sangat merekomendasikan penggunaan framework (integrasi routing, data fetching, build), dan hanya menyebut Next.js sebagai implementasi RSC
    • CRA pada praktiknya berhenti dirawat sekitar 2022 (secara resmi belum deprecated saat itu, tetapi perlahan digantikan di komunitas)
    • Di dokumentasi resmi maupun komunitas, pendapat seperti "Next.js adalah React 18 yang sesungguhnya" menonjolkan keterkaitan yang kuat dengan Next.js

Hubungan React dengan perusahaan pemilik (sponsor)

  • Meta (Facebook)

    • React sejak awal adalah proyek yang dimiliki dan dipimpin oleh Facebook/Meta
    • Meski open source, pengembangan nyata dikerjakan oleh tim React di Meta, dan rapat inti serta roadmap juga berpusat di internal
    • Fitur baru diuji dan divalidasi lebih dulu oleh berbagai tim aplikasi internal Meta sebelum dirilis ke luar
    • Tim React memiliki kebebasan pengembangan yang tinggi dan secara proaktif memimpin penyusunan roadmap dan visi
    • Secara internal perlu dibuktikan bagaimana hasil dan proyek ini berkontribusi pada bisnis Meta
    • Meta aktif memanfaatkan infrastruktur server miliknya sendiri serta teknologi internal seperti GraphQL dan Relay, sehingga memakai React dengan cara yang berbeda dari komunitas dalam hal routing, state management, dan lain-lain
    • Karena itu, di internal Meta frekuensi penggunaan library pihak ketiga dari luar relatif rendah

  • Vercel, Next.js, dan React

    • Vercel adalah platform hosting web app sekaligus pengembang framework Next.js
    • Model bisnisnya adalah memperluas adopsi framework seperti Next → mendorong hosting di platform Vercel
    • CEO-nya, Guillermo Rauch, sejak awal sangat percaya dan berinvestasi pada filosofi rendering React
    • Pada 2021, pemimpin tim React Sebastian Markbage pindah dari Meta ke Vercel, lalu diikuti tokoh penting seperti Andrew Clark dan Tom Occhino
    • Anggota yang pindah ke Vercel mengimplementasikan fitur inti seperti React Server Components (RSC) dan Next.js App Router di sisi React maupun Next.js
    • Engineer Vercel juga memberi kontribusi nyata pada React core dan fitur server rendering
    • Per 2025, tim React bekerja tersebar di Meta dan Vercel (basis utama tetap Meta, tetapi implementasi core penting juga melibatkan Vercel), dengan sebagian kontributor eksternal

Pola penggunaan React

  • Arsitektur standar

    • React sendiri mendukung berbagai pendekatan seperti SPA, SSR, SSG, hybrid, dan lainnya
      • SPA: merender seluruh tree React di client dari HTML kosong
      • SSR: menghasilkan HTML dinamis di server untuk setiap request
      • SSG: menghasilkan HTML statis lebih dulu saat build time
      • Bisa dikombinasikan dengan berbagai bahasa atau framework lain (Python/Django, Ruby/Rails, PHP/WordPress, dan lain-lain)
    • Sejak sekitar 2015, pendekatan SPA (client rendering) menjadi standar, tetapi ada trade-off seperti kecepatan loading awal, ukuran bundle JS, dan perbedaan dengan perilaku browser native
    • Data fetching awalnya diimplementasikan langsung dalam Redux dan semacamnya, lalu disederhanakan dengan munculnya hook/library khusus seperti React Query/Apollo/SWR/RTK Query
    • Framework seperti Next.js dan Remix memperluas pemanfaatan React dengan menstandarkan SSR, SSG, file-system routing serta menstrukturkan data fetching
    • Ada tren berpindah ke arsitektur berbasis SSR (server rendering, prefetch, code splitting, dan lain-lain)
    • Tim React menghindari fenomena "data fetching waterfall" dan merekomendasikan pola peningkatan performa seperti prefetch per route

  • Kondisi penggunaan build tool dan framework

    • Tool/framework utama:
      • Next.js (SSR/SSG/RSC/SPA)
      • Remix / React-Router v7 (SSR/SSG/SPA)
      • Vite (SPA, build tool, mendukung berbagai plugin framework)
      • Create React App (SPA)
    • Vite bermula dari ekosistem Vue, tetapi kini mendukung React, Svelte, dan banyak lainnya → plugin resmi React, serta menjadi build tool standar untuk framework
    • Remix/React-Router juga belakangan bergerak ke struktur dukungan SSR/SSG berbasis Vite
    • Ringkasan statistik download:
      • Tingkat penggunaan Next.js jauh di posisi pertama
      • Plugin React untuk Vite tumbuh pesat dan menjadi yang kedua paling banyak dipakai
      • CRA (react-scripts) menurun sejak 2023, tetapi masih cukup banyak dipakai
      • Remix kuat dari sisi word of mouth, tetapi skala keseluruhannya terbatas; React Router juga lambat beralih ke framework mode
      • Gatsby jauh di bawah Next/Vite/CRA, dan belakangan bahkan tersalip Astro (situs statis multi-framework)
      • Astro tidak khusus untuk React, tetapi skalanya mirip Remix
      • Jika penggunaan Vite+CRA digabung, angkanya setara dengan Next → permintaan untuk pendekatan SPA juga masih tinggi

Bagian dalam React Server Components (RSC) dan hubungannya dengan framework

  • Latar belakang pengembangan RSC dan kolaborasi dengan Vercel

    • Infrastruktur internal Meta sudah dibangun dengan struktur servernya sendiri, sehingga ada keterbatasan dalam mengembangkan dan menguji RSC (React Server Components)
    • RSC adalah desain visioner yang dipimpin langsung oleh tim React, bukan arahan atau tuntutan dari Meta maupun Vercel, melainkan berangkat dari visi independen tim React
    • Tim React mengajukan visi RSC ke Vercel, dan Vercel bergabung sebagai tempat eksperimen sekaligus pendukung pengembangan
    • Anggota inti React seperti Sebastian Markbage dan Andrew Clark berpindah dari Meta ke Vercel, dan tim Next.js membangun App Router (contoh penerapan RSC nyata pertama)
    • Dalam proses ini, Next.js hampir dirancang dan diimplementasikan ulang dari nol
    • Framework lain seperti Shopify (Hydrogen) dan Remix juga sempat mencoba pengujian awal dan kolaborasi, tetapi keterlibatan penuhnya terbatas
    • Akibatnya, hanya Next.js App Router yang menjadi implementasi RSC "kelas produksi" yang nyata; framework lain (React Router, Parcel, Waku, dan lain-lain) masih dalam proses integrasi, sementara penggunaan publik praktis dimonopoli Next

  • Struktur integrasi RSC dengan framework/bundler

    • Pertanyaan "mengapa RSC pasti membutuhkan framework atau bundler?" sering muncul
    • SSR lama (renderToString, renderToPipeableStream) bisa dijalankan di mana saja, tetapi RSC secara struktural jauh lebih kompleks
      • Perlu menafsirkan directive 'use client', 'use server' dalam kode
      • Perlu otomatisasi pemisahan dan pendaftaran client/server component
      • Wajib terintegrasi erat dengan bundler yang menganalisis dan mengompilasi seluruh module graph (misalnya Webpack, Vite, dan lain-lain)
    • React core hanya menyediakan logika inti RSC dan API serialisasi data, sementara cara kerja nyata, routing, pemanggilan endpoint, dan lain-lain menjadi tanggung jawab framework
    • Setiap framework memiliki cara pemanfaatan, arsitektur, dan implementasi RSC yang berbeda
      • Next.js App Router menerapkan aturannya sendiri untuk layout, routing, dan lain-lain
      • Parcel, Waku, React Router, dan lainnya sedang mengadopsi desain yang berbeda-beda
    • Ringkasnya:
      • RSC adalah fitur hybrid yang tertanam di React core, tetapi penggunaan nyatanya wajib bergantung pada integrasi bundler/framework
      • Kelebihan RSC baru bisa benar-benar dimanfaatkan bila framework mendukungnya

Kekhawatiran dan kebingungan di komunitas

  • 1. Kekhawatiran bahwa "Vercel telah menguasai React"

    • Karena Vercel mempekerjakan anggota utama tim React, dan Next.js ditekankan dalam dokumentasi maupun contoh, muncul kecurigaan bahwa "Vercel memimpin pengembangan React"
    • Kenyataannya, tim React-lah yang memimpin visi RSC dan struktur Next App Router, sementara Vercel berperan sebagai pendukung dan tempat eksperimen
    • Jadi bukan Vercel yang "menguasai" React, melainkan sebagian tim inti React pindah ke Vercel untuk mewujudkan visinya

  • 2. Kesalahpahaman bahwa "React sekarang hanya berjalan di Next"

    • Karena hanya Next.js yang ditekankan sebagai satu-satunya implementasi produksi RSC, kesalahpahaman ini pun muncul
    • Dokumentasi resmi React juga menyebut beragam framework lain maupun cara penggunaan tanpa framework
    • Next hanyalah framework berbasis React; React tetap bisa dipakai sendiri atau bersama tool lain

  • 3. Kekhawatiran bahwa "React bisa hilang dari aplikasi client"

    • Karena fitur server (RSC, SSR, dan lain-lain) ditekankan, ada suara yang khawatir dukungan SPA client akan dihentikan
    • Fitur client rendering React tidak akan pernah hilang
      • Codebase besar seperti Meta pun banyak memakai pendekatan client
      • Tim React sangat ketat dalam menjaga kompatibilitas dan dukungan migrasi

  • 4. "Mengapa React memaksa penggunaan framework?"

    • Tim React pada dasarnya merekomendasikan framework karena kelebihan produktivitas dan performa dari integrasi data fetching, routing, SSR, dan lain-lain
    • Posisi mereka adalah "konfigurasi manual (SPA kustom) tidak efisien dalam jangka panjang, framework adalah standar industri"
    • Pada kenyataannya ada beragam pola penggunaan, tetapi rekomendasi itu terasa terlalu seragam
      • SPA tetap valid karena alasan nyata seperti hambatan masuk bagi pemula, perusahaan dengan keterbatasan hosting server, dan kesederhanaan hosting SPA
    • Panduan untuk "cara non-framework" di dokumentasi resmi diperlakukan sebagai hal sekunder, sehingga menimbulkan rasa terpinggirkan di komunitas

  • 5. Keterbatasan dokumentasi resmi dan kontroversi perbaikannya

    • CRA (react-scripts) secara resmi deprecated, dan keterlambatan menyebut tool pengganti seperti Vite memperbesar kebingungan
    • Pendekatan "non-framework" seperti SPA kini juga diakui secara resmi dan ditambahkan panduannya (dokumentasi terbaru 2025)
    • Keterlambatan penyebutan resmi build tool utama seperti Vite juga dipersoalkan oleh komunitas dan tokoh ekosistem (seperti Evan You)
    • Dalam dokumentasi terbaru yang sudah diperbaiki, SPA, Vite/Parcel/RSPack, dan lainnya juga direkomendasikan, beserta panduan memilih router dan data fetching

  • 6. Kurangnya dokumentasi dan penjelasan resmi tentang RSC

    • Dibanding materi eksternal seperti Next.js atau Vercel, penjelasan dan pengantar konsep RSC di dokumentasi resmi React masih kurang
    • Informasi yang ada hanya terpecah di API Reference, sementara panduan konsep/penerapan secara menyeluruh masih kurang
    • Komunitas dan tokoh utama (seperti Dan Abramov) aktif memberi penjelasan tambahan, tetapi kurangnya peresmian ini terus menimbulkan kebingungan
    • Muncul kebutuhan untuk menambahkan bagian dokumentasi tentang konsep, arsitektur, contoh adopsi, FAQ, dan lain-lain untuk RSC

Ringkasan atas kekhawatiran utama

  • Penekanan pada framework dan fitur server menanamkan kesalahpahaman di komunitas bahwa hal itu dilakukan demi kepentingan Vercel, tetapi kenyataannya tidak demikian
    • Cara komunikasi tim React dan penyusunan dokumentasi resmi memang turut memperbesar salah paham
  • Fitur client rendering React akan terus dipertahankan ke depan; fitur server (RSC/SSR, dan lain-lain) hanyalah opsi, sehingga pendekatan lama seperti SPA tetap bisa dipakai
  • Kekhawatiran dan kebingungan komunitas juga dipengaruhi oleh kurangnya komunikasi dari tim React dan lemahnya aktivitas developer relations (DevRel)
    • Perlu ada penyampaian posisi resmi, pelurusan salah paham, serta pengakuan dan panduan untuk berbagai pola penggunaan
  • Rekomendasi "gunakan framework" berangkat dari niat baik, tetapi pada praktiknya terasa terlalu seragam dan mendapat kritik karena mengabaikan berbagai pola penggunaan
  • Sejak 2025, dokumentasi resmi sudah membaik dengan mengakui pendekatan SPA/build kustom dan menambahkan panduan, tetapi butuh waktu lama untuk benar-benar mencerminkan feedback komunitas
  • Dokumentasi resmi masih perlu diperkuat pada konsep-konsep inti seperti RSC (React Server Components) dan trade-off-nya
    • Ini akan membantu pemahaman komunitas yang lebih tepat dan mencegah kontroversi yang tidak perlu

Penutup

  • Tulisan ini memberikan jawaban atas berbagai pertanyaan tentang bagaimana React berkembang, di bawah pengaruh dan tujuan apa React dikembangkan, serta bagaimana pola penggunaannya terbentuk dalam ekosistem saat ini
  • Tujuannya adalah mengurai kebingungan atau FUD (fear, uncertainty, doubt) yang muncul terkait arah dan perubahan dalam tim React
    • Meski seseorang mungkin tidak setuju dengan arah teknis tersebut atau tidak merasa perlu memakai RSC/framework besar, niat dan arah tim React tetap cukup masuk akal
  • Kebijakan tim React lahir dari niat baik untuk menstandarkan performa dan memperbaiki UX komunitas, tetapi komunikasi dan dokumentasi yang kurang ramah memperbesar kebingungan yang tidak perlu
  • Kebutuhan untuk menghormati keragaman pola penggunaan nyata seperti SPA, framework, dan beragam build tool serta memperbaiki dokumentasi resmi kian besar
  • Ke depan, perbaikan dokumentasi yang mencerminkan feedback komunitas, merangkul berbagai arsitektur, dan komunikasi terbuka akan menjadi kunci bagi perkembangan React yang sehat

Bacaan terkait

16 komentar

 
ahwjdekf 2025-06-19

React terasa seperti library yang belum matang dan ada yang kurang... Misalnya, kalau lihat dokumentasi resmi useEffect yang penuh sekali dengan catatan... rasanya cuma bikin geleng-geleng... Sikap membuat begitu banyak lubang kelinci seperti ini lalu menyuruh orang memakainya dengan baik itu sebenarnya bagaimana... Saya sering merasa banyak keputusan diambil seadanya, seperti tambal sulam tanpa banyak pemikiran.
 
ahwjdekf 2025-10-23

Melihat insiden AWS meledak, saya jadi berpikir, ya memang begitulah...
 
geek12356 2025-06-18

Kalau tidak bisa mengajukan usulan perbaikan, berarti kamu masih junior
 
woonki 2025-06-17

React Native juga suasananya mirip. Jika untuk React ada Next.js, maka untuk React Native ada Expo. Dokumentasi resmi juga merekomendasikan penggunaan framework Expo, dan metode cli yang lama sekarang jadi sulit ditemukan.
 
preserde 2025-06-16

Sebenarnya isu pengembangan web frontend yang muncul di sini cukup sedikit... Meski begitu, belakangan rasanya agak tidak biasa karena nextjs terlalu sering disebut.
Kesannya seperti, cuma Server Component yang bermasalah, selebihnya sih tidak apa-apa~
 
ahwjdekf 2025-06-16

Tolong ekosistem js dan fe di sisi ini dibikin hancur total lalu di-reset sekali. Dan sekalian saja bikin framework yang juga mencakup hal-hal seperti state management. Terlalu banyak pilihan? Itu bukan kebebasan, cuma bentuk ketidakbertanggungjawaban.
 
passerby 2025-06-16

Menurut saya, kenyamanan memakai framework dan keputusan React sendiri untuk meninggalkan CRA itu persoalan yang benar-benar berbeda. Saat melihat dokumentasi React yang baru langsung menyuruh memasang Next, saya merasa agak janggal, dan ternyata bukan hanya saya yang merasakannya.
 
dohyun682 2025-06-16

Saya kira Vercel dan tim pengembang React itu terpisah, tetapi ternyata hubungan mereka sebenarnya lebih dekat.
 
quilt8703 2025-06-16

Saya sedang membuat prototipe game dengan React, yang hanya membutuhkan interaksi UI, perhitungan state internal, dan penampilan state. Saya merasa belakangan ini penyiapannya lebih rumit jika mengikuti dokumentasi resmi dibandingkan beberapa tahun lalu saat create-react-app hampir dikeluarkan dari dokumentasi resmi. Sepertinya tulisan yang saya buat waktu itu agak relevan.
 
click 2025-06-16

Fakta bahwa RSC sejak awal dikembangkan berbasis Next.js tampaknya memang tidak berbeda.
Jika digabungkan dengan fakta bahwa Next.js makin lama makin tersendat di lingkungan selain Vercel,
saya tidak tahu bagaimana pemikiran internal tim React, tetapi alur logikanya jadi seperti “RSC adalah masa depan! Tapi untuk menjalankan RSC kami merekomendasikan Next.js, dan untuk Next.js pakailah Vercel”, lalu kalau ditanya apakah ini tidak ada kaitannya dengan kepentingan Vercel, ya hmm...
Sebanyak apa pun diklaim sebagai salah paham, pada akhirnya orang-orang pasti merasa bahwa Vercel telah menguasai React, dan bukankah mereka juga tidak merespons dengan cepat untuk meluruskan salah paham itu?
 
spp00 2025-06-17

Saat ini pun situs resmi React berjalan di atas Vercel, bukan di server milik Meta.
 
moderna 2025-06-16

Saya setuju.
 
click 2025-06-16

Sama-sama didanai oleh Vercel, saya merasa Svelte mungkin karena skalanya lebih kecil jadi tidak mengalami vendor lock-in seperti ini, dan saya juga penasaran apa perbedaannya.
 
spp00 2025-06-17

Svelte hanya disponsori oleh Vercel, bukan dipimpin oleh Vercel. Sebaliknya, Next dipimpin sepenuhnya oleh Vercel.

Bahkan dalam kasus repositori GitHub, Next berada di bawah organisasi Vercel, sedangkan Svelte tidak.

Dan pada Next.js, ada Vercel dalam keterangan hak cipta di footer situs resminya, sementara pada Svelte tidak ada.
 
click 2025-06-17

Jadi, ternyata Vercel merekrut Rich Harris itu sifatnya sebagai dukungan ya.
 
spp00 2025-06-17

https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte Ya, ini adalah perekrutan yang sifatnya sangat seperti sponsorship. Intinya, dia dibayar gaji agar bisa fokus penuh waktu pada pengembangan Svelte. Pihak Vercel juga menegaskan dengan jelas bahwa Svelte tetap merupakan proyek independen.