محدودیت‌های تعامل با جاوااسکریپت

بسیاری از زبان‌های برنامه‌نویسی دارای یک رابط تابع خارجی یا FFI هستند که امکان فراخوانی مستقیم توابع در زبان میزبان را فراهم می‌کند. برای نمونه، Haskell می‌تواند بطور مستقیم توابع C را فراخوانی کند. سایر نمونه‌ها عبارتند از:

• فراخوانی مستقیم توابع C از Python
• فراخوانی مستقیم توابع Objective-C از Swift
• فراخوانی مستقیم توابع Java از Scala

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

چرا Elm انتخاب متفاوتی نسبت به سایر زبان‌های برنامه‌نویسی در این زمینه داشته است؟

مزایا و معایب

مفهوم پورت به نوعی در تاریخ زبان‌های برنامه‌نویسی استثنایی است. دو استراتژی رایج برای تعامل بین دو زبان وجود دارد و Elm هیچ کدام از آن‌ها را انتخاب نکرده است:

1. سازگاری کامل با نسخه قبلی: برای نمونه، ++C یک پیاده‌سازی از C و TypeScript یک پیاده‌سازی از JavaScript است. این رویکرد بیشترین آزادی در عملکرد را دارد و بطور فوق‌العاده‌ای موثر بوده است. در حقیقت، همه در حال حاضر از زبان برنامه‌نویسی شما استفاده می‌کنند.
2. رابط تابع خارجی: این امکان را می‌دهد که به توابع زبان میزبان بطور مستقیم دسترسی داشته باشید. برای نمونه، Haskell می‌تواند بطور مستقیم توابع C را فراخوانی کند. دوباره، این موضوع بطور قابل توجهی موثر بوده است.

این مسیرها برای پذیرش سریع‌تر و انعطاف‌پذیری بیشتر جذاب هستند، اما برای Elm به دو دلیل اصلی ایده‌آل نیستند:

1. از دست دادن تضمین عملکرد. یکی از بهترین ویژگی‌های Elm این است که دیگر نیازی به نگرانی درباره مجموعه‌ای از مشکلات عجیب و غریب ندارید. هیچ استثنای غافلگیرکننده‌ای وجود ندارد و توابع نمی‌توانند داده‌ها را به روش‌های غافلگیرکننده تغییر دهند. فکر می‌کنم این ارزش اصلی Elm نسبت به زبان‌های مشابه است، اما اگر بتوانیم بطور مستقیم جاوااسکریپت را فراخوانی کنیم، همه این‌ها از بین می‌رود. آیا این بسته خطای زمان اجرا تولید می‌کند؟ کِی؟ آیا مقادیری که به آن می‌دهم را تغییر می‌دهد؟ آیا نیاز به شناسایی آن دارم؟ آیا شامل عوارض جانبی می‌شود؟ آیا به برخی سرورهای شخص ثالث پیام ارسال می‌کند؟ آیا گذرواژه‌ها را ثبت می‌کند؟ بخش قابل توجهی از کاربران Elm بطور خاص به این زبان جذب شده‌اند زیرا دیگر نیازی به فکر کردن به این مسایل ندارند.
2. سیل بسته‌های نرم‌افزاری. تقاضای زیادی برای کپی مستقیم APIهای جاوااسکریپت به Elm وجود دارد. دو سال قبل از ایجاد بسته elm/html، اطمینان دارم اگر ممکن بود، کسی به تبدیل کد jQuery کمک می‌کرد. این موضوع در زبان‌های تابعی که به جاوااسکریپت کامپایل می‌شوند، اما طراحی‌های تعامل سنتی‌تری دارند، قبلا اتفاق افتاده است. تا جایی که می‌دانم، سیل بسته‌های نرم‌افزاری به نوعی منحصر به زبان‌های قابل کامپایل به جاوااسکریپت است. برای نمونه، این موضوع درباره پایتون به هیچ وجه به این اندازه مطرح نیست، بنابراین فکر می‌کنم این مشکل، نتیجه فرهنگ و تاریخ منحصر بفرد اکوسیستم جاوااسکریپت باشد.

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

• بسته‌ها برای Elm طراحی شده‌اند. با افزایش تجربه و اعتماد به نفس جامعه کاربری، شروع به مشاهده رویکردهای نوین در طراحی رابط کاربری و تجسم داده‌ها می‌کنیم که بطور یکپارچه با معماری Elm و اکوسیستم آن کار می‌کنند. انتظار دارم این روند با سایر بخش‌ها نیز ادامه یابد!

• کد قابل حمل است. اگر روزی کامپایلر خروجی x86 یا WebAssembly تولید کند، اکوسیستم به کار خود ادامه می‌دهد، اما سریع‌تر! پورت‌ها تضمین می‌کنند که تمام بسته‌های نرم‌افزاری بطور کامل به زبان Elm نوشته شوند و خود Elm به گونه‌ای طراحی شده است که خروجی کامپایلر بجز جاوااسکریپت نیز قابل قبول باشد.

• بسته‌ها امن‌تر هستند. زبان‌هایی مانند جاوااسکریپت نگرانی‌های جدی امنیتی با بسته‌های نرم‌افزاری دارند. گزارش‌هایی از سرقت اعتبارنامه‌ها و سرقت کلیدهای API غیر معمول نیستند و هزینه دایمی بازبینی امنیتی را بر تمام بسته‌های نرم‌افزاری تحمیل می‌کنند. آیا آن‌ها یک keylogger به window اضافه می‌کنند؟ بسته‌های Elm می‌توانند تضمین کنند که مجموعه کاملی از سواستفاده‌های امنیتی به سادگی نمی‌توانند اتفاق بیفتند، این کار منجر به کاهش هزینه‌های ممیزی امنیتی می‌شود.

• بهینه‌سازی آسان‌تر است. سَبک کد خروجی در گذشته از نسخه‌ای به نسخه دیگر بطور قابل توجهی تغییر کرده است. برای نمونه، نسخه 0.19 توانست اندازه فایل خروجی را بطور چشمگیری کاهش دهد. اینکار با (۱) تولید کد به گونه‌ای که بهتر با مینیفایرهای جاوااسکریپت کار کند و (۲) استفاده از نمایش‌های زمان اجرای مختلف از نوع داده سفارشی بسته به سطح بهینه‌سازی انتخابی، انجام شده است. انتظار دارم این موضوع دوباره برای Code Slicing یا اگر یک قرارداد فراخوانی سریع‌تر برای Currying پیدا کنیم، تغییر کند. علاوه بر این، کامپایلر می‌تواند با اطمینان فرض کند که تمام کد خالص است، که ممکن است به آن اجازه دهد کد را بطور تهاجمی‌تری نسبت به سایر کامپایلرها جابجا کند. در حال حاضر، قفل شدن به یک قرارداد فراخوانی خاص، احتمالا برخی از این بهینه‌سازی‌ها را غیرممکن می‌کند.

این مسیر طولانی و دشوار است، اما زبان‌های برنامه‌نویسی برای بیش از ۳۰ سال زنده می‌مانند. آن‌ها باید از تیم‌ها و شرکت‌ها به مدت دهه‌ها حمایت کنند و وقتی به این فکر می‌کنم که Elm در ۲۰ یا ۳۰ سال آینده چگونه خواهد بود، فکر می‌کنم مزایا و معایب ناشی از پورت‌ها واقعا امیدوارکننده به نظر می‌رسند! سخنرانی من با موضوع What is Success کمی کند شروع می‌شود، اما به این موضوع بیشتر می‌پردازد!

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