چرا توسعه دهندگان بیشتر از پلت فرم استفاده نمی کنند؟

برای سال‌ها، مدافعان استانداردهای وب، عملکرد و دسترسی، از توسعه‌دهندگان وب درخواست کرده‌اند تا از پلتفرم استفاده کنند. من اغلب یکی از آن مدافعان بوده ام.

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

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

واضح‌ترین دلیل تاریخی است: برای طولانی‌ترین زمان، مرورگرها با اکوسیستم بالای خود بازی می‌کردند. کتابخانه‌هایی مانند jQuery شکاف‌های مهمی را پر می‌کردند در حالی که مرورگرها APIهای معادل را پیاده‌سازی می‌کردند – و حتی در آن زمان، ممکن است قبل از اینکه بتوانید واقعا از آنها استفاده کنید، منتظر بمانید تا عقب مانده‌هایی مانند IE6 از بین بروند. امروزه، بیشتر مرورگرها همیشه سبز هستند (سافاری قابل بحث است، اگرچه 7 بار در سال بد نیست)، اما تا سال 2020 یا بیشتر، توسعه دهندگان وب مجبور بودند با یک وب کاملا توده برخورد کنند. در آن محیط، چرخیدن خودتان یک انتخاب معقول است.

دلیل دیگر آشنایی است: وقتی عادت دارید به دنبال مؤلفه‌های React در npm بگردید، این همان چیزی است که بدون در نظر گرفتن مشکلی که در دست دارید، به دنبال آن هستید. اگر «موقعیت چسبنده» را در npm جستجو کنید، هیچ بسته‌ای وجود ندارد که بگوید «فقط از موقعیت CSS استفاده کنید: sticky، you dolt».

و اغلب، حتی با یک استاندارد قوی، کتابخانه های npm شکاف مفیدی بین ارگونومی چارچوب و پلت فرم زیر آن را پر می کنند. برای من همیشه جالب بود که بسیاری از توسعه‌دهندگان React ترجیح می‌دادند به اصطلاحات JSX و React بچسبند – APIهای DOM خام «بی‌خطر» به نظر می‌رسند – اما از استفاده از کتابخانه‌های سطح پایین‌تر در جایی که دستکاری‌های DOM خام رایج هستند، کاملا خوشحال بودند. به عنوان مثال، یک کتابخانه فهرست مجازی ممکن است با خوشحالی از APIهای DOM خام برای عملکرد خالص استفاده کند، در حالی که ابتدا موارد سطح بالاتری را که یک توسعه‌دهنده تازه‌کار React می‌تواند بهتر درک کند، در معرض دید قرار می‌دهد.

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

برخی از این تأثیر نیز توسط مستندات هدایت می شد. بسیاری از بسته‌های npm دارای جزئیات عاشقانه README یا وب‌سایت‌هایی با مثال‌ها، آموزش‌ها و تصاویر هستند. در حالی که تا زمانی که MDN به عنوان مکانی مناسب برای اسناد وب (با web.dev به عنوان بازوی آینده‌نگر گوگل) شناخته شد، اسناد پلتفرم وب در وبلاگ‌ها، StackOverflow و سایت‌هایی مانند ترفندهای CSS پراکنده بودند. و بسیاری از این سایت ها فقط به شما می گویند که از یک کتابخانه معروف مانند jQuery یا GreenSock استفاده کنید!

با این حال، اگر فقط در مورد کتابخانه های شخص ثالث در مقابل API های پلتفرم بود، فکر نمی کنم می تواند به طور کامل ضدیت نسبت به «استفاده از پلت فرم» را توضیح دهد. توسعه‌دهندگانی که تنبل هستند (یا تکرار می‌کنم؟)، و فقط یک راه‌حل آماده برای هر مشکلی که با آن روبرو هستند می‌خواهند، بعید به نظر می‌رسند که این راه‌حل از npm، مرورگر، یا کپی شده از GitHub Gist تصادفی کسی باشد. آنها می خواهند مشکل خود را حل کنند و ادامه دهند. اما منبع متفاوتی برای ضد «استفاده از پلتفرم» وجود دارد که می‌خواهم آن را بررسی کنم.

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

به عنوان مثال، بیایید تصور کنیم که در حال تلاش برای ایجاد یک گفتگوی مودال هستید. ممکن است از نظر بصری درک کنید که قرار است اینها چگونه کار کنند: محتوا روی صفحه ظاهر می‌شود، اما پس‌زمینه همچنان قابل مشاهده است، اگرچه تا حدی مسدود شده است، و شاید کلیک کردن در خارج از کادر گفتگو آن را رد کند. بنابراین ممکن است موقعیت:absolute و z-index را انتخاب کنید تا دیالوگ را به درستی قرار دهید - آها، اما پس‌زمینه همچنان پیمایش می‌کند، بنابراین باید سرریز روی بدنه را غیرفعال کنید... و سپس اگر چیزی در مورد دسترسی فهمیدید، متوجه می‌شوید که باید Esc را کنترل کنید تا رد کنید، و یک تله فوکوس بسازید، و فوکوس را به t برگردانید.

عنصری که دیالوگ را راه اندازی کرد و…

برای بسیاری از توسعه دهندگان، چیزی که من توضیح دادم مانند یک کابوس به نظر می رسد (و یک راه خوب برای ساختن چیزی که نیمه کاره است). اما برای بسیاری از توسعه دهندگان، این به نظر سرگرم کننده است! با شروع ساختن این چیز به این فکر کنید که چقدر یاد می گیرید. و به این فکر کنید که چگونه می‌توانید با افزودن انیمیشن‌ها، تم‌ها، یک دکمه «بستن» اختیاری شروع به قرار دادن چرخش خود در آن کنید... قبل از اینکه متوجه شوید، کتابخانه‌ای ساخته‌اید که برای npm آماده است. این بسیار سرگرم کننده تر از گرفتن <dialog> و نامیدن آن یک روز است - چه خراب!

و برای بسیاری از ما، قبل از اینکه APIهایی مانند <dialog> وجود داشته باشند، اینگونه بود که پلتفرم وب را یاد گرفتیم! بسیاری از افرادی که اکنون از "استفاده از پلتفرم" دفاع می کنند، زمانی خود نویسندگان پلی فیل ها، شیم ها و کتابخانه ها بودند. می دانم چون خودم یکی هستم! من سال‌ها بر روی ابزارسازی برای IndexedDB، WebSQL و سایر APIهای ذخیره‌سازی مرورگر به عنوان بخشی از کارم روی PouchDB کار کردم، که در نهایت باعث شد به اندازه کافی اعتماد به نفس داشته باشم تا در جلسات استانداردهای W3C بنشینم و حتی مسائل را باز کنم و درخواست‌ها را روی مشخصات IndexedDB بکشم.

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

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

و اگر منصف باشیم، درک CSS از لحاظ تاریخی سخت بوده است! دلیلی وجود دارد که سایت "ترفندهای CSS" نامیده می شود. چیزهایی مانند رفع روشن، شناورها، و حداقل عرض: 0 ترفند به سختی بصری هستند. به جای تلاش برای درک الگوریتم داخلی CSS، اغلب ساده تر است که منطق ضروری مورد نظر خود را تصور کنید و سپس آن را در جاوا اسکریپت بیان کنید. به‌علاوه، برای سال‌ها CSS راه ساده‌ای برای بیان الگوهای رایج مانند بستن خط، تغییر اندازه ناحیه متنی، پنهان کردن نوار اسکرول و غیره نداشت. بنابراین البته توسعه‌دهندگان خودشان آن را با استفاده از ابزارهایی که قبلا فهمیده‌اند ساخته‌اند.

من حتی فکر نمی کنم این پدیده "اجتناب از پلت فرم" به وب محدود شود. این می تواند برای هر توسعه دهنده ای که در بالای پلتفرمی کار می کند که کاملا درک نمی کند اعمال شود. به عنوان مثال، در محل کار من، ما از ClickHouse برای ذخیره انواع مختلف داده های تحلیلی استفاده می کنیم. در یک نقطه، من و همکارم در مورد نحوه ذخیره داده‌های بزرگ JSON در یک ستون با هم اختلاف نظر داشتیم: او سیستمی برای فشرده‌سازی آن‌ها قبل از ذخیره‌سازی ساخت، در حالی که من داده‌ها را در یک ذخیره‌سازی کلید-مقدار جداگانه قرار دادم و فقط کلید را در ClickHouse وارد کردم. معلوم شد هر دو اشتباه می‌کردیم!

ClickHouse به طور خودکار داده ها را فشرده می کند و به عنوان یک ذخیره داده ستونی، اگر فقط به ClickHouse اجازه مدیریت آن را بدهید، در واقع فشرده سازی بهتری در بین ردیف ها دریافت خواهید کرد. و فروشگاه مجزای کلید-مقدار فقط یک نسخه فقیر از کاری بود که یک SELECT ستونی قبلا انجام می‌داد.

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

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

من واقعا تلاش کرده‌ام که در کل این پست در مورد هوش مصنوعی صحبت نکنم (زیرا در طول یک سال گذشته این کار را تا حد مرگ انجام داده‌ام)، اما البته نمی‌توانم از خود فکر نکنم که چگونه کدنویسی هوش مصنوعی بر این پدیده تأثیر می‌گذارد. من در واقع هم یک برداشت خوش بینانه و هم بدبینانه دارم:

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

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

به همین دلیل، من مطمئن هستم که تا زمانی که پلتفرم وجود دارد، "استفاده از پلتفرم" را خواهیم شنید.

شما می توانید در مورد fediverse یا Lobsters نظر دهید.