خالق Svelte: توسعه وب باید سرگرم کننده تر باشد

خالق Svelte، Rich Harris، MPAs در مقابل SPAs، برنامه‌ها در مقابل Docs، نیاز به یک چارچوب برنامه انتقالی، و راه درست برای ساخت وب‌سایت‌ها را بررسی می‌کند.

Svelte و چارچوب فول پشته آن، SvelteKit، با اندیشیدن خارج از چارچوب در رویکرد خود به توسعه جاوا اسکریپت، سروصدا به پا کرده اند و مورد تشویق قرار گرفته اند، از جمله جایزه بهترین نرم افزار منبع باز.

من اخیراً فرصتی داشتم تا با ریچ هریس، خالق Svelte، در مورد روندهای جاوا اسکریپت جلویی و مسیر پیش روی Svelte صحبت کنم. ما همچنین برنامه‌های چند صفحه‌ای در مقابل برنامه‌های تک صفحه‌ای، برنامه‌ها در مقابل اسناد، مفهوم «برنامه انتقالی» او و اجرای یک پروژه نرم‌افزار منبع باز، از جمله موارد دیگر را مورد بحث قرار دادیم.

متیو تایسون: بسیار متشکرم که برای صحبت کردن وقت گذاشتید. شما در نیویورک تایمز کار می کنید. آیا شما در نیویورک زندگی می کنید؟

ریچ هریس: من در واقع در نیویورک، در بروکلین زندگی می کنم. با این حال، من در واقع اخطار خود را در نیویورک تایمز تسلیم کردم و اکنون در تلاش هستم تا قبل از ترک همه مسئولیت‌هایم را انجام دهم. من در ۸ نوامبر یک Vercel را شروع می کنم.

تایسون: آه، Vercel با SvelteKit همکاری خوبی دارد. (Vercel یک پلت فرم تحویل جلویی است.) به یاد دارم که Vercel اخیراً پشتیبانی SvelteKit را اضافه کرده است.

هریس: SvelteKit تا حدودی از گیلرمو (Guillermo Rauch، مدیر عامل Vercel) الهام گرفته شده است، هم به این معنا که از Next.js الگوبرداری شده است (Next.js توسط Vercel نگهداری می شود) و زیرا گیلرمو خاطرنشان کرده بود که کاربران Vercel اغلب مطمئن نیستند که راه “مبارک” برای ساخت یک برنامه Svelte چیست.

تایسون: برای من جالب است که Svelte با موفقیت توانسته است وضعیت موجود، یعنی رفتن به زمان کامپایل را جبران کند. چگونه شما و تیم نگاه کردن به چیزها را به روش های جدید پرورش می دهید؟

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

ما به کار طراحی چارچوب به عنوان یک کار اساساً بازیگوش نزدیک می شویم. ما این کار را انجام می دهیم زیرا سرگرم کننده است و می خواهیم توسعه وب سرگرم کننده تر باشد. این به ما فضایی می‌دهد تا ایده‌های نسبتاً دور از ذهنی را سرگرم کنیم، که پس از یک فرآیند طولانی ریختن دوچرخه و اصلاح، اغلب به ویژگی‌های امضا تبدیل می‌شوند.

Tyson: ارگونومی استفاده از Svelte همان چیزی است که در ابتدا مرا به عنوان یک توسعه دهنده به سمت آن کشاند. آیا به پرورش تجربه توسعه دهنده توجه می کنید؟

هریس: ما انجام می دهیم. «تجربه توسعه‌دهنده» تقریباً یک کلمه کثیف در حلقه‌های خاص است، زیرا فرض می‌شود که در تضاد با تجربه کاربر نهایی است، که اولویت دارد، اما این لزوماً درست نیست، به‌خصوص زمانی که فضای راه‌حل بزرگ‌تری دارید که ذهنیت کامپایلر محور ارائه می‌کند. . Svelte تا حد زیادی آزمایشی برای به حداکثر رساندن UX بدون آسیب رساندن به DX و بالعکس است.

این همیشه درست نبود. قبل از نسخه ۳، DX کمی فکری بود. اما معلوم می شود که می توانید بهترین UX را در جهان داشته باشید و اصلاً مهم نیست مگر اینکه DX آنقدر خوب باشد که مردم واقعاً بخواهند از آن استفاده کنند. مردم Svelte 2 را تحمل کردند، اما آنها Svelte 3 را دوست دارند، و این انتشار زمانی بود که ما شروع به ایجاد امواج کردیم.

تایسون: در سخنرانی اخیر خود در Jamstack Conf 2021، این ظاهر را توضیح می دهید تضاد بین برنامه‌های چند صفحه‌ای (MPA) و برنامه‌های تک صفحه‌ای (SPA) و نحوه نگاه کردن به آن روش چندان ظریفی نیست. شما ایده “برنامه انتقالی” را به عنوان یک قطعنامه ارائه می دهید. آیا می‌خواهید به طور خلاصه در مورد منظورتان از یک برنامه انتقالی صحبت کنید، و اینکه SvelteKit چگونه در آن تصویر قرار می‌گیرد؟

هریس: افکار قبیله ای زیادی در مورد روش “درست” برای ساخت برنامه ها وجود دارد، و اخیراً این به عنوان شکافی بین اردوگاه های سنت گرا و مدرنیست که از ساخت MPA و SPA دفاع می کنند، آشکار شده است. به ترتیب. حداقل این کاریکاتور است.

واقعیت این است که اکثر فریم‌ورک‌ها بر روی مجموعه بسیار ظریف‌تری از هنجارها در مورد مواردی مانند محل زندگی منطق رندر شما همگرا می‌شوند، اما بحث در مورد این موارد به اندازه‌ای که می‌تواند سازنده باشد، نیست، زیرا این تفاوت‌های ظریف تمایل به ایجاد دارد. غرق شده توسط لفاظی مطلق گرایانه.

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

SvelteKit تلاش ما برای ایجاد یک چارچوب برنامه انتقالی است. این طراحی شده است تا بهترین راه ممکن برای ساخت یک برنامه Svelte برای اکثریت قریب به اتفاق افراد باشد. اما این اصطلاح چارچوب هایی مانند Next و Nuxt را نیز پوشش می دهد.

تایسون: یکی دیگر از زمینه‌های تضاد آشکاری که شناسایی می‌کنید، برنامه‌ها در مقابل اسناد است. آیا می‌خواهید نحوه نگاه شما و SvelteKit به این بخش را به شیوه‌ای سازنده‌تر توضیح دهید؟

هریس: من برای افرادی که اسناد و برنامه‌ها را چیزهایی کاملاً مجزا و با الزامات فناوری کاملاً متفاوت می‌دانند، موهایم را کمی کندم. تمام هدف رسانه های تعاملی این است که اسناد می توانند برنامه مانند باشند!

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

اسناد و برنامه‌ها صرفاً قطب‌هایی در یک طیف هستند. اغلب اوقات پیش می‌آید که یک سایت منفرد ویژگی‌هایی را از سراسر آن طیف نشان دهد، بنابراین مهم است که ابزارهایی که استفاده می‌کنیم منعکس کننده آن باشند.

ایده‌آل افلاطونی چارچوب نویسندگی وب به شما این امکان را می‌دهد که سایت‌هایی بسازید بدون اینکه واقعاً نیازی به فکر کردن درباره «نوع» سایتی که می‌سازید داشته باشید. یکی از نمونه‌هایی از این که چگونه در عمل کار می‌کند، محدود کردن جاوا اسکریپت است که کاربران نهایی فقط به مواردی که برای قسمت‌های «appy» نیاز دارند، دانلود می‌کنند.

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

تایسون: اجازه دهید در مورد Wasm از شما بپرسم. پیش‌بینی می‌کنید چه تأثیری بر توسعه front-end به طور کلی داشته باشد، و به طور خاص، چقدر برای زبان‌های غیر JS مانند Java یا C که در فرانت‌اند استفاده می‌شوند، چقدر خواهد بود؟

هریس: من فکر می‌کنم مردم تمایل دارند تأثیر Wasm را بر توسعه‌ی فرانت‌اند بیش از حد ارزیابی کنند. Wasm شما را به یک مجادله کننده سریعتر دیوی تبدیل نمی کند. قطعاً فرصت های جدیدی را باز می کند. باورنکردنی است که ما اکنون می توانیم FFmpeg را در مرورگر اجرا کنیم. اما من پیش بینی نمی کنم که اکثر ما به طور منظم با آن تعامل داشته باشیم.

من با گفتن این موضوع خارج از حوزه تخصصی خود هستم. (این نظرات احتمالاً دو سال بعد به طرز ناامیدکننده ای ساده به نظر می رسند!) اما اکثر زبان های غیر JS مسلماً برای قسمت جلویی مناسب نیستند زیرا باینری های Wasm کمی درشت هستند، مگر اینکه از چیزی سطح پایین و بدون استفاده از یک زبانه استفاده کنید. stdlib بزرگ در برخی زمینه ها – بازی، ویرایش ویدیو، و غیره – این یک معامله ارزشمند است، اما نه در توسعه وب به طور کلی.

تایسون: می‌توانید کمی در مورد پشتیبانی SvelteKit از محیط‌های خروجی متعدد صحبت کنید؟

هریس: ما در اوایل متوجه شدیم که پشتیبانی از محیط‌های متعدد – به نحوی که از قابلیت‌های منحصربه‌فرد آنها نهایت استفاده را ببرد – ضروری است. در عصر حاضر، گره خوردن به یک پلتفرم یا فناوری خاص، مانند سرورهای Node یا Lambda، خوب نیست. به همین دلیل ما توانستیم چارچوب را به گونه‌ای طراحی کنیم که افراد بتوانند با تلاش بسیار کم، پشتیبانی خود خود را برای محیط‌های جدید اضافه کنند. هنوز مطمئناً جزئیاتی وجود دارد که باید به آنها پی ببریم، اما در کل موفقیت بزرگی بوده است و نمی توانم تصور کنم که چارچوب ها در آینده به شکل دیگری کار کنند.

تایسون: آیا توصیه ای برای افرادی که علاقه مند به ایجاد پروژه های منبع باز موفق هستند دارید؟

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

در نهایت، روی اسناد سرمایه گذاری کنید. بدیهی به نظر می رسد، اما اغلب یک فکر بعدی است، و مستندات خوب سود زیادی را به همراه خواهد داشت. در واقع من به Readme Driven Development اعتقاد زیادی دارم، یعنی نوشتن اسناد حتی قبل از نوشتن هر کدی. به این ترتیب، متوجه خواهید شد که چرا طراحی API شما قبل از اینکه روی آن سرمایه گذاری کنید بد است. بسیاری از توسعه دهندگان به جزئیات پیاده سازی وسواس می پردازند در حالی که از طراحی API غفلت می کنند، که کاملاً عقب مانده است. جزئیات پیاده‌سازی موقتی هستند، اما تغییر APIها بسیار سخت است.

تایسون: افکار عالی — متشکرم، ریچ. با آرزوی موفقیت برای شما در پست جدید خود در Vercel!

هریس: متشکرم!