میسکو هیوری Qwik JS فوق العاده سریع را توضیح می دهد

مدیر ارشد فناوری Builder.io در مورد چگونگی مقابله Qwik با چالش‌های واکنش‌پذیری جاوا اسکریپت و آنچه که طراح سایت بصری Builder باید برای تولیدکنندگان محتوا و توسعه‌دهندگان ارائه دهد، بحث می‌کند.

Misko Hevery مدیر ارشد فناوری Builder، طراح سایت بصری آنلاین است. او همچنین خالق Qwik، یک چارچوب جاوا اسکریپت نسل بعدی است. Heery قبل از روزهای سازنده و Qwik خود، Angular را ایجاد کرد که یکی از فریمورک‌های شاخص جاوا اسکریپت بود و Karma< /a>، اجرای آزمایشی محبوب جاوا اسکریپت.

تایسون: با تماشای اخیر ریچ هریس از Qwik آگاه شدم ارائه Jamstack Conf. او توضیح می دهد که چگونه چندین پروژه تلاش می کنند تا کاستی های چارچوب های واکنشی را برطرف کنند.

Hevery: متشکرم، ریچ!

تایسون: Qwik تجدید نظر در واکنش پذیری از اصول اولیه است. واقعاً جالب است که چگونه ساخت برنامه را فعال کرده اید با مرزهای بارگذاری تنبل داخلی. چگونه برای انجام این کار انگیزه پیدا کردید و به این رویکرد رسیدید؟

Hevery: بنابراین ایده در واقع از سخنرانی من در ng-conf آمد. چند سال پیش. در آنجا من اساساً آنچه امروز Qwik است توضیح دادم. من مدام می‌دیدم که چارچوب‌های دیگر اساساً همان مشکلات قدیمی را تکرار می‌کنند، و به نظر می‌رسد هیچ یک از چارچوب‌ها به فیل در اتاق نمی‌پردازد. به نظر می رسد همه آنها بارگذاری تنبل را به عنوان یک فکر بعدی در نظر می گیرند، و من می خواستم آن را تغییر دهم.

من هدفی را برای داشتن یک سیستم کاملاً با قابلیت بارگذاری تنبل تعیین کردم و به عقب کار کردم تا ببینم چه نوع چارچوبی می‌توانم بسازم که این محدودیت‌ها را برآورده کند. اکثر فریم ورک ها به اندازه فریمورک اهمیت می دهند، اما به اندازه برنامه اهمیت نمی دهند. اندازه برنامه “مشکل آنها” نیست. من چارچوبی می خواستم که به طور خاص به مشکل اندازه برنامه رسیدگی کند. هر برنامه کاربردی دنیای واقعی مرتبه‌ای بزرگتر از چارچوب است، بنابراین باید روی آن تمرکز کنیم.

تایسون: جالب است!

بنابراین شما مدیر فنی Builder و همچنین خالق Qwik هستید. Builder یک ویرایشگر WYSIWYG چشمگیر است. آیا از Qwik در زیر کاپوت استفاده می کند؟

Hevery: ما در شرف انتشار صفحه اصلی جدید خود هستیم که تمام آخرین مواردی را که Qwik ارائه می دهد به نمایش می گذارد. این فقط HTML را در بالای صفحه بارگذاری می کند، تعامل بارگذاری تنبل، و همه اسکریپت های شخص ثالث را در وب کارگر اجرا می کند. هدف ما کسب ۱۰۰/۱۰۰ در Google PageSpeed است و نشان می‌دهد که سایت‌های تجارت الکترونیک می‌توانند سریع باشند.

صفحه اصلی ما در بالای Qwik ساخته می‌شود و به محض انتشار آن، می‌توانیم همان قابلیت را به مشتریان خود ارائه دهیم. بنابراین ما Qwik را هم به عنوان یک پروژه منبع باز و هم به عنوان خدماتی برای ساخت سایت های تجارت الکترونیکی سریع ارائه خواهیم کرد.

Tyson: Builder به شما امکان می‌دهد تا انواع چارچوب‌ها را برای خروجی از طراح بصری انتخاب کنید (React، Vue، و غیره). من تصور می کنم که Qwik گزینه خروجی دیگری در آینده خواهد بود؟

Hevery: بله، ما قبلاً Qwik را داریم که با Builder کار می کند و به زودی برای همه مشتریان ما در دسترس خواهد بود.

تایسون: آیا داشتن چندین هدف صادراتی آنقدر که به نظر می رسد یک چالش فنی دشوار است؟

Hevery: این مشکل با Mitosis حل می‌شود. Mitosis پروژه ای است که به شما امکان می دهد یک کامپوننت را یک بار بنویسید و سپس آن را به تمام چارچوب های وب رایج صادر کنید. این به شما قابلیت “نوشتن یک بار در هر نقطه” را می دهد.

Tyson: Qwik به شما امکان می‌دهد برنامه‌ای را با محدودیت‌هایی در مدیریت‌کننده‌های منابع، وضعیت و رویداد بسازید. این بدان معنی است که برنامه می تواند به کنترل دقیق آنچه بارگذاری شده است دست یابد. آیا این یک توصیف منصفانه است؟

Hevery: بله! Qwik باید چندین چالش فنی سخت را حل کند که سایر چارچوب‌ها به سادگی نادیده گرفته می‌شوند.

اول، چگونه برنامه های بزرگ را به بخش های کوچک با قابلیت بارگذاری تنبل تقسیم می کنید؟ این سخت‌تر از آن چیزی است که به نظر می‌رسد، زیرا در زمان نوشتن برنامه نمی‌دانید بهترین مرزهای تنبل‌بار کجا هستند. تنها پس از اجرای برنامه و مشاهده استفاده در دنیای واقعی، می توانید تعیین کنید که کدام ویژگی بیشتر استفاده می شود.

دوم، چارچوب نباید نیاز داشته باشد که همه اجزای قابل مشاهده در صفحه دانلود و اجرا شوند. این چیزی است که همه چارچوب‌های موجود نیاز دارند: اگر مؤلفه‌ای را می‌بینید، قبل از اینکه بتوانید آن را تعاملی کنید، باید تمام کد آن را دانلود و اجرا کنید.

سوم، چارچوب باید تمام شنوندگان رویداد را در HTML سریال کند. بدون این، همه الگوهای برنامه باید مشتاقانه دانلود شوند.

چهارم، چارچوب باید روابط داده‌ای بین مؤلفه‌ها را سریالی کند (واکنشی). بدون این، هر جهشی در وضعیت مستلزم این است که کل برنامه دانلود و اجرا شود.

تایسون: این واقعاً یک شکست مفید است. این مکان بسیاری از اقدامات در دنیای جاوا اسکریپت در حال حاضر در حال انجام است.

می توانید کمی در مورد اینکه Qwik “قابل ادامه مجدد” است، توضیح دهید؟

Hevery: شاید این نسخه نمایشی بتواند آن را بهتر توضیح دهد؟ اما ایده اصلی این است که وضعیت برنامه به صورت سریالی در HTML است و بنابراین چارچوب می تواند اجرا را در جایی که سرور متوقف کرده است ادامه دهد. مزیت بزرگ این است که مشتری مجبور نیست تمام کارهایی را که سرور انجام داده است دوباره انجام دهد. این باعث می‌شود راه‌اندازی مشتری آنی باشد و تجربه کاربری اپلیکیشن را تا حد زیادی افزایش دهد. از آنجا که Qwik فقط زمانی کد را برای مؤلفه بارگیری می کند که مؤلفه نیاز به جهش داشته باشد، بخش استاتیک سایت هرگز کد آنها را دانلود نخواهد کرد.

تایسون: Qwik در نسخه‌های اولیه است (اگرچه می‌تواند همه ایده های اصلی). برای رسیدن به افت ۱.۰ بیشتر روی چه حوزه هایی تمرکز کرده اید؟

Hevery: ما عمداً سعی می‌کنیم نسخه اول را حداقل نگه داریم. ویژگی کلیدی بهینه‌ساز است که Qwik را قادر می‌سازد تا برنامه شما را به تعداد زیادی تنبل ریز تقسیم کند. بارگیری تکه ها همانطور که می توانید تصور کنید، طراحی بهینه ساز بسیار مشکل است، اما این چیزی است که تمام جادوی Qwik را فعال می کند. بنابراین برای نسخه ۱.۰ ما فقط می‌خواهیم راهی برای ساختن یک برنامه سرتاسر و نشان دادن بارگیری تنبل ظریف داشته باشیم که قبلاً هرگز دیده نشده بود.

تایسون: چه رابطه ای بین برداشت Qwik از ساخت برنامه و سازنده/باندلر وجود دارد؟

Hevery: ما می‌خواهیم بتوانیم سریع‌ترین سایت‌های ممکن را برای مشتریان خود ایجاد کنیم، و Qwik راهی برای رسیدن به آن است. از آنجایی که اکثر مشتریان ما در فضای تجارت الکترونیک هستند، سرعت چیزی است که مستقیماً بر تبدیل و در نتیجه بر درآمد تأثیر می گذارد.

تایسون: آیا چیز دیگری وجود دارد که بخواهید روی آن دست بزنید؟

Hevery: بخش کلیدی استراتژی Qwik Partytown است. Qwik می‌تواند برنامه شما را سریع کند، اما به نظر می‌رسد که اسکریپت‌های شخص ثالث می‌توانند تمام عملکردی را که Qwik برای ایجاد آن سخت کار کرده است، کاملاً از بین ببرد.

به همین دلیل Qwik نه تنها باید برنامه شما را سریع راه اندازی کند، بلکه باید تمام اسکریپت های شخص ثالث را برای وب کارمندان بارگذاری کند تا عملکرد سریع را حفظ کند. پارتی تاون همین کار را می کند. با ایجاد محیطی در وب‌کارگر که می‌تواند اسکریپت‌ها را اجرا کند و موضوع اصلی را برای کاربر باقی بگذارد، می‌توانید کیک خود را داشته باشید و آن را نیز بخورید.

تایسون: وای، جالب است، من از پارتی تاون اطلاعی نداشتم. چارچوبی برای اجرای اسکریپت های گران قیمت در یک رشته کارگر… به نظر می رسد که می تواند تاثیر زیادی در همه انواع برنامه ها داشته باشد. این به نوعی من را به یاد توانایی Astro برای هیدراته کردن یک جزء هنگامی که نخ بیکار است می اندازد.

آیا شما از Partytown در بیلدر استفاده می کنید؟

Hevery: بله، Partytown یک بخش کلیدی از استراتژی است. بدون Partytown امکان نمایش ۱۰۰/۱۰۰ در Google PageSpeed ​​برای سایت های ما وجود نخواهد داشت.

Tyson: Builder برای افراد بازاریابی مفید است، تا آنها را قادر می سازد تا بدون دانش فنی سایت بسازند، اما شما همچنین پشتیبانی زیادی برای توسعه دهندگان دارید. آیا می‌خواهید کمی در مورد آنچه که Builder را برای کدنویس‌های موجود جذاب می‌کند صحبت کنید؟

Hevery: در واقع، Builder هم برای سازندگان محتوا و هم برای مهندسان نرم افزار مفید است. سازندگان محتوا می خواهند دائماً چیزها را تغییر دهند و مهندسی فقط می خواهد ویژگی های جدیدی ایجاد کند. این دو گروه برنامه های انتشار متفاوتی دارند. بازاریابی می‌خواهد همه چیز در نیمه‌شب جمعه سیاه فعال شود، و مهندسی فقط می‌خواهد چیزها را منتشر کند (نه در جمعه‌ها تا هیچ غافلگیری آخر هفته آنها را نابود نکند). بنابراین این ابزار واقعاً به این دو گروه از مردم اجازه می دهد تا به روشی مکمل تر همزیستی کنند.

تایسون: هه! اینها برخی از مشاهدات خنده دار و واقعی در مورد توسعه نرم افزار هستند.

علاوه بر ابزارهای بهبود یافته مانند Builder، چگونه سعی می کنید بین خواسته های طرف تجاری و مهندسی از صندلی CTO تعادل برقرار کنید؟

هوری: هه، مطمئن نیستم تعادل داشته باشم! اما بله، من سعی می کنم هفته خود را به سه روز با تمرکز بر کسب و کار و دو روز بر روی کدنویسی تقسیم کنم. شما باید جداسازی واضحی داشته باشید، در غیر این صورت در سیاهچاله مکیده می شوید و هرگز بیرون نمی آیید.

تایسون: آیا راهی وجود دارد که بتوان از Builder یک صادرات دریافت کرد و کد را با دست تغییر داد، سپس آن را به بیلدر وارد کرد و دوباره با طراح ویرایش کرد؟

Hevery: بله، هم واردکننده و هم صادرکننده داریم. HTML تنها یکی از بسیاری از فرمت هایی است که ما پشتیبانی می کنیم. به عنوان مثال، می توان یک طرح را در Figma ایجاد کرد و سپس آن را به بیلدر وارد کرد. به طور مشابه، ما می‌توانیم یک سایت HTML را انتخاب کنیم و آن را به Figma فشار دهیم تا افراد خلاق آن را بهبود بخشند، بنابراین تعداد کمی از گزینه‌های واردات/صادرات در دسترس است.

تایسون: به اندازه کافی منصفانه است!

متوجه شدم چندین گزینه ادغام داده در Builder برای مصرف ذخیره‌سازی داده و API وجود دارد. می توانید کمی در مورد آنها بگویید؟

Hevery: مردم Builder را به عنوان یک ویرایشگر رابط کاربری با کشیدن و رها کردن تصور می کنند. اما در واقعیت، بسیار بیشتر است. لحظه کلیدی با Builder زمانی است که توسعه دهندگان و سازندگان محتوا متوجه می شوند که می توانند اجزای خود را به صفحه بکشند.

کامپوننت‌ها دارای ورودی/پایه‌ها هستند و بنابراین Builder اتصال داده‌ها را نیز درک می‌کند. داده ها از کجا می آیند؟ خوب، یکپارچه‌سازی‌های فهرست‌شده در آنجا همه مکان‌هایی را به شما نشان می‌دهند که می‌توانید از آنجا داده‌ها را دریافت کنید. به عنوان مثال، کاتالوگ شما از Shopify می آید اما شما آن را به اجزای سفارشی خود وارد می کنید.

تایسون: آیا می گویید که Builder به سمت تبدیل شدن به یک وب IDE کامل حرکت می کند؟ متوجه شدم که شما ویرایش کد درون خطی را به عنوان یک ویژگی بتا معرفی کرده اید.

Hevery: فکر نمی‌کنم این درست باشد. IDE ها به چیزهای زیادی نیاز دارند که Builder نه دارد و نه به آن نیاز دارد، بنابراین فکر نمی‌کنم که این توصیف درستی باشد.

من می‌توانم بگویم که Builder تنها به اندازه‌ای که افراد خلاق نیاز دارند، انجام می‌دهد تا کارشان را به نحوی انجام دهد که به خوبی با چرخه عمر توسعه مهندسی مطابقت داشته باشد. برای آن به یک IDE کامل نیاز ندارید.

تایسون: مشتاقانه منتظرم ببینم شما و تیم سازنده ویراستار را کجا خواهید برد. و به عنوان یک کدنویس، نمی توانم صبر کنم تا Qwik 1.0 را به دست بیاورم.

دوباره از وقتی که در اختیار گذاشتید متشکرم، میسکو.