دیدار کیف برو مه 2018:
سرب: - سلام به همه! متشکرم که در اینجا حضور دارید! امروز ما دو سخنران رسمی داریم - لیوشا و وانیا. اگر زمان کافی داشته باشیم، دو تا دیگر نیز وجود خواهد داشت. اولین سخنران الکسی گراچف است، او درباره GopherJS به ما خواهد گفت.
الکسی گراچف (از این پس - AG): - من یک توسعه دهنده Go هستم و خدمات وب را در Go می نویسم. گاهی اوقات شما باید با frontend مقابله کنید، گاهی اوقات باید به صورت دستی وارد آن شوید. من می خواهم در مورد تجربه و تحقیقم در مورد Go on the frontend صحبت کنم.
افسانه این است: ابتدا در مورد اینکه چرا میخواهیم Go را در فرانتاند اجرا کنیم، صحبت خواهیم کرد، سپس در مورد چگونگی انجام این کار صحبت خواهیم کرد. دو راه وجود دارد - Web Assembly و GopherJS. بیایید ببینیم وضعیت این راه حل ها چگونه است و چه کاری می توان انجام داد.
قسمت جلویی چه مشکلی دارد؟
آیا همه موافقند که همه چیز با فرانت اند خوب است؟
آیا آزمایشات کافی وجود ندارد؟ ساخت کند؟ زیست بوم؟ خوب.
در مورد frontend، نقل قولی را که یکی از توسعه دهندگان فرانت اند در کتاب خود گفته است، دوست دارم:
جاوا اسکریپت سیستم نوع ندارد. اکنون مشکلاتی را که در مسیر کارم با آن مواجه شدم نام می برم و نحوه حل آنها را توضیح می دهم.
سیستم نوع را به طور کلی به سختی می توان در جاواسریپت یک سیستم نوع نامید - خطوطی وجود دارد که نوع شی را نشان می دهد، اما در واقع این ربطی به انواع ندارد. این مشکل در TypeScript (افزونه ای برای جاواسریپت) و Flow (یک بررسی کننده نوع ایستا در جاوا اسکریپت) حل شده است. در واقع، frontend قبلاً به نقطه حل مشکل یک سیستم بد نوع در جاوا اسکریپت رسیده است.
هیچ کتابخانه استانداردی در مرورگر وجود ندارد - برخی از اشیاء داخلی و عملکردهای "جادویی" در مرورگرها وجود دارد. اما در جاوا اسکریپت هیچ کتابخانه استانداردی وجود ندارد. این مشکل قبلاً یک بار توسط jQuery حل شده بود (همه از jQuery با تمام نمونههای اولیه، کمککنندهها و توابع مورد نیاز برای کار استفاده کردند). اکنون همه از Lodash استفاده می کنند:
جهنم برگشت به تماس من فکر میکنم همه کد جاوا اسکریپت را حدود 5 سال پیش دیدند، و به نظر میرسید که یک "نودل" از پیچیدگی باورنکردنی تماسها. اکنون این مشکل حل شده است (با انتشار ES-15 یا ES-16)، وعده هایی به جاوا اسکریپت اضافه شده است و همه می توانند برای مدتی راحت نفس بکشند.
تا زمانی که جهنم Promise از راه رسید... من نمیدانم صنعت پیشرو چگونه مدیریت میکند، اما آنها همیشه خودشان را به جنگل عجیبی میرانند. ما هم موفق شدیم روی وعده ها جهنم کنیم. سپس این مشکل را با اضافه کردن یک primitive جدید - async/await حل کردیم:
مشکل ناهمزمانی حل شده است. Async/wait در زبان های مختلف یک بدوی نسبتاً محبوب است. پایتون و دیگران این رویکرد را دارند - بسیار خوب است. مشکل حل شد.
چه مشکلی حل نمی شود؟ پیچیدگی فزاینده چارچوب ها، پیچیدگی اکوسیستم و خود برنامه ها.
- نحو جاوا اسکریپت کمی عجیب است. همه ما مشکلات اضافه کردن یک آرایه و یک شی و جوک های دیگر را می دانیم.
- جاوا اسکریپت چند پارادایم است. اکنون که اکوسیستم بسیار بزرگ است، این یک سیستم به ویژه فشار است:
- همه به سبک های مختلف می نویسند - برخی به صورت ساختاری می نویسند، برخی به صورت کاربردی می نویسند، توسعه دهندگان مختلف متفاوت می نویسند.
- از بسته های مختلف، پارادایم های مختلف زمانی که از بسته های مختلف استفاده می کنید.
- برنامه نویسی کاربردی در جاواسریپت "سرگرم کننده" زیادی دارد - کتابخانه rambda ظاهر شد و اکنون هیچ کس نمی تواند برنامه های نوشته شده در این کتابخانه را بخواند.
- همه اینها تأثیر زیادی بر اکوسیستم می گذارد و به طرز باورنکردنی رشد کرده است. بستهها با یکدیگر ناسازگار هستند: برخی بر اساس وعدهها، برخی بر اساس async/wait، برخی بر اساس تماسهای برگشتی هستند. در پارادایم های مختلف هم می نویسند!
- این امر نگهداری پروژه را دشوار می کند. اگر نتوانید کد را بخوانید، پیدا کردن یک باگ سخت است.
اسمبلی وب چیست؟
مردان شجاع بنیاد موزیلا و تعدادی از شرکت های دیگر چیزی به نام Web Assembly را ارائه کردند. این چیه؟
- این یک ماشین مجازی ساخته شده در مرورگر است که از فرمت باینری پشتیبانی می کند.
- برنامههای باینری به آنجا میرسند و تقریباً بهصورت بومی اجرا میشوند، یعنی مرورگر نیازی به تجزیه همه نودلهای کد جاوا اسکریپت ندارد.
- همه مرورگرها پشتیبانی را اعلام کرده اند.
- از آنجایی که این بایت کد است، می توانید برای هر زبانی یک کامپایلر بنویسید.
- چهار مرورگر اصلی در حال حاضر با پشتیبانی Web Assembly عرضه می شوند.
- به زودی منتظر پشتیبانی بومی در Go هستیم. این معماری جدید قبلاً اضافه شده است: GOARCH=wasm GOOS=js (به زودی). تا اینجا که من فهمیدم کاربردی نیست اما گفته شده که حتما در Go خواهد بود.
الان باید چیکار کنیم؟ GopherJS
در حالی که ما از Web Assembly پشتیبانی نداریم، ترانسپایلری مانند GopherJS وجود دارد.
- کد Go به جاوا اسکریپت "خالص" منتقل می شود.
- در همه مرورگرها اجرا می شود - هیچ ویژگی جدیدی وجود ندارد که فقط توسط مرورگرهای مدرن پشتیبانی شود (این Vanilla JS است که روی هر چیزی اجرا می شود).
- تقریباً از همه چیزهایی که Go دارد پشتیبانی وجود دارد، از جمله برنامهها و کانالها... همه چیزهایی که خیلی دوست داریم و میدانیم.
- تقریباً کل کتابخانه استاندارد پشتیبانی می شود، به جز آن دسته از بسته هایی که پشتیبانی از آنها در مرورگر معنی ندارد: syscall، تعاملات شبکه (یک کلاینت net/http وجود دارد، اما سرور وجود ندارد، و مشتری از طریق XMLHttpRequest شبیه سازی می شود). به طور کلی، کل کتابخانه استاندارد در دسترس است - اینجا در مرورگر است، اینجا stdlib Go است که ما آن را دوست داریم.
- کل اکوسیستم بسته در Go، تمام راه حل های شخص ثالث (قالب سازی و غیره) را می توان با استفاده از GopherJS کامپایل کرد و در مرورگر اجرا کرد.
GopherJS بسیار آسان است - این فقط یک بسته Go معمولی است. ما میرویم دریافت، و یک دستور GopherJS برای ساخت برنامه داریم:
این یک سلام کوچک است...
... یک برنامه Go معمولی، یک بسته fmt کتابخانه استاندارد معمولی و Binding Js برای رسیدن به API مرورگر. Println در نهایت به گزارش کنسول تبدیل میشود و مرورگر «Hello gophers» را مینویسد! به همین سادگی است: ما ساخت GopherJS را انجام می دهیم - آن را در مرورگر راه اندازی می کنیم - همه چیز کار می کند!
در حال حاضر چه چیزی دارید؟ اتصالات
پیوندهایی برای همه فریمورک های محبوب js وجود دارد:
- جی کوئری
- Angular.js;
- D3.js برای ترسیم و کار با داده های بزرگ.
- React.js;
- VueJS؛
- حتی از Electron نیز پشتیبانی می شود (یعنی می توانیم برنامه های دسکتاپ را روی Electron بنویسیم).
- و جالبترین چیز WebGL است (ما میتوانیم برنامههای گرافیکی کامل، از جمله بازیهایی با گرافیک سهبعدی، موسیقی و همه چیزهای خوب بسازیم).
- و بسیاری از اتصالات دیگر به تمام چارچوب ها و کتابخانه های محبوب جاوا اسکریپت.
چارچوب
- یک چارچوب وب قبلاً به طور خاص برای GopherJS - Vecty توسعه یافته است. این یک آنالوگ کامل از React.js است، اما فقط در Go توسعه یافته است، با مشخصات GopherJS.
- کیسه های بازی وجود دارد (تعجب!). من دو مورد از محبوب ترین ها را پیدا کردم:
- Engo;
- ابیتن.
من به شما چند نمونه از ظاهر آن را نشان خواهم داد و آنچه را که قبلاً می توانید در Go بنویسید:
یا این گزینه (من نتوانستم یک تیرانداز سه بعدی پیدا کنم، اما شاید وجود داشته باشد):
من چه پیشنهادی دارم؟
اکنون صنعت فرانتاند در چنین وضعیتی قرار دارد که تمام زبانهایی که قبلاً از جاوا اسکریپت گریه میکردند به آنجا میروند. اکنون همه چیز در "مجموعه های وب" کامپایل می شود. ما به چه چیزی نیاز داریم تا جایگاه واقعی خود را به عنوان Gophers در آنجا بگیریم؟
Go به طور سنتی فرض می کرد که یک زبان برنامه نویسی سیستم است و عملاً هیچ کتابخانه ای برای کار با UI وجود ندارد. چیزی هست، اما نیمه رها شده، نیمه غیر کاربردی.
و اکنون فرصت خوبی برای ایجاد کتابخانه های UI در Go است که روی GopherJS اجرا می شوند! بالاخره می توانید فریمورک خود را بنویسید! این زمانی است که می توانید یک فریم ورک بنویسید، و یکی از اولین ها خواهد بود و زودهنگام پذیرفته می شود، و ستاره خواهید بود (اگر فریمورک خوبی باشد).
میتوانید بستههای مختلفی را که قبلاً در اکوسیستم Go هستند، با ویژگیهای مرورگر تطبیق دهید (مثلاً موتور الگو). آنها قبلاً کار می کنند، می توانید اتصالات راحت ایجاد کنید تا بتوانید به راحتی محتوا را مستقیماً در مرورگر ارائه دهید. بهعلاوه، میتوانید برای مثال، سرویسی بسازید که میتواند با استفاده از همان کد، همان چیزی را روی سرور و در قسمت جلویی ارائه کند - همه چیزهایی که توسعهدهندگان فرانتاند دوست دارند (فقط اکنون در Go).
شما می توانید یک بازی بنویسید! فقط برای سرگرمی…
این تمام چیزی است که می خواستم بگویم.
پرسش
سوال (از این پس Q نامیده می شود): - آیا در Go یا Js می نویسم؟
AG: – شما روال ها، کانال ها، ساختارها، جاسازی – همه چیز را در Go می نویسید... در یک رویداد مشترک می شوید، یک تابع را در آنجا ارسال می کنید.
که در: - پس من با جهای "برهنه" می نویسم؟
AG: – نه، شما طوری می نویسید که انگار در Go و به API مرورگر متصل می شوید (API تغییر نکرده است). می توانید پیوندهای خود را بنویسید تا پیام ها به کانال ارسال شوند - دشوار نیست.
که در: - در مورد موبایل چطور؟
AG: - من قطعاً دیدم: برای پچ Cordova که Js اجرا می کند، اتصالاتی وجود دارد. در React Native - نمی دانم؛ شاید وجود داشته باشد، شاید نه (من علاقه خاصی نداشتم). موتور بازی N-go از هر دو برنامه موبایل - iOS و Android - پشتیبانی می کند.
که در: – سوال در مورد اسمبلی وب. با وجود فشردهسازی و «زیپ کردن»، فضای بیشتری اشغال میشود... آیا ما دنیای جلویی را به این شکل بیشتر نمیکشیم؟
AG: – Web Assembly یک فرمت باینری است و باینری به طور پیشفرض در نسخه نهایی نمیتواند بیشتر از متن باشد... شما به زمان اجرا کشیده میشوید، اما این مانند کشیدن کتابخانه استاندارد جاوا اسکریپت زمانی است که وجود ندارد، بنابراین ما از مقداری لوداش استفاده کنید. نمی دانم لوداش چقدر می گیرد.
که در: - واضح است که کمتر از زمان اجرا ...
AG: - در جاوا اسکریپت "خالص"؟
که در: - آره. قبل از ارسال آن را فشرده می کنیم...
AG: – اما این متن است... به طور کلی، یک مگابایت زیاد به نظر می رسد، اما این تمام است (شما کل زمان اجرا را دارید). بعد، منطق کسب و کار خود را می نویسید، که باینری شما را 1٪ افزایش می دهد. تا اینجای کار من این را نمی بینم که طرف مقابل را بکشد. علاوه بر این، اسمبلی وب به دلیل واضحی سریعتر از جاوا اسکریپت کار می کند - نیازی به تجزیه و تحلیل ندارد.
که در: – این هنوز یک نکته بحث برانگیز است... هنوز هیچ مرجعی از «وسما» (مجمع وب) وجود ندارد تا بتوان بدون ابهام قضاوت کرد. از نظر مفهومی، بله: همه ما می دانیم که باینری باید سریعتر باشد، اما اجرای فعلی همان V8 بسیار کارآمد است.
AG: - آره.
که در: - تلفیقی در آنجا واقعاً بسیار عالی عمل می کند و این یک واقعیت نیست که مزیت بزرگی وجود خواهد داشت.
AG: - اسمبلی وب نیز توسط افراد بزرگ ساخته شده است.
که در: - به نظر من هنوز قضاوت در مورد Web Assembly دشوار است. سالهاست که صحبتهایی وجود دارد، اما دستاوردهای واقعی کمی وجود دارد که میتوان احساس کرد.
AG: - شاید. خواهیم دید.
که در: – ما مشکلی در باطن نداریم... شاید باید این مشکلات را روی فرانت اند بگذاریم؟ چرا به آنجا برویم؟
AG: - ما باید کارکنان خط مقدم را نگه داریم.
چند تبلیغ 🙂
از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید
Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا
منبع: www.habr.com