Фактори
Повний список:
- 🕹️ Функціонал
- 🐞 Стабільність
- ⚡ Продуктивність
- 🎁 Пакетна екосистема
- 🌎 Спільнота
- 👶 Складність вивчення
- 📖 Документація
- 🔧 Інструменти
- 🏛️ Репутація
- 👫 Команда
- ⚖️ Сумісність
- 📈 Популярність
Розглядаємо важливість кожного фактору, а також визначаємо критерії, якими ви повинні керуватися при оцінці технології.
1. Функціонал
Найважливіша причина, з якої ви обрали саме цю технологію — її функціонал. Але тут важливо знати як далеко заходити.
React, мабуть, найбільш популярна фронт-енд бібліотека на цей момент, але більшість дорікань виникають через те, що такі речі, як роутинг та управління станом, лягають на плечі React-Router та Redux.
Фактично, Vue, як найбільший конкурент React, має тут суттєві переваги. Надаючи офіційні пакети для таких поширених потреб, він зумів реалізувати комплексне рішення та охопити багато проблем.
Знову ж таки, копніть глибше — і вас буде спіткати громіздкий та складний фреймворк, що намагається зробити все і всюди.
Тож іноді необхідний мінімалістичний підхід. Бібліотеки на зразок Lodash чи Ramda дозволять замінити ваші громіздкі вкладені цикли for на короткі функціональні вирази — і цього достатньо, щоб зробити з них безцінні інструменти.
Знову ж таки, це все про знаходження «золотої середини».
Оцінка:
А— Дає можливість робити те, що було неможливо.
В — Ви можете робити ті ж речі, що і раніше, але краще.
С — Надає менше можливостей, ніж з попередньою технологією.
2. Стабільність
У вас може бути найбільш елегантний та багатофункціональний фреймворк, але це не має значення, якщо кожні дві хвилини трапляються помилки.
З цієї причини багато інструментів у JavaScript екосистемі фокусуються на стабільності та безпеці. Не треба далеко ходити: це вже звичні успішні TypeScript та Flow або навіть мови, на зразок Reason.
І стосовно рівня даних, система типів GraphQL також турбується про те, щоб усе працювало добре.
Оцінка:
А— Менше багів, легше розв'язувати проблеми та проводити налагодження.
В — Впроваджена технологія не впливає на стабільність роботи ПЗ.
С — Наслідком застосування технології стали нові баги.
3. Продуктивність
Якщо ви коли-небудь мали справу з бойовими мистецтвами, ви знаєте, що вашою найкращою перевагою є швидкість, а не сила.
Аналогічно: уся чудова функціональність марна, якщо ваш застосунок завантажується 15 секунд. За цей час користувач вже закрив вкладку — і ви програли бій, так його і не почавши!
В екосистемі JavaScript, яскравим прикладом зосередженості на швидкості є Preact: його API ідентичний React, тому він не намагається конкурувати за критерієм функціоналу. Preact є легшим та швидшим за React, що дозволяє зберегти безцінні мілісекунди та покращити продуктивність вашого веб-застосунку.
Оцінка:
А— Більш легка збірка, більш швидке завантаження або інші покращення продуктивності.
В — Впроваджена технологія не впливає на продуктивність програмного забезпечення.
С — Технологія уповільнює ваш застосунок.
4. Пакетна екосистема
Перед тим, щоб інвестувати час у будь-яку нову технологію, варто оглянути екосистему, що склалася навколо неї.
Розвинута екосистема-не лише величезна економія часу завдяки роботі інших, це ще й ознака того, що технологія досягла певного рівня зрілості. З цієї причини, добре підтримувані сторонні пакети свідчать про те, що розробники розглядають цю технологію у довгостроковій перспективі.
Оцінка:
А— Екосистема має однозначні рішення для загальних проблем; сторонні пакети добре підтримуються та документуються.
В — Перспективна пакетна екосистема з альтернативними можливостями.
С — Немає екосистеми пакетів, необхідно багато ручної роботи.
5. Спільнота
Інший фактор, який варто оглянути — загальна спільнота. Спеціальний форум або канал у Slack може стати у пригоді у разі проблем
(Spectrum — «золота середина» між чатами та традиційними форумами)
Також корисно мати репозиторій відповідей зі Stack Overflow для пошуку. Та обов'язково, добре підтримувана сторінка з переліченими проблемами на GitHub.
Оцінка:
А— Форум і/або чат (Slack/Discord/тощо) зі щоденною активністю, GitHub issues, що вирішуються протягом дня. Відповіді на питання на Stack Overflow.
В — Форум і/або чат з непостійною активністю.
С — Відсутність спільноти поза GitHub.
6. Складність вивчення
Простота у засвоєнні бібліотеки збільшує її популярність серед розробників. Дехто вважає, що розробники намагатимуться будь-що освоїти складну технологію, якщо вона революційна, але часто це не так.
Близьким поняттям до кривої вивчення є крива "прийняття". При першому запуску Meteor був надзвичайно простий у використанні (у порівнянні з іншими альтернативами), але він вимагав прийняти увесь стек технологій одразу, що ускладнює його застосування до наявних проектів.
React також відомий важкою кривою засвоєння: для розробників, що розділяли HTML та JavaScript, використання JSX може бути нелегкою справою. З іншого боку, з Vue почати набагато легше, тому що не треба переосмислювати ваш підхід до фронт-енд розробки.
Оцінка:
А— Можливо розпочати роботу за один день.
В — Необхідно близько тижня для початку роботи.
С — Необхідно більше ніж тиждень для засвоєння основ.
7. Документація
Важливою частиною освоєння нової технології є зрозуміла документація. Насправді, створення гарної документації — складніше, ніж здається, тому що автори документацій, зазвичай, мають найбільше досвіду в даній технології. Вони пішли набагато далі, ніж ті, хто тільки починають знайомство з бібліотекою.
Тож написання зрозумілої документації вимагає від автора забути на мить те, що він знає та уявити себе новачком.
(Документація Vue.js поєднує гарний дизайн з багатим наповненням)
Також необхідно враховувати розповсюджені проблеми, розуміти спосіб мислення користувачів та бути наготові у разі будь-яких змін. І все це займає багато дорогоцінного часу і відволікає від написання коду...
Таким чином, ви можете зрозуміти чому гарна документація — цінний інструмент, який зустрічається досить рідко.
Оцінка:
А— Сайт, присвячений документації, скріншоти, приклади проектів, покрокові інструкції, API документація та добре коментований код.
В — Базовий ReadMe та API документація.
С — Дуже стислий ReadMe; єдиною можливістю дізнатися про особливості використання бібліотеки — ознайомитись з кодом.
8. Інструменти
Може здатися, що, як і документація, інструменти відіграють другорядну роль у підтримці бібліотеки, однак вони надзвичайно важливі для утвердження успіху та популярності технології.
(Redux's DevTools вже заслуговують уваги)
Я вважаю, що велику роль в утвердженні успіху Redux відіграло чудове Devtools розширення для браузера, яке дозволяє візуалізувати сховище Redux зручним для користувачів способом. Аналогічно, підтримка TypeScript редактором VS Code чудово вплинула на прийняття технології розробниками.
Оцінка:
А— Виконується два або більше пунктів: розширення для браузера, розширення для текстового редактора, CLI утиліти, сторонні SaaS сервіси.
В — Виконується один з пунктів: розширення для браузера, розширення для текстового редактора, CLI утиліти, сторонні SaaS сервіси.
С — Немає допоміжних інструментів.
9. Репутація
Зрештою, навіть найбільш елеганта, добре документована бібліотека, залишиться лише яскравим спогадом, якщо вона проіснувала лише 6 місяців.
Ми всі можемо розповісти історії про чергову «перспективну технологію», а згодом повернутися до добре відомих Rails/PHP/вставте перевірену технологію тут, коли усе піде шкереберть.
(Express: досі залишається конкурентом, навіть через стільки років)
З цієї причини, ніщо не може перевершити гарну репутацію. Express є одним з прикладів: вперше випущений у 2010, він досі залишається серверним фреймворком Node.js за замовчуванням. І навіть екосистема JavaScript, що активно розвивається, не завадить цьому.
Оцінка:
А— Використовується 4+ років, впроваджено у проекти великих та відомих компаній.
В — Використовується 1-4 роки, впроваджується невеликими компаніями, що вперше ознайомлюються з технологією.
С — Існує менше ніж рік, і ще не було реального використання технології.
10. Команда
Не усі проекти мають репутацію. Коли бібліотека абсолютно нова, як ви можете оцінити її потенціал? Надійним рішенням буде подивитися хто стоїть за нею.
Коли було вперше випущено React, факт, що за цим стоїть Facebook, був великим аргументом для того, щоб спробувати фреймворк. Згодом Facebook випустив Relay та GraphQL, демонструючи, що успіх React не був випадковістю.
(Google Open Source: більше ніж 2000 проектів для декстопу, мобільних застосунків тощо).
Також великі компанії мають більше ресурсів для інвестування: Google мав можливість продовжувати підтримувати первинну версію Angular.js навіть після випуску нових, несумісних версій.
Звичайно, це не означає, що дрібніші компанії не можуть розробляти інновації. Яскравим прикладом слугує Vue.js, не кажучи вже про 99% програмного забезпечення відкритим сирцевим кодом.
Оцінка:
А— Підтримується великою компанією з open-source командою.
В — Підтримується командою середнього розміру, що складається з інженерів, що добре себе зарекомендували.
С — Підтримується самостійним розробником.
11. Сумісність
Чудовим аспектом впровадження передових бібліотек є їх швидкий розвиток. На жаль, це одночасно й великий недолік!
Швидкий темп впроваджень може призводити до частих критичних змін, коли нові практики змінюють старі шаблони, залишаючи увесь тягар рефакторингу на «першопрохідців».
React Router спричинив багато галасу, коли було вирішено повністю змінити API між 3 і 4 версією. Те ж саме було й в Angular, коли Angular.js став «просто Angular».
Часті оновлення — весело і цікаво, коли ви тільки починаєте новий проект, але як тільки ваш застосунок вийде на ринок, останнє, на що ви захочете витрачати свій дорогоцінний час — рефакторинг та налагодження коду з кожним оновленням бібліотеки.
Оцінка:
А— Оновлення, у більшості, сумісні зі старішими версіями, застарілі версії обробляються з попередженнями, а несумісні старіші версії підтримуються два роки і більше.
В — Критичні зміни трапляються, але вони добре документовані та розгортаються поступово.
С — Часто трапляються критичні зміни, що потребують багато рефакторингу. Без належного керівництва.
12. Популярність
І останній, але не менш важливий критерій — популярність або, іншими словами, галас навколо технології.
Зазвичай така метушня розцінюється погано («не стань жертвою хайпу»), скоріше як індикатор переваги стилю над змістом. Але це не завжди так.
З помірною популярністю новий проект може залучити більше користувачів та учасників, а це означає, що помилки швидше виявлятимуться і виправлятимуться, пакетна екосистема розвиватиметься - і все буде добре.
Але існує й інша сторона медалі: надмірний галас може призвести до того, що розробники користуватимуться незавершеними версіями, повними проблем, що призведе до падіння репутації. Як кажуть: «у вас лише один шанс справити гарне враження».
Оцінка:
А— Високий рівень популярності: на вершині Hacker News, тисячі зірок на GitHub, обговорення на престижних конференціях тощо.
В — Деякий інтерес щодо початкового запуску, сотні зірок на GitHub.
С — Нікому невідомий розробник невпинно працює. «Одного дня я покажу їм! Я покажу їм усім!».
Ще декілька факторів
- Масштабованість: як технологія проявляє себе у великих проектах.
- Визнання: хто ще використовує зараз технологію.
- Сумісність: наскільки добре співпрацює технологія з іншими.
- Зміна технології: наскільки легко перейти до іншої технології після застосованої.
Висновок
Описана у статті шкала жодною мірою не є абсолютним мірилом цінності бібліотеки. Така суб'єктивна оцінка залежатиме від проекту та ваших потреб.
Тим не менш, описані фактори можуть скласти непоганий контрольний список, щоб переконатися, що ви не пропустите нічого важливого, перш ніж зробити великий стрибок у майбутнє!
Ще немає коментарів