لماذا أصبح رجل في عالم جافا من المؤيدين المتحمسين لـ Node.js و JavaScript؟

طرح ديفيد هارون ، مؤلف المادة التي ننشرها اليوم ، السؤال التالي: "هل يجب على الشخص الذي عمل لأكثر من 10 سنوات في Sun Microsystems في فريق Java SE ، حتى النفس الأخير ، أن يفكر فقط في Java bytecode ويخلق أمثلة من الواجهات المجردة؟ ". سأل هذا السؤال فيما يتعلق بنفسه ، وبالنسبة له أصبحت منصة Node.js ، بعد جافا ، وكأنها نسمة من الهواء النقي. يقول ديفيد أنه عندما تم فصله من Sun في يناير 2009 (مباشرة قبل الاستحواذ على شركة Oracle هذه) ، اكتشف Node.js. ربطته هذه التكنولوجيا به. ماذا يعني "مدمن مخدرات"؟ منذ عام 2010 ، كتب الكثير عن البرمجة لـ Node.js. على وجه التحديد ، كتب العديد من الكتب ، بما في ذلك Node.js Web Development ، التي تم إصدار الطبعة الرابعة منها هذا العام. قام بإعداد العديد من المواد الصغيرة حول Node.js المنشورة على الإنترنت. في الواقع ، قضى الكثير من الوقت والجهد في التحدث عن منصة Node.js وميزات JavaScript. لماذا انجذب أولئك الذين عملوا سابقًا حصريًا في جافا إلى Node.js و JavaScript؟

حول عالم جافا

أثناء العمل في صن ، كنت أؤمن بتقنية جافا. قدمت عروض تقديمية في JavaONE ، وشاركت في تطوير فئة java.awt.Robot ، ونظمت حدث مسابقة Mustang Regressions (كانت منافسة تهدف إلى العثور على أخطاء في Java 1.6) ، وساعدت في إطلاق ترخيص توزيع لمشروع Java ، والذي كان بمثابة إجابة على السؤال حول توزيعات Linux JDK قبل ظهور OpenJDK. في وقت لاحق ، لعبت دورًا في إطلاق مشروع OpenJDK. على طول الطريق ، لمدة 6 سنوات ، قمت بنشر مواد مدونة على java.net (الآن هذا الموقع مغلق). كانت هذه عبارة عن مقالتين أو أسبوعين مخصصة للأحداث المهمة في نظام جافا البيئي تم لعب دور مهم في عملي من خلال حماية Java من أولئك الذين تنبأوا بمستقبل كئيب لهذه التقنية.


وقد تم منح هذه الجائزة ، جائزة Duke ، لموظفي Sun المتميزين. حصلت عليها بعد أن نظمت مسابقة موستانج للتراجع

ماذا حدث للشخص الذي فعل الكثير مع كل ما يتعلق بـ Java؟ في الواقع ، أريد أن أتحدث هنا عن كيف تحولت من محب Java إلى مؤيد متحمس لـ Node.js و JavaScript.

يجب أن أقول أن ما حدث لي لا يمكن أن يسمى التخلي الكامل عن جافا. على مدى السنوات الثلاث الماضية ، كتبت الكثير من كود جافا ، استخدمت Spring و Hibernate. على الرغم من أن ما أفعله الآن في هذا المجال يعجبني حقًا (أعمل في صناعة الطاقة الشمسية ، أفعل ما أستمتع به ، على سبيل المثال - أكتب طلبات للعمل مع البيانات من قطاع الطاقة) ، برمجة Java في عيني الآن فقدت روعتها السابقة.

سمحت لي سنتان من التطوير باستخدام Spring بتوضيح شيء واحد مهم بوضوح: محاولة إخفاء الآليات المعقدة لا تؤدي إلى البساطة ، إنها تؤدي فقط إلى ظهور هياكل أكثر تعقيدًا.

هنا ، باختصار ، الأفكار الرئيسية التي سأتناولها في هذه المادة:

• برامج Java ممتلئة برمز مرجعي يخفي نوايا المبرمج.
• لقد أعطاني العمل مع Spring and Spring Boot درسًا جيدًا ، وهو أن محاولة إخفاء الآليات المعقدة تؤدي إلى بنيات أكثر تعقيدًا.
• إن منصة Java EE عبارة عن مشروع تم إنشاؤه ، إذا جاز التعبير ، من خلال "الجهود المشتركة" ، والتي تغطي على الإطلاق جميع احتياجات تطوير تطبيقات المؤسسة. ونتيجة لذلك ، أثبتت منصة Java EE أنها باهظة.
• التطوير باستخدام Spring هو تجربة ممتعة إلى حد ما. يختفي هذا الوهم في اليوم الذي يأتي فيه استثناء من المستحيل تمامًا فهمه من أعماق نظام فرعي لم تسمع به من قبل ، ويستغرق الأمر ثلاثة أيام على الأقل لمعرفة ما هي المشكلة.
• ما هي الآليات المساعدة التي تخلق عبئًا زائدًا على النظام الذي تحتاجه لإطار عمل يمكنه "كتابة" كود للمبرمجين؟
• على الرغم من أن IDEs مثل Eclipse هي تطبيقات قوية ، إلا أنها مؤشر على مدى تعقيد نظام جافا البيئي.
• جاءت منصة Node.js نتيجة لجهود شخص واحد لتحسين رؤيته للهندسة المعمارية خفيفة الوزن التي يحركها الحدث.
• يبدو أن مجتمع جافا سكريبت متحمسا للتخلص من شفرة مرجعية ، مما يسمح للمبرمجين بالتعبير عن نواياهم بأوضح صورة ممكنة.
• Async / await هو حل لمشكلة جحيم رد الاتصال JS ، وهو مثال على رفض رمز القالب ويساهم في وضوح التعبير عن نوايا المبرمجين.
• برمجة Node.js متعة حقيقية.
• لا توجد كتابة قوية خاصة بـ Java في JavaScript. هذا هو نعمة اللسان ولعنه. هذا يجعل كتابة التعليمات البرمجية أسهل ، ولكن للتحقق من صحتها ، عليك تخصيص مزيد من الوقت للاختبار.
• نظام إدارة العبوات الذي قدمته npm / yarn سهل وممتع في الاستخدام. لا يمكن مقارنتها مع مخضرم.
• يقدم كل من Java و Node.js أداءً رائعًا. يتعارض هذا مع الأسطورة القائلة بأن JavaScript هي لغة بطيئة ، يؤدي استخدامها إلى ضعف أداء منصة Node.js.
• يعتمد Performance Node.js على جهود Google لتحسين V8 ، المحرك الذي يؤثر على سرعة متصفح Chrome.
• تساهم المنافسة الشرسة بين الشركات المصنعة لمحركات JS المستندة إلى المستعرض في تطوير JavaScript ، وهذا مفيد جدًا لـ Node.js.

حول مشكلات تطوير Java

بعض الأدوات أو الأشياء هي نتيجة سنوات عديدة من الجهود التي بذلها المهندسون لتحسينها. يجرب المبرمجون أفكارًا مختلفة ، ويزيلون السمات غير الضرورية ، ونتيجة لذلك يحصلون على كيانات يوجد فيها حصريًا ما يلزم لحل مشكلة معينة. في كثير من الأحيان ، تحتوي هذه التقنيات على نوع من البساطة الجذابة للغاية التي تخفي قدرات قوية. هذا لا ينطبق على Java.

Spring هو إطار شائع لتطوير تطبيقات الويب المستندة إلى Java.

الهدف الرئيسي من Spring ، وخاصة Spring Boot ، هو توفير القدرة على استخدام مكدس Java EE الذي تم تكوينه مسبقًا. لا يجب على المبرمج الذي يستخدم Spring ، من أجل إنشاء نظام جاهز ، رعاية servlets وأنظمة التخزين المستمرة وخوادم التطبيقات وما لا يزال غير معروف. كل هذه المخاوف تنتقل إلى Spring ، والمبرمج يكتب كودًا يطبق منطق التطبيق. على سبيل المثال ، آليات JPARepository مسؤولة عن إنشاء استعلامات قاعدة البيانات للطرق التي تبدو أسماؤها مثل findUserByFirstName . لا يحتاج المبرمج إلى كتابة الرمز لمثل هذه الأساليب. يكفي أن تمرر وصف الطريقة إلى النظام ، وسيقوم Spring بالباقي.

يبدو كل شيء جيدًا جدًا ، من الجيد العمل بهذا الأسلوب ، ولكن - حتى يحدث شيء غير متوقع.

أعني حالة حيث ، على سبيل المثال ، يتم طرح PersistentObjectException الإسبات مع detached entity passed to persist الرسالة الذي detached entity passed to persist . ماذا يمكن أن يعني؟ استغرق الأمر عدة أيام لمعرفة ذلك. كما اتضح ، إذا كنت تصف كل شيء بطريقة مبسطة جدًا ، فهذا يعني أن بيانات JSON التي يتم تلقيها عند نقطة نهاية REST لها حقول معرّف مع بعض القيم. السبات ، مرة أخرى ، إذا لم يخوض في التفاصيل ، يسعى إلى التحكم في قيم المعرّف ، ونتيجة لذلك ، يطرح الاستثناء الغامض أعلاه. هناك الآلاف من رسائل الخطأ هذه مربكة ويصعب قراءتها. مع الأخذ في الاعتبار أن هناك سلسلة كاملة من الأنظمة الفرعية تعتمد على بعضها البعض في Spring ، فإن مكدس Spring يبدو كعدو محلف لمبرمج يشاهده وينتظر أن يقوم المبرمج بأبسط خطأ ، وعندما يحدث ذلك ، يطرح استثناءات غير متوافقة معه التشغيل العادي للتطبيق.

علاوة على ذلك ، يمكنك هنا تذكر آثار المكدس الأطول. وهي تمثل العديد من الشاشات المليئة بجميع أنواع الطرق المجردة. من الواضح أن Spring يخلق التكوين الضروري لتنفيذ ما يتم التعبير عنه في التعليمات البرمجية. لا شك أن هذا المستوى من التجريد يتطلب قدرًا كبيرًا من المنطق الإضافي ، والذي يهدف إلى اكتشاف كل ما هو ضروري لعمل الكود ، على سبيل المثال ، من أجل تلبية الطلبات. وآثار المكدس الطويلة ليست سيئة بالضرورة. من المرجح أن تكون هذه الأشياء من الأعراض ، مما يؤدي إلى السؤال عن نوع الحمل على النظام الذي تم إنشاؤه بواسطة الآليات المساعدة.

كيف يتم findUserByFirstName طريقة findUserByFirstName ، بالنظر إلى أن المبرمج لم يكتب الرمز لهذه الطريقة؟ يحتاج الإطار إلى تحليل اسم الطريقة ، وفهم نية المبرمج ، وإنشاء شيء مثل شجرة بناء الجملة المجردة ، وإنشاء نوع من كود SQL ، وما إلى ذلك. كيف يقوم كل هذا بتحميل النظام؟ وكل هذا موجود فقط بحيث لا يحتاج المبرمج إلى كتابة التعليمات البرمجية؟

بعد أن تضطر إلى المرور بعشرات المرات من خلال شيء مثل البحث عن معنى الخطأ أعلاه ، قضاء أسابيع في محاولة كشف الأسرار التي ، بشكل عام ، لا يجب أن تكشف ، يمكنك الوصول إلى نفس الاستنتاج الذي توصلت إليه . معناه هو أن محاولة إخفاء الآليات المعقدة لا تؤدي إلى البساطة ، ولكنها تؤدي فقط إلى ظهور هياكل أكثر تعقيدًا. منصة Node.js أبسط بكثير.

أخفى شعار "مسائل التوافق" فكرة رائعة ، والتي بموجبها كان التوافق مع الإصدارات السابقة أهم ميزة في منصة جافا. لقد أخذنا هذا على محمل الجد ، ووضعنا الصور على القمصان مثل تلك التي يمكنك رؤيتها أدناه.


التوافق العكسي مهم جدا.

بالطبع ، يمكن أن يكون هذا المستوى من الاهتمام بالتوافق مع الإصدارات السابقة مصدرًا لقلق مستمر ، ومن المفيد من وقت لآخر الابتعاد عن الآليات القديمة التي لم تعد تستفيد.

جافا و Node.js

Spring و Java EE معقدان للغاية. يُنظر إلى منصة Node.js على خلفيتها على أنها نسمة من الهواء النقي. أول شيء تلاحظه عند التعرف على Node.js هو نهج Ryan Dahl لتطوير منصة النظام الأساسي. أخبرته تجربته أن المنصات التي تستخدم التدفقات مطلوبة لإنشاء أنظمة معقدة وثقيلة الوزن. كان يبحث عن شيء آخر ، وقضى بضع سنوات في تحسين مجموعة الآليات الأساسية المجسدة في Node.js. ونتيجة لذلك ، حصل على نظام خفيف الوزن يتميز بخيط تنفيذ واحد ، والاستخدام المبتكر لوظائف جافا سكريبت مجهولة الهوية كرد اتصال غير متزامن ، ومكتبة وقت التشغيل التي تنفذ في الأصل آليات غير متزامنة. كانت الرسالة الأولية عند إنشاء مثل هذا النظام هي توفير معالجة حدث عالية الأداء مع تسليم هذه الأحداث في وظيفة رد الاتصال.

بعد ذلك ، تعد إحدى ميزات Node.js الهامة استخدام JavaScript. هناك شعور بأن أولئك الذين يكتبون في JS لديهم ميل للتخلص من كود القالب ، مما يسمح لهم بوصف نوايا المبرمج بوضوح.

كمثال على الفرق بين جافا وجافا سكريبت ، خذ بعين الاعتبار تنفيذ وظائف المستمع (المراقبين). في Java ، للعمل مع المستمعين ، تحتاج إلى إنشاء مثيل محدد للواجهة المجردة. وهذا يستلزم استخدام تركيبات لغوية ضخمة تخفي جوهر ما يحدث. كيف يمكن تمييز نية المبرمج المخفية تحت أغلفة الكود المعبأ؟

تستخدم JavaScript وظائف بسيطة مجهولة بدلاً من ذلك. عند تنفيذ مستمع ، لا تحتاج للبحث عن واجهة مجردة مناسبة. يكفي ، دون الحاجة إلى استخدام مجموعة متنوعة من النصوص المساعدة ، لكتابة التعليمات البرمجية اللازمة.

لذا ، إليك فكرة مهمة يمكن استخلاصها من تحليل الآليات المذكورة أعلاه: معظم لغات البرمجة تخفي نوايا المبرمج ، مما يؤدي إلى حقيقة أن الشفرة صعبة الفهم.

يبدو القرار المتعلق باستخدام وظائف رد الاتصال التي تقدمها Node.js جذابًا للغاية. لكنها لا تخلو من المشاكل.

حل المشكلات وحل المشكلات

في جافا سكريبت ، كانت هناك مشكلتان مرتبطتان بالبرمجة غير المتزامنة. الأول هو ما يسميه Node.js الجحيم رد الاتصال. تكمن هذه المشكلة في حقيقة أنه أثناء التطوير ، من السهل الوقوع في فخ مبني من وظائف رد الاتصال المتداخلة بشدة ، حيث يعقد كل مستوى من مستويات التعشيق البرنامج ، بالإضافة إلى معالجة نتائج التعليمات البرمجية والأخطاء. كانت هناك مشكلة أخرى تتعلق بهذا الأمر ، كان جوهرها أن آليات لغة JavaScript لم تساعد المبرمج على التعبير بشكل صحيح عن أفكار تنفيذ التعليمات البرمجية غير المتزامنة.

ظهرت عدة مكتبات لتبسيط التطوير غير المتزامن على JS. لكن هذا مثال آخر على محاولة إخفاء الآليات المعقدة التي تؤدي فقط إلى ظهور هياكل أكثر تعقيدًا.

فكر في مثال:

 const async = require('async'); const fs = require('fs'); const cat = function(filez, fini) { async.eachSeries(filez, function(filenm, next) {   fs.readFile(filenm, 'utf8', function(err, data) {     if (err) return next(err);     process.stdout.write(data, 'utf8', function(err) {       if (err) next(err);       else next();     });   }); }, function(err) {   if (err) fini(err);   else fini(); }); }; cat(process.argv.slice(2), function(err) { if (err) console.error(err.stack); }); 

هذا تقليد لا يوصف cat Unix. async مكتبة async في تبسيط تسلسلات المكالمات غير المتزامنة. ومع ذلك ، فإن استخدامه يتطلب كمية كبيرة من الشفرة المعيارية التي تخفي نية المبرمج.

في الجوهر ، يحتوي هذا الرمز على حلقة. لم يتم كتابتها كدورة منتظمة ، ولا تستخدم الإنشاءات الطبيعية لوصف الدورات. علاوة على ذلك ، فإن نتائج تنفيذ التعليمات البرمجية والأخطاء الناتجة عنها لا تصل إلى حيث كانت صحيحة. يتم قفلها في عمليات الاستدعاء ، وهو أمر غير مريح. ولكن ، قبل تنفيذ معايير ES2015 / 2016 في Node.js ، لا يمكن فعل أي شيء أفضل.

إذا أعدنا كتابة هذا الرمز مع مراعاة الميزات الجديدة ، التي تتوفر بشكل خاص في Node.js 10.x ، نحصل على ما يلي:

 const fs = require('fs').promises; async function cat(filenmz) { for (var filenm of filenmz) {   let data = await fs.readFile(filenm, 'utf8');   await new Promise((resolve, reject) => {     process.stdout.write(data, 'utf8', (err) => {       if (err) reject(err);       else resolve();     });   }); } } cat(process.argv.slice(2)).catch(err => {   console.error(err.stack); }); 

في هذا المثال ، استخدمنا بناء async/await . يتم عرض نفس الآليات غير المتزامنة هنا كما في المثال السابق ، ولكن يتم استخدام الهياكل المعتادة المستخدمة في تنظيم الحلقات هنا. يبدو العمل مع النتائج والأخطاء أمرًا طبيعيًا تمامًا. مثل هذا الرمز أسهل للقراءة والكتابة. هذا النهج يجعل من السهل فهم نية المبرمج.

العيب الوحيد هو أن process.stdout.write لا تحتوي على واجهة Promise ، ونتيجة لذلك ، لا يمكن استخدام هذه الآلية في وظائف غير متزامنة دون تغليفها في وعد.

الآن يمكننا أن نستنتج أن مشكلة الجحيم رد الاتصال في جافا سكريبت تم حلها بطريقة مختلفة عن محاولة إخفاء الآليات المعقدة. بدلاً من ذلك ، تم إجراء تغييرات على اللغة ، والتي حلت المشكلة نفسها ، وأنقذتنا من الإزعاج الناجم عن الحاجة إلى استخدام كميات كبيرة من رمز القالب في حل مؤقت. بالإضافة إلى ذلك ، باستخدام آلية التزامن / الانتظار ، أصبح الرمز ببساطة أكثر جمالا.

بدأنا هذا القسم بمناقشة عيب Node.js ، ولكن الحل الرائع للجحيم لاستدعاء ما جعل الحديث عن العيوب يتحول إلى حديث عن نقاط قوة Node.js وجافا سكريبت.

كتابة قوية ، واجهات ، ووضوح كود وهمي

في تلك الأيام عندما كنت أحمي Java من جميع أنواع الهجمات ، أكدت أن الكتابة الصارمة تسمح لك بكتابة تطبيقات ضخمة. في تلك الأيام ، كان تطوير أنظمة متجانسة قيد الاستخدام (لم تكن هناك خدمات دقيقة ، ولم يكن هناك Docker وما شابه). بما أن Java هي لغة مكتوبة بقوة ، فإن مترجم Java يساعد المبرمج على تجنب الكثير من المشاكل عن طريق منعه من تجميع التعليمات البرمجية الخاطئة.

جافا سكريبت ، بخلاف جافا ، لا يتم كتابتها بقوة. من هذا يمكننا أن نخلص إلى نتيجة واضحة مفادها أن المبرمج لا يعرف بالضبط الأشياء التي عليه العمل معها. كيف يمكن للمبرمج معرفة ما يجب فعله ، على سبيل المثال ، مع شيء معين يتم تلقيه من مكان ما؟

الجانب الآخر من كتابة Java القوية هو أنك تحتاج إلى تنفيذ إجراءات boilerplate باستمرار. يقوم المبرمج بالصب أو التحقق من أن كل شيء كما هو متوقع تمامًا. يقضي المطور وقتًا في كتابة التعليمات البرمجية ، ويقوم بذلك بدقة استثنائية ، ويستخدم كميات كبيرة من تصميمات القوالب ، ويأمل أن يساعد كل ذلك في توفير الوقت من خلال الكشف المبكر وتصحيح الأخطاء.

مشكلة البرمجة بلغة مكتوبة بقوة كبيرة لدرجة أن المبرمج ، مع عدم وجود خيارات تقريبًا ، يجب أن يستخدم IDE كبيرًا ومعقدًا. محرر رمز بسيط لا يكفي هنا. الطريقة الوحيدة للحفاظ على مبرمج جافا في حالة مناسبة (باستثناء البيتزا) هي إظهاره باستمرار لقوائم منسدلة تحتوي على حقول الكائنات المتاحة أو أوصاف معلمات الطريقة. تساعد هذه الآليات وغيرها من الآليات الداعمة لـ IDEs مثل Eclipse أو NetBeans أو IntelliJ في إنشاء فئات ، وتسهيل إعادة البناء ، وغيرها من المهام.

و ... لن أتحدث عن مخضرم. هذه مجرد أداة كابوس.

في JavaScript ، لا يتم تحديد أنواع المتغيرات عندما يتم الإعلان عنها ، وعادة ما لا يتم استخدام نوع الكتابة ، وهكذا. ونتيجة لذلك ، من السهل قراءة التعليمات البرمجية ، ولكن هذه الحالة تعني أيضًا خطر أخطاء البرمجة التي يصعب اكتشافها.

ما إذا كان ما سبق يتعلق بإيجابيات Java أو السلبيات يعتمد على وجهة النظر.

قبل عشر سنوات ، اعتقدت أن كل هذه الصعوبات تبرر نفسها من خلال منح المبرمج ثقة أكبر في الشفرة التي يكتبها. اليوم ، أعتقد أن الكتابة القوية تزيد من عبء عمل المبرمج ومن الأسهل بكثير تطوير المشاريع كما يفعلون في JavaScript.

محاربة الأخطاء باستخدام وحدات صغيرة يسهل اختبارها

Node.js يدفع المبرمج لتقسيم مشاريعه إلى أجزاء صغيرة ، إلى ما يسمى الوحدات. قد تجد هذه الحقيقة غير مهمة ، لكنها تحل جزئياً المشكلة التي ذكرناها للتو.

فيما يلي الخصائص الرئيسية للوحدة:

• الاستقلال تجمع الوحدة النمطية بين التعليمات البرمجية المترابطة في كيان واحد.
• مسح الحدود. الكود الموجود داخل الوحدة النمطية محمي من التداخل بواسطة أي آليات خارجية.
• تصدير صريح. بشكل افتراضي ، لا يتم تصدير بيانات التعليمات البرمجية والوحدة النمطية. يقرر المطور بشكل مستقل الوظائف والبيانات التي يجب إتاحتها للجمهور.
• استيراد صريح. عند تطوير الوحدة ، يقرر المبرمج بنفسه الوحدات التي سيعتمد عليها.
• الاستقلال المحتمل. يمكن جعل الوحدات متاحة للجمهور ، بالمعنى الواسع للكلمة ، عن طريق نشرها في npm ، أو ، إذا كانت مخصصة للاحتياجات الداخلية للشركة ، عن طريق النشر في مستودعات مغلقة. هذا يجعل من السهل استخدام نفس الوحدات النمطية في التطبيقات المختلفة.
• كود سهل الفهم. حقيقة أن الوحدات صغيرة ، تبسط قراءة وفهم التعليمات البرمجية الخاصة بها ، تفتح إمكانية مناقشة مجانية عنها.
• تسهيل الاختبار. يمكن بسهولة اختبار وحدة صغيرة ، إذا تم تنفيذها بشكل صحيح.

كل هذا يجعل وحدات Node.js وحدات ذات حدود محددة بوضوح ، كودها سهل الكتابة والقراءة والاختبار.

ومع ذلك ، فإن القلق بشأن العمل مع جافا سكريبت هو حقيقة أن نقص الكتابة القوية يمكن أن يؤدي بسهولة إلى كود يفعل شيئًا خطأ. في وحدة صغيرة تهدف إلى حل بعض المشاكل الضيقة بحدود واضحة ، "شيء ما خطأ" يمكن أن يؤثر فقط على رمز الوحدة النمطية نفسها. هذا يؤدي إلى حقيقة أن المشاكل التي قد تسبب نقص الكتابة الصارمة ، يتم تأمينها داخل الوحدة.

حل آخر لمشكلة الكتابة الديناميكية في JavaScript هو اختبار الكود بدقة.

يجب على المطور أن يأخذ الاختبار على محمل الجد ، والذي يأخذ جزءًا من الفوائد التي تأتي من بساطة عملية تطوير JS. يجب أن تجد أنظمة الاختبار التي تم إنشاؤها بواسطة مبرمج JS تلك الأخطاء ، إذا تم تطويرها بواسطتها في شيء مثل Java ، فإن المترجم يمكنه العثور عليها تلقائيًا. هل تكتب اختبارات لتطبيقات JS الخاصة بك؟

بالنسبة لأولئك الذين يحتاجون إلى نظام كتابة ثابت في JavaScript ، قد يكون من المفيد إلقاء نظرة على TypeScript. لا أستخدم هذه اللغة ، لكني سمعت الكثير من الأشياء الجيدة عنها. وهو متوافق مع JavaScript ويمد اللغة بنظام تحكم بالنوع وميزات مفيدة أخرى.

في النهاية ، يمكننا القول أن استخدام نهج نمطي للتطوير هو قوة Node.js وجافا سكريبت.

إدارة الحزم

أشعر بالسوء من مجرد التفكير في مخضرم ، لذلك لا يمكنني حتى الكتابة عنه بشكل طبيعي. وكما أفهمها ، فإن مافين ، دون مساومة ، إما محبوب أو مكروه.

المشكلة هنا هي أنه في بيئة جافا لا يوجد نظام شامل لإدارة الحزم. توجد حزم مخضرم ، يمكنك العمل معها بشكل طبيعي ، وهي مدعومة من Gradle. لكن الطريقة التي يتم بها تنظيم العمل معهم لا تشبه إلى حد كبير وسائل الراحة التي يمنحها نظام إدارة الحزم لـ Node.js للمطور.

في عالم Node.js ، هناك مديران رائعان للحزم يعملان بشكل وثيق مع بعضهما البعض. في البداية ، كانت الأداة الوحيدة هي مستودع npm وأداة سطر الأوامر التي تحمل الاسم نفسه.

بفضل npm ، لدينا مخطط ممتاز لوصف تبعيات الحزمة. يمكن أن تكون التبعيات صارمة (على سبيل المثال ، يشار إلى أن الإصدار 1.2.3 فقط من حزمة معينة مطلوب) ، أو يتم منحه بدرجات متعددة من الحرية - حتى * ، مما يعني استخدام أحدث إصدار من حزمة معينة.

نشر مجتمع Node.js مئات الآلاف من الحزم في مستودع npm. في الوقت نفسه ، يعد استخدام الحزم غير الموجودة في npm بنفس سهولة استخدام الحزم من npm.

تبين أن نظام npm ناجح جدًا بحيث لا يستخدمه فقط مطورو منتجات الخادم على Node.js ، ولكن أيضًا المبرمجين الأماميين. في السابق ، تم استخدام أدوات مثل Bower لإدارة الحزم. تم إيقاف Bower ، والآن يمكنك أن تجد أن جميع مكتبات JS لتطوير الواجهة الأمامية موجودة كحزم npm. تتم كتابة العديد من أدوات الدعم لتطوير العميل ، مثل Vue.js CLI و Webpack كتطبيقات Node.js.

نظام آخر لإدارة الحزم لـ Node.js ، الغزل ، يقوم بتنزيل الحزم من مستودع npm ويستخدم نفس ملفات التكوين. الميزة الرئيسية للغزل على مدير حزمة npm هي سرعته العالية.

مستودع npm ، سواء كان استخدام مدير حزم npm أو مدير حزم الغزل ، هو أساس قوي لما يجعل تطوير Node.js سهلًا وممتعًا.


ذات مرة ، بعد أن ساعدت في تطوير java.awt.Robot ، تم إلهامي لإنشاء هذا الشيء. بينما تتكون صورة دوق الرسمية من منحنيات ، تم بناء RoboDuke من خطوط مستقيمة. فقط مفاصل الكوع لهذا الروبوت مستديرة

الأداء

تم انتقاد كل من Java و JavaScript بسبب أدائها الضعيف. في كلتا الحالتين ، يقوم المحول البرمجي بتحويل شفرة المصدر للبرنامج إلى كود ثانوي يتم تنفيذه على جهاز ظاهري يتم تطبيقه لمنصة معينة. يقوم الجهاز الظاهري ، بدوره ، بتحويل الرمز الثانوي إلى رمز الجهاز باستخدام العديد من التحسينات.

كل من جافا وجافا سكريبت لها أسباب للسعي لتحقيق أداء عالي. إذا تحدثنا عن Java و Node.js ، فإنهما مرتبطان بالرغبة في وجود رمز خادم سريع. في حالة جافا سكريبت المستندة إلى المستعرض ، فإن الحافز للأداء العالي هو تحسين جودة تطبيقات العميل. سنتحدث عن هذا في القسم الخاص بتطبيقات الإنترنت الغنية.

JDK Sun/Oracle HotSpot — , -. , , , , , . HotSpot — , .

JavaScript, , JS-, , , - . , JavaScript . , , . , , Google Docs, . JS .

Node.js , V8 Google Chrome.

, Google, V8, . , V8 Crankshaft Turbofan.

— , , R Python. , , . JavaScript, , , JavaScript.

JavaScript , TensorFlow.js. API API TensorFlow Python, . , , , .

IBM, Node.js, , , Docker/Kubernetes. , Node.js Spring Boot. -, . , Node.js , , , V8.

, Node.js . . - , Node.js , . , «Node.js Web Development», , :

• — .
• , Node.js .
• .

JavaScript , Node.js. — Node.js-. Node.js- node-gyp , . , Rust- Node.js.

WebAssembly , , JavaScript, . WebAssembly , JavaScript-. WebAssembly Node.js.

-

- (Rich Internet Applications, RIA) . , , ( ) JS-, .

, 20 . Sun Netscape Java- Netscape Navigator. JavaScript , , Java-. , Java-, — Java-. , . .

JavaScript , . RIA, , - Java -.

, RIA . Node.js , , , . JavaScript.

إليك بعض الأمثلة:

• Google Docs ( ), , .
• , React, Angular Vue.js, , HTML, CSS JavaScript.
• Electron — Node.js Chromium. - . , Visual Studio Code, Atom, GitKraken, Postman.
• Electron/NW.js , -, , React, Angular, Vue, .

Java, , - -, JavaScript. , , - Sun Microsystems. Sun , . . Java- , Java Java Web Start. Java- Webstart-.

Java, , , IDE NetBeans Eclipse . Java , , Java.

JavaFX.

JavaFX, 10 , Sun iPhone. , Java, , , . Flash iOS. . JavaFX , , . - React, Vue.js .

JavaScript Node Java.

Java, - JavaONE. Java . , , , .


Java

الملخص

. «P-» (Perl, PHP, Python) Java, Node.js, Ruby, Haskell, Go, Rust, . .

, , , Java, Node.js, , , Node.js-. Java , Node.js . , , , Java, .

. , , Node.js - , - . . , XBRL-. XBRL Python, , , Python. , , , .

أعزائي القراء! , , JavaScript - , - Node.js, .