فلاتر یا ری اکت نیتیو

تفاوت واقعی این دو کجاست؟

در یک جمله از خود مستندات هر کدام. پرسش و پاسخ رسمی فلاتر می پرسد آیا فلاتر از ویجت های داخلی سیستم عامل استفاده می کند و جواب خودش را با یک کلمه شروع می کند: نه. فلاتر مجموعه ویجت های خودش را دارد، شامل متریال و کوپرتینو، که چارچوب و موتور خودش آنها را مدیریت و رسم می کنند. در سمت مقابل، مستندات ری اکت نیتیو می گوید در زمان اجرا، ری اکت نیتیو ویوهای متناظر اندروید و iOS را برای کامپوننت های شما می سازد، و چون کامپوننت ها پشتشان همان ویوهای پلتفرم است، اپ مثل هر اپ دیگری به نظر می رسد و رفتار می کند.

پس دو مسیر متفاوت برای رسیدن به یک تصویر. فلاتر مثل یک موتور بازی رفتار می کند: بوم خودش را می گیرد و همه چیز را روی آن می کشد. خود مستندات فلاتر همین تشبیه را می کند وقتی توضیح می دهد کد دارت روی iOS به یک کتابخانه ARM بومی کامپایل می شود و داخل یک پروژه runner قرار می گیرد. ری اکت نیتیو در عوض مثل یک راننده رفتار می کند: خودش چیزی نمی کشد و به ویوهای پلتفرم می گوید چه کار کنند.

این تفاوت دو نتیجه عملی دارد که در تصمیم گیری به کار می آیند. اول، وقتی سیستم عامل ظاهر کامپوننت هایش را عوض می کند، اپ ری اکت نیتیو همراهش عوض می شود و اپ فلاتر همان است که بود، تا وقتی خودتان به روزش کنید. دوم، اگر رابط شما باید روی اندروید و iOS دقیقا یکسان دیده شود، فلاتر آن را رایگان به شما می دهد و ری اکت نیتیو نه.

کدام یک بهتر است؟ هیچ کدام. این دو جواب دو سوال متفاوت اند و بقیه این درس درباره این است که سوال شما کدام است.

دارت یا جاوااسکریپت؛ کدام برای تیم شما ارزان تر است؟

فلاتر با دارت نوشته می شود. سایت خود دارت آن را زبانی توصیف می کند که برای سمت کاربر بهینه شده و هدفش ساخت اپ سریع روی هر پلتفرمی است، و می گوید دارت پایه فلاتر را هم تشکیل می دهد. پرسش و پاسخ فلاتر توضیح می دهد چرا دارت انتخاب شد: ترکیب دو چیز، یک چرخه توسعه سریع مبتنی بر JIT که هات ریلود با حفظ وضعیت را ممکن می کند، و یک کامپایلر پیش از اجرا که کد ARM کارآمد تولید می کند.

ری اکت نیتیو با جاوااسکریپت و ری اکت نوشته می شود. مستندات خودش می گوید شما با جاوااسکریپت هم به ای پی آی های پلتفرم دسترسی پیدا می کنید و هم ظاهر و رفتار رابط را با کامپوننت های ری اکت توصیف می کنید.

حالا سوال عملی: کدام برای شما ارزان تر است؟ جواب تقریبا همیشه همان است که تیمتان بلد است. اگر توسعه دهنده وب دارید که ری اکت می نویسد، ری اکت نیتیو تقریبا از روز اول کار می کند و بخش زیادی از عادت ها و ابزارها منتقل می شوند. اگر تیمتان سابقه وب ندارد و از صفر شروع می کند، دارت زبان کوچکی است و یادگیری اش سخت تر از جاوااسکریپت نیست؛ در آن حالت این محور تصمیم نیست.

یک چیز را در مصاحبه استخدام زیاد می شنویم و درست نیست: اینکه دارت «زبان کمیابی» است و نیرو پیدا نمی شود. آنچه واقعا کمیاب است، توسعه دهنده موبایل باتجربه است، در هر دو اکوسیستم. کسی که ری اکت بلد است لزوما ری اکت نیتیو بلد نیست؛ چرخه انتشار، دیباگ روی دستگاه، امضا و ای پی آی های پلتفرم چیزهایی هستند که در وب یاد نمی گیرید.

اکوسیستم را چطور بسنجیم بدون تکیه بر عدد بی منبع؟

مقاله های مقایسه معمولا اینجا عدد سهم بازار می آورند. ما نمی آوریم، چون آن عددها منبع قابل استنادی ندارند و به هر حال به تصمیم شما ربطی ندارند. سوال درست این نیست که کدام اکوسیستم بزرگ تر است؛ این است که آن سه یا چهار قابلیتی که اپ شما بدون آنها کار نمی کند، در کدام اکوسیستم پشتیبانی زنده ای دارند.

پس فهرست خودتان را بنویسید. درگاه پرداخت، نقشه، نوتیفیکیشن، دوربین، اسکن بارکد، ورود با حساب، هر چه که هست. بعد برای هر کدام در ثبت کننده بسته همان اکوسیستم جستجو کنید: pub.dev برای دارت و فلاتر، و npm برای جاوااسکریپت.

و سه چیز را در هر بسته نگاه کنید که با شمردن ستاره پیدا نمی شوند. یک، تاریخ آخرین انتشار؛ بسته ای که یک سال است منتشر نشده روی نسخه بعدی سیستم عامل مسئله شماست. دو، اینکه بسته یک SDK بومی را می پیچد یا خودش پیاده سازی کرده؛ بسته ای که SDK رسمی را می پیچد معمولا با به روزرسانی آن SDK هم راه می آید. سه، اینکه issue های باز درباره همان پلتفرمی هستند که برای شما مهم است یا نه.

یک نکته که در هر دو اکوسیستم یکسان است و در تصمیم فراموش می شود: هر قابلیتی که به سخت افزار یا به یک سرویس پلتفرم وصل می شود، بالاخره یک نفر باید کد بومی اش را بنویسد. اگر بسته خوبی وجود داشته باشد، آن یک نفر شما نیستید. اگر نداشته باشد، شما هستید و باید در برآورد پروژه پیش بینی اش کنید. صفحه طراحی اپلیکیشن ما هم همین را می گوید: پیش از پیشنهاد هر مسیر، اول می پرسیم اپ قرار است چه کار کند.

پس کدام را انتخاب کنم؟

سه سوال، به همین ترتیب. اول، تیم شما امروز چه بلد است؟ اگر ری اکت می نویسند، ری اکت نیتیو انتخاب پیش فرض است و برای دور شدن از آن باید دلیل داشته باشید. دوم، رابط اپ چقدر اختصاصی است؟ اگر طرح شما پر از حرکت و شکل های غیراستاندارد است و باید روی هر دو پلتفرم مو به مو یکسان باشد، فلاتر همان چیزی است که برای این کار ساخته شده. سوم، چند SDK بومی باید وصل شود؟ هر چه این عدد بزرگ تر باشد، وزن اکوسیستمی که بسته زنده دارد بیشتر می شود، و این را باید برای پروژه خودتان بسنجید نه به طور کلی.

و موضع ما، که در صفحه های فروش کمتر نوشته می شود: برای اپ یک کسب و کار متوسط ایرانی، فهرست محتوا و فرم و پرداخت و نوتیفیکیشن، هر دو فریمورک جواب می دهند و انتخاب بین آنها گلوگاه پروژه نیست. گلوگاه معمولا جای دیگری است: بک اند، طراحی رابط، و اینکه چه کسی بعد از تحویل نگهش می دارد. اگر پیمانکاری انتخاب فریمورک را به مهم ترین تصمیم پروژه تبدیل کرد، احتمالا دارد از موضوع اصلی فرار می کند.

یک استثنای واقعی هم هست. اگر اپ شما بازی است یا رابط سنگین گرافیکی دارد، هیچ کدام از این دو جواب پیش فرض نیست و باید سراغ ابزار همان حوزه بروید. و اگر اپ فقط یک نسخه موبایلی از سایت شماست، شاید اصلا به اپ احتیاج ندارید؛ این سوال را قبل از انتخاب فریمورک بپرسید، نه بعدش.