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

* (الان که من این مقاله رو می‌نویسم چند ساعتی می‌شه که نسخه‌ی 0.5 هم اومده و نویسنده از امکانات آینده در نسخه‌ی 0.6 هم صحبت کرده.)
* برای اطلاعات بیشتر در مورد به وبلاگ مرتضی الوانی مراجعه کنید که توضیحات کاملی داده و تنها فارسی‌زبانی روی وب بود که من دیدم در مورد blueprint نوشته. (منم دوم! )

فریم‌ورک همیشه خوبه؟

فریم‌ورک، مجموعه‌ای از کتاب‌خانه‌ها، ابزارها و تعریف‌هایی است که به ما کمک می‌کنن در زمان کمتری کار بیشتر و مؤثرتری انجام بدیم. از جمله فریم‌ورک‌های وب، می‌شه از jQuery ،Prototype و YUI برای جاوا اسکریپت، و CakePHP برای PHP نام برد. در زمینه‌ی برنامه‌نویسی غیر وبی مثلا برنامه‌نویسی تحت ویندوز، می‌شه .NET Framework مایکروسافت رو مثال زد که حجم عظیمی از کدهای نوشته‌شده رو در اختیار برنامه‌نویس قرار می‌ده.

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

علاوه بر این، همون‌طور که وبلاگ MondayByNoon هم در پست اخیرش اشاره کرده، معمولا در بیشتر فریم‌ورک‌ها حجم عظیمی از کد نوشته شده بدون استفاده می‌مونه. این مسئله در برنامه‌نویسی سمتٍ سرور (Server-Side) مثل PHP مشکلی ایجاد نمی‌کنه. چون فقط بخش‌هایی include می‌شن که مورد استفاده قرار می‌گیرن. بنابراین مشکل به طور خاص متوجه فریم‌ورک‌های سمتِ کلاینت از جمله فریم‌ورک‌های جاوا اسکریپتی می‌شه. چرا که حجم احتمالا زیادی از کد باید به کلاینت منتقل بشه برای فراخوانی فقط چند تابع!

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

… فریم‌ورک برای سی‌اس‌اس دیگه چه صیغه‌ایه؟!

در واقع موضوع از دوازدهم ژوئن با مقاله‌ای شروع شد که جف کرافت توی شماره‌ی ۲۳۹ مجله‌ی A List Apart نوشت؛ تحت عنوان «فریم‌ورک برای طراحان». در این مقاله، نویسنده قصد داشته مفهوم فریم‌ورک رو به طراحی وب تعمیم بده و توضیح می‌ده که چه طور می‌شه کارهای تکراری رو در قالب یه فریم‌ورک درآورد، چه چیزهایی رو می‌شه به این صورت درآورد و سودمندی‌های این کار چیه. (بهتون توصیه می‌کنم این مقاله رو بخونید.) آقایی به نام Olav Bjorkoy هم با خوندن این مقاله، طرح پیشنهادی نویسنده برای فریم‌ورک رو در قالب پروژه‌ی blueprint اجرا کرده.

حالا سوال اینه که آیا یک سی‌اس‌اس فریم‌ورک هم می‌تونه مثل فریم‌ورک‌های جاوا اسکریپتی باشه؟ یعنی آیا می‌شه یک چارچوب کاری مثل blueprint ساخت که برای همه قابل استفاده باشه بشه پروژه‌ها رو بر اساسش توسعه داد؟ من معتقدم که نه.

به نظر من نمی‌شه از یه ساختار از پیش نوشته شده برای نوشتن استایل‌شیت‌ها استفاده کرد. css و xhtml دو چیز جدا از هم‌دیگه نیستن. نمی‌شه xhtml رو در یه قالب استایل‌شیت برد و محدود کرد. هر پروژه و کاری xhtml مخصوص به خودشو داره. classها و idهای مخصوص به خودشو داره که با توجه به پروژه به شکل مفهومی نام‌گذاری شده‌ن. استفاده از یه فریم‌ورک مثل blueprint باعث حذف بیشتر این نام‌گذاری‌ها به صورت مفهومی می‌شه. با نگاه کردن به فایل‌های نمونه‌ای که توی ورژن ۰٫۵ گذاشته شده‌ن این موضوع کاملا مشهوده که با نگاه کردن به کد هیچ برداشتی از محتوای هر بخش نمی‌شه داشت. و همون‌طور که MondayByNoon اشاره می‌کنه، این یعنی عمل کردن ضد یکی از اهداف اصلی پروژه‌ی استانداردهای وب: ساختن xhtmlهایی با بار معنایی بالا.

از طرف دیگه، یادگیری فریم‌ورک رو باید بررسی کرد. آیا وقتی که صرف یادگیری و یادآوری سی‌اس‌اس فریم‌ورک می‌کنیم به استفاده ازش میارزه؟ وقتی که xhtml به صورت مفهومی و با تعریف کلاس‌ها و idهای معنادار نوشته نشده باشه، و قرار باشه از یه فریم‌ورک با نام‌های خاص استفاده کنیم یادگیری این نام‌ها احتیاج به زمان نسبتاً زیادی داره. از طرفی هر یادگیری (که در واقع همون حفظ کردن می‌شه) احتیاج به تکرار برای یادآوری داره که اینم خودش با صرف مقداری وقت همراه می‌شه.

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

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

من فکر می‌کنم جواب این سوال دقیقا توی مقاله‌ی آقای کرافت در A List Apart داده می‌شه. مطمئنا بخش‌هایی از کد هستند که همیشه و در هر پروژه‌ای تکرار می‌شن. در همین زمینه reset.css آقای اریک میر رو می‌شه مثال زد که نمونه‌ی خوبی از کدهای تکراری تنظیمات اولیه‌ی المان‌هاست. من فکر نمی‌کنم بیش از این حد در سی‌اس‌اس کدها تکرار بشن. مگر این‌که برای xhtml یکسانی نوشته بشن که بحث جداگونه‌ای داره. حتی در همین حد reset.css هم بخشی از تعریف‌ها بازنویسی (override) می‌شن. چه برسه به وقتی که شما از فریم‌ورکی استفاده بکنید که برای هر المانی که دستش رسیده کلی استایل تعریف کرده!

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

blueprint به چه دردی می‌خوره؟

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

خلاصه اینکه…

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

پی‌نوشت: من این جوریم: یا نمی‌نویسم یا وقتی می‌خوام بنویسم شب نمی‌خوابم هفت ساعت می‌شینم تا بخوام چهارتا خط بنویسم!