چرا وب مزخرفه؟!

این مقاله با یه سوال ساده شروع می‌شه: «چرا وب مزخرفه؟!». بدبینانه‌ست نه؟ متأسفانه اینجا امکانی برای نظرسنجی وجود نداره که ببینم همین ابتدای حرفم چند نفر با این موضوع موافق/مخالف هستن؛ اما توی چند سطر آتی دلیل این برداشت رو توضیح می‌دم. چون متن کمی طولانیه، حوصله به خرج بدید و صبر کنید.

از سادگی تا پیچیدگی

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

وب، بدون شک، یکی از مهم‌ترین دستاوردهای نوین ارتباطاتی بشر بوده. پیش از اومدن وب به عرصه‌ی وجود، فناوری‌های ارتباطی نوین، مدتها بود که دنیا رو تسخیر کرده بودن؛ مثلاً ابداع فناوری بی‌سیم حدود سال ۱۸۸۰ میلادی رخ داده و شالوده‌ی اینترنت دهه‌ی ۶۰ میلادی ریخته شده. تاریخ به ما می‌گه که وب، به معنای امروزی، اواخر دهه‌ی ۸۰ میلادی به وجود اومده، یعنی حدود ۳۰ سال پیش؛ اما مثل همه فناوری‌های جوان حوزه‌ی فناوری اطلاعات، رشدی به‌اندازه‌ی تاریخ بشر داشته.

پیش از وب، رسانه‌ها برای انتقال اطلاعات، که بهش جریانِ داده هم گفته می‌شه، استفاده می‌شدن. تلفن، رادیو و تلویزیون برای انتقال صدا و تصویر مدتها بود که شناخته شده بودن. از اینترنت، ابتدا برای جریانِ داده‌ای استفاده می‌شد که غالباً شکل خاصی نداشت و داده‌ها توسط خودِ نرم‌افزار تفسیر می‌شد. کمی بعد، کاربران اینترنت (که در بدو تنها سازمان‌های معدودی بودن)، شروع به توسعه‌ی پروتکل‌هایی کردن که در لایه‌ی کاربردی اینترنت، استانداردهایی برای تفسیر پیام به‌وجود بیارن. پروتکل FTP برای انتقال فایل (۱۹۸۰) و پروتکل SMTP برای انتقال نامه (۱۹۸۲)، از نام‌های آشنای این استانداردسازی‌ها هستن، که به دلیل سادگیِ پیاده‌سازی، فراگیر شدن. سال ۱۹۸۶، کارگروه IETF برای توسعه و مدیریت استانداردهای اینترنت به وجود اومد تا از هرج و مرج پروتکل‌ها در دنیای اینترنت جلوگیری کنه.

این پروتکل‌ها معمولاً برای انتقال پیام‌هایی با محتوای یک‌شکل طراحی می‌شدن؛ اما این نیاز احساس می‌شد که بتوان پیامی با محتوای متن، صوت و تصویر به طور هم‌زمان منتقل کرد. تیم برنرز-لی، پایه‌گذار وب، به دنبال قالبی بود که بشه از طریقش پیام‌هایی انتقال داد که شکل یکنواختی ندارن و اسمش رو گذاشت فرامَتن (البته این کلمه ابداع خودِ برنرز-لی نبود و به سال ۱۹۶۵ برمی‌گشت). این ایده باعث شد که سال ۱۹۹۱ پروتکل HTTP ایجاد بشه. پروتکل HTTP، سادگیِ اجداد خودش، مثل FTP و SMTP رو به ارث برد، که همگی مبتنی بر نوشته، فرمان‌هایی ساده و فراداده‌هایی همه‌فهم بودن. برای آشنایی با پروتکل HTTP و برای درک این سادگی، کافیه نگاهی به سند RFC این پروتکل در اینجا نگاهی بندازید.

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

سردرگمی توسعه‌دهنده‌ها و طراحان وب در هجمه‌ی استانداردهای شرکتی سال‌ها طول کشید، ولی در نهایت، انتشار استاندارد HTML5 در سال ۲۰۱۴، بازگشتی البته دیرهنگام به فرایند استانداردسازی وب بود. به سر عقل اومدن (نسبی) بازیگران اصلی صنعت وب گامی روبه‌جلو برای سادگی بود، اما متأسفانه تبعات جنگِ پیشین و معضلی به نام سازگاریِ عقب‌رو هنوز هم در استاندارد جدید باقی موند و شاید سال‌های بیشتری باید بگذره تا به مقصود برسه. بررسی موردی این پیچیدگی‌ها، که بیشترِ طراحان وب باهاش آشنا هستن، اون قدر مفصله که مقاله‌ی جدایی می‌خواد.

تغییر میدان مبارزه

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

جاواسکریپت، در سال ۱۹۹۵ توسط نت‌اسکیپ، برای افزودن پویایی به HTML به وجود اومد؛ اما مثل تمام استانداردهای دیگه‌ی وب دست‌نخورده باقی نموند و به سرعت پیچیدگی‌هایی بهش اضافه شد که خوشایند برنامه‌نویس‌ها نبود. حکمرانی چهارچوب‌های کاریِ جاواسکریپتی با ظهور jQuery در سال ۲۰۰۶، تنها برای یک منظور عالی توسط خود برنامه‌نویس‌ها آغاز شد و اون برگردوندن سادگی به عرصه‌ی طراحی وب بود (البته jQuery تقریباً هم‌زمان با YUI توسعه پیدا کرد ولی تأثیر خیلی زیادی در بازنگری و بازطراحی YUI داشت). پس از jQuery، چهارچوب‌های دیگه‌ای هم ایجاد شد که هر کدوم برای رفع نیازی توسط تیم‌های کوچک برنامه‌نویسی توسعه پیدا می‌کردن. (امروز، تعداد این چهارچوب‌ها از هزار گذشته؛ فهرستی از چهارچوب‌های کاری جاواسکریپتی رو می‌تونید اینجا ببینید.)

محبوبیتِ چهارچوب‌های کاری جاواسکریپتی، البته از نظر شرکت‌های بزرگ هم دور نموند و به‌زودی پای اونها رو به این حوزه هم باز کرد. چهارچوب‌های Angular گوگل (۲۰۱۰) و React فیس‌بوک (۲۰۱۳) با پشتیبانی شرکت‌های سازنده‌شون و با شتاب به چنان محبوبیتی رسیدن که امروز به مهمترین بازیگران این حوزه بدل شدن. اما محبوبیت این دو چهارچوب دیگه فقط به انتخاب طبیعی خودِ برنامه‌نویس‌ها نبود. معرفی و تبلیغات نقش مؤثرتری در انتخاب داشت؛ و به همین راحتی، اصلِ سادگی در هیاهوی شرکت‌های بزرگ گم شد.

در واقع رقابت فناورانه‌ی شرکت‌های بزرگ، بعد از پایان رقابت بر سر استانداردهای اصلی، تموم نشد و فقط به حوزه‌ی دیگه‌ای سرایت کرد. اما این بار نهادی برای مدیریت استانداردهای چهارچوبی جاواسکریپتی (مانند IETF برای اینترنت و W3C برای وب) وجود نداشت و استانداردهای شرکتی دوباره بر سر کار اومدن؛ و امروز سردرگمی و دعوای برنامه‌نویس‌ها بر سر اینکه کدوم چهارچوب بهتره، همچنان ادامه داره.

این، همه‌ی ماجرا نیست...

یکی از ویژگی‌های بارز پروتکل HTTP، ارائه‌ی مفهوم URL برای نامیدن، مکان‌یابی و دسترسی به منابع در وبه. یک URL در کنار یکی از روش‌های درخواست HTTP، عمل واحدی رو، شامل گرفتن، ایجاد، به‌روزرسانی و غیره، برروی یکی از منابع وب، توصیف می‌کنه. استانداردهای IETF ساختار URL رو برای مکان‌یابی منابع وب به‌خوبی تعریف می‌کنن، اما در تعریف منابع وب به این جمله اکتفا می‌کنند که: یک منبع وب هر چیزیه که از طریق شبکه‌ی جهانی وب قابل دستیابیه؛ و این ابهام در تعریف منابع وب سرآغاز مشکلات برنامه‌نویس‌ها در طراحی API شد.

بزرگترین نقش رو در دامن زدن به آتش این مشکلات، خواسته یا ناخواسته، پایگاه‌های داده دارن. پایگاه‌های داده‌ی رابطه‌ای از قدیم‌الایام (از دهه‌ی ۷۰ میلادی)، هنوز هم پراستفاده‌ترین قشر پایگاه‌های داده رو تشکیل می‌دن (نک‍. سهم پایگاه‌های داده از بازار). با گذشت این همه سال و با توسعه و محبوبیت روزافزون زبان‌های برنامه‌نویسی شیءگرا، پایگاه‌های داده‌ای رابطه‌ای (به طور کلی) هنوز هم از ساختار مسطح جدول‌ها و ستون‌ها برای ذخیره‌ی اطلاعات استفاده می‌کنن که چندان ارتباطی به مفهوم شیء، وراثت و مخفی‌سازی نداره. البته مدتهاست که برنامه‌نویس‌ها با این ناهماهنگی کنار اومدن، اما اثری که این پایگاه‌های داده روی شیوه‌ی ارائه‌ی داده‌ها در وب گذاشتن، اثری منفی بوده؛ که چهارچوب‌های برنامه‌سازی از شراکت در این جُرم باز هم بی‌نصیب نبوده‌ن.

برای شفاف‌تر شدن مطلب، از مثال همیشگیِ یک سیستم فروش آنلاین استفاده می‌کنم. امروز دیگه کسی از اینکه یک برنامه‌نویس، یک API برای گرفتن فهرست سفارش‌ها، یک API برای گرفتن اطلاعات اولیه‌ی سفارش و یک API جداگانه برای گرفتن اطلاعات تک‌تکِ اقلامِ فروخته‌شده‌ی هر سفارش، طراحی کنه، تعجبی نمی‌کنه. طراحی API به این شیوه، نتیجه‌ی طبیعی پیروی از ساختار داده در پایگاه‌های داده‌ی رابطه‌ایه؛ به هر حال اطلاعات سفارش و اقلام فروخته‌شده در جدول‌های جداگانه‌ای ذخیره شدن، درسته؟ (برای درک ایراد این طراحی به این فکر کنید که اگه در نرم‌افزارتون بخواید اطلاعات سفارش رو برگردونید چطور عمل می‌کنید، یا اینکه اگه از پایگاه داده‌ای غیررابطه‌ای استفاده می‌کردید، طراحی API چه تغییری می‌کرد.)

امروز کتاب‌های زیادی در مورد یک طراحی خوب API نوشته شده و هر کدوم از جنبه‌ای به این مشکل پرداختن، اما هیچکدوم تبدیل به استاندارد نشدن. استانداردهایی مثل REST و HATEOS هم به نظم بخشیدن به API کمک می‌کنن، اما باز هم در مورد تعریف منبع وب ابهام رو باقی می‌گذارن.

چرا وب مزخرفه؟

حالا به این سؤال برمی‌گردم که: چرا وب مزخرفه؟ چون مبهم و پیچیده‌ست؛ اما این پیچیدگی نشأت گرفته از ایده‌ی طراحان اصلی و پایه‌گذارانش نیست، بلکه ما برنامه‌نویس‌ها پیچیده‌ش کردیم. پیچیدگی، یادگیری و انتخاب رو خیلی سخت و طاقت‌فرسا کرده. این پیچیدگی تا جایی پیش رفته که شرکت‌ها به جای برنامه‌نویس جاواسکریپت، مثلاً دنبال برنامه‌نویس React هستن و به جای برنامه‌نویس PHP، دنبال برنامه‌نویس لاراول. خودِ زبان‌های برنامه‌نویسی به‌ندرت تغییر بنیادی می‌کنن، اما این وضعیت باعث شده که اگه روزی این استانداردهای شرکتی و این چهارچوب‌ها اصطلاحاً از مُد بیفتن، برنامه‌نویس‌ها باید دنبال یادگیری چهارچوب‌های جدیدی باشن تا بتونن شغل خودشون رو حفظ کنن (به یاد داشته باشید ده سال پیش YUI یکی از چهارچوب‌های پرطرفدار بوده اما الان حتی اسمی ازش برده نمی‌شه).

شرکت‌های بزرگ در تولید و اشاعه‌ی پیچیدگی‌ها، همون طور که اشاره کردم، نقش ویژه‌ای دارن؛ اما اگه ما برنامه‌نویس‌ها در انتخاب، محبوبیت رو (که با تبلیغات و پول قابل خریدنه) جایگزین منطق و اصول همه‌فهم نمی‌کردیم، اونها به هدف‌شون می‌رسیدن؟

جمع‌بندی: چه باید کرد؟

فراموش نکنیم که تمام فناوری‌های ارتباطی، هرچند در پیاده‌سازی سخت و پیچیده بوده‌ن، اما برای پاسخ به نیازهای ساده‌ای ایجاد شده‌ن:

• من می‌خوام بتونم پیامم رو به تمام دنیا ارسال کنم (اینترنت).
• من می‌خوام ارتباطی مطمئن بر بستر اینترنت داشته باشم (TCP).
• من می‌خوام بتونم در کنار متن، داده‌های چندرسانه‌ای و ارتباط بین اطلاعاتم رو ارسال کنم (HTTP).
• و غیره.

نیازهای ساده، نیاز به ابزارهای ساده دارن. در گذشته، طراحان پروتکل‌ها همیشه اصل سادگیِ کاربری رو مقدم بر هر اصل دیگه‌ای دونستن؛ این اصل باید همیشه در طراحی نرم‌افزارها، رابطهای کاربری و API ها لحاظ بشه.

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

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

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