Reddit - javascript - Структура JavaScript, яка розміщує веб-сторінки на дієті

+1
Мене спокушає звивистий і твердий, але відсутність екосистеми змусило мене схилятися до Preact.

reddit

FWIW, багато з них у лівій частині таблиці жертвують правильністю і навіть досвідом розробника в ім'я продуктивності. Не зовсім впевнений, у чому сенс можливості стверджувати, що реалізація є "швидкою", якщо її бракує майже у кожному іншому вимірі.

Особливо, якщо "продуктивність" - це лише еталонна цифра і взагалі не перекладається на досвід користувачів. Яка ІМО - більшість із них.

Який ваш вибір?

для своїх власних речей я використовую одну, яку я вже писав [1], але я б не рекомендував її для великих команд, команд з різними наборами навичок/спеціалізацій або для тих, хто не готовий використовувати власні погляди/компоненти.

загалом я люблю дотримуватися чистого js, тому я більше шанувальник гіперскрипту над JSX або навіть важчими DSL. цікаві деякі нові спостережувані безвудові основи, засновані на ідеях S.js (надлишки, тверді, звивисті, велли), хоча більшість із цієї парадигми борються за регідратацію DOM SSR, що, на мою думку, важливо, якщо Ви створюєте веб-сайт, який потребує хороших SEO-можливостей.

одне, що я бачу з популярних рамок, - це те, наскільки сильно вони розростаються. можливо, це просто тому, що компоненти в цій екосистемі, як правило, не мінімальні, але, як правило, великі і підтримують багато випадків, що робить їх обох популярними, але також насиченими функціями. можливо, це пов'язано з тим, що величезні команди розробляють додатки, або різними знаннями величезної бази користувачів. занадто просто поєднати 20 популярних схвалених екосистемою компонентів, щоб отримати MVP, який становить 500 Мб залежностей компонентів, а потім лише зростає звідти. Я вже просив, щоб хтось вказував мені на загальнодоступний веб-сайт, побудований за допомогою React або Vue, який насправді є швидким (як вимірюється об'єктивно розробниками, а не суб'єктивно людьми, як "завантаження в світловідбиваючомуСінглтон · 255d

для власних речей я використовую одну, яку я написав

Колись я це сам робив. кілька років тому: http://footworkjs.com/

. на основі нокауту на той момент.

Я настійно рекомендую нікому не використовувати власну структуру. навіть для особистих проектів.

Якщо ви хочете написати такий для розширення набору навичок, тоді чудово, що працює (і в підсумку я отримав те, що я отримав із досвіду). Але якщо ви схожі на мене, витрачаєте непомірну кількість часу на основи, які в кінцевому підсумку використовуються лише вами або, можливо, одним чи двома іншими. просто не робіть. є краще використання вашого часу.

це дійсний пункт. але контрапунктом є те, що якби всі просто використовували існуючі/популярні фреймворки, то всі б ще були на jQuery.

Здається, робота над ногами подовжує Нокаут і продається як більш повна структура. навіть сам нокаут є вищим за domvm, оскільки забезпечує прив'язку даних та синтаксичний аналіз шаблону.

domvm ближче до React, оскільки це просто шар vdom, який забезпечує ізоляцію компонентів, необов'язковий приватний стан і vdom. це також не нова бібліотека, і вона була написана, коли DX, який я шукав, був наданий лише Mithril (крихітний, pure-js, впадаючий jQuery без необхідності node, Babel і 500 МБ node_modules). domvm скинув маршрутизацію, додав SSR з регідратацією, стан приватного компонента, ізольоване перемальовування та був меншим та швидшим, ніж Mithril та React (і все ще є).

якби я почав сьогодні, було б досить безглуздо створити власний шар vdom, оскільки зараз існує багато хороших варіантів, які відповідають вимогам, яких я хотів, і тоді, і зараз.

але контрапунктом є те, що якби всі просто використовували існуючі/популярні фреймворки, то всі б ще були на jQuery.

Це не означає, що кожен повинен бігти і писати власну структуру.

Я також вважав, що моя реалізація компонентів, що дозволяє автозавантаження модулів, і моє рішення щодо управління станом було новим і "кращим", ніж те, що було там.

Те, що я зрозумів пізніше. було кілька речей:

  • Не упереджуйте інші рамки/бібліотеки, перш ніж глибоко їх зрозуміти. Потрібні фактичні інвестиції у вивчення чогось, написання хорошої частини коду (не просто привіт-світ/тощо), щоб знати, чи варто це чи ні.
  • Працювати з іншими розробниками означає не писати власні одноразові рішення в 99,9999% випадків. Вам буде важко зібрати команду навколо вашого улюбленого домашнього пивоварного середовища/бібліотеки.