Vue vs React - Част 0: Изтъняване на стадото

В тази серия демонстрирам някои от основните разлики в опита на развитие между използването на Vue и React за постигане на едни и същи резултати.

Съдържание

Част 0: Изтъняване на стадото

Част 1: По числата

Част 2: Основни компоненти

Част 3: Разширени компоненти

Част 4: Разширено управление на държавата с Vuex и React-Redux

Част 5: Време за вземане на решение

Наскоро бях поставена задача да избера библиотека на компонентите от предния край за бъдещето на нашия продукт по време на работа. Започнах със списък от опции и бързо го филтрирах до Vue и React.

Ъглова - крива на обучение

Както е при всяка пълноценна рамка, Angular има голяма крива на обучение. Докато четях документите им, гледах видео уроци и сравнявах еквивалентен код от други библиотеки, отнемаше последователно повече време, за да разбера ъгловия начин. Може би това говори повече за мен, отколкото за Angular, но все пак това е заключението, до което стигнах.

Примери за допълнителна сложност съществуват в архитектурата на приложенията, дефинициите на компоненти и дори обвързването на шаблони. Може би един от най-големите закачалки за хора, които все още не са запознати с него, е използването на Angular от инжектиране на зависимост.

Инжектиране на зависимостта

За много разработчици една от причините Angular е по-трудна за научаване от някои алтернативи е инжектирането на зависимост. Най-общо казано, когато създава модул, този модул е ​​отговорен за вноса и консумацията на собствените си зависимости. Въпреки това, Angular обхваща модел на дизайн, наречен „инверсия на контрола“, който прави приложението отговорно за инжектиране на зависимости в дочерните компоненти.

Основното предимство на инжектирането на зависимост е лекотата на тестване - тъй като имате контрол върху това какви зависимости се инжектират във вашите модули, можете лесно да предавате макети, когато тествате. Въпреки че е ценно, това допълнително удобство при тестване идва с цената на четим код. При този модел компонентите разчитат на зависимости, които не са импортирали, предоставени им от допълнителен слой логика на приложение. Изискването на разработчиците да възприемат този модел на дизайн, за да бъдат продуктивни, е едно от нещата, които правят Angular 'труден.

Ами ако бихме могли да имаме най-доброто от двата свята? Ами ако бихме могли да напишем нашите компоненти по стандартния за индустрията начин, при който всеки компонент импортира свои собствени зависимости, като същевременно се наслаждава на тестовите предимства на инжектирането на зависимост? За щастие, Jest ни покри! Jest осигурява средство за прихващане на импортирането и изискване на декларации и замяна на тях с макети. Инжектирането на зависимостта не изисква да пишете кода си по различен начин. Ето няколко демонстрации.

решение

Кривата на учене на ъгъл е по-висока на няколко места, отколкото смятам, че трябва да бъде. Значителна част от тази крива на обучение е овладяване на инжектирането на зависимост и допълнителния слой на приложение, който се изисква. Според мен инверсията на контрола е тромав дизайн, който компенсира себе си, като прави приложението ви тест. Въпреки това, Jest ми позволява да напиша тестова кодова база, без да се налага да се огъвам към тромав дизайн.

Поради притесненията относно размера на изтеглянето, няколко проблема с кривата на учене и не искам да се занимавам с рамка, изградена около инжектиране на зависимост, избрах да се откажа от Angular.

Svelte и Stencil - до скоро

Svelte и Stencil са наистина иновативни технологии.

Не можете да пишете сериозни приложения във ванилов JavaScript, без да удряте стената на сложност. Но компилатор може да го направи вместо вас. - Блог Svelte

Ето идеята. Вие пишете кода си по чист, четим начин и Svelte / Stencil го компилира в нещо мъничко, бързо и ванилиращо. Сериозно можете да използвате тези компоненти с всяка рамка или библиотека. И работи изключително добре! Това отнема време на изпълнение, което обикновено трябва да изтеглите, и да го резюмирате в стъпка на изграждане.

И какво не е наред със Svelte? Едно от основните съображения при предприемането на бизнес с печалба в производството е общността. Има ли съществуващи компоненти? Има ли документи? Колко голям е екипът, който го поддържа? Ще мога ли да наема хора, които го знаят? Задаването на тези въпроси ви помага да избегнете риск.

Отговорите на повечето от тези въпроси не са достатъчно благоприятни, за да напишете цялостно приложение, използвайки Svelte. Малък пример: Svelte няма собствен рутер и няма добро виртуално изпълнение на превъртане. Да, знам, че има отлични опции, които не се предлагат, като PageJS и Navigo. Но това показва в малък мащаб, че няма надеждно поддържано от първа страна решение за някои от основните строителни блокове за приложения - фундаментални градивни елементи, за които повечето екосистеми имат решения на първо ниво.

Същите проблеми се отнасят за Stencil - той просто още не е достатъчно зрял.

Сега, това, че изключваме използването на Svelte / Stencil за цялостно приложение, не означава, че ще ги изключим при писането на някои от нашите отделни компоненти. Всъщност използването им за някои от по-сложните ни споделяеми компоненти може да ни изолира от бъдещи промени, тъй като продукцията им е ванилия JS. Разбира се, това ще изисква моят екип да научи втора библиотека с нов компонент ... Ще преминем този мост, когато стигнем там.

решение

Според мен Svelte и Stencil все още не са достатъчно зрели, за да рискуват да ги използват за цялостно приложение. Вероятно ще оценим използването им за конкретни компоненти, когато дойде времето.

Проповядвайте - значи ми казвате, че има шанс

Бърза 3kB алтернатива на React със същия съвременен API. - Практикувайте Документи

Използвам Preact в личен проект повече от година и наистина ми хареса. Тъй като React все още е на масата и Preact е толкова подобен, има смисъл поне да го опитаме в случай, че отидем с React. Ето списък на разликите между двете.

Какво е добре за Preact?

  • Preact е една десета от размера на React. Това подобрява размера на пакета и времето за изпълнение.
  • Той е съвместим с API на React, така че можете да използвате Preact-compat, за да замените React for Preact в съществуващо приложение и то Just Works ™. Също така ви позволява да се насладите на цялата библиотека на компоненти на React (най-вече).
  • CLI му е страхотен, като осигурява на PWA код, базиран на маршрута, разделящ се извън кутията. Нещо повече, можете сами да конфигурирате неговия начален шаблон.

Какво е лошото в Preact?

  • Preact следва набор от функции на React. Това означава, че тя винаги стои зад най-новата версия на React.
  • preact-compat не винаги работи.
  • Документите на Preact са оскъдни, защото очакват да прочетете документите на React.

решение

На теория Preact е React с по-малко изтегляне и по-бързо изпълнение. Той дори има няколко хубави промени в API, като излагане на реквизити и състояние като аргументи на метода на изобразяване и позволяване на използването на клас за стилизиране (все още можете да използвате className).

Ако в края на тази поредица решим да продължим с React, бих искал да пробвам Preact. По този начин може да запазим стека си над главата, колкото е възможно по-малко, докато теоретично все още ни предоставя достъп до компонентната екосистема на React. И ако не се получи по някаква причина, рискът е малък - превръщането му в правилното React трябва да отнеме много малко време.

Продължете към Част 1:

Част 1: По числата