رابط کاربری بومی در مقابل رابط کاربری وب: چگونه انتخاب کنیم

چه زمانی توسعه یک برنامه دسکتاپ بومی یا برنامه وب UI مبتنی بر Electron منطقی‌تر است؟ ما این را برای شما توضیح می‌دهیم.

وقتی دربارهٔ «برنامهٔ دسکتاپ» صحبت می‌کنیم، عموماً منظورمان برنامه‌ای است که با رابط کاربری گرافیکی بومی برای پلتفرم اجرا می‌شود یا توسط ابزارک تصویری چندپلتفرمی پشتیبانی می‌شود. اما امروزه یک برنامهٔ دسکتاپ به همان اندازه می‌تواند صفحهٔ وب زیبایی باشد که در یک نمونهٔ مستقل مرورگر اجرا می‌شود.

اگر این به‌نظر انتقادی می‌آید، چنین نیست. برنامهٔ دسکتاپ با رابط کاربری وب امکان ارائهٔ رابط‌های کاربری غنی را با استفاده از تمام فرهنگ موجود مؤلفه‌های رابط کاربری وب فراهم می‌کند. با این حال، این قدرت و انعطاف‌پذیری هزینه‌ای دارد – به‌قدری که تلاش برای توسعهٔ یک برنامهٔ دسکتاپ بومی ممکن است ارزشمند باشد.

به‌طور دقیق برنامهٔ دسکتاپ بومی چیست؟

در واقع، ما چه چیزی را «بومی» می‌نامیم؟

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

برنامه‌های دسکتاپی مانند Visual Studio Code یا کلاینت Slack مبتنی بر وب هستند. آنها بر پایه فناوری‌هایی مانند Electron یا Tauri ساخته می‌شوند، جایی که لبهٔ جلو برنامهٔ شما با HTML، CSS و JavaScript ساخته می‌شود. (بخش پشتی نیز می‌تواند JavaScript باشد اما الزامی نیست.)

برنامه‌های دسکتاپ واقعی مانند محصول کامل Visual Studio، Microsoft Word یا Adobe Creative Suite از لبهٔ جلو یا بسته‌بندی مبتنی بر وب استفاده نمی‌کنند. بخشی از این به دلیل بار کدهای ارثی است که پیش از برنامه‌های رابط کاربری وب و Electron ساخته شده‌اند: اگر کار نمی‌کند، تغییرش ندهید. اما برنامه‌های بومی همچنین کنترل دقیق‌تری بر تجربه کاربری ارائه می‌دهند، هرچند به هزینهٔ نیاز به توسعهٔ بیشتر.

مزایای برنامه‌های مبتنی بر وب

بزرگ‌ترین مزیت یک برنامهٔ وب UI نسبت به یک برنامهٔ دسکتاپ بومی توانایی آن در بهره‌گیری از اکوسیستم عظیم مؤلفه‌های UI مبتنی بر وب است. اگر عنصری از UI می‌خواهید به کاربر نشان دهید، احتمالاً یک نسخهٔ وب از آن وجود دارد. نه تنها این، بلکه پیاده‌سازی آن اغلب بسیار آسان‌تر از نسخهٔ بومی پلتفرم است.

چون مؤلفه‌های وب این‌قدر عمومی هستند، بازاستفاده از یک مؤلفه برای برنامهٔ وب UI بسیار آسان‌تر از استفاده از ویجتی است که برای ابزارک یا سیستم پنجره‌ای دیگری نوشته شده باشد. این فقط شامل مؤلفه‌های رایج مانند فرم‌ها و فیلدهای ورودی نیست، بلکه رابط‌های پیچیده‌تری مانند نمودارهای تعاملی ۳‑بعدی نیز می‌شود. تقریباً تمام آنچه می‌تواند بخشی از UI یک برنامهٔ بومی باشد، می‌تواند به‌عنوان یک مؤلفهٔ وب ارائه شود.

برنامه‌های وب UI همچنین قابلیت حمل‌پذیری را ارائه می‌دهند. ارائهٔ یک نسخهٔ چندپلتفرمی از یک برنامهٔ وب UI بسیار آسان‌تر از همتای بومی آن است. تقریباً تمام انتزاع‌های مربوط به پلتفرم، مانند نحوهٔ کار با کلیپ‌بورد، توسط زمان‌اجرای مرورگر مدیریت می‌شود.

معایب رابط‌های وب برای برنامه‌های دسکتاپ

تمام مزایای مذکور برای رابط‌های وب همراه با معایبی هستند. بزرگ‌ترین معضل، وابستگی به مرورگر وب است — چه مرورگری که همراه با برنامه بسته‌بندی شده باشد و چه نمای وب بومی روی پلتفرم هدف.

بسته‌بندی یک مرورگر با برنامه رایج‌ترین رویکرد است؛ این همان کاری است که Electron و شاخه‌های آن انجام می‌دهند. این به توسعه‌دهندگان امکان کنترل دقیق بر این که کدام نسخهٔ مرورگر استفاده شود، چه نیازهایی پشتیبانی می‌کند و چگونه این نیازها را برآورده می‌کند، می‌دهد. اما این کنترل هزینهٔ بزرگی در حجم باینری دارد. بسته‌های مرورگر می‌توانند حتی برای برنامهٔ سادهٔ «سلام دنیا» تا حدود ۱۰۰ مگابایت برسند.

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

اگر از ویژگی‌های پیشرفتهٔ مرورگر استفاده نمی‌کنید، معمولاً می‌توانید با استفاده از نمای وب کار کنید. اما اگر کاری انجام می‌دهید که شامل، به عنوان مثال، WebAssembly یا سایر فناوری‌های مرورگر در حال توسعه سریع باشد، می‌توانید به‌طور ایمن فرض کنید نمای وب پلتفرم حداقل یک سال از نسخه‌های جاری مرورگر عقب خواهد ماند.

یکی دیگر از محدودیت‌های مهم این است که هر تعامل بین UI برنامه و بخش پشتی تنها به آنچه مرورگر می‌تواند پشتیبانی کند محدود است. در بیشتر موارد، این به این معنی است که باید این تعاملات را به آنچه می‌تواند از طریق یک سوکت شبکهٔ محلی بین مرورگر و بخش پشتی عبور کند، محدود کنید. در نظریه می‌تواند شامل افزونهٔ مرورگر یا «گسترش مؤلفه» (از طریق Chrome) باشد، اما اکثر رابط‌های وب از اتصال شبکه‌ای استفاده می‌کنند.

یک روش اصلی که این می‌تواند ظاهر شود، تأخیر UI است. به‌روزرسانی‌های زمان واقعی که از یک بخش پشتی به مرورگر جریان می‌یابند، توسط پشتهٔ شبکه محدود می‌شوند. کارهای پرکاربرد از نظر عملکرد می‌توانند به مرورگر منتقل شوند — به عنوان مثال، به‌عنوان یک ماژول WebAssembly — اما با این هزینهٔ احتمالی افزودن زبان یا مجموعه‌ای دیگر از مراحل ساخت به نیازهای پروژه.

چگونه بین برنامهٔ بومی یا وب UI انتخاب کنیم

یک برنامهٔ کاملاً بومی — که بدون نیاز به وب UI اجرا می‌شود — احتمالاً بهترین انتخاب شما است زمانی که معیارهای زیر را داشته باشید:

• یک وب UI ضروری نیست. برای مثال، یک ابزار خط فرمان سبک می‌تواند یک رابط وب اختیاری برای راحتی داشته باشد اما برای عملکرد به آن نیاز ندارد.
• حجم محصول تحویلی مهم است. (مثال ابزار خط فرمان نیز در اینجا قرار می‌گیرد.)
• می‌خواهید تا حد امکان لایه‌های بین برنامه و سیستم عامل یا زیرساخت را کاهش دهید.
• UI نیاز به حداقل تأخیر دارد، یا کدهای حساس به عملکرد نمی‌توانند در مرورگر اجرا شوند.

یک وب UI در موارد زیر بیشترین معنای خود را دارد:

• حجم محصول تحویلی قابل مذاکره است.
• سهولت استفاده از مؤلفه‌های وب برای لبهٔ جلو برای توسعه مداوم برنامه ضروری است.
• قابل‌قبول است که با زیرساخت سیستم از طریق انتزاع‌های ارائه‌شده توسط مرورگر کار کنید.
• لبهٔ جلو نیازی به کم‌ترین تأخیر ممکن نسبت به بخش پشتی ندارد. (یا زمانی که هر رفتار حساس به عملکرد می‌تواند به مرورگر منتقل شود.)

خط بین برنامه‌های محلی و برنامه‌های وب در حال محو شدن است و این وضعیت برای مدتی ادامه دارد. وب به یک پلتفرم کاربردی مستقل تبدیل شده است که امکاناتی فراهم می‌کند که برنامه‌های دسکتاپ سنتی سخت می‌توانند آن را برآورده کنند. اما دسکتاپ و خط فرمان همراه آن ناپدید نشده‌اند و دلیل خوبی برای این وجود دارد.