در انتظار زبان بزرگ بعدی (NBL برای زبان بزرگ بعدی) ، این اکنون 3 سال یا بیشتر است ، زیرا من مشتریان خود را آینده ای روشن برای JavaScript به عنوان یک زبان برنامه نویسی زبان پیش بینی می کنم. استدلال من عمدتاً مبتنی بر زیبایی شناسی ، سادگی و ماهیت پویا او بود. در سال 1995 توسط Sun Microsystems (به دست آمده توسط Oracle) و Netscape (خریداری شده توسط AOL) طراحی شده است ، ادغام آن در مرورگرهای اینترنتی به طور گسترده ای گسترش یافته است ، اما فقط از سال 2004 از طریق برنامه های AJAX و وب مانند Gmail و Google Maps ، که این زبان عنوان خود را به دست آورد و عنوان خود را برای درد و خوب بودن و خوشحالی از عارض
با وجود برخی تلاش های ناموفق ، استفاده از آن محدود به جبهه بود ، به این معنی که مرورگرهای وب که در آن می توانیم صفحات وب را تحریک کنیم. در سالهای اخیر ، جامعه منبع آزاد تصمیماتی پدید آمده است. من به طور خاص در مورد Helma ، که در دستگاه مجازی جاوا فعالیت می کند ، فکر می کنم ، بنابراین به راحتی با اکوسیستم جاوا گسترده تر ادغام می شود ، بلکه با راه حل های خلاقانه تری مانند Jaxer ، که ویژگی آن ایجاد محیطی شبیه به مرورگر (مانند دستکاری DOM) بر روی سرور است. از همه ، این احتمالاً ناروال بود که قوی ترین تصور از معماری ساده او و مدولار بودن مترجم جاوا اسکریپت را برای من به جا گذاشت.
در سالهای اخیر ، من اخبار مربوط به راه حل های سرور ، آزمایش هر یک از آنها و تجزیه و تحلیل رویکردهای آنها را دنبال کرده ام. از نظر ترافیک ایجاد شده توسط هر مقاله ای که موضوع را در بر می گیرد ، فهمیدم که من منزوی نیستم. اما هیچ یک از پروژه ها نتوانستند مرا متقاعد کنند که از این شخص بد که PHP است ، دست بکشد. تا چند ماه پیش با ظهور Nodejs.
بیایید کمی برگردیم. آژاکس توجه داشته باشید که اهمیت و نیاز به اثربخشی در مرورگرهای وب و مترجم JavaScript داده های اصلی در مورد برنامه های اینترنتی غنی SO (RIA) است. ویراستاران موزیلا و مایکروسافت ، با سافاری به اپل پیوستند و اخیراً Google با Chrome یک مسابقه بهینه سازی را آغاز کرده است. این رقابت سالم نسل های جدیدی از مترجمان مانند Tracemonkey را برای Firefox 3.6 ، سنجاب های Safari 5 ، Carakan برای Opera و V8 برای Chrome به وجود آورده است. برای مدت طولانی او عقب مانده است ، حتی مایکروسافت در نسخه 9 در اینترنت اکسپلورر شرط بندی کرده است. امروز ، JavaScript بدون شک زبانی است که بخش بزرگتر از تلاش های توسعه را متمرکز می کند.
اما دلیل دیگری وجود دارد که JavaScript یک انتخاب سریع و عالی از سرور است. از نظر طبیعت ، این برخلاف سرورهای با محوریت ، به وقایع گرایش دارد. این ویژگی این زبان از منشأ آن ناشی می شود ، جایی که قصد دارد در مرورگرهای اینترنتی کار کند و حفظ رویدادهای مصرف کننده بدون اشباع کل مرورگر با هر عمل ضروری است. به طور سنتی ، برنامه های سرور در حالت مسدود کردن موضوع SO -Called نوشته شده اند. این مورد در مورد برنامه های PHP و CGI و بیشتر کاربردهای پایتون ، روبی یا جاوا است.
من سعی خواهم کرد تا حد ممکن باشم. هنگامی که سرور درخواستی را دریافت می کند ، مانند ارسال فرم ، سرور موضوع موجود را در اختیار شما قرار می دهد و برنامه ای را که عملیات خود را یکی پس از دیگری انجام می دهد راه اندازی می کند (اتصال پایگاه داده برای تأیید نام و رمز عبور کاربر ، در یک پرونده ورود به سیستم ، …) بنویسید ، قبل از اینکه پاسخ را به فرم برگردانید و موضوع را ببندید. اما تعداد موضوعات محدود است و این برنامه ها هنگام رسیدن به اشباع حافظه به سرعت خطاها را ایجاد می کنند. هر نخ تا پایان تمام عملیات انحصار می شود. این عملیات مانند نوشتن پرونده در مقایسه با سرعت پردازنده مدت زیادی طول می کشد و این فقط یک ضرر است. برای برنامه های با حجم زیاد ترافیک ، هر درخواست باید رمزگذاری شود تا حد ممکن کوتاه باشد. از طرف دیگر ، در محیط رویداد ، این عملیات مشابه غیر مسدود کننده نامیده می شوند ، زیرا در حالی که منتظر خواسته شده برای یک پایگاه داده یا در یک فایل هستند ، سرور ممکن است به انجام کارهای دیگر در همان موضوع ادامه دهد.
عدم وجود یک جایگزین بدون مسدود کردن حتی می تواند برای سناریوهای خاص مانند بارگیری پرونده های بزرگ ، گروه بندی نتایج از چندین باکتری و آخرین و مهمترین پشتیبانی پروتکل Bayeux (دنباله دار) که راه را برای فشار HTTP باز می کند ، به غیر کار تبدیل شود.
با این فرض که بیشتر برنامه های سرور در پیش بینی نتایج عملیات I/O (دسترسی به پایگاه داده های شبکه ، خواندن و نوشتن در سیستم فایل ، …) هزینه می شود ، برنامه نویسی رویداد به ویژه با محیط سرور سازگار است. خمیده در پایتون و Eventmachine در روبی به این مشکل پاسخ می دهد ، اما هیچ کس از قدرت زبان ادغام این توابع ، بومی استفاده نمی کند.
بیایید به گره برگردیم. توسط نویسنده آن به عنوان پایه ای عالی برای توسعه برنامه های وب توصیف شده است ، این مبتنی بر موتور V8 JavaScript است که توسط Google برای مرورگر خود Chrome ساخته و مورد استفاده قرار گرفته و باز شده است. این یکی از سریعترین بازار است (سریعترین چیزی را نمی گویم) و با هر نسخه جدید بهبود می یابد. همه چیز در توسعه گره در اپتیک رویدادی ساخته و بهینه می شود که به طور قابل توجهی توانایی نوشتن برنامه های آهسته را کاهش می دهد ، زیرا خواستار مسدود کردن عملیات به I/O می شود. جامعه منبع باز پتانسیل این پلتفرم را تشخیص می دهد و یک اکوسیستم غنی ساخته شده است ، از جمله درایورها (Couchdb ، MongoDB ، Redis ،…) ، کتابخانه ها (HAML ، SASS ، Expresso ،…) و فریم ها (اتصال ، اکسپرس ، …).
به نمایندگی از مشتری ، من برنامه نمونه سازی شده و پردازش سریع ، ساده و بصری است. کد ظریف ، کوتاه و خوانا است. تنها چیزی که انتظار داشتم وعده های JavaScript از سرور بود. برای تحقق پروتو و علی رغم جوانان اکوسیستم ، مجبور شدم هر چیزی را از دست بدهم. دیدن این امر به من این امکان را می دهد تا از مفاهیم وام گرفته شده از جهان روبی و پایتون استفاده کنم ، که در PHP وجود ندارد (یک فکر ویژه برای SASS). برای کسانی که با توسعه برنامه های مشتری غنی از جاوا اسکریپت آشنا هستند ، انتقال تقریباً لحظه ای خواهد بود.
برای خلاصه کردن node.js در چندین جمله:
- JavaScript برای رویدادها ساخته شده است: فراخوانی برنامه نویسی برای توسعه دهندگان برنامه AJAX شناخته شده است و برای این کار ، نحو ویژگی های ناشناس و پشتیبانی از بسته بندی سازگار و ظریف است.
- گره بر روی JavaScript ساخته شده است: با حضور در مرورگرها احتمالاً بیشترین برنامه های جهان است و 15 سال تجربه دارد.
- گره تثبیت می شود: API رسیده و نزدیک به نهایی شدن است.
- گره دارای اکوسیستم است: بسیاری از کتابخانه ها در دسترس هستند ، همه در کد باز ، اخبار در حال ظهور است و همه کیفیت خوبی از تحقق دارند.
- گره ساده و کوچک است: اسناد در یک نگاه است و به آن اجازه می دهد تا به سرعت ویژگی های آن را بشناسد.
- گره سریع است: موتور V8 و معماری غیر مسدود کننده آن را به یکی از قدرتمندترین معماری های موجود در بازار ، به خصوص برای درخواست های طولانی و شدید IO تبدیل می کند.
