Когда термины «веб-сайт» и «веб-приложение» используются взаимозаменяемо, это может привести к болезненным последствиям для результата проекта.

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

Создание образовательного веб-сайта для компании с меньшей вероятностью будет полагаться на надежную структуру для обработки изменений DOM или создания маршрутизации на стороне клиента, по крайней мере, это мое намерение.

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

Но будьте осторожны, когда мы создаем веб-приложение.

Сотни, если не тысячи зависимостей, некоторые из которых мы даже не уверены в безопасности, вводятся при установке пакетов.

Кроме того, мы создаем сложные настройки для сборщиков модулей.

Чтобы убедиться, что то, что создается, является быстрым и доступным в этой беспокойной, но всепроникающей среде разработки, требуются знания и внимание к деталям.

Запустите npm ls — prod в корневом каталоге вашего проекта и проверьте, не выглядит ли что-то в этом списке знакомым, если у вас есть какие-либо сомнения.

Даже если вы это сделаете, сторонние скрипты — которых, я уверен, на вашем сайте есть по крайней мере несколько — при этом не учитываются.

Фреймворки вынуждают разработчиков использовать неустойчивые шаблоны.

Например, проблема с этим кодом начинается здесь:

Элемент ‹span› не является заменой элемента ‹label›, который обеспечивает преимущества доступности, а ‹span – нет.

Если мы намерены сделать что-то на стороне клиента перед отправкой формы, то мы должны переместить действие, связанное с обработчиком onClick элемента ‹button›, в обработчик onSubmit элемента ‹form›.

Когда мы попытаемся провести рефакторинг; Мы получим что-то вроде

Этот компонент теперь не только более доступен, но и использует меньше JavaScript. В мире, где JavaScript повсюду, удаление его строк должно быть терапевтическим. Браузер дает нам так много бесплатно, и мы должны стараться использовать его как можно больше.

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

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

Одностраничные приложения: проигрышный компромисс.

Одним из компромиссов, на который идут программисты, является принятие модели одностраничных приложений (SPA), даже если она не подходит для проекта.

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

Несмотря на синхронность, встроенная функция навигации браузера предлагает множество преимуществ.

Одним из таких примеров является сложная спецификация, используемая для ведения истории.
Пользователи, решившие не использовать JavaScript, не будут полностью лишены возможности просматривать контент.

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

Бежать быстрее в гонке Javascript?

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

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

Вы обнаружите, что, хотя вы, возможно, итерируете не так быстро, как ваши конкуренты, ваш продукт будет быстрее.