نوشته های ابوالفضل بغلانی

تجربه های یادگیری ui/ux از زبان کسی که طراح ui/ux نیست!

ابوالفضل بغلانی — Wed, 25 Nov 2020 19:25:03 +0330

سلام خدمت همه دوستان عزیزاگر میخواید سریع برسید به اصل مطلب لطفا از بخش اصل مطلب شروع به خواندن کنید!https://careerfoundry.com/تصویر از <پیش درآمد>هر وقت میام ویرگول از خودم بدم میاد که هر مطلبی نوشته بودم برای خیلی ها جذاب بوده و خواستار ادامه اش بودن اما من نتونستم اون طور که باید منظم و خوب ادامه اش بدم!باورم نمیشه بیشتر از یک سال از مجموعه زیر پوست جاوااسکریپت میگذزه و خروجی اش فقط 3 تا مطلب بوده ?واقعا از صمیم قلبم امیدوارم بتونم بعد از این بیشتر و بهتر بنویسم!بگذریم! حرف امروزم چیز دیگه ایه! میخوام به عنوان کسی که طراح رابط / تجربه کاربری نیست چند تا نکته درباره یادگیری این حرفه بگم!اما انگیزه ام چیه که پا توی کفش طراحان عزیز ui/ux کردم؟من فقط میخواستم یه کامنت بزارم!امروز این مطلب در ویرگول توجه ام رو جلب کرد: https://vrgl.ir/4mKNCمیخواستم تجربیاتم از تلاش هام برای طراحی ui / ux یه کامنت برای ایشون بزارم، اما یادم افتاد دیشب هم یه کامنت خیلی مفصل برای یکی دیگر از دوستان زیر پست قبلی خودم گذاشته بودم و بعد یهو گفتم:یافتم!? چرا این کامنت های بلند نتونن تبدیل به پست های کوتاه بشن؟!به این شکل هم به فرد مورد نظر حرفم رو زدم، هم شاید افراد دیگری باشن که مطلب به دردشون بخوره، هم شرمنده دوستانی که منو دنبال می کنن نمیشم و میتونم هر از چند گاهی یه مطلب جدید منتشر کنم!تازه میتونیم اسم این سری از مطالب رو بزاریم: پومِنت (پست + کامنت ?)<اصل مطلب>همونطور که گفتم من یه توسعه دهنده ام! اما توسعه دهنده ای که مثل خیلی های دیگه از "طراحی وب" به توسعه وب رسید. حقیقتش اون زمان اصلا کلمه توسعه وب، فرانت اند و بک اند و ... به گوش ما هم نخورده بود! اما بر خلاف خیلی های دیگه من هنوزم به اون بُعد طراحیِ کار در وب علاقه دارم. از طرفی من یه فریلنسرم و گاهی مجبور میشم واقعا خودم دست به کار طراحی ui / ux بشم. بنابراین شروع کردم و یه چیزایی یاد گرفتم هر چند واقعا حرفه ای نیستم!لیکیشن آموزش زبان آموزشگاه سلام؛ آخرین تلاش من در طراحی رابط کاربری که البته هنوز کامل نشده. میدونم خیلی نواقص داره! گفتم که من طراح نیستم ! و اما تجربه هام:1. در یادگیری هر مهارتی مسیر کلی ارزشمند تر از تک تک عناصر آموزشی استنمیخواید وقت تون رو تلف کنید که؟ درسته؟ پس بدونید یادگیری هر مهارتی بیشتر از خود آموزش به مسیر آموزش بر می گرده. فرض کنید میخواید زبان یاد بگیرید. عضو شدن تو پیج های آموزش زبان اینستا به شما چیزایی یاد میده ولی بدون هیچ ساختار و ترتیبی. پس بعد از چند سال ممکنه بازم نتونید حرفه ای باشید. اما با یه مسیر آموزشی خوب خیلی ها رو دیدیم که یک ساله تقریبا مسلط شدن. مهارت های دیگه هم همینه! یه مسیر آموزشی صحیح و روشن خیلی موثر تر از کلی دوره و مطلب آموزشیه بدون هیچ ترتیب خاصیدر واقع ویدیو های یوتیوب، اینستا، فلان مقاله، فلان درسنامه همه شون یک سری Material هستن. یعنی یه قطعه از یک پازل. اما ترتیب استفاده و یادگیری صحیح این موارد، داشتن هدف های کوتاه مدت، میان مدت و بلند مدت میتونه تضمین کنه شما حرفه ای بشید بدون اینکه زمان زیادی تلف کنید.من مخالف خود آموزی نیستم، اما معتقدم آموزش هر مهارتی مثل بالارفتن از اورست نیازمند یه شرپا (کسی که مسیر قله رو به خوبی بلده) هست. حالا اگه دوره ای باشه که مسیر شما رو از نقطه a به b به درستی مشخص کنه، حتی اگر تک تک عناصر آموزشی اش هم عالی نباشن بازم ارزشمنده. چون حالا که شما راه و هدف رو شناختید میتونید به صورت گزینشی از طریق یوتیوب، مدیوم، اینستا یا هر جای دیگه ای محتوای آموزشی رو منطبق با مسیر اصلی تون پیگیری کنید. در واقع این همه مطالب آموزشی خوب توی اینترنت وقتی واقعا به درد میخوره که شما مسیر یادگیری صحیح داشته باشید.2. به هیچ عنوان صرفا دنبال منابع فارسی نباشید!شاید این حرف تکراری باشه! به عنوان یه توسعه دهنده میدونم مطالب ارزشمند خیلی زیادی در مبحث توسعه وب به زبان فارسی نداریم اما در مبحث توسعه ui/ux وضع خیلی خراب تره!نمیخوام به عزیزان فعال تو این حوزه توهین کنم! اصلا! اما این نظر شخصی منه که واقعا طراحی ui/ux باید از منابع انگلیسی یاد گرفته بشهالبته ما محتوا های آموزشی خیلی خوبی به فارسی در این حرفه داریم اما با توجه به بند 1 منظورم اینه که من دوره کامل و جامع یا لااقل مسیر کامل و جامعی برای تبدیل شدن به طراح ui/ux به زبان فارسی نمی شناسم! البته شاید شما بتونید پیدا کنید. قطعا چیزایی هستن که من ندیدم!تنها دوره نسبتا جامعی که فکر میکنم (فقط فکر میکنم) به زبان فارسی داریم دوره ui/ux سایت 7لرن هست که احتمالا میخوام امتحانش کنم. https://7learn.ac/course-ui-expert بنابراین توصیه می کنم سرچ کنید: I wanna be a ui ux designer و مقالات مرتبط رو بخونید. و سعی کنید یه سری دوره جامع پیدا کنید که با دیدن توضیحات بتونید بفهمید از کجا شروع میشه و تا کجا قراره شما رو برسونه.3. تا میتونید طراحی کنید و طرح هاتون رو منتشر کنید!خجالت نکشید! در هر مرحله از یادگیری تون تا میتونید طراحی کنید و تا جایی که می تونید به بقیه نشونش بدید. سعی کنید یه نفر رو پیدا کنید که بهتون دعوتنامه dribble رو بده یا خودتون اکانت pro رو بخرید. خلاصه این طراحی کردنباعث میشه چیزایی که یاد گرفتید تثبیت بشهاکثرا متوجه میشید خیلی از موارد رو یاد نگرفتید و دوباره میرید سراغ آموزش هانمونه کار براتون ساخته میشهدر مسیر پیشرفت کلی دوست و آشنا پیدا می کنیدکلی نظر های سازنده ( و غیر سازنده ?) دریافت می کنیدو...خلاصه بزارید مهارت تون به جای شما صحبت کنه!4. از جامعه طراحان ui/ux غافل نشیداصولا این حرفه جامعه خوب و سرزنده و غالبا با معرفتی داره!!کارای همدیگه رو به اشتراک میزارن، نظر میدن، نقد می کنن و خلاصه در ارتباط بودن با اعضای این جامعه هم جالبه هم پر از فایده.این بند میتونه در ادامه بند قبلی باشه. کمی که حرفه ای تر شدید نمونه کارهاتون رو خیلی با سلیقه تر، ویترینی تر و خلاصه بهتر توی سایت خارجی مثل dribble بزارید و از دیگران نظر بگیرید و ارتباطات بسازید!کم کم میتونید منتظر مشتری های مشتاق هم باشید. چرا که کار شما خیلی راحت تر از ما برنامه نویس هاست. کیفیت کد رو هر کسی نمی تونه آنالیز کنه اما زیبایی و هنر نهفته در کار شما ظاهری و عیان هست. پس هر کسی با هر میزانی از درک طراحی میتونه کارهای شما رو ببینه و مشتاق بشه باهاتون کار کنه5. نمونه ببینید!زمانی که عکاسی می کردم استادم همیشه می گفتن تا میتونی عکس ببین و نقد عکس بخون!این توی طراحی هم واقعا مفیده. دیدن کارهای حرفه ای های این زمینه میتونه براتون الهام بخش و مفید باشه. خوندن نقد ها دیگران بر اون کار هایی که فکر می کردید خیلی عالی هستن حتی مفید تر هم هست!میتونید از dribble یا awwwards و... برای این کار استفاده کنیدفعلا همین نکات به نظرم اومد! شاید بعدا کامل تر شد!ممنون که تا اینجا اومدید :)

این this ـِ پرحاشیه (چرا توابع باید bind شوند؟) | مجموعه زیر پوست جاوااسکریپت

ابوالفضل بغلانی — Tue, 21 Apr 2020 00:14:39 +0430

بسم الله الرحمن الرحیم<مقدمه>موقع تعیین یه تابع به عنوان callback برای یک event با this به مشکل خوردید؟ یا نمیدونید چرا توی ری‌اکت باید this رو bind کرد؟ اینکه react میگه بهتره از arrow function ها برای event ها استفاده نکنید گیج تون کرده؟ یا کلا میخواید بدونید توابع در جاوااسکریپت چطور اجرا میشن؟ این نوشته ها برای شماست :)اکوسیستم ری‌اکت از مسیر درستشچند وقت پیش که در رابطه با معماری flux مطالعه می کردم برخوردم به یه repository گیت هاب که مربوط بود به pete hunt (از مدیران فنی فیس بوک که در تیم توسعه ری اکت هم نقش کلیدی داشته و حالا بعد از فروش استارتاپ میلیون دلاری خودش به توییتر، همونجا مشغول کاره) و یه نکته فوق العاده دیدم که توجه منو به خودش جلب کرد.اکوسیستم ری‌اکت گیج کننده و طاقت فرسا به نظر میرسه چون هیچ وقت از راه درستش آموزش داده نمیشهاین نکته ساده به نظر من فوق العاده است. یکی از علل خستگی جاوااسکریپت (javascript fatigue به معنی سردرگم و خسته شدن توسعه دهنده) فراوانی بسیار زیاد ابزارهای این زبانه. سعی کنید یه اپ ری‌اکتی رو اجرا کنید. اون وقت میبینید که با ده ها ابزار از جمله npm، ماژول باندلر ها، babel، لینتر ها و کلی چیز دیگه در حال سر و کله زدن هستید و نکته مهم اینجاست که معمولا آموزش ها یه سیر منطقی رو از ابتدای مسیر جاوااسکریپت تا پایانش دنبال نمی کنن. توسعه دهنده جوان یهو وارد ریداکس میشه در حالی که حتی نمیدونه توابع در این زبان واقعا چه جوری عمل می کنن و هزاران نکته ریز دیگه.خلاصه منم برگشتم از اول مستندات ری اکت رو باز کردم و سعی کردم مرحله به مرحله هر چی نقص دارم برطرف کنم. با این دید وقتی به پله های بالاتر میرسیدم حس می کردم تا حالا هیچی بلد نبودم!! اولین مطلب جدیدی که در این سیر بررسی کردم بحث نحوه عملکرد توابع، جایگاه this و arrow function ها بود.منبع محتوای این مطلب کجاست؟برای این متن از مقاله Understanding JavaScript Function Invocation and "this" که در مستندات خود ری‌اکت بهش رفرنس داده شده، مقاله This is why we need to bind event handlers in Class Components in React از freeCodeCamp و دو سه مقاله انگلیسی معتبر دیگه استفاده شده.با این مقدمه بحث اصلی امروز رو شروع می کنیم.<متن اصلی>صدا زدن توابع در پشت صحنه جاوااسکریپتچیزی که ما بعنوان صدا زدن (function calling or invoking) می شناسیم در واقع یه sugaring برای دستور اصلی هست. sugaring یعنی شیرین کردن! یعنی اینکه یه دستوری در سینتکس زبان به شکلی راحت تر از اون چیزی که واقعا هست بیان میشه. در واقع مثل یه میانبر در نظر بگیریدش. (sugaring تعریف وسیع تری داره برای اینجا همین کافیه) بعدا اون دستور راحت در پشت صحنه تبدیل به دستور اصلی میشه.همونطور که می بینید روش پایه (primitive) برای صدا زدن توابع اسفاده از متد call هست. بله! روشی که ما تابع رو صدا میزنیم به این روش تبدیل و سپس اجرا میشه و اتفاق مهم همینجا میفته!تابع call به عنوان ورودی اول this Value رو قبول می کنه و بعد بقیه آرگومان ها رو. یعنی هر چیزی که به عنوان آرگومان اول به این تابع بدیم در بدنه معادل this در نظر گرفته می شه!خب همونطور که می‌بینید مفهوم this در جاوااسکریپت یه مقدار با تصور ما متفاوته! ما الان this رو معادل یه رشته قرار دادیم و هیچ مشکلی هم پیش نیومد! پس اینکه this باید به نزدیک ترین context اشاره کنه یا ... رو بریزید دور.از طرفی می دونیم اون مدلی که ما توابع رو صدا میزنیم(اسم تابع با پرانتز) اصولا به این مدل (استفاده از call) تبدیل میشه. پس کی آرگومان اول تابع call یا همون مقدار this رو تعیین می کنه؟ خود موتور جاوااسکریپت یه مقداری رو به عنوان this پاس میده به تابع. پس چیزی که javascript به عنوان this پاس مید به تابع کلید ماجراست. حالا کارو یکم پیچیده تر کنیم!اینجا هم داستان همونه! موتور js تابع رو به وسیله call صدا میزنه و به عنوان this شیئی که صاحب تابع هست رو بهش پاس. این منطقیه! حالا بیاید تابع رو بصورت داینامیک به شئ اضافه کنیم. یعنی بیرون از شئ تابع رو تعریف می کنیم بعد اضافه اش میکنیم به شئ.تابع آخر که نوشته hello رو همون who در نظر بگیرید و اشتباه منو ببخشید.میبینیم که صدا زدن تابع who به عنوان عضوی از شئ و به عنوان یک تابع دو مقدار متفاوت رو برای this بر می‌گردونه. اما چرا؟جاوااسکریپت چه چیزی رو به عنوان this تعیین میکنه؟اینکه this چه مقداری داشته باشه صرفا بر اساس جایی که تابع در اون صدا زده شده تعیین میشه نه جایی که تعریف شده.جالبه نه؟ در واقع وقتی ما از دستور کوتاه تر برای صدا زدن تابع استفاده می کنیم موتور js بر اساس شرایط در همون زمانِ صدا زدن تصمیم می گیره این this چی باشه!موتور js تقریبا همیشه undefined رو بعنوان this پاس میده. اما این مقدار فورا به شئ global (مثلا window) تغییر پیدا می کنه. اما اگر در حال استفاده از strict mode باشید این اتفاق نمی افته و this در تابع شما معادل undefined فرض میشه. در اشیاء هم که که مشخصه. وقتی تابعی به عنوان عضوی از یک شئ صدا زده میشه همون شئ بعنوان this درنظر گرفته میشه.پس this معمولا اینجوری خواهد بود:در همه توابع در scope عمومی: window (یا شئ گلوبال)در توابع عضو یک شئ (یا کلاس): همون شئدر صورت استفاده از strict: کلا undefined . درسته مسیرش پیچیده بود اما نتیجه نهایی معقوله! نه؟خب پس چرا توی کامپوننت ها باید this رو bind کنیم؟دو خط بالاتر گفتیم اگه تابع از یک کلاس باشه this در بدنه تابع میشه معادل همون کلاس پس چرا در ری‌اکت نیاز به bind کردن توابع هست؟ما در ری‌اکت معمولا زمانی this رو bind می کنیم که داریم یه تابعی رو بعنوان کال‌بک پاس میدیم. نکته کلیدی در پاس دادن یک تابع به تابع دیگه اینه: چیزی که واقعا تحویل تابع دیگه میشه reference تابع هست. میدونم سخت گفتم پس بیاید اینجوری فرض کنیم: تصویر بالا رو خوب ببینید. یه مثال هست صرفا برای درک راحت تر مطلب. فرض کنید وقتی ما یه تابع رو به عنوان callback پاس میدیم یا اصلا به یه متغیر انتساب میدیم صرفا تعریف بدنه تابع میره اونجا میشینه و موقع اجرا هیچ درکی از اینکه این تابع از چه مبدا و کجا اومده وجود نداره. برای همین اگر در بدنه تابع از this استفاده کنیم در واقع یا undefined بر میگرده یا شئ window. نه اون شیئی که ما میخوایم.این کد رو ببینید. وقتی از نمونه ساخته شده از کلاس مستقیما تابعی که درون خودش this داشت رو فراخوانی کردیم، this به کلاس سازنده اشاره داره. اما وقتی اون رو به تابع دیگه ای پاس دادیم انگار که تابع محیط اصلی خودش رو فراموش کرده باشه، this داره به شی window اشاره می کنه. اگر این تابع (thisVal) رو به یه متغیر دیگه هم پاس بدیم همین اتفاق می‌افته و اصطلاحا تابع با پاس داده شدن محیط خودش رو از دست میده / فراموش میکنه. (loosing 'this' context)اینجاست که چند تا راه حل مطرح میشه. رسمی ترین اونها استفاده از bind هست.استفاده از bind برای اینکه بتونیم تعیین کنیم در بدنه یک تابع this همیشه و در هرجایی بدون وابستگی به محل فراخوانی به یک شئ مشخص (مثلا شئ والدش) اشاره داشته باشه باید اون تابع رو bind کنیم. احتمالا اینکه چطور این کارو انجام بدیم رو قبلا دیدید پس زیاد راجع بهش صحبت نمی کنیم. بحث ما این بود که چرا این کارو انجام میدیم. بهرحال زحمت جستجو رو براتون کشیدم!! :) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_objects/Function/bind پس نقش Arrow Function ها چیه؟ذات arrow function ها در مواردی متفاوت با توابع دیگه در جاوااسکریپته. چیزی که اینجا برای ما مهمه اینه که این توابع از lexical this استفاده می کنن. یعنی اینکه کلمه this در این توابع همیشه به نزدیک ترین context اشاره داره. برای همین شما دیگه مشکل bind کردن رو ندارید و سادگی و خوانایی کدتون هم خیلی بهتر میشه.به این تصویر از مستندات رسمی react نگاه کنید. علت اینکه با استفاده از arrow function مطمئن هستیم که this به جای درستی اشاره می کنه همین lexical this هست.تابع arrow ما در تابع رندر که متعلق به کلاس loggingButton هست نوشته شده. پس نزدیک ترین context بهش میشه همین کلاس loggingButton . طبق گفته های قبلی this در بدنه این نوع توابع به نزدیک ترین context اشاره میکنه پس this داره به کلاس جاری که دقیقا مد نظر ماست اشاره می کنه. این رفتار خیلی منطقی تر از رفتار طبیعی توابع هست.پس تموم شد دیگه؟ همین بهترین راهه؟نه! توابع arrow خیلی خوب و کار راه انداز هستن اما مشکلات خاص خودشون رو هم دارن. در این مورد استفاده از این توابع میتونه دو تا مشکل در خصوص performance کد بوجود بیاره که یکی اش رندر شدن ناخواسته و بیش از کامپوننت هاست.اما مطلب کِی از arrow function ها در کامپوننت استفاده کنیم؟ کِی نکنیم؟ باشه طلب شما از من. این مطلب جای بیشتر از این صحبت کردن نیست.به عنوان نکته آخر باید بگم که، راه دیگه ای هم برای خلاص شدن از bind کردن هست. اونم چیزی نیست جز استفاده از class property ها که البته این مورد هنوز آزمایشیه و عضو رسمی زبان ecmascript نیست. هر چند babel میتونه این ویژگی رو برای شما تبدیل به استاندارد های فعلی بکنه. یعنی شما با روش جدید کد میزنید و babel اون رو به binding استاندارد فعلی تبدیل می کنه.خلاصه که فعلا بهترین روش استاندارد همون bind کردن هست اگر نه از نحوه درست استفاده از arrow ها اطلاع دارید و نه علاقه ای به کانفیگ کردن babel.من یه تقلب کردمبرای بهتر متوجه شدن شما، من پایه ای ترین حالت صدا زدن تابع رو معادل call در نظر گرفتم. اما این روش یه پله بالاتر از پایه ای ترین حالته. ولی بهرحال برای رسوندن مفهوم انتخاب خوبی بود! (مقاله اصلی که توسط مستندات رسمی React بهش اشاره شده تصمیم گرفته اینطوری مبحث رو باز کنه و منم ازش پیروی کردم!)ممنونم که تا آخرش خوندید و برای بهتر شدن خودتون یه قدم برداشتید.و خوشحال میشم اگر نظراتتون رو با من به اشتراک بگذارید و به من برای بهتر شدن کمک کنید ?

زیر پوست جاوااسکریپت | 1.1: بالاخره کامپایلری یا مفسری؟

ابوالفضل بغلانی — Thu, 19 Sep 2019 07:01:53 +0430

بسم الله الرحمن الرحیم<پیش_نوشت>یک سلام پر انرژی به شما که در حال مطالعه این مطلب هستی.بازم همون عکس قبلی!بالاخره بعد از 3 ماه فرصت شد تا قسمت اول این دنباله رو بنویسم. برای شروع کار با هر تکنولوژی جدیدی بهتره ابتدا کمی از ساختارش مطلع بشیم. این که بدونیم در پشت زمینه داره چه اتفاقی می‌افته حتی اگر اندک باشه باعث میشه نتیجه خیلی بهتری بگیریم.برای شروع از شما می‌خوام جاوااسکریپت رو توصیف کنید به احتمال خیلی زیاد در بین توصیفات‌تون از این چند تا کلید واژه استفاده می‌کنید:سطح بالامفسری (و نه کامپایلری)داینامیک تایپدارای وابستگی کم به نوع (می دونم عجیبه ولی ترجمه weakly-typed هست!)(البته احتمالا از واژه های اعصاب خرد کن، شلخته و... هم استفاده می‌کنید!!)در واقع چهار تا موضوع بالا، چهار محور کلی برای تقسیم بندی زبان های برنامه نویسی هستن. موضوع اصلی اینجاست که چهار خط بالا رو احتمالا 90 درصد از خوانندگان این مطلب از قبل می دونستن. اما مطمئنم اکثر ما واقعا نمی‌دونیم چرا جاوااسکریپت مفسری هست و اصلا مفسری بودن واقعا یعنی چی؟ داینامیک تایپ بودن واقعا یعنی چی و سوالاتی از این دست.خب دیگه مقدمه چینی کافیه! بیاید شروع کنیم و جواب "واقعی" این سوالات رو پیدا کنیم! در این مطلب به بحث مفسری/کامپایلری بودن جاوااسکریپت می‌پردازیم و در مقاله های بعد بقیه موارد رو بررسی می‌کنیم!<نوشتار>یکم: جاوااسکریپت زبانی مفسری است! (بعید میدونم!)با بحث نسبتا شیرین کامپایلری بودن یا مفسری بودن شروع میکنیم. گفتم که قصد ندارم همون چیزهایی که همه میدونیم و هزار بار شنیدیم رو دوباره بگم و دنبال یک جواب واقعی هستم. پس خیلی سریع و بدون توضیحات اضافه کامپایلر و مفسر رو معرفی میکنم تا به بحث اصلی خودمون برسیم. اگر دوست دارید بیشتر در رابطه با این دو تا بزرگوار بدونید، مطمئن باشید گوگل خوشحال میشه که بهتون کمک کنه :) جدا از شوخی، مطالعه این لینک برای درک این مسئله بسیار کاربردی هست :A Deeper Inspection Into Compilation And Interpretationماشین زبان ما را نمی‌فهمد!برای اینکه علت وجود کامپایلر و مفسر رو بدونیم، همین جمله ساده کافیه. ماشین (همون کامپیوتر) فقط زبان مختص به خودش رو می‌فهمه(فرض کنید زبان خودش صفر و یکه). ما میتونیم به صفر و یک برنامه بنویسیم؟ احتمالا نه! پس یه مترجم اینجا لازمه که زبان ما رو به زبان قابل فهم برای ماشین تبدیل کنه. کامپایلر(compiler) و مفسر(interpreter) دو تا از مترجم هایی هستن که زحمت تبدیل کد ما به کد ماشین رو می‌کشن (دست شون درد نکنه)کامپایلر (compiler)کامپایلر یک مترجم با صبر و حوصله است. ایشون ابتدا تمام کد منبع (source code) رو به کد ماشین تبدیل می‌کنه، سپس (معمولا) یه فایل خروجی قابل اجرا در اختیار کاربر قرار میده که کاملا ترجمه شده هست و از این به بعد کاربر فقط لازمه اون فایل رو اجرا کنه. مثل مترجمی که یک مقاله رو کاملا ترجمه میکنه و در اختیار شما میزاره.مفسر (interpreter)اگر در دیکشنری به دنبال معنای interpreter بگردید متوجه میشید که معمولا به "مترجم شفاهی" ترجمه میشه. دقیقا مثل معنای لغوی اش، مفسر یک خط از برنامه رو ترجمه می‌کنه و پس از ترجمه، اون رو اجرا میکنه و سپس میره سراغ خط بعدی. نکته اینجاست که عملیات ترجمه کد توسط interpreter در هربار اجرای برنامه لازمه انجام بشه.کدوم بهتره؟دستنوشته ای از Vaidehi Joshi منتشر شده در مقاله http://yon.ir/IALgUخب هردوی اینها مزایای خودشون رو دارن. یک زبان کامپایلری از نظر منطقی سریع تره چون نیاز نیست هر بار عملیات ترجمه کد ما به کد ماشین انجام بشه. همچنین اگر برنامه‌ای به یک زبان کامپایلری نوشته شده باشه لازم نیست کد منبعش رو برای اجرا در اختیار دیگران بزاریم، پس میشه گفت جای سورس اصلی برنامه امن تره!از طرفی یک زبان مفسری به شدت انعطاف پذیر تر از یک زبان کامپایلری هست. سرعت توسعه بالاتری داره، مدیریت خطاها و... در حین توسعه ساده تره و در کل توسعه آسان تری داره.نکته مهم: مفسری یا کامپایلری بودن جزئی از ذات یک زبان نیست!!اینجا، جاییه که خیلی از توسعه دهنده های ایرانی دچار اشتباه میشن. این که میگیم زبان C++ یک زبان کامپایلری هست یا فلان زبان مفسری هست، درواقع به معروف ترین پیاده سازی اون زبان اشاره داره. وگرنه ما میتونیم C++ مفسری (مثل ch) و یا پایتون کامپایلری داشته باشیم. پس اگر بگیم جاوااسکرپیت مفسری یا کامپایلری هست منظورمون اینه که معروف ترین پیاده سازی های این زبان به شکل مفسری عمل می‌کنن!خب حالا بالاخره، جاوااسکریپت مفسری است یا کامپایلری؟+ یکی از حضار: مفسریه دیگه همه میدونن!اکثرا شنیدیم جاوااسکریپت مفسریه. اما واقعا نمیشه این موضوع رو با قطعیت گفت. روشی که موتور های پردازش جاوااسکریپت مثل V8 کد ما رو پردازش می‌کنن واقعا به روش کامپایلر شبیهه. مواردی مثل hoisting یا lexical Scoping یا حتی کلوژرها این شباهت رو بیشتر هم میکنن. (اگر نمیدونید اینا چی هستن مشکلی نیست و ضربه ای به درک شما از این مقاله نمیزنه. اما بهتره توی گوگل جستجو کنید و راجع بهشون بیشتر بخونید چون مباحث مهمی هستن و مقالات خوب و روانی هم در موردشون وجود داره)به‌علاوه میشه گفت، موتور V8 (پر استفاده ترین موتور پردازش جاوااسکرپیت که توسط گوگل برای مرورگر کروم و با زبان ++C ساخته شد و بعدها توسط NodeJS مورد استفاده قرار گرفت) عملا تمام کد رو ابتدا تبدیل به کد ماشین می‌کنه و سپس اون رو اجرا می‌کنه. تازه این موتور برای شرایط مختلف از چند نوع متفاوتِ ترجمه کد منبع به کد ماشین استفاده میکنه. (توضیح دقیق این نحوه پردازش البته از حوصله این مقاله خارجه.)+ پس جاوااسکریپت شد کامپایلری دیگه؟نه! موتورهایی مثل V8 علیرغم روش فوق العاده شون، هیچ وقت یک فایل قابل اجرا به ما تحویل نمیدن و تفاوت هایی از این دست باعث میشه نتونیم به قطعیت بگیم جاوااسکریپت یک زبان کامپایلریه.+ خب پس چی شد بالاخره؟اگر گیج شدید و حس می‌کنید نهایتا متوجه نشدید جاوااسکریپت مفسریه یا کامپایلری باید بدونید شما تنها نیستید! بزرگترین متخصصان جاوااسکریپت هم درباره این مسئله نظرات متفاوتی دارند؛ کایل سیمپسون، نویسنده مجموعه کتابهای "شما جاوااسکریپت را نمی‌شناسید" که بیش 108 هزار ستاره در گیت هاب دریافت کرده معتقده که جاوااسکریپت زبانی کامپایلریه (یا حداقل زبانی مفسری نیست). این نقل قول رو ببینید:فرض کنید برنامه جاوااسکریپتی شما یک سینکس ارور در خط 7 دارد و شما یک alert یا console.log در خط اول دارید. اگر جاوااسکریپت یک زبان مفسری بود، شما باید اول alert یا console.log را مشاهده می‌کردید قبل از اینکه به سینتکس ارور برخورد کنید، درسته؟ اما این اتفاق نمی‌افته! در عوض جاوااسکریپت به شما یک ارور نشون میده قبل از اجرای حتی یک خط کد!از طرف دیگه شما افراد زیادی رو می‌بینید که هنوز هم معتقدن، جاوااسکریپت یک زبان مفسری هست. میشه گفت اینجا تفاوت اصلی در نگاه افراد به تعریف واقعی کامپایلر/مفسر هست.و اما نتیجه:من به شخصه نه میتونم جاوااسکریپت رو کامپایلری به حساب بیارم و نه مفسری. اما یک نکته مهمی رو میدونم که:با پیشرفت تکنولوژی مرز بین خیلی از چیزهای مختلف از بین میره. زمانی که JIT Compiler ها(مترجمی که عملیات کامپایل رو در لحظه روی کد منبع انجام میداد. چیزی بین مفسر و کامپایلر) ساخته شدن، یا حتی زمانی که موتور های مدرن پردازش جاوااسکریپت بر مبنای JIT ساخته شدن، هیچ کس نمیخواست خودش رو مقید کنه که به کامپایلری بودن یا مفسری بودن وفادار باشه. بلکه همه به دنبال افزایش کارایی و سرعت توسعه و ... بودن. پس ما هم لازم نیست خودمون رو مقید کنیم!تنها چیزی که درآخر میتونم بگم اینه که اگر به جای صفر و یکی فکر کردن، فاصله بین یک زبان کامپایلری و یک زبان مفسری رو یک بازه فرض کنیم، احتمالا جاوااسکریپت جایی در اواسط اون بازه است. جایی که بهترین کارایی و بیشترین منافع رو داشته باشه. و اینکه به کدوم نزدیک تره، خیلی مهم نیست!!<پی_نوشت>خب! بالاخره تموم شد! ممنون که تا اینجا همراه من بودید.با توجه به تحقیق از چند منبع خارجی، سعی در بهتر رساندن مطلب و... من سه چهار ساعت برای نوشتن همین مقاله ساده وقت گذاشتم. (خدا به خیر بگذرونه مطالب سخت تر رو!). از طرفی سایت های ایرانی راجع به خیلی از مفاهیم بنیادی JS هیچ مطلبی ندارن و اون مطالب موجود هم اصلا و ابدا موضوع رو دقیق بررسی نمی‌کنن(معمولا). مثلا از 10 منبع 8 تاشون میگن کال بک تابعیه که بعد از تموم شدن کار یه تابع دیگه اجرا میشه و تمام! این یعنی خیلی از توسعه دهنده های ما، به واقعیت و پشت صحنه تکنولوژی های مورد استفاده شون تسلط ندارن.نکته مهم اینجاست که از نظر من جاوااسکریپت مطالب زیادی داره که درست فهمیده نشدن و نمیشن (کال بک ها، کلوژر ها، async ،lexicalScoping و خیلی چیزهای دیگه!) و قصد دارم در یک دنباله راجع به همه شون بنویسم تا در کنار هم معنا و کاربرد واقعی اون ها رو بفهمیم.ازتون میخوام لطف کنید و در رابطه با این مقاله نظر بدید. لحنش، محتواش و اینکه اصلا مطالبش اون قدر که من فکر میکنم مهم بود یا نه. این باعث میشه بتونم بهتر درباره ادامه این دنباله تصمیم بگیرم.

زیر پوست جاوااسکریپت | مقدمه

ابوالفضل بغلانی — Thu, 20 Jun 2019 14:37:45 +0430

به نام آنکه هستی نام از او یافتسلاممن چند سال از جاوااسکریپت، این زبان پرکاربردِ پر رمز و راز استفاده کردم. با جی‌کوئری نازنین و البته سالخورده هم مدت زیادی همنشین بودم؛ ولی از یه زمانی به بعد فهمیدم دانش من در زمینه جاوااسکریپت نه تنها اندک، بلکه حتی کم ارزشه. دیگه نه جی کوئری مثل قدیم لازم و ملزوم هر پروژه ای هست و نه جاوااسکریپت به اون بد شکلی سابق.اینجا بود که تصمیم گرفتم برگردم به نقطه اول داستان. دقیقا مثل کسی که هیچی از این زبان نمی دونه شروع کنم به یادگرفتن جاوااسکریپت و از ابتدایی ترین نکته تا پیچیده ترین مسائل رو یکبار دیگه یاد بگیرم و مرور کنم.خیلی از توسعه دهنده ها میدونن جاوااسکریپت چه جور زبانیه. زبانی به ظاهر ساده که نکات ریز زیادی داره. دقیقا هم مشکل از همین نکات ریز شروع میشه. جایی که شما کدی می‌نویسی و انتظار داری نتیجه خاصی رو ازش بگیری اما در نهایت نتیجه ای کاملا خلاف انتظار بر می‌گرده و ساعت ها شما رو درگیر می‌کنه.من میخوام همینطور که در این زبان بیشتر سیر می‌کنم، نکات مفهومی و مهمی که معمولا از دید خیلی هامون پنهان میمونن رو بررسی کنم و به ساده ترین حالت ممکن اونها رو توضیح بدم.قطعا دونستن این مفاهیم فواید زیادی داره که برنخوردن به ارور های عجیب، دریافت پرفورمنس بهتر و حرفه ای تر کد زدن فقط بخشی از اون فواید هستن.خوشحال میشم در این مسیر همراهم باشید و ممنون میشم اگر کمکم کنید :)