اکثرتوسعه دهندگان از نحوه ی عملکرد سیستم های مدیریت محتوا پیش آگاهی دارند. WordPreess در سراسر دنیا نفوذ و ومحبوبیت یافته است و یکی از زیرساخت های اصلی هر بلاگی محسوب میشود.

اما یکی دیگر از گرایش هایی که بتازگی رونق گرفته استفاده از ژنراتورهای وب سایت استاتیک برای بلاگ ها یا وب سایت های کوچک است. این ژنراتورها کامپلایرهای پویایی هستند که کدهای پیش پردازش شده را به فایل های JS//CSS HTML استاتیک تبدیل میکنند. ویژگی این فایل های استاتیک این است که می توان آنها را بدون نیاز به پایگاه داده ها روی سرور نگه داشت. هرچند این گردش کار برای تمامی سایت ها بهترین گردش کار ممکن نیست اما توسعه دهندگان بنا به دلایلی به ژنراتورهای سایت استاتیک روی آورده اند.

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

سرمنشا وب استاتیک.

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

درطول سال ها وب ها رشد کرده و مواردی همچون پایگاه داده ها و موتورهای قدرتمندی چون WordPress  به آنها افزوده شدند. این موتورها بدون نیاز به نوشتن کدهای backend با قدرت تمام اپلیکیشن ها را اجرا میکنند و به همین دلیل بسرعت به راهکاری ارزشمند مبدل شدند.

با رشد موتورهای CMS مدیریت زمان بارگذاری به مساله ای ارزشمند تبدیل شد. توسعه دهندگان می بایست نگران زمان query پایگاه داده ها و الگوهای بزرگ می بودند. ذخیره سازی (caching) تا حدودی به حل این مساله کمک میکرد اما بعنوان یک صفحه ی وب استاتیک بندرت عملکردی مشابه داشت.

این تثبیت در سایت های استاتیک زمانی بوجود آمد که سیستم های مدیریت محتوا برای پروژه های کوچکتر زیادی بزرگ بودند. درست مانند صنعت وب که با چرخه ی تکامل خود به فواید صفحات HTML استاتیک پی برد با این تفاوت که این بار ما ابزار قدرتمندتری در اختیار داریم.

چرا سایت های استاتیک دوباره احیا شدند؟

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

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

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

وب سایت های استاتیک ساخته شده اند تا ترافیک سایت را مهار کنند. بنابراین درخصوص ذخیره سازی یا دریچه های پایگاه داده ها که ممکن است موجب کندی در زمان بارگذاری شوند جای نگرانی وجود ندارد.

بنابراین در یک جمع بندی به این نتیجه میرسیم که سایت های استاتیک بدلایل نامبرده در زیر احیایی دوباره یافتند:

بهبود قابلیت های مرورگر وب.

پیشتیبانی از پیش پردازش هایی مانند Sass/ Less و Haml/ Jade.

بسیاری از راهکارهای سوم شخص رایگان برای محتوای دینامیک.

ساخت سریع و موثر وب سایت ها توسط ژنراتورهای سایت استاتیک.

مزیت های سایت استاتیک نسبت به وب سایت های دینامیک.

وب سایت های استاتیک به پایگاه داده ها وابسته نیستند. آنها در انتظار اتصالات پایگاه داده ها نمانده و بالطبع تحت تاثیر خطاهای پایگاه داده ها نیز قرار ندارند.

سایت های استاتیک به هیچ یک از زبان های  backendوابسته نیستند. در این سایت ها به سرور با ویژگی های PHP، Rails، Python، Node یا سایر ویژگی ها بجز ویژگی های اصلی سرور نیازی ندارید. یک سایت استاتیک فقط محتوای استاتیک را بارگذاری میکند و دقیقا آنچه را انجام میدهد که اینترنت برای انجام آن ساخته شده.

به نگرانی های امنیتی که در وب سایت دینامیک وجود دارد دقت کنید. اگرچه در سالهای اخیر امنیت وب بهتر شده است اما هکرها همچنان توانایی وارد شدن به WordPress و سایر سیستم ها از طریق تزریق پایگاه داده ها یا تم ها و plugin هایی که بدرستی ساخته نشده اند را دارند.  

مزیت های سایت استاتیک در مقایسه با سایت دینامیک:

درخواست های HTTP در سایت های استاتیک نسبت به سایت های دینامیک سریعتر بارگذاری میشوند.

سایت های استاتیک نقاط آسیب پذیر کمتری داشته و درنتیجه امنیت بیشتری دارند.

ژنراتورهای سایت استاتیک در مقایسه با CMS دینامیک ابزارهایی همچون قالب بندی templating)) را ارائه میدهند.

یادگیری استفاده از ژنراتور سایت استاتیک از یادگیری یک CMS فول آسانتر است.

سایت های استاتیک به پایگاه داده ها یا سرور backend نیاز ندارند.

نقاط ضعف نسل استاتیک.

هرچند نسل سایت های استاتیک نقاط قوت بسیاری دارند اما معیابی نیز دارند و برای هر پروژه ای مناسب نیستند.

شاید بزرگترین نقص این نوع سایت مدیریت محتوا از دیدگاه کاربران است. یک توسعه دهنده نباید در نوشتن Markdown، ایجاد صفحه و هل دادن آن به سرور مشکلی داشته باشد. آیا یک مشتری غیرفنی قادر به انجام چنین کاری می باشد؟ آیا اصلا تمایلی به یادگیری آن دارد؟ این مساله بسیار مایه تاسف است چراکه دراینصورت وب سایت های کوچک هدف نخست ژنراتورهای استاتیک خواهند بود.

اما راهکار رفع این عیب CMS سایت استاتیک با ویژگی های مدیریت کاربری مانند Netlify CMS می باشد.

نقطه ضعف دیگر این سایت ها این است که هر زمان که نیاز به کامپایل مجدد سایت می باشد دستورات ترمینال باید بصورت دستی اجرا شوند. بیشتر ژنراتورها از طریق ترمینال اجرا میشوند و به دانش زبان قالب بندی مانند(ERB، EJS، Liquid و غیره) نیاز دارند.

البته این مساله ایراد بزرگی محسوب نمیشود. اما گروهی که با این فناوری ها آشنایی ندارند باید آموزش ببینند. صرفنظراز وقت گیر بودن، یادگیری این فناوری ها ارزشمند است.

از آنجاییکه ژنراتور سایت استاتیک برای تمام پروژه ها مناسب نیست بنابراین باید به نقاط ضعف نامبرده در ذیل دقت کنید:

عدم وجود GUI یا ویژوال backend برای ویرایش صفحات، تمام صفحات استاتیک باید بصورت دستی ویرایش شوند.

ساخت تم برای ژنراتور سایت استاتیک بسیار زمانبر است مگرآنکه از قبل با زبان قالب بندی آشنا باشید.

صفحات جدید باید هربار به سرور وارد شوند.

بابد بهنگام استفاده از ترمینال احساس راحتی کنید.

هیچ پاسخ صحیح یا اشتباهی وجود نداشته و توسعه دهنده تمام مسئولیت تصمیم گیری درخصوص آنچه که برای پروژه بهترین است را برعهده دارد.

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

ژنراتورهای سایت استاتیک: نصب و استفاده.

هر ژنراتور متفاوت بوده و پروسه ی نصب متفاوتی دارد. برای نمونه نصب Jekyl و نحوه ی استفاده از آنرا توضیح میدهیم.

ابتدا باید زبان یا زمان اجرای مورد نیاز برای ژنراتوری که استفاده میکنید را نصب کنید. نصب Jekyl به آسانی نصب Ruby gem است بنابراین برای شروع افزودن روبی به سیستم بهترین روش است. بیشتر سیستم های اجرایی این کار را توسط خط فرمان (command line) انجام میدهند بنابراین برای اطلاعات بیشتر به راهنمای نصب روبی مراجعه کنید.

 به محض نصب روبی میتوانید از خط فرمان، gem install jekyll را اجرا کنید. اگر تمام مراحل را با موفقیت انجام دهید می توانید سایت های Jekyl را هر قسمت از کامپیوتر که بخواهید نصب و راه اندازی کنید.

شما می توانید پروژه جدید jekyl را برای ایجاد فولدری بنام "پروژه" اجرا کنید. این حرکت راهنمای اصلی شما برای سایت جدید میشود و باید شامل Jekyl doc structure شود که سپس با استفاده از فرمان Jekyll build تجزیه شود.

توجه داشته باشید اکثر رخدادهای Jekyll مستقیما از ترمینال اجرا شده و از طریق روبی جم اداره میشود بنابراین شما باید براحتی فرمان ها را در CLI تایپ کنید.

هر ساخت جدید می تواند با Jekyll build و با استفاده از پارامترهای اختیاری مانند source برای دایرکتوری سفارشی یا destination برای دایرکتوری خروجی سفارشی راه اندازی شود. در  Jekyllگردش کار بطورکلی بدین شرح است: نصب و راه اندازی یک سایت جدید، کد نویسی، ساخت صفحات استاتیک و تست. سپس تکرار.

یکی دیگر از جنبه های جالب Jekyll این است که جزیی از سرور توسعه است. از طریق اجرای Jekyll serve می توانید یک سرور محلی را برای تست سایت Jekyll خود راه اندازی کنید. این کار با یک فرمان ساعت برای کامپایل کردن تغییرات در حالت پرواز یا درحالت حرکت همراه است که برای توسعه محلی بینظیر است.

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

نوشتن و انتشار محتوا.

ژنراتورهای استاتیک موجب سهولت در انتشار محتوا میشوند. بجای کد نویسی های دشوار HTML می توانید صفحاتی داشته باشید که بطور دینامیک از هر طرح بندی که شما تعریف کنید تبعیت کند.

تقریبا تمام ژنراتورهای سایت استاتیک برای محتوای صفحه از Markdown استفاده میکنند. این کار در سایت هایی همچون Git Hub و Stack Overflow که متغییرهای خود برای دستورالعمل Markdown را دارند امری عادی است.

البته امکان نوشتن محتوا با استفاده از HTML خام هنوز هم موجود است. اما درحالیکه Markdown برای کلی نویسی روش سریعتری است بطور طبیعی Markdown نمی تواند از کلاس های HTML استفاده کند. در هرصورت اسناد Markdown اسناد معتبر HTML هستند و بنابراین امکان میکس هردو وجود دارد.

بعضی از توسعه دهندگان به بهانه الزام Markdown برای نوشتن محتوا از ترکیب آنها طفره میروند. بسیار عالی میشود اگرتمام محتوا را در HTML بنویسید. Jekyll فرمت Textile را در رابطه با Markdown پشتیبانی میکند. ژنراتورهای دیگر همچون Pelican جایگزین های دیگر مانند restructured Text و Ascii Doc را پشتیبانی میکنند.

از آنجاییکه گزینه های بسیاری وجود دارند شما باید برای انتخاب مناسب ژنراتورها ی مختلفی را امتحان کنید. بطور اساسی دستور کار تولید محتوا در همه ژنراتورها به یک شکل عمل میکند و تنها در ساختارهای دایرکتوری و ترکیب(syntax) تفاوت دارند.

گام نهایی، انتشار محتوا بصورت آنلاین است. انتشار آنلاین محتوا از آپلود (ارسال) یک FTP ساده درست به روت سرور پیچیده تر نیست. اگر به بررسی سایر گزینه ها تمایل دارید Jekyll یک صفحه مخصوص متدهای گسترش دارد. اما درکل گسترش سایت تفاوت چندانی با نوشتن HTML خام از ابتدا و ارسال آن به سرور ندارد.

طراحی تم.

تمام ژنراتورهای سایت استاتیک از طریق includes امکان قطعه های کد قابل تکرار را دارند. هرکس که در PHP یا Python کار کرده باشد میداند که includes همان فایل های اکسترنال(خارجی) است که کدهای قالب بندی را بدون بازنویسی تکرار می کند.

از آنجاییکه تمام ژنراتورهای استاتیک برای کامپایل کردن به HTML ساخته شده اند تم های آنها از این include ها استفاده میکنند. بنابراین توسعه دهندگان frontend می توانند تم هایی که تاحدی دینامیک هستند را نوشته و برای دست یابی به فایل های سایت استاتیک از طریق ژنراتور آنها را اجرا کنند.

هر ژنراتور برای ساخت تم روش مخصوص بخود دارد اما همگی با استفاده از فایل های طرح بندی برای طراحی قالب های فردی از تکنیک های مشابه پیروی میکنند. مثلا شما می توانید برای صفحه اصلی یک فایل طرح بندی و برای صفحات داخلی فایل دیگری داشته باشید.

تجزیه دینامیک برای جایی است که همه چیز جالب میشود. بعنوان مثال Jekyll روی Liquid که یک موتور قالب بندی دینامیک است ساخته شده است. اما Middleman از روبی %u