آشنایی با Race Condition
وضعیت رقابتی یا Race Condition یکی از دلایل اصلی باگ در نرم افزار است و به راحتی می تواند منجر به از کار افتادن برنامه شود. معمولا علت اصلی Race Condition نا همانگی بین داده های ورودی و خروجی است. این ناهماهنگی معمولا به دلیل عدم رعایت حق تقدم در برنامه اتفاق می افتد. هرگاه یک متد قبل یا بعد از زمان پیش بینی شده اجرا شود عملکرد سایر متدهای برنامه را مختل میکند. داده ها به متدهای بعدی ناقص میرسند یا پوچ . متد بعدی ایده ای ندارد که با این داده ها نا معتبر چه کاری انجام دهد در نتیجه برنامه کرش میکند یا خطا روی میدهد.
در بعضی مواقع این کرش کردن می تواند ضررهای جبران ناپذیری به دنبال داشته باشد. در دهه ی 80 میلادی یک دستگاه پرتو درمانی دچار Race Condition شد و چند بیمار Overdose شدند که به مرگ آنها منجر شد. همچنین در مریخ نورد اسپریت وضعیت رقابتی باعث از کار افتادن ماژول عکس برداری شد چون همزمان ماژول دیگری در حال خالی کردن حافظه بود.
هنگامی که مدت زمان اجرای یک متد به طور دقیق مشخص نیست برنامه نویسی برای خروجی مشکل است. فرض کنید یک پست وبلاگ دارید که کاربر همزمان می تواند فایل عکس و ویدیو در فرم آپلود کند. عنوان و متن خیلی سریع در سرور دریافت میشود. عکس بیشتر طول میکشد و بسته به حجم ویدیو زمان نهایی رسیدن اطلاعات به سرور متغیر است. اگر بخواهید اطلاعات فایل عکس و ویدیو را در یک ردیف دیتابیس ذخیره کنید با Race Condition رو برو میشوید.
در بیشتر مواقع Race Condition در برنامه نویسی Async رو میدهد. در این حالت دستورات بلافاصله اجرا نمیشوند بلکه سیستم عامل زمان اجرای آنها را مشخص میکند. شما فقط می توانید رویدادی دریافت کنید که پایان یافتن اجرای متد را گزارش میدهد. به همین دلیل خیلی از برنامه نویسان از Async دوری می کنند یا خیلی از متدها را Lock میکنند تا خروجی را کنترل کنند.
نوشتن برنامه ای که در برابر Race Condition مقاوم باشد آسان نیست. در تست های روزانه نمی توانید آن را مشاهده کنید. RC معمولا در ترافیک بالا و زمانی که منابع سیستم به شدت محدود میشود خود را نشان میدهد. بسته به میزان اهمیت نرم افزار و عواقب ناشی از کرش شدن باید سعی کنید تست های دقیقتری روی برنامه انجام دهید.
وضعیت رقابتی یا Race Condition یکی از دلایل اصلی باگ در نرم افزار است و به راحتی می تواند منجر به از کار افتادن برنامه شود. معمولا علت اصلی Race Condition نا همانگی بین داده های ورودی و خروجی است. این ناهماهنگی معمولا به دلیل عدم رعایت حق تقدم در برنامه اتفاق می افتد. هرگاه یک متد قبل یا بعد از زمان پیش بینی شده اجرا شود عملکرد سایر متدهای برنامه را مختل میکند. داده ها به متدهای بعدی ناقص میرسند یا پوچ . متد بعدی ایده ای ندارد که با این داده ها نا معتبر چه کاری انجام دهد در نتیجه برنامه کرش میکند یا خطا روی میدهد.
در بعضی مواقع این کرش کردن می تواند ضررهای جبران ناپذیری به دنبال داشته باشد. در دهه ی 80 میلادی یک دستگاه پرتو درمانی دچار Race Condition شد و چند بیمار Overdose شدند که به مرگ آنها منجر شد. همچنین در مریخ نورد اسپریت وضعیت رقابتی باعث از کار افتادن ماژول عکس برداری شد چون همزمان ماژول دیگری در حال خالی کردن حافظه بود.
هنگامی که مدت زمان اجرای یک متد به طور دقیق مشخص نیست برنامه نویسی برای خروجی مشکل است. فرض کنید یک پست وبلاگ دارید که کاربر همزمان می تواند فایل عکس و ویدیو در فرم آپلود کند. عنوان و متن خیلی سریع در سرور دریافت میشود. عکس بیشتر طول میکشد و بسته به حجم ویدیو زمان نهایی رسیدن اطلاعات به سرور متغیر است. اگر بخواهید اطلاعات فایل عکس و ویدیو را در یک ردیف دیتابیس ذخیره کنید با Race Condition رو برو میشوید.
در بیشتر مواقع Race Condition در برنامه نویسی Async رو میدهد. در این حالت دستورات بلافاصله اجرا نمیشوند بلکه سیستم عامل زمان اجرای آنها را مشخص میکند. شما فقط می توانید رویدادی دریافت کنید که پایان یافتن اجرای متد را گزارش میدهد. به همین دلیل خیلی از برنامه نویسان از Async دوری می کنند یا خیلی از متدها را Lock میکنند تا خروجی را کنترل کنند.
نوشتن برنامه ای که در برابر Race Condition مقاوم باشد آسان نیست. در تست های روزانه نمی توانید آن را مشاهده کنید. RC معمولا در ترافیک بالا و زمانی که منابع سیستم به شدت محدود میشود خود را نشان میدهد. بسته به میزان اهمیت نرم افزار و عواقب ناشی از کرش شدن باید سعی کنید تست های دقیقتری روی برنامه انجام دهید.
ویوهای Async در Razor
با باز نویسی ASP موتور Razor هم باز نویسی شد و یک تغییر مهم در این بخش Async شدن ویوها است. بخش اصلی کدهای درون یک ویو HTML است که فرقی نکرده است. اما از اینجا به بعد وقتی ASP Core میخواهد محتوای HTML را با کدهای #C ترکیب و خروجی نهایی را ایجاد کند عملیات را به صورت Async انجام میدهد.
اجرای Async یعنی دیگر کدهای #C درون ویو بلافاصله اجرا نمیشوند. این مسئله در حلقه های For یا شرط های IF خودش را نشان نمیدهد. اما در تولید PartialView ها نقش مهمی دارد.
در ASP Core دیگر دستور Html.Action وجود ندارد. به این معنی که دیگر نمی توانید یک اکشن را مستقیما صدا بزنید و خروجی آن را درون ویو جایگزین کنید. این متد یکی از مشکل ساز ترین دستورات MVC5 و ماقبل بود و باعث باگ و ترافیک سنگین سایت میشد.
از آنجا که اکشن ها معمولا با دیتابیس کار میکردند ویو برای تولید نهایی باید منتظر پایان عملیات اکشن میشد. سنگین شدن سرور Race Condition ایجاد میکرد و ویو در نهایت Time Out میشد و کل صفحه را از کار می انداخت.
تولید ویو به صورت Async امکان اجرای موازی اکشن ها را می دهد. با این تفاوت که در ASP Core بجای اکشن از ViewComponent استفاده میشود . View Component نوع خاصی از کنترلر و اکشن است و همیشه به صورت Async اجرا میشود.
با باز نویسی ASP موتور Razor هم باز نویسی شد و یک تغییر مهم در این بخش Async شدن ویوها است. بخش اصلی کدهای درون یک ویو HTML است که فرقی نکرده است. اما از اینجا به بعد وقتی ASP Core میخواهد محتوای HTML را با کدهای #C ترکیب و خروجی نهایی را ایجاد کند عملیات را به صورت Async انجام میدهد.
اجرای Async یعنی دیگر کدهای #C درون ویو بلافاصله اجرا نمیشوند. این مسئله در حلقه های For یا شرط های IF خودش را نشان نمیدهد. اما در تولید PartialView ها نقش مهمی دارد.
در ASP Core دیگر دستور Html.Action وجود ندارد. به این معنی که دیگر نمی توانید یک اکشن را مستقیما صدا بزنید و خروجی آن را درون ویو جایگزین کنید. این متد یکی از مشکل ساز ترین دستورات MVC5 و ماقبل بود و باعث باگ و ترافیک سنگین سایت میشد.
از آنجا که اکشن ها معمولا با دیتابیس کار میکردند ویو برای تولید نهایی باید منتظر پایان عملیات اکشن میشد. سنگین شدن سرور Race Condition ایجاد میکرد و ویو در نهایت Time Out میشد و کل صفحه را از کار می انداخت.
تولید ویو به صورت Async امکان اجرای موازی اکشن ها را می دهد. با این تفاوت که در ASP Core بجای اکشن از ViewComponent استفاده میشود . View Component نوع خاصی از کنترلر و اکشن است و همیشه به صورت Async اجرا میشود.
فایل global.json
فریم ورک dotnet core به شما امکان میدهد چند نسخه آن را همزمان روی سیستم خود نصب کنید. بر خلاف نسخه های قبلی دات نت در Core فایلهای SDK فقط روی سیستم کپی میشوند و تغییراتی روی سیستم عامل بوجود نمی آورند. همه ی نسخه های dotnet روی سیستم خود را می توانید در آدرس C:\Program Files\dotnet\sdk بیابید.
همراه با نصب SDK یک برنامه ی CLI یا Command Line Interface هم نصب میشود و از طریق CMD یا Powershell در همه جای سیستم عامل در دسترس است. این برنامه تمامی دستورات dotnet مانند Build و Run را شامل میشود. معمولا در ویندوز از Visual Studio استفاده می کنید و اصلا متوجه این ابزار نمی شوید. اما در سایر سیستم عامل های مانند Linux و MacOS ابزار CLI تنها راه کامپایل و اجرای برنامه های dotnet core می باشد.
وقتی چند ورژن SDK همزمان روی سیستم نصب باشد CLI همیشه آخرین نسخه ی نصب شده را انتخاب می کند و پروژه ها را با آن میسازد. برای اینکه بدانید کدام ورژن روی سیستم شما فعال است می توانید دستور dotnet - - info را اجرا کنید.
مشکل زمانی پیش می آید که می خواهید از نسخه های قدیمی تر SDK استفاده کنید. در این صورت باید به dotnet بفهمانید که کدام ورژن را برای کار انتخاب کند. اینجاست که فایل global.json اهمیت پیدا میکند. این فایل در هر فولدری قرار گیرد همه ی پروژه های درون آن فولدر و فولدرهای زیرین را به نسخه ی SDK درونش تنظیم میکند. مثلا اگر آن را در ریشه ی درایو قرار دهید و ورژن 1 را در SDK تنظیم کنید تمام پروژه های آن درایو روی نسخه ی 1 کامپایل و اجرا میشوند.
استفاده از global.json وقتی که با نسخه های Preview کار می کنید بسیار مشکل گشاست و به شما کنترل کاملی روی کامپایلر dotnet core میدهد.
فریم ورک dotnet core به شما امکان میدهد چند نسخه آن را همزمان روی سیستم خود نصب کنید. بر خلاف نسخه های قبلی دات نت در Core فایلهای SDK فقط روی سیستم کپی میشوند و تغییراتی روی سیستم عامل بوجود نمی آورند. همه ی نسخه های dotnet روی سیستم خود را می توانید در آدرس C:\Program Files\dotnet\sdk بیابید.
همراه با نصب SDK یک برنامه ی CLI یا Command Line Interface هم نصب میشود و از طریق CMD یا Powershell در همه جای سیستم عامل در دسترس است. این برنامه تمامی دستورات dotnet مانند Build و Run را شامل میشود. معمولا در ویندوز از Visual Studio استفاده می کنید و اصلا متوجه این ابزار نمی شوید. اما در سایر سیستم عامل های مانند Linux و MacOS ابزار CLI تنها راه کامپایل و اجرای برنامه های dotnet core می باشد.
وقتی چند ورژن SDK همزمان روی سیستم نصب باشد CLI همیشه آخرین نسخه ی نصب شده را انتخاب می کند و پروژه ها را با آن میسازد. برای اینکه بدانید کدام ورژن روی سیستم شما فعال است می توانید دستور dotnet - - info را اجرا کنید.
مشکل زمانی پیش می آید که می خواهید از نسخه های قدیمی تر SDK استفاده کنید. در این صورت باید به dotnet بفهمانید که کدام ورژن را برای کار انتخاب کند. اینجاست که فایل global.json اهمیت پیدا میکند. این فایل در هر فولدری قرار گیرد همه ی پروژه های درون آن فولدر و فولدرهای زیرین را به نسخه ی SDK درونش تنظیم میکند. مثلا اگر آن را در ریشه ی درایو قرار دهید و ورژن 1 را در SDK تنظیم کنید تمام پروژه های آن درایو روی نسخه ی 1 کامپایل و اجرا میشوند.
استفاده از global.json وقتی که با نسخه های Preview کار می کنید بسیار مشکل گشاست و به شما کنترل کاملی روی کامپایلر dotnet core میدهد.
پروژه ی نمونه ASP Core
پروژه WebApp از روی قالب خالی پروژه های 2.0 ASP Core ایجاد شده و سرویس MVC و دیتابیس Sqlite با استفاده از تکنیک Code First بهش اضافه شده.
برای دانلود می توانید به آدرس زیر بروید :
https://github.com/codehaks/WebApp
پروژه WebApp از روی قالب خالی پروژه های 2.0 ASP Core ایجاد شده و سرویس MVC و دیتابیس Sqlite با استفاده از تکنیک Code First بهش اضافه شده.
برای دانلود می توانید به آدرس زیر بروید :
https://github.com/codehaks/WebApp
GitHub
codehaks/WebApp
ASP.NET Core Template. Contribute to codehaks/WebApp development by creating an account on GitHub.
مقایسه بین Middleware و Action Filter
ابتدا باید بدانیم که ASP Core با MVC فرق دارد. ASP یک محیط برنامه نویسی تحت وب است و MVC یکی از روش های استفاده از آن است. شما می توانید سرورهای ASP Core داشته باشید که بدون میان افزار MVC کار می کنند و موارد استفاده ی زیادی هم دارند.
در محیط ASP Core الگوی MVC کاملا از بنده ی اصلی فریم ورک جدا شده است. برای استفاده از MVC باید آن را به صورت یک Middleware یا میان افزار به پروژه ی ASP Core اضافه کنید.
فیلترهای MVC در مسیر Request و Response قرار میگیرند و می توانند آن را تغییر دهند. مثلا فیلتر Authorize چک می کند که آیا کاربر Login کرده یا خیر و جلوی استفاده بی نام از یک اکشن MVC را می گیرد. این دقیقا همان کاری است که Middleware ها انجام میدهند. با این تفاوت که آنها در یک سطح بالاتر کار میکنند. یک میان افزار میتواند یک درخواست را قبل از رسیدن به MVC قطع کند یا بعد از خروج از MVC تغییر دهد. اما Action Filter بخشی از فریم ورک MVC است و طبیعی است که درون میان افزار MVC اجرا میشود و بدون MVC وجود ندارد.
بسیاری از قابلیت های ASP Core با Middleware پیاده شده است. مثلا برای استفاده از فایلهای استاتیک باید میان افزار StaticFiles را لود کنید. همینطوری Routing هم یک Middleware است و خارج از محیط MVC درخواستها را بررسی می کند.
به طور کلی معمولا از Action Filter استفاده می کنید. موارد خیلی کمی پیش می آید که نیاز به پیاده سازی Middleware پیدا می کنید. اما باید بندانید که Middleware حق وتو دارد و در سطحی بالاتر از فیلترهای یا حتی MVC کار می کند. اگر نیاز داشتید کنترل Request و Response را به طور کامل در اختیار بگیرید میان افزار جایی است که باید شروع کنید.
ابتدا باید بدانیم که ASP Core با MVC فرق دارد. ASP یک محیط برنامه نویسی تحت وب است و MVC یکی از روش های استفاده از آن است. شما می توانید سرورهای ASP Core داشته باشید که بدون میان افزار MVC کار می کنند و موارد استفاده ی زیادی هم دارند.
در محیط ASP Core الگوی MVC کاملا از بنده ی اصلی فریم ورک جدا شده است. برای استفاده از MVC باید آن را به صورت یک Middleware یا میان افزار به پروژه ی ASP Core اضافه کنید.
فیلترهای MVC در مسیر Request و Response قرار میگیرند و می توانند آن را تغییر دهند. مثلا فیلتر Authorize چک می کند که آیا کاربر Login کرده یا خیر و جلوی استفاده بی نام از یک اکشن MVC را می گیرد. این دقیقا همان کاری است که Middleware ها انجام میدهند. با این تفاوت که آنها در یک سطح بالاتر کار میکنند. یک میان افزار میتواند یک درخواست را قبل از رسیدن به MVC قطع کند یا بعد از خروج از MVC تغییر دهد. اما Action Filter بخشی از فریم ورک MVC است و طبیعی است که درون میان افزار MVC اجرا میشود و بدون MVC وجود ندارد.
بسیاری از قابلیت های ASP Core با Middleware پیاده شده است. مثلا برای استفاده از فایلهای استاتیک باید میان افزار StaticFiles را لود کنید. همینطوری Routing هم یک Middleware است و خارج از محیط MVC درخواستها را بررسی می کند.
به طور کلی معمولا از Action Filter استفاده می کنید. موارد خیلی کمی پیش می آید که نیاز به پیاده سازی Middleware پیدا می کنید. اما باید بندانید که Middleware حق وتو دارد و در سطحی بالاتر از فیلترهای یا حتی MVC کار می کند. اگر نیاز داشتید کنترل Request و Response را به طور کامل در اختیار بگیرید میان افزار جایی است که باید شروع کنید.
آشنایی با متدهای Safe و Idempotent در HTTP
متدهای Safe
در پروتکل HTTP بعضی از متدها به عنوان Safe شناخته میشوند. منظور از Safe متدی است که کاری جز باز گرداندن اطلاعات انجام نمی دهد. متدهای Safe نباید اطلاعات دتابیس را تغییر دهند. اجرای یک متد Safe نباید برای کاربر هیچ عواقبی داشته باشد یا وضعیت سرور را تغییر دهد. متد GET یک متد Safe است و نباید پشت آن کدی بنویسید که اطلاعات را تغییر یا حذف کند.
متدهای Idempotent
منظور از متد Idempotent این است که نتیجه ی اجرای آن در بار N ام باید با نتیجه ی اجرا در بار اول یکسان باشد. متدهای GET و PUT و DELETE شامل آن می شوند. هر وقت کاربر درخواست اجرای یک متد از نوع DELETE میدهد شما می توانید اطلاعات را حذف کنید و نتیجه را به کاربر برگردانید. اما باید برنامه را به شکلی طراحی کنید که وقتی دوباره همان متد را با همان مقادیر اجرا کند خروجی همانند مرحله ی اول به کاربر برگردد.
رعایت کردن قوانین HTTP یک مبنای مشترک به همه ی برنامه نویسان میدهد. به خصوص زمانی که وب سرویس طراحی می کنید و هزاران برنامه نویس دیگر قرار است از آن استفاده کنند باید بیش از همیشه به قوانید آن پایبند باشید تا پروژه ی شما استانداردهای یک سایت خوب را داشته باشد.
متدهای Safe
در پروتکل HTTP بعضی از متدها به عنوان Safe شناخته میشوند. منظور از Safe متدی است که کاری جز باز گرداندن اطلاعات انجام نمی دهد. متدهای Safe نباید اطلاعات دتابیس را تغییر دهند. اجرای یک متد Safe نباید برای کاربر هیچ عواقبی داشته باشد یا وضعیت سرور را تغییر دهد. متد GET یک متد Safe است و نباید پشت آن کدی بنویسید که اطلاعات را تغییر یا حذف کند.
متدهای Idempotent
منظور از متد Idempotent این است که نتیجه ی اجرای آن در بار N ام باید با نتیجه ی اجرا در بار اول یکسان باشد. متدهای GET و PUT و DELETE شامل آن می شوند. هر وقت کاربر درخواست اجرای یک متد از نوع DELETE میدهد شما می توانید اطلاعات را حذف کنید و نتیجه را به کاربر برگردانید. اما باید برنامه را به شکلی طراحی کنید که وقتی دوباره همان متد را با همان مقادیر اجرا کند خروجی همانند مرحله ی اول به کاربر برگردد.
رعایت کردن قوانین HTTP یک مبنای مشترک به همه ی برنامه نویسان میدهد. به خصوص زمانی که وب سرویس طراحی می کنید و هزاران برنامه نویس دیگر قرار است از آن استفاده کنند باید بیش از همیشه به قوانید آن پایبند باشید تا پروژه ی شما استانداردهای یک سایت خوب را داشته باشد.
آشنایی با الگوی MVVM
بسیاری از برنامه نویسان ASP با الگوی MVC آشنایی دارند. اما مدل MVVM که به معنی Model - View - ViewModel است کمتر مورد استفاده قرار میگیرد.
اولین نکته این است که پیاده سازی سایت با الگوی MVVM بر مبنای تکنولوژی ASP ممکن نیست.
در این الگو داده ها بین UI و ViewModel که چیزی شبیه همان کنترلر در mvc است گردش می کنند و بلا فاصله به دیتابیس منتقل نمی شوند.
تمامی سایت های SPA از این الگو استفاده می کنند. هر وقت از ابزای مانند knockout.js یا آنگولار استفاده می کنید یک برنامه ی جاوا اسکریپت وظیفه ی مدیریت و اعتبار سنجی داده ها را بر عهده میگیرد.
در این روش تغییرات در دیتا به صورت ظاهری تغییر میکنند اما در عمل به صورت یک ajax به سرور ارسال می شوند که معمولا در لحظه روی نمی دهد.
وقتی مجبور نیستید برای مدیریت اطلاعات آنها را بعد از هر تغییر به سرور ارسال کنید از ترافیک سرور کم می کنید و کمتر صفحه رفرش میشود. در نتیجه رابط کاربری روانتر کار میکند.
لازم نیست یک سایت برای همه ی قسمت ها از این الگو استفاده کند. بلکه اگر فقط برای صفحاتی که کاربر با آنها زیاد سرو کار دارد هم پیاده شود هم تاثیر بسیار مطلوبی در UX می گذارد.
یکی از بهترین ابزار برای پیاده سازی الگوی MVVM در سایت های ASP Core فریم ورک Vue.js است.
بسیاری از برنامه نویسان ASP با الگوی MVC آشنایی دارند. اما مدل MVVM که به معنی Model - View - ViewModel است کمتر مورد استفاده قرار میگیرد.
اولین نکته این است که پیاده سازی سایت با الگوی MVVM بر مبنای تکنولوژی ASP ممکن نیست.
در این الگو داده ها بین UI و ViewModel که چیزی شبیه همان کنترلر در mvc است گردش می کنند و بلا فاصله به دیتابیس منتقل نمی شوند.
تمامی سایت های SPA از این الگو استفاده می کنند. هر وقت از ابزای مانند knockout.js یا آنگولار استفاده می کنید یک برنامه ی جاوا اسکریپت وظیفه ی مدیریت و اعتبار سنجی داده ها را بر عهده میگیرد.
در این روش تغییرات در دیتا به صورت ظاهری تغییر میکنند اما در عمل به صورت یک ajax به سرور ارسال می شوند که معمولا در لحظه روی نمی دهد.
وقتی مجبور نیستید برای مدیریت اطلاعات آنها را بعد از هر تغییر به سرور ارسال کنید از ترافیک سرور کم می کنید و کمتر صفحه رفرش میشود. در نتیجه رابط کاربری روانتر کار میکند.
لازم نیست یک سایت برای همه ی قسمت ها از این الگو استفاده کند. بلکه اگر فقط برای صفحاتی که کاربر با آنها زیاد سرو کار دارد هم پیاده شود هم تاثیر بسیار مطلوبی در UX می گذارد.
یکی از بهترین ابزار برای پیاده سازی الگوی MVVM در سایت های ASP Core فریم ورک Vue.js است.
چرا جاوا اسکریپت؟
تکنولوژی های سمت سرور برای طراحی رابط کاربری ساخته نشده اند و ابزار مناسبی هم برای اینکار نیستند.
استفاده از جاوا اسکریپت می تواند تجربه ی کاربری سایت را چند برابر بهتر کند.
علاوه بر زیبایی استفاده از جاوااسکریپت از ترافیک سرور و پهنای باند شبکه هم کم میکند. وقتی از javascript استفاده می کنید فقط داده ها را دانلود می کنید که در مقایسه با تمام محتویات صفحه حجم به مراتب کمتری دارد.
وقتی وظایفی از قبیل جستجو، اعتبار سنجی و مرتب سازی را به جاوااسکریپت میسپارید از رم و پردازشگر کاربر کمک می گیرید. این کمک به حدی نیست که روی سیستم کاربر اثر منفی داشته باشد اما حجم بسیار بالایی از منابع سرور را آزاد میکند.
پیاده سازی سایت با ajax و وب سرویس پیچیده تر است و زمان بیشتری میبرد. اما هزینه ای است که در برابر نتیجه ی کار ارزشش را دارد.
تکنولوژی های سمت سرور برای طراحی رابط کاربری ساخته نشده اند و ابزار مناسبی هم برای اینکار نیستند.
استفاده از جاوا اسکریپت می تواند تجربه ی کاربری سایت را چند برابر بهتر کند.
علاوه بر زیبایی استفاده از جاوااسکریپت از ترافیک سرور و پهنای باند شبکه هم کم میکند. وقتی از javascript استفاده می کنید فقط داده ها را دانلود می کنید که در مقایسه با تمام محتویات صفحه حجم به مراتب کمتری دارد.
وقتی وظایفی از قبیل جستجو، اعتبار سنجی و مرتب سازی را به جاوااسکریپت میسپارید از رم و پردازشگر کاربر کمک می گیرید. این کمک به حدی نیست که روی سیستم کاربر اثر منفی داشته باشد اما حجم بسیار بالایی از منابع سرور را آزاد میکند.
پیاده سازی سایت با ajax و وب سرویس پیچیده تر است و زمان بیشتری میبرد. اما هزینه ای است که در برابر نتیجه ی کار ارزشش را دارد.