اشکان محمدی
اشکان محمدی
خواندن ۴ دقیقه·۲ سال پیش

فریمورکی بهتر از react ؟؟

قضیه اینه که من همیشه از نحوه نوشتن کد های React متنفر بودم. کسانی که با React کار کرده اند می دونند که چقدر باید کد های طولانی و بی جهت بنویسیم فقط برای یه value binding ساده برای یک فرم! دنبال بهونه بودم از React فرار کنم و برم سمت یه فریمورکی که این همه boilerplate نداشته باشه. با یه سرچ اولیه به نظرم اومد که فریمورک های دیگه راه حل های بهتری برای پیاده سازی component logic دارند.

اول از همه رفتم سراغ svelte js که ببینم جدیدا چه چیزایی بهش اضافه/ازش حذف شده. دیدم که api های stable ای داره و از یک سال پیش تا الان تغییرات آن چنانی نکرده که باعث بشه با نسخه های قبل ناسازگار باشه. و اینکه متوجه شدم یه فریمورک SSR به نام svelte kit هم بر پایه sapper توسعه داده شده که نسبت اون با svelte js مثل نسبت next js به react js هست. یعنی در واقع svelte kit خودش نوعی metaframework محسوب میشه. با دیدن document هاش امیدوار شدم و تصمیم گرفتم یه پروژه starter باهاش راه بندازم و باهاش ور برم ببینم چند چنده.

از همون لحظه ای که تصمیم گرفتم از typescript استفاده کنم باگ ها شروع شد. هزار جور تنظیمات باید انجام بدی که یه Svg بتونی import کنی و استفاده کنی در حالی که next js همه این ها رو از قبل به صورت پیش فرض داره. هر چی هم path alias درست می کردم با typescript به مشکل می خورد در حالی که اصلا توی react من چنین مشکلی نداشتم.

تا اینجا کمی کوتاه اومدم و گشتم دنبال ui library های svelte js . با کمی جست و جو svelte material ui رو پیدا کردم که به اختصار بهش میگن smui. حالا حدس بزنید نحوه استفاده از این کتابخانه چطوری بود؟؟؟

  • باید خودت فایل های theme با فرمت scss رو از طریق خط فرمان generate کنی
  • بعد باید خودت اونها رو کامپایل و به html لینک کنی
  • هر گونه شخصی سازی رو باید از طریق css و سلکتور global: انجام بدی چون svelte نمی تونه استایل داخلی کمپوننت های smui رو دست کاری کنه

بگذریم از اینکه به خاطر selector specificity خیلی بالایی که selector های داخلی کمپوننت ها داشتند اصلا نمی شد از طریق class استایل ها رو اعمال کنی. تازه وقتی هم می خواستی بری سراغ دستکاری کردن کلاس های داخلی مشکل این بود که اسم کلاس ها رو از کجا بیاری!!؟؟؟؟؟ (هی هربار باید پنجره inspector رو باز می کردم که بتونم اسم کلاس های داخلی رو ببینم که این روش هم به درد نمی خورد چون اسمشون ممکنه توی نسخه های بعد عوض شه و استایل ها به فنا بره)

واقعا به اینجا که رسیدم دلم برای nextui تنگ شد. هر شخصی سازی به راحتی با پراپرتی css انجام میشد و از همونجا به تمام متغیر ها و color pallet های تم دسترسی داشتی. هیچ کدوم از این بازی های مسخره هم نیاز نبود. selector specificity هم دیگه مشکلی نبود چون این رو خود styled-components هندل می کرد.

از svelte ناامید شدم. پوسته قشنگی داشت و واقعا هم component logic رو به شیوهء بهتری نسبت به react اداره می کرد اما تو بحث styling اصلا DX رو در نظر نگرفته بود. تازه با typescript هم مشکل داشت.

حالا نوبت vue بود. ولی متاسفانه با دیدن ورژن جدیدش (v3) با دو دست دریغ به سرم کوبیدم. واقعا داشتم کلافه می شدم. نسخه جدید vue کاملا یک کپی مزخرف از hook های react بود که اسمش رو گذاشته بودن composition api.

همین که اسم یه سری پکیج رو سرچ کردم دیدم اکثرا یه پکیج جدا دارن برای v2 و یکی دیگه برای v3. بعضی ها هم که کلا از قافله جا مونده بودن. البته وقتی میزان تفاوت این دو ورژن رو با هم مقایسه کنید شما هم به این نتیجه می رسید که بایدم این طور باشه. وقتی توی یه ورژن پیاز تبدیل به تربچه میشه دیگه نباید انتظار migrate کردن از ورژن قدیمی رو داشت

این تناقض ها رو که دیدم فهمیدم که اصلا vue قابل اعتماد نیست و api های stable ای نداره.

پایتون وقتی از ورژن 2 به 3 اومد تنها تفاوتش توی عبارت print بود ?? ... ولی vue ... بگذریم.

خلاصه که دور هامو زدم و دوباره برگشتم به همون ری اکت قدیمی خودمون. پیچیده، مزخرف، تنفربرانگیز ولی کارراه‌بنداز، سرراست و پایدار.




reactprogrammingبرنامه نویسیمهندسی نرم افزارvue
یه برنامه نویس ساده که از تجربیات و آموخته هاش می نویسه
شاید از این پست‌ها خوشتان بیاید