Чи все ще нам потрібні фреймворки JavaScript?

Як веб-розробник, я намагаюся регулярно оцінювати свій набір інструментів і визначати, чи можу я обійтися без того чи іншого інструменту. Нещодавно я досліджував, наскільки легко розробити складний інтерфейсний додаток без інтерфейсного фреймворку.

Що таке фреймворк JavaScript?

Простіше кажучи, фреймворк JavaScript - це інструмент, який можна використовувати для розробки вдосконалених веб-додатків, особливо SPA.

У той час веб-розробники застосовували логіку інтерфейсу, покладаючись на JS та jQuery. Але в міру того, як інтерфейсні програми ставали дедалі складнішими, інструменти зростали, щоб відповідати цій складності.

Популярні сьогодні рамки мають кілька основних спільних рис. Більшість інтерфейсних фреймворків / бібліотек, від Vue до React, забезпечують деяку комбінацію наступного:

  • Синхронізація стану та подання
  • Маршрутизація
  • Шаблонна система
  • Багаторазові компоненти

Чи все-таки необхідні фреймворки?

Це залежить від того, як ви наголошуєте на необхідному слові . Багато хто буде стверджувати, що основи інтерфейсу не є і ніколи не були необхідними. Однак вони дуже корисні інструменти.

Тож питання полягає в тому, чи є сьогодні фреймворки jQuery? Чи будуть вирішені проблеми, які вони вирішують, такими змінами, як DOM API?

Важко сказати, але досягнення власного JS, специфікація веб-компонентів та легко налаштовані інструменти побудови, зробили розробку SPA-середовища настільки простою, як ніколи раніше.

Щоб вивчити це далі, я розробив односторінковий додаток, використовуючи лише ванільний JavaScript, власні веб-компоненти та посилку. На цьому шляху було кілька підводних каменів та труднощів, які підкреслили сильні сторони структур JS.

У той же час, коли я пройшов початкові перешкоди, я був здивований тим, наскільки просто було створити односторінковий додаток із просто ванільним JS.

Огляд

Додаток просте. Це додаток рецептів з основними можливостями CRUD. Користувач може створювати, редагувати, видаляти, улюбляти та фільтрувати список рецептів.

Компоненти

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

Ви також можете використовувати гачки життєвого циклу, такі як connectedCallback, disconnectedCallback, attributeChangedCallback.

Маршрутизація

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

Спочатку я використовував пакет npm під назвою Vanilla JS Router. З API історії браузера не все так складно реалізувати свій власний код менше ніж у 100 рядків! Примітка: Я не застосовую справді складну логіку, таку як охорона маршрутів.

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

Ретроспектива

Створивши додаток, я витратив трохи часу, щоб подумати про плюси і мінуси всього процесу від початку до кінця. Почну з поганих новин.

Мінуси

Специфікація все ще змінюється

Специфікація веб-компонента є старою та новою. Це існує набагато довше, ніж я спочатку думав. Веб-компоненти вперше були представлені Алексом Расселом на Fronteers Conference 2011. Однак поштовх до веб-компонентів насправді зріс за останні рік-два. Таким чином, у специфікації все ще багато сум'яття. Наприклад, від імпорту HTML було відмовлено, хоча більшість документації / ресурсів все ще посилаються на них.

Тестування

Існує не так багато спеціальних ресурсів для тестування власних веб-компонентів. Є кілька перспективних інструментів, таких як skatejs ssr та тестер веб-компонентів від Polymer. Але ці інструменти насправді призначені для використання з відповідними бібліотеками. Це створює певні труднощі для використання з власними веб-компонентами.

Виявлення змін

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

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

Тіньовий DOM

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

Формування структур DOM

Частина пишності фреймворків / бібліотек, таких як Angular та React, полягає в тому, що вони є майстрами свого DOMain. Тобто вони чудово піддають ефективному рендерингу та рендерингу структур у DOM. З блогу Angular University:

Angular не генерує HTML, а потім передає його браузеру для його аналізу, натомість Angular генерує структури даних DOM безпосередньо!

Наприклад, Angular, на відміну від jQuery, відображає структури даних DOM безпосередньо. Тобто, замість того, щоб передавати HTML браузеру для синтаксичного аналізу, а потім рендеринга в структури даних DOM. Це є більш продуктивним, оскільки усуває цей крок розбору. Віртуальний DOM також є досить корисним, оскільки він заважає вам переробляти все щоразу, коли вам потрібно оновити ваш вигляд.

Плюси

З іншого боку, є кілька незаперечних переваг у розробці додатків таким чином:

Розмір пачки

Кінцевий продукт може бути (наголос на банку ) набагато меншим і компактнішим, ніж будь-що, розроблене за допомогою сучасних каркасів. Наприклад, остаточна збірка мого повнофункціонального додатка рецептів була менше половини розміру нової збірки Angular.

Примітка: Це оновлені, оптимізовані розміри набору.

Розуміння

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

Продуктивність

Те, що ці інтерфейсні фреймворки та бібліотеки роблять за лаштунками, є дивовижним. Однак ви можете заплатити ціну за виконання, якщо вирішите використовувати будь-яку з них; не існує такого поняття, як безкоштовний обід. Існує багато потенційних затримок продуктивності в масштабі: чи це витрачені рендери, надлишкові прослуховувачі, глибоке порівняння об’єктів чи непотрібні та великі маніпуляції DOM. Тут ви можете вирішити велику складність, впроваджуючи речі з нуля.

Команди Angular та React, здається, знають про ці підводні камені, і запропонували такі речі, як перевизначення методу shouldUpdate та onPush ChangeDetection як засіб подальшої оптимізації продуктивності.

Простота та володіння кодом

Ви ризикуєте щоразу, коли вводите код третьої сторони. Цей ризик зменшується за допомогою перевірених і перевірених бібліотек / фреймворків, але ніколи по-справжньому не усувається. Якщо ви можете уникнути написання коду самостійно або зі своєю командою, ви можете зменшити цей ризик і підтримувати кодову базу, яку ви знаєте всередині та поза.

Нотатки та цікаві ласощі

У мене був вибух, працюючи з посилкою. Іноді він намагався обійти певні крайні випадки дещо обмеженішим, ніж Webpack, але здебільшого я виявив, що рядок тегу "zero config" відповідає дійсності.

Мені також ясно, що багато хто називає React «бібліотекою», а Vue «прогресивною» структурою. Хоча я розумію причини цього, я думаю, що React, Vue та Angular вирішують багато однакових проблем. Таким чином, я розглядаю їх усіх разом під терміном "рамки".

Чому б не використовувати трафарет або полімер? Я хотів якомога більше уникати використання пакетів, бібліотек та фреймворків. Я хотів побачити, наскільки веб-стандарти досягли сучасного розвитку (окрім інструментів побудови).

Я впевнений, що існує безліч інших способів розробки SPA або інтерфейсного додатку взагалі без великих фреймворків чи бібліотеки, я спробував тут один шлях, і я хотів би почути про інших!

Резюме

Великою евристикою для рішення використовувати чи не використовувати фреймворк є те, що я називаю, «переломною точкою». У міру зростання вашого додатка настає момент, коли ви в кінцевому підсумку створюєте власний фреймворк для повторного використання функціональності та структури. Наприклад, у вас є купа форм, і ви хочете створити багаторазову логіку для реактивної перевірки.

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

Тим не менш, більшу частину того, що роблять фреймворки, з часом стане легше робити з меншими бібліотеками та / або власним кодом. Візьмемо мою заявку як приклад. У той же час, якщо великі фреймворки та бібліотеки залишаються універсальними, вони можуть змінюватися, адаптуватися та залишатися в силі. Якщо ні, вони можуть опинитися як jQuery - здебільшого інструмент минулого.

Висновок

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

У цей час, наскільки я можу зрозуміти, плюси використання фреймворку часто перевершують мінуси. Однак, якщо основи не починають вирішувати нові проблеми і продовжуватимуть розвиватися, вони з часом зникнуть.

Ресурси

Керівництво Angular для початківців: Чому Angular? Найвищі переваги

Примітка: Ця публікація є частиною поточної серії Angular for Beginners, ось і повна серія: Angular For Beginners… blog.angular-university.io Порівняння з іншими фреймворками - Vue.js

Vue.js - Прогресивна платформа JavaScript vuejs.org Оптимізація продуктивності - React

Внутрішньо React використовує кілька розумних методів, щоб мінімізувати кількість дорогих операцій DOM, необхідних для оновлення веб-компонентів responsejs.org

Як розробники, ми всі знаємо, що повторне використання коду якомога більше - це гарна ідея. Традиційно це не було так… developer.mozilla.org Найглибша причина існування сучасних фреймворків JavaScript

Я бачив багатьох, багатьох людей, які наосліп використовують сучасні фреймворки, такі як React, Angular або Vue.js. Ці фреймворки забезпечують… medium.com Стилізацію веб-компонентів за допомогою спільного таблиці стилів

Веб-компоненти - це дивовижна нова функція Інтернету, що дозволяє розробникам визначати власні власні елементи HTML ... www.smashingmagazine.com