قیمت فریمورک های جاوا اسکریپت

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

• دانلود فایل از طریق شبکه
• تجزیه و کامپایل کد منبع بدون بسته بندی پس از دانلود.
• اجرای کد جاوا اسکریپت
• مصرف حافظه

این ترکیب معلوم می شود بسیار گران قیمت.

و ما کدهای JS بیشتری را در پروژه های خود اضافه می کنیم. همانطور که سازمان‌ها به سمت سایت‌هایی می‌روند که از چارچوب‌ها و کتابخانه‌هایی مانند React، Vue و دیگران پشتیبانی می‌کنند، ما عملکرد اصلی سایت‌ها را به شدت به جاوا اسکریپت وابسته می‌کنیم.

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

این پروژه به من کمک کرد تا این را بفهمم. بایگانی HTTP.

اطلاعات

پروژه HTTP Archive در مجموع 4308655 لینک به سایت های دسکتاپ معمولی و 5484239 لینک به سایت های موبایل را ردیابی می کند. در میان بسیاری از معیارهای مرتبط با این پیوندها، فهرستی از فناوری های موجود در سایت های مربوطه وجود دارد. این بدان معناست که ما می‌توانیم هزاران سایتی را که از چارچوب‌ها و کتابخانه‌های مختلف استفاده می‌کنند نمونه‌برداری کنیم و از میزان کد ارسالی آنها به مشتریان و میزان بارگذاری این کد در سیستم‌های کاربران مطلع شویم.

من داده‌های مارس 2020 را جمع‌آوری کردم، که جدیدترین داده‌ای بود که به آن دسترسی داشتم.

تصمیم گرفتم داده‌های بایگانی HTTP را در همه سایت‌ها با داده‌های سایت‌هایی که با استفاده از React، Vue، و Angular پیدا شده‌اند مقایسه کنم، اگرچه در نظر داشتم از منابع دیگر نیز استفاده کنم.

برای جالب‌تر کردن آن، سایت‌هایی را نیز به مجموعه داده‌های منبع اضافه کردم که از jQuery استفاده می‌کنند. این کتابخانه هنوز هم بسیار محبوب است. همچنین رویکرد متفاوتی را برای توسعه وب نسبت به مدل Single Page Application (SPA) ارائه شده توسط React، Vue و Angular معرفی می کند.

پیوندهایی در آرشیو HTTP که نشان دهنده سایت هایی است که مشخص شده است از فناوری های مورد علاقه استفاده می کنند

چارچوب یا کتابخانه
لینک به سایت های موبایل
لینک به سایت های معمولی

جی کوئری
4615474
3714643

واکنش نشان می دهند
489827
241023

VUE
85649
43691

گوشه دار
19423
18088

امیدها و آرزوها

قبل از اینکه به تجزیه و تحلیل داده ها بپردازیم، می خواهم در مورد آنچه می خواهم به آن امیدوار باشم صحبت کنم.

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

بنابراین، در یک دنیای ایده آل، نوعی چارچوب باید ایجاد یک سایت با کارایی بالا را آسان کند. این باید یا به دلیل این واقعیت انجام شود که چارچوب به توسعه دهنده یک پایه مناسب برای ساخت یک پروژه می دهد، یا به دلیل این واقعیت که محدودیت هایی را برای توسعه اعمال می کند، الزاماتی را برای آن مطرح می کند که توسعه چیزی را که تبدیل می شود پیچیده می کند. کند بودن

بهترین چارچوب ها باید هر دو را انجام دهند: پایه خوبی ارائه دهند، و محدودیت هایی را در کار اعمال کنند، که به شما امکان می دهد به نتیجه مناسبی برسید.

تجزیه و تحلیل مقادیر میانه داده ها اطلاعات مورد نیاز را در اختیار ما قرار نمی دهد. و در واقع، این رویکرد از توجه ما خارج می شود خیلی مهمه. در عوض، درصدهایی را از داده‌هایی که داشتم به دست آوردم. اینها 10، 25، 50 (میانگین)، 75، 90 صدک هستند.

من به صدک 10 و 90 علاقه خاصی دارم. صدک 10 بهترین عملکرد (یا حداقل کم و بیش نزدیک به بهترین) را برای یک چارچوب خاص نشان می دهد. به عبارت دیگر، این بدان معناست که تنها 10 درصد از سایت هایی که از یک چارچوب خاص استفاده می کنند به این سطح یا بالاتر می رسند. از سوی دیگر، صدک 90، روی دیگر سکه است - به ما نشان می دهد که اوضاع چقدر می تواند بد شود. صدک 90، سایت‌هایی است که عقب مانده‌اند، آن دسته از 10 درصد پایین سایت‌هایی که بیشترین کد JS یا طولانی‌ترین زمان پردازش کد خود را در رشته اصلی دارند.

حجم کد جاوا اسکریپت

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

مقدار کد جاوا اسکریپت (Kb) منتقل شده به دستگاه های تلفن همراه

صدک
10
25
50
75
90

همه سایت ها
93.4 
196.6 
413.5 
746.8 
1201.6 

سایت های جی کوئری
110.3 
219.8 
430.4 
748.6 
1162.3 

سایت های Vue
244.7 
409.3 
692.1 
1065.5 
1570.7 

سایت های زاویه ای
445.1 
675.6 
1066.4 
1761.5 
2893.2 

React Sites
345.8 
441.6 
690.3 
1238.5 
1893.6 

مقدار کد جاوا اسکریپت ارسال شده به دستگاه های تلفن همراه

مقدار کد جاوا اسکریپت (Kb) منتقل شده به دستگاه های دسکتاپ

صدک
10
25
50
75
90

همه سایت ها
105.5 
226.6 
450.4 
808.8 
1267.3 

سایت های جی کوئری
121.7 
242.2 
458.3 
803.4 
1235.3 

سایت های Vue
248.0 
420.1 
718.0 
1122.5 
1643.1 

سایت های زاویه ای
468.8 
716.9 
1144.2 
1930.0 
3283.1 

React Sites
308.6 
469.0 
841.9 
1472.2 
2197.8 

مقدار کد جاوا اسکریپت ارسال شده به دستگاه های دسکتاپ

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

آنچه در مورد این داده ها قابل توجه است این است که برخی از چارچوب ها و کتابخانه ها را می توان نقطه شروع بهتری برای یک پروژه نسبت به سایرین در نظر گرفت. سایت های دارای jQuery بهترین به نظر می رسند. در نسخه‌های دسکتاپ سایت‌ها، 15 درصد بیشتر از همه سایت‌ها جاوا اسکریپت دارند و در تلفن همراه، 18 درصد بیشتر است. (البته، در اینجا مقداری خرابی داده وجود دارد. واقعیت این است که jQuery در بسیاری از سایت ها وجود دارد، بنابراین طبیعی است که این گونه سایت ها بیشتر از سایرین با تعداد کل سایت ها مرتبط هستند. با این حال، این روی خام بودن تأثیری نمی گذارد. داده ها برای هر چارچوب خروجی است.)

در حالی که افزایش 15 تا 18 درصدی در حجم کد یک رقم قابل توجه است، در مقایسه با سایر چارچوب ها و کتابخانه ها، می توان نتیجه گرفت که "مالیات" اخذ شده توسط jQuery بسیار پایین است. سایت های زاویه ای در صدک دهم 10 درصد بیشتر از همه سایت ها به دسکتاپ داده و 344 درصد بیشتر به موبایل ارسال می کنند. سایت‌های React سنگین‌ترین سایت‌های بعدی هستند که ۱۹۳ درصد بیشتر از همه سایت‌ها به دسکتاپ کد ارسال می‌کنند و ۲۷۰ درصد بیشتر برای موبایل.

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

جالب اینجاست که سایت های جی کوئری از این ایده پیروی می کنند. در حالی که آنها کمی سنگین تر از همه سایت ها در صدک 10 هستند (15-18٪)، در صدک 90 کمی سبک تر هستند و در حدود 3٪ هم در دسکتاپ و هم در تلفن همراه هستند. این به این معنی نیست که این یک مزیت بسیار قابل توجه است، اما می توان گفت که سایت های جی کوئری، حداقل، اندازه کدهای جاوا اسکریپت بزرگی را حتی در بزرگترین نسخه های خود ندارند.

اما در مورد سایر فریم ورک ها نمی توان همین را گفت.

درست مانند مورد صدک 10، سایت های صدک 90 در Angular و React با سایت های دیگر متفاوت هستند، اما متأسفانه برای بدتر تفاوت دارند.

در صدک 90، سایت های انگولار 141 درصد بیشتر از همه سایت ها به موبایل داده و 159 درصد بیشتر به دسکتاپ ارسال می کنند. سایت های React 73 درصد بیشتر از همه سایت ها به دسکتاپ و 58 درصد بیشتر به موبایل ارسال می کنند. اندازه کد سایت های React در صدک 90 2197.8 کیلوبایت است. این بدان معناست که چنین سایت‌هایی 322.9 کیلوبایت داده بیشتری را نسبت به نزدیک‌ترین رقبای خود بر اساس Vue به دستگاه‌های تلفن همراه ارسال می‌کنند. شکاف بین سایت های دسکتاپ مبتنی بر Angular و React با سایت های دیگر حتی بیشتر است. به عنوان مثال، سایت های دسکتاپ React نسبت به سایت های مشابه Vue، 554.7 کیلوبایت کد JS بیشتری را به دستگاه ها ارسال می کنند.

زمان صرف شده برای پردازش کد جاوا اسکریپت در موضوع اصلی

داده های بالا به وضوح نشان می دهد که سایت هایی که از چارچوب ها و کتابخانه های مورد مطالعه استفاده می کنند حاوی مقادیر زیادی کد جاوا اسکریپت هستند. اما البته، این تنها بخشی از معادله ما است.

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

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

زمان پردازنده (بر حسب میلی ثانیه) مربوط به پردازش اسکریپت در دستگاه های تلفن همراه

صدک
10
25
50
75
90

همه سایت ها
356.4
959.7
2372.1
5367.3
10485.8

سایت های جی کوئری
575.3
1147.4
2555.9
5511.0
10349.4

سایت های Vue
1130.0
2087.9
4100.4
7676.1
12849.4

سایت های زاویه ای
1471.3
2380.1
4118.6
7450.8
13296.4

React Sites
2700.1
5090.3
9287.6
14509.6
20813.3

زمان پردازشگر مربوط به پردازش اسکریپت در دستگاه های تلفن همراه

زمان پردازنده (بر حسب میلی ثانیه) مربوط به پردازش اسکریپت در دستگاه های دسکتاپ

صدک
10
25
50
75
90

همه سایت ها
146.0
351.8
831.0
1739.8
3236.8

سایت های جی کوئری
199.6
399.2
877.5
1779.9
3215.5

سایت های Vue
350.4
650.8
1280.7
2388.5
4010.8

سایت های زاویه ای
482.2
777.9
1365.5
2400.6
4171.8

React Sites
508.0
1045.6
2121.1
4235.1
7444.3

زمان پردازنده مربوط به پردازش اسکریپت در دستگاه های دسکتاپ

در اینجا می توانید چیزی بسیار آشنا را ببینید.

برای شروع، سایت‌های دارای jQuery نسبت به سایر سایت‌ها به میزان قابل توجهی کمتر برای پردازش جاوا اسکریپت در رشته اصلی هزینه می‌کنند. در صدک دهم، در مقایسه با همه سایت‌ها، سایت‌های jQuery روی موبایل 10 درصد زمان بیشتری را برای پردازش کد JS در موضوع اصلی صرف می‌کنند. در مورد سایت های دسکتاپ جی کوئری، زمان پردازش 61 درصد افزایش می یابد. در صدک 37، سایت های جی کوئری امتیاز بسیار نزدیکی به امتیازات کل دارند. به طور خاص، سایت های جی کوئری در دستگاه های تلفن همراه 90٪ زمان کمتری را در موضوع اصلی نسبت به همه سایت ها و 1.3٪ زمان کمتری را در دستگاه های دسکتاپ صرف می کنند.

در طرف دیگر رتبه بندی ما، فریم ورک هایی هستند که با بالاترین بار روی رشته اصلی مشخص می شوند. این دوباره Angular و React است. تنها تفاوت بین این دو این است که در حالی که سایت‌های Angular کد بیشتری را نسبت به سایت‌های React به مرورگرها ارسال می‌کنند، سایت‌های Angular زمان کمتری از CPU برای پردازش کد می‌گیرند. خیلی کمتر

در صدک دهم، سایت‌های Desktop Angular 10 درصد بیشتر از همه سایت‌ها زمان بیشتری را برای پردازش کد JS موضوع اصلی صرف می‌کنند. برای سایت های موبایل این رقم 230 درصد است. سایت های React بدترین عملکرد را دارند. در دسکتاپ، آنها 313٪ بیشتر از همه سایت ها زمان بیشتری را برای پردازش کد و 248٪ بیشتر در تلفن همراه صرف می کنند. 658% اشتباه تایپی نیست. در صدک 658، سایت های React 10 ثانیه از زمان موضوع اصلی را صرف پردازش کد خود می کنند.

صدک 90 وقتی با این اعداد بزرگ مقایسه می شود، حداقل کمی بهتر به نظر می رسد. در مقایسه با همه سایت‌ها، پروژه‌های Angular 29 درصد زمان بیشتری را روی دستگاه‌های دسکتاپ در موضوع اصلی و 27 درصد زمان بیشتری را در دستگاه‌های تلفن همراه صرف می‌کنند. در مورد سایت های React، همین ارقام به ترتیب 130 و 98 درصد به نظر می رسند.

درصد انحراف برای صدک 90 بهتر از مقادیر مشابه برای صدک 10 به نظر می رسد. اما در اینجا لازم به یادآوری است که اعداد نشان دهنده زمان نسبتاً ترسناک به نظر می رسند. فرض کنید 20.8 ثانیه در تاپیک اصلی موبایل برای وب سایتی که با React ساخته شده است. (من فکر می کنم داستان آنچه در این مدت واقعاً اتفاق می افتد شایسته یک مقاله جداگانه است).

یک عارضه بالقوه در اینجا وجود دارد (با تشکر جرمی برای جلب توجه من به این ویژگی، و برای بررسی دقیق داده ها از این دیدگاه). واقعیت این است که بسیاری از سایت ها از چندین ابزار فرانت اند استفاده می کنند. به طور خاص، من سایت‌های زیادی را دیده‌ام که از jQuery در کنار React یا Vue استفاده می‌کنند، زیرا آن سایت‌ها از jQuery به چارچوب‌ها یا کتابخانه‌های دیگر مهاجرت می‌کنند. در نتیجه، من دوباره به پایگاه داده ضربه زدم، این بار فقط پیوندهایی را انتخاب کردم که مربوط به سایت هایی هستند که فقط از React، jQuery، Angular یا Vue استفاده می کنند، اما نه ترکیبی از آنها. این چیزی است که من دریافت کردم.

زمان پردازشگر (بر حسب میلی ثانیه) مربوط به پردازش اسکریپت ها در دستگاه های تلفن همراه در شرایطی که سایت ها فقط از یک چارچوب یا فقط یک کتابخانه استفاده می کنند.

صدک
10
25
50
75
90

سایت هایی که فقط از jQuery استفاده می کنند
542.9
1062.2
2297.4
4769.7
8718.2

سایت هایی که فقط از Vue استفاده می کنند
944.0
1716.3
3194.7
5959.6
9843.8

سایت هایی که فقط از Angular استفاده می کنند
1328.9
2151.9
3695.3
6629.3
11607.7

سایت هایی که فقط از React استفاده می کنند
2443.2
4620.5
10061.4
17074.3
24956.3

زمان پردازشگر مربوط به پردازش اسکریپت ها در دستگاه های تلفن همراه در شرایطی که سایت ها فقط از یک چارچوب یا فقط یک کتابخانه استفاده می کنند.

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

در واقع، عملکرد هر یک از ابزارهای front-end مورد مطالعه در همه موارد بهتر به نظر می رسد، به جز یک استثناء عجیب. چیزی که من را شگفت زده کرد این بود که در صدک 50 و بالاتر، سایت هایی که از React استفاده می کنند، زمانی که React تنها کتابخانه ای است که استفاده می کنند، عملکرد بدتری دارند. اتفاقاً این دلیلی بود که من این داده ها را در اینجا ارائه کردم.

این کمی عجیب است، اما من همچنان سعی می کنم به دنبال توضیحی برای این عجیب باشم.

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

اما با انتقال پروژه از jQuery به React و تکیه بیشتر بر React، همه چیز در حال تغییر است. اگر سایت واقعاً باکیفیت باشد و توسعه دهندگان سایت با دقت از React استفاده کنند، با چنین سایتی همه چیز خوب خواهد بود. اما برای یک سایت متوسط ​​React، استفاده گسترده از React به این معنی است که رشته اصلی تحت بار سنگین است.

شکاف بین دستگاه های موبایل و دسکتاپ

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

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

افزایش زمان (درصد) مربوط به پردازش اسکریپت ها در دستگاه های تلفن همراه در مقایسه با دسکتاپ

صدک
10
25
50
75
90

همه سایت ها
144.1
172.8
185.5
208.5
224.0

سایت های جی کوئری
188.2
187.4
191.3
209.6
221.9

سایت های Vue
222.5
220.8
220.2
221.4
220.4

سایت های زاویه ای
205.1
206.0
201.6
210.4
218.7

React Sites
431.5
386.8
337.9
242.6
179.6

در حالی که می‌توان انتظار داشت که تفاوتی در سرعت پردازش کد بین تلفن و لپ‌تاپ وجود داشته باشد، چنین اعداد زیادی به من می‌گویند که فریمورک‌های مدرن به اندازه کافی برای دستگاه‌های کم مصرف مورد هدف قرار نمی‌گیرند و تلاش می‌کنند تا شکافی را که کشف کرده‌اند ببندند. حتی در صدک دهم، سایت‌های React 10 درصد زمان بیشتری را در رشته اصلی موبایل نسبت به رشته اصلی دسکتاپ صرف می‌کنند. jQuery کمترین شکاف را دارد، اما حتی در اینجا نیز رقم مربوطه 431.5٪ است. وقتی توسعه دهندگان وب سایت پروژه های خود را به گونه ای می سازند که پردازش آنها به زمان پردازشگر بیشتری نیاز دارد (و این اتفاق می افتد و با گذشت زمان بدتر می شود)، صاحبان دستگاه های کم مصرف باید هزینه آن را بپردازند.

نمایش نتایج: از

چارچوب های خوب باید به توسعه دهندگان پایه خوبی برای ساخت پروژه های وب (از نظر امنیت، دسترسی، عملکرد) بدهند، یا باید محدودیت های داخلی داشته باشند که ساختن چیزی را که این محدودیت ها را نقض می کند دشوار می کند.

به نظر نمی رسد که این در مورد عملکرد پروژه های وب (و احتمالاً در مورد آنها) صدق نمی کند دسترسی).

شایان ذکر است که صرفاً به این دلیل که سایت‌های React یا Angular زمان بیشتری را برای تهیه کد نسبت به سایرین صرف می‌کنند، لزوماً به این معنی نیست که سایت‌های React در حین اجرا نسبت به سایت‌های Vue از CPU فشرده‌تر هستند. در واقع، داده‌هایی که ما بررسی کرده‌ایم، اطلاعات کمی در مورد عملکرد عملیاتی چارچوب‌ها و کتابخانه‌ها نشان می‌دهند. آنها بیشتر در مورد رویکردهای توسعه صحبت می کنند که آگاهانه یا غیر آگاهانه، این چارچوب ها می توانند برنامه نویسان را تحت فشار قرار دهند. ما در مورد اسناد چارچوب ها، در مورد اکوسیستم آنها، در مورد تکنیک های توسعه رایج صحبت می کنیم.

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

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

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

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

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

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

• خود را با عقل سلیم آزمایش کنید. آیا واقعاً نیاز به استفاده از چارچوب انتخابی دارید؟ جاوا اسکریپت خالص امروزه توانایی زیادی دارد.
• آیا جایگزین سبک تری برای فریم ورک انتخاب شده (مانند Preact، Svelte یا چیز دیگری) وجود دارد که بتواند 90 درصد از قابلیت های این فریم ورک را در اختیار شما قرار دهد؟
• اگر قبلاً از یک چارچوب استفاده می‌کنید، در نظر بگیرید که آیا چیزی وجود دارد که گزینه‌های بهتر، محافظه‌کارانه‌تر و استاندارد را ارائه می‌دهد (مثلاً Nuxt.js به جای Vue، Next.js به جای React و غیره).
• شما چه خواهد شد بودجه عملکرد جاوا اسکریپت؟
• چگونه می توانید محدود کردن یک فرآیند توسعه برای اینکه تزریق کد جاوا اسکریپت بیشتر از حد ضروری به پروژه را دشوارتر کند؟
• اگر از چارچوبی برای سهولت توسعه استفاده می کنید، در نظر بگیرید آیا نیاز دارید ارسال کد فریمورک به مشتریان شاید بتوانید تمام مشکلات سرور را حل کنید؟

معمولاً این ایده ها ارزش دیدن دارند، صرف نظر از اینکه دقیقاً چه چیزی را برای توسعه front-end انتخاب کرده اید. اما زمانی که روی پروژه ای کار می کنید که از همان ابتدا فاقد عملکرد است، اهمیت ویژه ای دارند.

خوانندگان عزیز! چارچوب ایده آل جاوا اسکریپت را چگونه می بینید؟

منبع: www.habr.com