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

Я хотел продемонстрировать, насколько вырос JavaScript, и указать, что могут быть некоторые простые варианты использования, в которых использование фреймворка может быть излишним. Пожалуйста, не переносите свое 200-компонентное приложение React со сложным управлением состоянием в собственное приложение JavaScript. Это только усложнит жизнь всем. 🙂

Поскольку интерфейсная экосистема растет с каждым днем, у нас есть больше возможностей, чем когда-либо. Крупные игроки давно не менялись (Angular, React, Vue), и нет никаких признаков того, что они скоро изменятся. Поэтому, начиная новый проект, люди часто спрашивают себя: «Хорошо, какую из этих фреймворков / библиотек мне следует использовать?».

Но, возможно, вам стоит просто использовать простой JavaScript.

Не поймите меня неправильно, все эти инструменты могут быть действительно классными и могут многое предложить разработчику. Их отдельные экосистемы довольно большие, и я считаю, что у каждой из них есть свое место в проекте. Но я также считаю, что люди действительно жестко относятся к ним.

Это может быть довольно ограничивающим фактором, особенно для людей, только начинающих знакомиться с миром JavaScript. Если вы просто сосредоточитесь на одном из этих инструментов, вы столкнетесь с трудностями, когда достигнете их предела или когда вам придется переключиться на другой проект, где стек будет совершенно другим.

Наш маленький язык прошел долгий путь. И, когда браузеры делают огромные скачки и прогресс, сегодня можно сделать многое, просто используя только JavaScript, и я хотел бы это подчеркнуть.

Что бы вы могли сделать, если бы вы хотели создать для своего проекта архитектуру на основе компонентов?

Что ж, допустим, у вас есть статический HTML-код в вашем index.html, например:

И вы хотите делать что-нибудь с помощью div js-app. Вы можете просто получить его с помощью селектора запросов и изменить его вручную. Но предположим, что вы хотите использовать более компонентный подход (потому что в наши дни компоненты в моде). Вы можете написать что-то вроде этого в своем файле index.js:

Мы создаем класс JavaScript и передаем имя класса js-app его конструктору. Это выбирает правильный элемент с помощью селектора запроса в строке 3 и сохраняет его в переменной context экземпляра класса.
Вот ссылка на этот пример. на код-песочнице .

Так зачем мы это сделали? Это кажется излишним для простого изменения внутреннего HTML-кода div.
Что ж, если мы структурируем наш код таким образом, мы сможем довольно легко комбинировать компоненты. Допустим, у нас есть такая форма имени пользователя и пароля:

Допустим, мы хотим добавить некоторую проверку этим входным данным, чтобы они стали красными, когда поля пусты. Мы могли бы добавить следующий код css и js, чтобы заставить его работать, как в предыдущем примере:

CSS просто меняет цвет фона, поэтому он указывает, какой ввод ошибочен.
js содержит класс, экземпляр которого создается дважды в нижней части файла. Один раз для элемента ввода пароля и один раз для элемента ввода пароля. поэтому оба этих экземпляра отделены друг от друга и имеют свои собственные обработчики событий.
Мы добавляем пару обработчиков событий: один запускается, как только пользователь начинает печатать (onChange), а другой запускается, когда пользователь оставляет вход (onBlur). Мы показываем фон ошибки только в том случае, если пользователь снимает фокус с элемента ввода, а содержимое элемента пустое.
Вот ссылка на пример в изолированной программной среде.

Итак, у нас есть простая форма с некоторой проверкой, просто с использованием собственного JavaScript. Мы также структурировали код более компонентно-ориентированным способом. Мы также могли бы пойти дальше и извлечь класс RequiredInput в его собственный файл и импортировать его, создать его экземпляр или расширить по мере необходимости, так что этот подход может быть довольно гибкий.