ده سال پس از ارائه تأثیرگذار ریاکت در Oscon 2014، ما به بررسی مفاهیم پشت ریاکت پرداخته و میزان تطبیق آنها با سال 2024 را بررسی میکنیم.
ده سال پیش، کریستوفر چدو، توسعهدهنده فیسبوک، در Oscon (کنفرانس متنباز O’Reilly) ارائهای درباره فریمورک جاوااسکریپتی نسبتاً جدیدی به نام ریاکت داشت. این ارائه جذاب بود زیرا مفاهیم پشت ریاکت را توضیح میداد - نه تنها اینکه چگونه کار میکرد، بلکه چرا ایجاد شده بود.
با توجه به تسلطی که ریاکت از سال 2014 در اکوسیستم توسعه فرانتاند به دست آورده است، در این مقاله به بررسی مفاهیم پشت ریاکت میپردازم و تعیین میکنم که این مفاهیم چقدر بهخوبی در سال 2024 جایگاه دارند. این موضوع بهویژه در سال 2024 مهم است، زمانی که محصولات نرمافزاری بزرگ مانند مایکروسافت اج رویکردی را که من آن را "پسا-ریاکت" مینامم، به توسعه وب شروع کردهاند (تیم مایکروسافت اج این رویکرد را "HTML-first" مینامد). همچنین، فریمورکهای غیر ریاکت مانند Svelte و Solid بهطور فزایندهای به گزینههای قابلتوجهی برای توسعهدهندگان فرانتاند تبدیل شدهاند.
چرا ریاکت در سال 2014 وبدولوپمنت (صنعت توسعه وب) را تسخیر کرد
در ارائه سال 2014 خود، چدو توضیح داد که پیدایش ریاکت از گسترش PHP توسط فیسبوک به وجود آمد که در فوریه 2010 بهعنوان نرمافزار متنباز به نام XHP منتشر شد. "ما نحو PHP را برای قرار دادن XML در آن گسترش دادیم." این کار عمدتاً به دلایل امنیتی انجام شد، اما همچنین به "چرخه تکرار بسیار سریع" منجر شد.
با این حال، از آنجا که PHP یک زبان سمت سرور بود، هر بار که چیزی تغییر میکرد، صفحه باید بهطور کامل دوباره رندر میشد. بنابراین تیم فیسبوک تصمیم گرفت بخش بزرگی از منطق اپلیکیشن XHP را به جاوااسکریپت، زبان اسکریپتی بومی مرورگر، منتقل کند، زیرا آنها میخواستند از سفرهای رفت و برگشتی - از سرور به کلاینت و بازگشت به سرور و سپس به کلاینت - اجتناب کنند. سپس به دنبال راههایی برای بهینهسازی استفاده از جاوااسکریپت بودند.
"من تمایل دارم که ریاکت را بهعنوان کنترل نسخه برای DOM در نظر بگیرم"
– کریستوفر چدو، 2014 (از طریق AdonisSMU)
بهطور خلاصه، آنها به ایجاد کتابخانه جاوااسکریپتی به نام ریاکت رسیدند: نوآوری کلیدی در ایجاد یک "DOM مجازی" بود. DOM (مدل شیء سند)، همانطور که ویکیپدیا بهخوبی توضیح میدهد، "نمایشی شیءگرا از یک سند HTML است که بهعنوان رابطی بین جاوااسکریپت و خود سند عمل میکند."
همانطور که چدو توضیح داد، ریاکت دو نسخه "مجازی" از DOM را در اختیار شما قرار میدهد (یکی قبل و یکی بعد از هر تعامل)، از طریق آن یک فرآیند "تفاوتگیری" اجرا میشود تا مشخص شود دقیقاً چه چیزی تغییر کرده است. سپس ریاکت آن تغییرات را به DOM واقعی اعمال میکند - به این معنا که فقط بخشی از DOM تغییر میکند و بقیه آن بهصورت اولیه باقی میماند. این، به نوبه خود، به این معناست که فقط بخشی از صفحه وب نیاز به رندر مجدد برای کاربر نهایی دارد.
چدو یک نقلقول مفید داشت که مزایای ریاکت را خلاصه میکرد: "من تمایل دارم که ریاکت را بهعنوان کنترل نسخه برای DOM در نظر بگیرم" (به AdonisSMU نسبت داده شده است). بنابراین در این چارچوب، ریاکت مانند گیت برای فرانتاند است.
یکی دیگر از نوآوریها ایجاد JSX (جاوااسکریپت XML، رسماً جاوااسکریپت Syntax eXtension) بود، یک گسترش XML مانند برای نحو جاوااسکریپت. در سال 2013، پیت هانت از فیسبوک آن را بهعنوان "یک گسترش نحوی اختیاری، در صورتی که شما خوانایی HTML را به جاوااسکریپت خام ترجیح میدهید" توصیف کرد.
یکی از ایدههای مهم پشت ریاکت این بود که مبتنی بر الگو نبود، مانند فریمورکهای محبوب قبلی (مانند روبی آن ریلز و جنگو). همانطور که هانت اشاره کرد، "ریاکت به ساخت رابطهای کاربری بهطور متفاوتی نزدیک میشود با تقسیم آنها به کامپوننتها [که] به این معناست که ریاکت از یک زبان برنامهنویسی واقعی و کامل برای رندر کردن رابطهای کاربری استفاده میکند."
ریاکت واقعاً روش انقلابی برای توسعه برنامههای وب ارائه داد - و بهویژه مناسب برنامههای بزرگ بود که دادهها بهطور مداوم تغییر میکردند. توسعهدهندگان تأثیرگذار شروع به توجه به ریاکت کردند و پذیرش ریاکت در سال 2014 رشد کرد. جیمز لانگ، در آن زمان توسعهدهنده در موزیلا، با پستی در می 2014 با عنوان "حذف پیچیدگی رابط کاربری، یا چرا ریاکت فوقالعاده است" حال و هوای بویانتی اطراف ریاکت را خلاصه کرد (اگر میخواهید به جزئیات فنی بپردازید، آن پست را بخوانید، اما برای اهداف ما اینجا، تیتر خودش گویای همهچیز است!).
منتقدان ریاکت
با وجود محبوبیتش، مدت زیادی طول نکشید تا شکایات درباره ریاکت آغاز شود. تا پایان سال 2015، برخی توسعهدهندگان از "خستگی ریاکت" به دلیل منحنی یادگیری تند آن شکایت داشتند. در دسامبر 2015، اریک کلمنز نوشت:
"در نهایت، مشکل این است که با انتخاب ریاکت (و ذاتاً JSX)، بهطور ناخواسته وارد یک لانه پیچیده از ابزارهای ساخت، بویلرپلیتها، لینترها و وقتگیرها شدهاید که باید قبل از اینکه چیزی خلق کنید با آنها دست و پنجه نرم کنید."
توسعهدهندگان همچنین با نحوه مدیریت وضعیت (state) در ریاکت مشکل داشتند. در آگوست 2016، چارلی کرافورد در The New Stack نوشت:
"مشکلات زمانی شروع میشوند که درخت کامپوننت بلند(از نظر طول) میشود، و شما کامپوننتهایی دارید که از یکدیگر دور هستند و یکی از دیگری نیست، و هر دو کامپوننت به یک بخش از وضعیت وابسته هستند."
تا سال 2017، برخی توسعهدهندگان تأثیرگذار شروع به ابراز شکایات منظم درباره ریاکت کردند. در آگوست 2017، الکس راسل - که در آن زمان برای تیم کروم گوگل کار میکرد - به ایده اینکه DOM مجازی سریع است، واکنش نشان داد:
"[…] هرگز هیچ مبنای واقعی برای این ایده که VDOM 'سریع' است، وجود نداشت، و هنوز هم وجود ندارد. این یک معامله بین فضا و *راحتی* است، نه سرعت."
یکبار دیگر، در ژوئن 2019، راسل اشاره کرد که "تفاوتگیری" در واقع نسبت به سایر فریمورکها کند است:
"معلوم شد تفاوتگیری کند است! فریمورکهای دیگر (Svelte، Lit، Vue و غیره) با اتخاذ رویکردهای مختلف سریعتر هستند، اما آنها نحو سطح مشابهی دارند و خیلی کوچکتر هستند.
مدافعان ریاکت
برخی از مسائل ریاکت که توسعهدهندگان در طول دهه گذشته از آنها شکایت کردهاند، یا برطرف شدهاند یا حل شدهاند. به عنوان مثال، منحنی یادگیری دیگر چندان مسئلهای نیست - بسیاری از توسعهدهندگان جدید فرانتاند از سال 2014 وارد بازار شدهاند و بسیاری از آنها با یادگیری ریاکت شروع کردهاند. همچنین راهحلهای خوبی برای مسائل مدیریت وضعیت به وجود آمدهاند، مانند Redux یا Context API ریاکت.
حتی با وجود مسائل عملکردی، ریاکت مدافعان خود را دارد. در رأس آنها، شرکت Vercel که فریمورک پیشرو ریاکت در صنعت، یعنی Next.js، را اجرا میکند. در ژوئیه 2023، Vercel پست وبلاگی طولانی درباره ریاکت 18، نسخه پایدار کنونی، منتشر کرد. این پست توضیح میداد که "چگونه ویژگیهای همزمان مانند Transitions، Suspense و مؤلفههای سمت سرور ریاکت عملکرد برنامهها را بهبود میبخشند."
اما حتی اگر این ویژگیها عملکرد را بهبود بخشند، آیا این به بهای پیچیدگی تمام شده است؟ برخی، از جمله مدیر عامل Netlify، مت بیلمن، اینگونه فکر میکنند. در ژانویه امسال، بیلمن از یک توییت از مدیر عامل Vercel، گییرمو راوخ، استفاده کرد تا به پیچیدگی ظاهری Vercel (و به تبع آن ریاکت) کنایه بزند.
باید توجه داشت که Netlify رقیب مستقیم Vercel است! در طول آن ارائه، بیلمن Astro را بهعنوان جایگزینی بسیار سادهتر برای Next.js معرفی کرد. در حالی که Astro به کاربران اجازه میدهد ریاکت را ادغام کنند، آنها میتوانند فریمورکهای UI جایگزین مانند Vue، Svelte و Solid را نیز انتخاب کنند.
فقط همین هفته، Netlify و Astro اعلام کردند که بهصورت رسمی با هم همکاری میکنند — بنابراین میتوانیم انتظار داشته باشیم که روایت "ساده نگه داشتن" بیشتر از سمت Netlify ادامه یابد.
نتیجهگیری: آیا به دنیای پس از ریاکت رسیدهایم یا خیر؟
هنوز زود است که اعلام کنیم ما در یک چشمانداز فرانتاند پسا-ریاکت هستیم، زیرا ریاکت — و فریمورکهای مرتبط مانند Next.js — همچنان بهشدت محبوب هستند. اما این حس وجود دارد که اکنون توسعهدهندگان رویکردهای جایگزین قابل توجهی برای انتخاب دارند. نه Astro و نه Svelte از روش DOM مجازی استفاده نمیکنند، بنابراین توسعهدهندگان میتوانند اکنون یک فریمورک وب انتخاب کنند که به ریاکت وابسته نیست (اگرچه Astro همچنان ریاکت را بهعنوان یک گزینه ارائه میدهد).
همچنین رویکرد "HTML-first" وجود دارد که مایکروسافت اج در حال پیگیری آن است، که الکس راسل (که عضو آن تیم است) آن را بهعنوان "یک معماری مدرن مبتنی بر Web Components و HTML-first" توصیف کرده است.
در هر صورت، توسعه فرانتاند دیگر مانند چند سال پیش به ریاکت وابسته نیست. اگر شما یک توسعهدهنده وب جدید هستید که وارد این حرفه میشوید، حتی ممکن است بهطور جدی به صرفنظر کردن از ریاکت فکر کنید — اگرچه بهطور مسلم این کار، چشمانداز شغلی کوتاهمدت شما را کاهش میدهد. اما این حداقل گزینهای است که باید بهطور جدی در نظر بگیرید و حتی ممکن است به شما کمک کند که شغلی با یک کارفرمای آیندهنگر پیدا کنید.