مزیت های ASP.NET MVC نسبت به ASP.NET WebForms

ASP.NET MVC یک فریم ورک کاملاً جدید برای ساختن اپلیکیشن های ASP.NET است که با هدف جداسازی شفاف لایه های برنامه و قابلیت تست پذیری بالا بوجود آمده است. برنامه نویسان دات نت با استفاده از ASP.NET MVC می توانند رفتار Stateless وب را درک کنند و بر روی کدهای HTML خروجی صفحات خود کنترل کامل داشته باشند. در فریم ورک ASP.NET MVC بر خلاف ASP.NET WebFroms آدرس های صفحات وب سایت به فایل های فیزیکی aspx وابسته نیستند. در این مطلب اشاره ای کوتاه خواهیم داشت به مزیت های کلی ASP.NET MVC نسبت به ASP.NET WebForms :

1) Separation of Concern : فریم ورک ASP.NET MVC شما را مجبور می کند تا یک جداسازی شفاف از قسمت های مهم اپلیکیشن خود داشته باشید. شما باید کدهای مربوط به دسترسی به داده ها را در قسمت Model و کدهای مربوط به رابط کاربری را در قسمت View بنویسید و برای ایجاد ارتباط میان این دو لایه از Controllerها استفاده کنید. با این جداسازی شفاف، پیچیدگی های پروژه کمتر شده و نگهداری پروژه در درازمدت و انجام تغییرات بر روی آن آسان تر می شود.

2) کنترل کامل بر روی HTML خروجی : با استفاده از ASP.NET MVC شما می توانید درخواست های کاربر را پردازش کنید و خروجی مناسب HTML را به مرورگر بفرستید. کدهای HTML خروجی شما کاملاً تمیز هستند و از کدهای عجیب و غریبی که ASP.NET WebForms برای شما ایجاد می کند خبری نیست!

3) ایجاد URLهای RESTful : با کامپوننت های URL Mapping در این فریم ورک می توانید URLهایی بدون پسوند، واضح و قابل جستجو بسازید. این URLها از قوانین نام گذاری REST پشتیبانی می کنند و از نظر SEO در موتورهای جستجوگر امتیاز خوبی می گیرند.

4) قابلیت تست پذیری : یکی از اهداف مهم طراحی فریم ورک ASP.NET MVC قابلیت تست پذیری بوده است. به علت جدا سازی شفاف میان کدهای منطق برنامه و کدهای مربوط به رابط کاربری، تست کردن اجزای مختلف وب اپلیکیشن های ASP.NET MVC آسان است. ASP.NET MVC با تمام فریم ورک های Testing که برای دات نت ساخته شده اند کار می کند.

5) عدم استفاده از PostBack و ViewState : در ASP.NET MVC خبری از فرم های تحت سرور (یا همان runat=»server» معروف) نیست. شما رویدادی به نام PostBack ندارید و حالت کنترل های شما با استفاده از ViewState حفظ نخواهد شد! این یک مزیت است زیرا باعث ایجاد خروجی واضح تر و صفحات سبک تر می شود.

6) آسان تر کردن کار تیمی : به علت جداسازی واضح میان قسمت های مختلف پروژه و قابلیت تست آسان، کار کردن به صورت تیمی را آسان تر می کند. هر یک از اعضای تیم بر اساس نوع تخصص خودشان می توانند قسمت هایی از پروژه (Model یا View) را طراحی کنند و با استفاده از Controllerها ارتباط میان لایه ها را بسازند.

7) اجبار در کدنویسی مبتنی بر الگوی طراحی : ASP.NET MVC توسعه دهندگان را مجبور به رعایت الگوی طراحی MVC می کند. این اجبار باعث ایجاد یک وب اپلیکیشن با ساختار استاندارد می شود که نگهداری و توسعه آن در دراز مدت آسان خواهد بود.

8 ) کدباز بودن : سورس کد فریم ورک ASP.NET MVC با مجوز Ms-pl که یک مجوز اوپن سورس از شرکت مایکروسافت است، منتشر می شود. کدباز بودن این فریم ورک باعث شده تا شرکت مایکروسافت فیدبک های دقیق تر و سودمندتری از جامعه توسعه دهندگان ASP.NET دریافت کند ودر نتیجه باعث پیشرفت سریعتر آن شده است.

9) سرعت بیشتر در بارگذاری صفحات : همانطور که اشاره شده، با حذف کنترل های تحت سرور، PostBack و ViewState که باعث ایجاد کدهای اضافی جاوا اسکریپت می شود، سرعت لود صفحات وب در ASP.NET MVC به مراتب بیشتر از وب فرم هاست.

farasun.wordpress.com

مشترک فراسان شويد

farasun.wordpress.com

WebMatrix توسعه وب را آسان تر می کند

مایکروسافت به تازگی ابزار جدیدی برای توسعه دهندگان وب به نام WebMatrix ارائه کرده است که سفارشی کردن وب اپلیکیشن های موجود یا ساخت یک وب سایت جدید را با امکانات خوب و راه حل های ساده، آسان می کند. این ابزار سبک به افراد کمک می کند تا به راحتی برنامه نویسی با ASP.NET را شروع کنند و خیلی زود در آن پیشرفت کنند. WebMatrix شامل ابزارهای مهم مایکروسافت برای توسعه وب  است. این ابزارها شامل :

• IIS Developer Express : یک وب سرور سبک و رایگان که با تمام نسخه های ویندوز و نسخه کامل IIS سازگار است.
• ASP.NET : یک فریم ورک رایگان شامل کلاس های پایه برای توسعه وب.
• SQL Server Compact : یک نسخه embedded و بسیار سبک و رایگان از SQL Server که بر اساس فایل کار می کند.
• Razor Syntax : یک View Engine جدید و ساده برای ASP.NET که کدهای سمت سرور سی شارپ یا ویژوال بیسیک را با کدهای HTML ترکیب می کند (مانند  PHP) و یادگیری آن ساده و لذت بخش است.

WebMatrix با استفاده از تکنولوژی های بالا، یک محیط مجتمع ساده و در عین حال قدرتمند برای ساخت وب سایت های داینامیک و مطابق با استاندرادهای جدید به ساده ترین شکل ممکن در اختیار کاربر خود قرار می دهد. شما با وب ماتریکس می توانید یک وب اپلیکیشن اوپن سورس مثل BlogEngine.NET را انتخاب کنید، آن را بر اساس نیاز خود سفارشی کنید و به راحتی آن را بر روی هاست خود پابلیش کنید. پروسه استفاده از وب اپلیکیشن های اوپن سورس در اینترنت با WebMatrix بسیار آسان خواهد بود. شما با وب ماتریکس حتی قادر به انتخاب CMSهای نوشته شده با PHP مثل وردپرس، جوملا و Drupal نیز هستید و حتی می توانید آن ها را با ابزارهای موجود در وب ماتریکس توسعه داده و از همانجا بر روی هاست خود پابلیش کنید.

برای شروع شما می توانید WebMatrix را از اینجا دانلود کنید. اگر دات نت فریم ورک 4.0 را نصب نداشته باشید، کمی حجم دانلود وب ماتریکس بالا خواهد بود، در غیر این صورت با دانلود 15 تا 20 مگابایت WebMatrix را در اختیار خواهید داشت. پس از اجرای آن با یک محیط ساده مواجه خواهید شد که فقط 4 انتخاب را پیش روی شما می گذارد. می توانید یک سایت جدید خالی ایجاد کنید یا از وب اپلیکیشن های موجود در گالری مایکروسافت برای شروع استفاده کنید. هر طور که شروع کنید، وب ماتریکس به شما اجازه مدیریت بر صفحات سایت و تغییر آن ها، مدیریت بر فایل های وب سایت، مدیریت بر دیتابیس سایت و در نهایت پابلیش سایت بر روی سرور را می دهد.

همانطور که اشاره شد، شما در وب ماتریکس می توانید از سینتاکس Razor برای نوشتن کدهای سی شارپ و ویژوال بیسیک در میان کدهای HTML بهر ببرید. یادگیری سینتاکس Razor خیلی آسان است. شما کدهای خود را با یک علامت @ آغاز می کنید و بلاک کد خود را در سی شارپ با { و } محصور می کنید. هر جا که از علامت @ استفاده کنید یعنی می خواهید یک کد سمت سرور را بنویسید. از متغیرها بدون تعیین نوع آن ها استفاده می کنید، سپس ASP.NET خودش بهترین تصمیم را برای تعیین نوع متغیر بر اساس مقداری که درون آن ذخیره می شود خواهد گرفت. صفحاتی که دارای کد Razor هستند دارای پسوندهای مخصوص cshtml یا vbhtml خواهند بود. سینتاکس Razor تمام قدرت ASP.NET را با قواعدی آسان تر در اختیار مبتدیان قرار می دهد، اما حرفه ای ها نیز می توانند به بهترین شکل برای بالا بردن کارایی خود از آن استفاده کنند. یک کد بسیار ساده با سینتاکس Razor را ببینید :




<html>
<head>
<title>Razor Syntax Sample</title>
</head>
<body>
@{
var message = «Hello World.»;
var today = DateTime.Now.ToString();
}
<p>Message : @message</p>
<p>Today is : @today</p>
</body>
</html>

اینطور که پیداست مایکروسافت راه درستی را انتخاب کرده و باید منتظر تکنولوژی های جدیدتر و بهترش در زمینه توسعه وب باشیم. اینکه نظر مایکروسافت در این چند سال اخیر نسبت به نرم افزارهای اوپن سورس تغییرات مثبت زیادی داشته خیلی خوب و سازنده است. مایکروسافت نیز اهمیت استفاده از وب اپلیکیشن های اوپن سورس را در توسعه وب به خوبی می داند و به همین دلیل Microsoft Web Gallery را راه اندازی کرده و توسعه دهندگان را به جای باز تولید اپلیکیشن های تکراری به استفاده و توسعه وب اپلیکیشن های اوپن سورس موجود تشویق می کند. Web Platform Installer و WebMatrix دو ابزار مهم مایکروسافت در زمینه توسعه وب هستند که به صورت توکار از وب اپلیکیشن های اوپن سورس پشتیبانی می کنند و قادرند آن ها را دانلود، تنظیم و پابلیش کنند. تکنولوژی های تحت وب هرچه بازتر باشند بیشتر مورد تایید و مورد اعتماد توسعه دهندگان وب خواهند بود، این را مایکروسافت به خوبی می داند. بدون شک در آینده ای نه چندان دور از WebMatrix و Razor Syntax بیشتر خواهیم شنید.

منابع بیشتر در مورد WebMatrix

• دانلود WebMatrix
• یادگیری استفاده از WebMatrix
• نوشته Scott Guthrie در مورد WebMatirx
• نوشته Scott Hanselman در مورد WebMatrix

نکات امنیتی برای برنامه نویسان ASP.NET

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

در این مطلب کوتاه با نکاتی آشنا خواهید شد که اگر آن ها را بکار ببرید می توانید تا حدی امنیت وب اپلیکیشن های خود را تامین کنید.

1) داده های ورودی کاربران را اعتبارسنجی کنید

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

2) اطلاعات حساس را کد کنید

قانون دوم : هر اطلاعاتی را که فکر می کنید ممکن است از آن سوء استفاده شود را کد کنید. حتماً Username و Password کاربران را کد کرده و سپس ذخیره کنید. Hash کردن رمز عبور یکی از بهترین و مطمئن ترین راه ها برای تامین امنیت رمزعبور کاربران است. برای این کار در دات نت راه حل های خوبی وجود دارد. اطلاعات حساس دیگر مثل Connection String دیتابیس خود را حتماً Encrypt کنید. در ASP.NET توصیه شده است به جای اینکه رشته اتصال دیتابیس خود را در کدهای خود بنویسید، آن را به صورت جداگانه در فایل Web.config تعریف کنید. از آن جایی که فرمت این فایل XML است و امنیت پایینی دارد، شما باید تمام اطلاعات حساس این فایل از جمله Connection String را کد کرده و سپس ذخیره کنید.

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

3) اطلاعات تکنیکی را از دید کاربران مخفی کنید

در برنامه های ASP.NET هنگامی که خطایی رخ می دهد که توسط برنامه هندل نشده، تمام اطلاعات تکنیکی مربوط به خطای مذکور با ذکر جزئیات و حتی خطی از برنامه که خطا در آن اتفاق افتاده است توسط کاربران قابل مشاهده است. البته این تنظیمات پیش فرض ASP.NET برای زمان توسعه در Localhost و خطایابی مناسب است که هنگام پابلیش وب اپلیکیشن بر روی اینترنت یا اینترانت باید تغییر کند. متاسفانه برخی از برنامه نویسان ناشی هنگام توزیع وب اپلیکیشن خود همان فایل web.config روی لوکال هاست خود را بدون هیچ تغییری بر روی محیط اجرایی قرار می دهند. این گونه پیغام های خطای ASP.NET معمولاً اطلاعات مناسبی در مورد آسیب پذیری های یک وب سایت در اختیار یک هکر قرار می دهد. برای حل این مشکل شما باید تمام خطاهای ممکن را هندل کنید و مقدار ویژگی customErrors در فایل web.config را برابر RemoteOnly قرار دهید.

<customErrors mode=«RemoteOnly«></customErrors>

4) حالت دیباگ را غیرفعال کنید

هنگام توسعه یک وب اپلیکیشن در ASP.NET حالت Debug به صورت پیش فرض true است. شما باید پس از توسعه و هنگام آپلود وب اپلیکشن در یک هاست اینترنتی خاصیت debug در قسمت compilation فایل web.config را برابر false قرار دهید. این کار هم کارایی برنامه تحت وب شما را بالاتر می برد و هم از نشان دادن برخی از خطاها که باعث لو رفتن کدهای شما می شود جلوگیری می کند.

5) مواظب حملات SQL Injection باشید

این نوع حملات در اکثر وب سایت های اطلاعاتی مبتنی بر دیتابیس مرسوم است. به این صورت که کاربر/هکر یک کد SQL را به برنامه شما تزریق می کند و باعث ایجاد خرابکاری می شود. با وجود خطرناک بودن و جدی بودن این نوع حمله باز هم هستند برنامه نویسانی که به این مورد توجهی ندارند. به طور مثال در یک فرم لاگین نا امن که کوئری چک کردن Username و Password شبیه به کد زیر باشد، حمله SQL Injection به راحتی امکان پذیر است.

string query = «SELECT * FROM Users WHERE username='» +
txtUsername.Text + «‹ AND password='» + txtPassword.Text + «‹»;

در این موقعیت یک فرد نسبتاً باهوش با نوشتن رشته x› or username like %x در فیلد password به راحتی می تواند فرم لاگین شما را رد کرده و خود را به عنوان یک کاربر قانونی جا بزند. برای جلوگیری از این مشکل حتماً قانون اول را رعایت کنید و به جای استفاده از مقادیر تکست باکس ها به این صورت، از کلاس SqlParameter برای مقداردهی استفاده کنید. یکی از راه های دیگر برای جلوگیری از این حمله استفاده از ORMهایی مثل LINQ  to SQL است.

6) جلوگیری از حملات Cross-site Scripting

یکی از مرسوم ترین و در دسترس ترین نوع حملات به وب سایت هاست که فرد خرابکار سعی می کند اسکریپت مخربی را به وب اپلیکیشن شما تزریق کند. به طور مثال در فرم های ورود اطلاعات کاربر خرابکار می تواند به جای وارد کردن اطلاعات صحیح، کدهای جاوا اسکریپت مخرب را وارد کند. خوشبختانه ASP.NET به صورت پیش فرض دارای یک محافظ درخواست توکار است که در اکثر مواقع جلوی این حملات را می گیرد. اما باز هم نمی توان به صورت صد در صد به آن اطمینان کرد، چون راه هایی برای دور زدن آن نیز وجود دارد. بهتر است هنگام نمایش دادن داده های ورودی کاربر، ابتدا رشته مورد نظر را با Server.HtmlEncode به یک رشته امن HTML تبدیل کنید و سپس آن را نمایش دهید. در این صورت اگر حتی کاربر اسکریپت مخربی را با موفقیت به برنامه شما تزریق کرده باشد، آن اسکریپت اجرا نخواهد شد و فقط به صورت یک رشته به نمایش در خواهد آمد.

7) سیستم لاگین خود را امن بسازید

روش مرسوم برای پیاده سازی سیستم لاگین در وب، روش استفاده از Session است. Session متغیرهایی هستند که بر روی سرور به ازای هر کاربر لاگین شده ساخته می شوند و وب اپلیکیشن با چک کردن متوالی آن در هر صفحه هویت کاربر وارد شده را شناسایی می کند. یک Session معمولاً برای یک مدت زمان محدودی (مثلاً 20 دقیقه) اعتبار دارد و پس از آن کاربر دوباره باید به سیستم لاگین کند. در ASP.NET بهترین و امن ترین راه برای پیاده سازی لاگین استفاده از ویژگی خوب تشخیص هویت خود دات نت است. منظورم همان FormsAuthentication است که شما با آن می توانید یک سیستم لاگین بسیار امن پیاده سازی کنید. به هیچ وجه از کوکی ها برای پیاده سازی یک سیستم لاگین استفاده نکنید! از کوکی ها فقط برای پیاده سازی قابلیت «Remember Me» استفاده کنید آن هم با کلی احتیاط! یک نکته دیگر در مورد لاگین این است که تعداد تلاش های ناموفق یک کاربر برای لاگین را محدود کنید. مثلاً بعد از 5 بار وارد کردن اشتباه رمز عبور به او تا یک مدت اجازه ورود ندهید!

8 ) در مواقع لازم از تصاویر امنیتی استفاده کنید

این نکته را در اکثر وب سایت ها و هنگام ثبت نام دیده اید. مثلاً گوگل در هنگام ثبت نام شما را مجبور می کند که یکسری حروف عجیب و غریب را که در عکس می بینید درون تکست باکس وارد کنید تا بفهمد شما آدم هستید! شما هم سعی کنید در اکثر فرم هایی که نیاز به لاگین کاربر ندارند (مثل فرم ثبت نام یا فرم تماس) از این تصاویر استفاده کنید.

9) امنیت دیتابیس خود را تامین کنید

معمولاً دیتابیس های SQL Server دارای امنیت بسیار خوبی هستند اما اگر از دیتابیس Access برای ذخیره اطلاعات استفاده می کنید حتماً 1- روی فایل آن پسورد بذارید 2- مطمئن شوید که فولدری که فایل دیتابیس در آن قرار دارد توسط کاربران قابل دسترسی نباشد 3- حتماً اطلاعات داخل آن را کدگذاری کنید.

farasun.wordpress.com

مطالب مرتبط :

• طراحی و برنامه نویسی وب با تکنولوژی های رایگان مایکروسافت
• 10 نکته SEO برای وب سایت های ASP.NET
• پیاده سازی «من را بخاطر بسپار» در ASP.NET
  

مصائب فلش! یا چرا اپل از فلش استفاده نمی کند؟

Flash نام بزرگی در دنیای اینترنت و PCهاست که این روزها آینده و حیاتش به چالش جدی کشیده شده است. با سر و صدایی که اپل با پشتیبانی نکردن از ادوبی فلش در محصولات خود از جمله iPad و iPhone راه انداخت و با ارائه HTML 5 که امکانات چند رسانه ای فوق العاده خوبی به توسعه دهندگان وب می دهد، تردید بسیار جدی ای در آینده Adobe Flash بوجود آمده است. فلش در زمان پیدایش خود یک پدیده دوست داشتنی و مدرن بود. پدیده ای که به شما اجازه می داد با کمترین دانش و کمترین زحمت انیمیشن های اینتراکتیو بسیازید و از آن ها در وب استفاده کنید. مشکل فلش شاید این بود که مثل تکنولوژی های دیگر زود به زود تغییر نکرد و همان رویه اولیه خود را دنبال کرد تا به امروز که دیگر جوابگوی نیازهای توسعه دهندگان وب و حتی کاربران اینترنت نیست.

مشکلاتی که در نوشته به آن ها اشاره شده، مشکلاتی نیستند که در این چند ماه اخیر بوجود آمده باشند. این ها مشکلاتی هستند که از ابتدا در مورد استفاده فایل های فلش در وب مطرح بودند.

موتورهای جستجو فلش را دوست ندارند!

یکی از مهمرین دلایل برای عدم استفاده از فلش، ایندکس نشدن محتویات فایل های فلش در موتورهای جستجوست. اطلاعات مخفی شده در فایل های گرافیکی مثل فایل های فلش برای موتورهای جستجو قابل دسترسی نیستند، هرچند موتورهای جستجوی پیشرفته ای مثل گوگل سعی می کنند محتویات فایل های فلش را نیز ایندکس کنند، اما این عمل با محدودیت های بسیار زیادی مواجه است. وب سایت هایی که کاملاً با فلش ساخته شده اند وضع بسیار نامناسبی از نظر SEO دارند. تگ های متا در فایل های HTML از مهمترین عناصر مربوط به SEO هستند که در وب سایت های Full Flash قابل استفاده نیستند. فایل های فلش معمولاً اطلاعات متنی بسیار کمی ارائه می کنند و اکثراً برای تاثیر گذاری بیشتر فایل های عکس و فیلم را به نمایش می گذارند. گوگل چند وقت پیش از بهبود جستجوی text در فایل های فلش خبر داد و ایندکس کردن اطلاعات عکس، فیلم و انیمیشن بکار رفته در یک فایل فلش را منتفی دانست.

فلش استانداردهای Usability وب را رعایت نمی کند

سایت های فلش زیبا و چشم نواز هستند. شاید برای یک کاربر عادی استفاده از یک سایت فلش حتی راحت تر از استفاده از یک وب سایت معمولی ساخته شده با HTML و CSS باشد. اما محدویدت هایی که فلش برای یک کاربر ایجاد می کند استانداردهای قابل استفاده بودن وب را زیر پا می گذارد. به طور مثال در یک وب سایت فول فلش سعی کنید از دکمه Back مرورگر خود استفاده کنید، متاسفانه کار نمی کند. سعی کنید قسمتی از متن را انتخاب و کپی کنید، یا سعی کنید با استفاده از امکانات مرورگر خود اندازه متن را بزرگ و کوچک کنید! متاسفانه هیچکدام از این امکانات کار نمی کنند. اصلاً یک نکته مهم دیگر : در وب سایت های فول فلش شما نمی توانید استایل صفحه را با استفاده از ابزارهایی مثل Stylish بر اساس سلیقه خود تغییر دهید!

کاربرانی که فلش ندارند!

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

دلایل اپل برای استفاده نکردن از فلش

استیو جابز در نوشته ای دلایل خود را برای عدم استفاده از فلش در محصولات اپل بیان کرده است. اولین دلیل و از نظر من مهمترین دلیل برای استفاده نکردن از فلش، بسته بودن فلش نسبت به سایر تکنولوژی های وب و مخصوصاً HTML و CSS است. استانداردهای فلش را فقط ادوبی تعیین می کند و تمام آینده آن در دست این شرکت است. این در حالی است که استانداردهای مهم وب مثل HTML، CSS و JavaScript همگی باز هستند. چرا باید این استاندرادهای باز را کنار بگذاریم و از محصول بسته شرکت ادوبی استفاده کنیم!؟

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

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

به هر حال با ارائه HTML5 و CSS3 باید منتظر کم رنگ تر شدن هرچه بیشتر نقش Adobe Flash در توسعه وب باشیم. شرکت مایکروسافت نیز همانند گوگل و اپل در مرورگر خود اینترنت اکسپلورر 9 از HTML5 پشتیبانی خواهد کرد و این یعنی آینده وب را تکنولوژی های بازی همچون HTML, CSS و JavaScript خواهند ساخت.

دلایل دیگر برای عدم استفاده از فلش

در وب سایت های فول فلش معمولاً URLهای یکتایی برای هر صفحه وجود ندارد. این مسئله باعث می شود کاربران نتوانند یک صفحه خاص از سایت را بوکمارک کنند و موتورهای جستجو نیز قادر به تفکیک صفحات مختلف از هم نخواهند بود.

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

همانطور که در متن اشاره شد، فایل های فلش معمولاً حجم زیادی دارند و این باعث استفاده بیشتر از پهنای باند اینترت کاربران و در نتیجه عدم رضایت آن ها می شود.