- این مثال‌ها با کروم اجرا شدند. مثال اول را با فایرفاکس اجرا کردید؟ مثال دوم که به همین نحو باید باشد. 
اجرا شدن مثال اول با فایرفاکس به این معنا است که هنوز پیاده سازی استاندارد ES 6 در فایرفاکس، توابع قرار گرفته‌ی در یک block را block-scoped نمی‌داند (و این پیاده سازی هنوز ناقص است).
- وجود let به نوعی پیاده سازی مفهوم fail fast است. هر چه سریعتر مشکلات مشخص شوند، بهتر از این است که در آینده با گنگ بودن میدان دید متغیرها، مشکلات دیباگ برنامه بیشتر شوند.

بهتر است الگوی CQRS را دنبال کنید.

Jexus Manager هم امکان تنظیم و ویرایش جزئیات مربوط به SSL سایت‌های IIS Express را دارد.

- در متد runDownloadTask همان کلاس، encoding دریافت را هم مشخص کنید:
- البته ترجمه فارسی آن ماشینی و به احتمال زیاد توسط مترجم آنلاین گوگل انجام شده و ... فاقد ارزش است.

- نگارش مورد استفاده در این سری «بتا 15» است. بنابراین آنچنان شاهد تغییرات اساسی در API در دسترس آن نخواهید بود.
همچنین نگارش نهایی آن هم به زودی در دسترس خواهد بود.
+ زمانیکه قرار است از فریم ورک‌های جاوا اسکریپتی SPA یا Single page applications مانند AngularJS استفاده شود، عملا دات نت تبدیل خواهد شد به فراهم کننده‌ی اطلاعات و دریافت کننده‌ی اطلاعات و نه بیشتر. بنابراین حداکثر به یک وب سرور نیاز خواهد بود؛ به همراه فناوری که بتواند JSON تولید کند (ارسال data به کلاینت) و JSON دریافت کند (دریافت data از کاربر). در این حالت اهمیتی ندارد که از MVC استفاده کنید یا از ASP.NET Web API و یا ... هر فناوری سمت سرور دیگری. همینقدر که این فناوری بتواند خروجی JSON را پردازش کند و یا در کنار آن وب سروری هم جهت هاست سایت فراهم باشد، کافی است.
یعنی در این حالت قابلیت‌های رندر HTML فناوری‌هایی مانند ASP.NET MVC و هم ASP.NET Web forms فراموش خواهند شد؛ چون استفاده‌ای از توانمندی‌های آن‌ها نخواهیم کرد.
استفاده از فریم ورک‌های SPA یعنی آزادی انتخاب نحوه‌ی ندر HTML نهایی و مدیریت فعالیت‌های کاربران در سمت کاربر. سمت سرور آن هم چیزی بیشتر از دریافت و یا ارسال data با فرمت JSON نیست.

- اتفاقا برعکس است. چون از سرور محتوای JSON را دریافت می‌کنید (Data)، حجم کمتری نسبت به HTML نهایی رندر شده‌ی در سمت سرور (HTML+Data) دارد.
- از سال 2014، گوگل شروع به پردازش جاوا اسکریپت موجود در صفحات وب هم کرده‌است. بنابراین مشکلی با این نوع برنامه‌ها ندارد.

ممنون. بله. منظور package.json بوده.

- شاید Angular 2 بهترین نباشد یا نشود، اما این مهم نیست. عوامل زیادی در انتخاب یک فریم ورک مؤثر هستند:

• چه کسانی این فریم ورک را توسعه می‌دهند؟ گوگل. این مورد خیلی مهم است. در این بین شاید Aurelia مدرن‌تر به نظر برسد اما تیم آن سابقه‌ی خوبی در نگهداری محصولات قبلی آن ندارد. برای مثال Durandal آن‌ها به طور کامل رها شده و الان Aurelia را شروع کرده‌اند.

• تیم Angular اینقدر شجاعت داشته که اقرار کند نگارش 1 آن مشکلات زیادی دارد و دست به یک بازنویسی کامل زده‌اند. باید دقت کرد که چقدر این‌کار برای یک تیم محبوب در وب مشکل است و قطعا نگارش 2 آن که با این حجم بالای اعتراضات عدم سازگاری با نگارش 1 آن تولید شده‌است، بسیاری از مشکلات نگارش قبلی را ندارد. همچنین همین مساله سازگاری آن‌را با نگارش‌های بعد از 2 نیز تضمین خواهد کرد. چون اینبار دست به یک طراحی مجدد زده‌اند و ... این طراحی مجدد خیلی برای آن‌ها گران تمام شده‌است (خصوصا از لحاظ حجم انتقادهای رسیده). بنابراین در آینده در زمینه سازگاری با نگارش‌های قبلی به شدت محتاط خواهند بود. این موردی است که استفاده کنندگان از ReactJS به زودی با آن مواجه خواهند شد.

• گروه کاربری مصرف کنندگان آن. چه تعداد مقاله، ویدیوی آموزشی، انجمن رفع اشکال و امثال این‌ها را در مورد یک محصول می‌توانید پیدا کنید؟ قطعا AngularJS در این زمینه حرف اول را می‌زند.

• Angular 2 بر مبنای استاندارد web component طراحی شده‌است که در دراز مدت نیز سبب برد AngularJS 2 خواهد شد و نیاز کمتر به بازنویسی‌های کلی.

• Angular 2 برای کار با محصولات موبایل بهینه سازی شده‌است و مانند بوت استرپ 3 یک فریم ورک mobile first است.

• استفاده‌ی از Type Script به عنوان زبان اول این پلتفرم (البته استفاده‌ی از آن اجباری نیست). این مساله در دراز مدت سبب تولید کدهایی با کیفیت بالاتر می‌شود. برای مثال الان ReactJS مخلوطی است از ES 5 و ES 6. اما AngularJS 2 تصمیم بهتری را اتخاذ کرده‌است. همین مساله سبب شده‌است که توسعه‌ی Type Script توسط مایکروسافت سرعت بیشتری پیدا کند.

• داشتن امکانات توکار بیشتری نسبت به رقبا. برای مثال ReactJS یک کتابخانه است؛ اما AngularJS 2 یک فریم ورک کامل که تمام کتابخانه‌های جانبی رقبا را یکجا از روز اول دارد.

بنابراین آیا پس از ارائه‌ی نهایی Angular 2، ارزش یادگیری را دارد؟ بله؛ حتما. ابتدا (و هم اکنون) اعتراض‌های شدیدی در مورد عدم سازگاری آن با نگارش‌های قبلی وجود خواهد داشت و پس از مدتی همه آن‌را فراموش کرده و خودشان را وفق می‌دهند.  

مشکل عنوان شده در قسمت «تداخل ReSharper با شماره نگارش TypeScript نصب شده» با آخرین نگارش ReSharper برطرف شده‌است:

نیاز هست وقت بگذارید و تک تک آن‌ها را استخراج و بعد آنالیز کنید. نمونه‌ی نحوه‌ی استخراج استریم‌ها در مطلب «فشرده سازی حجم فایل‌های PDF توسط iTextSharp» بحث شده‌است.