چرا پلیفیلها هنوز برای وب خوبن
فرانتاند
جاوااسکریپتخلاصهٔ کاملتر
به گفتهٔ لیا وِرو، خیلی از توسعهدهندههای وب حتی نمیدونن که کسی ممکنه مخالف پلیفیل باشه. ولی تو یه جلسهٔ اخیر WHATWG که او پیشنهادی دربارهٔ گسترش mutation observerها ارائه کرده، اَن ون کِستِرن — که ویراستار فعال اصلی بیشتر استانداردهای WHATWG (HTML، DOM، Fetch و...) و مهندس WebKit در اپله — نظر داده که پلیفیلکردن مضره. وِرو میگه با پرسوجو فهمیده این نظرِ کل جامعه نیست، ولی دیدگاهها از اون چیزی که فکر میکرد دودلتر بودن.
استدلال محوریش اینه: چیزی که انعطاف طراحی رو محدود میکنه خودِ پلیفیل نیست، بلکه اینه که توسعهدهندهها میخوان وقتی رفتار نیتیو وجود داره ازش استفاده کنن و وقتی نیست، چیزی نشکنه. این ریسک برای هر الگوی fallback هست — از پراپرتیهای CSS برای بهبود تدریجی گرفته تا importهای شرطی بعد از تشخیص ویژگی. پس حذف پلیفیلها نیازو از بین نمیبره؛ ضمن اینکه بقیهٔ راهها قابلحمل و درست نیستن. باگ یه پلیفیل رو میشه مرکزی رفع کرد، ولی باگ یه فالبک دستساز رو باید تو همهٔ جاها پیدا کنی.
به گفتهٔ او یکی از بزرگترین مزیتهای پلیفیل جداکردن طراحی API از پیادهسازیه: خودِ API رو استاندارد تعیین میکنه و پلیفیل فقط پیادهسازیو میده، پس عوضکردن یه پلیفیل بدرفتار با یکی دیگه تقریباً هیچ هزینهای نداره. مهمتر اینکه پلیفیلها تعادل قدرتو برمیگردونن؛ مثال تاریخیش IE7.js و html5shiv بود که به توسعهدهندهها اجازه داد سالها قبل از پشتیبانی IE از استانداردهای مدرن استفاده کنن، و همین کمک کرد بالاخره از IE6 و IE7 عبور کنیم.
نویسنده پلیفیل رو برای پلتفرم وب مثل «تست کاربر» برای طراحی محصول میدونه؛ پلیفیل عملاً یه نمونهٔ اولیه از خودِ ویژگیه که بازخورد واقعی میده بدون اینکه بدهی فنی رو تو پلتفرم دائمی کنه. حتی میگه شاید مرورگرها باید خودشون این پلیفیلها رو بسازن. او فرایند WHATWG رو هم نقد میکنه که واکنشیه و تا وقتی دو پیادهساز ابراز علاقه نکنن ویژگیو جلو نمیبره، در حالی که خودِ نشوندادن نیاز توسعهدهندهست که در وهلهٔ اول علاقهٔ پیادهسازها رو میسازه.
در نهایت وِرو میگه این یه بحث هزینه-فایدهست. ما هواپیماها رو زمینگیر نمیکنیم چون سقوط اتفاق میافته؛ post-mortem میکنیم تا ریشهشو پیدا کنیم، نه اینکه کل ناوگانو بخوابونیم. تو بیش از ۳۰ سال تاریخ وب، موارد شکست پلیفیل انگشتشماره و معمولاً خوب مدیریت شدن (حتی «smooshgate» به array.flat() ختم شد). بهجای تلاش برای حذف پلیفیلها، باید فعالتر نیازهای توسعهدهندهها رو کشف کرد تا یه پلیفیل هیچوقت اونقدر محبوب نشه که فضای طراحی API نیتیو رو تهدید کنه.
نکات کلیدی:
- یه ویراستار بانفوذ استانداردهای وب گفته پلیفیل مضره؛ لیا وِرو محکم مخالفت میکنه
- حذف پلیفیلها نیاز بهشونو از بین نمیبره و راههای جایگزین بدترن
- پلیفیل طراحی API رو از پیادهسازی جدا میکنه، پس تعویضش تقریباً بیهزینهست
- پلیفیلها تعادل قدرتو برمیگردونن؛ عبور از IE6/IE7 مدیون همینها بود
- پلیفیل مثل نمونهٔ اولیه/تست کاربره: بازخورد واقعی بدون بدهی فنی دائمی
