Что лучше масштабируется: JavaScript фреймворки или нативный язык - Smart-Frontend

Что лучше масштабируется: JavaScript фреймворки или нативный язык

Что лучше масштабируется: JavaScript фреймворки или нативный язык


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

Пока чаша весов не склонилась окончательно в ту или иную сторону. Хотя на самом деле утверждение о невозможности масштабирования «ванильного» js — полная чушь. Являются ли фреймворки серьезными конкурентами для JavaScript? Давайте попробуем разобраться.

Что такое «масштабирование»?

Означает ли это, что нативный язык не способен справиться с нагрузкой больших приложений так, как это могут сделать фреймворки? Это ложь! Все JavaScript фреймворки работают на основе «ванильного» js. Это значит, что они не имели бы возможности «масштабирования», если бы она отсутствовала у нативного языка.

«Масштабирование» — бессмысленный, но очень важный термин. Его, как правило, используют те, кто отрицает потенциал «ванильного» JavaScript просто потому, что он им не нравится. Но стараются они это делать так, как будто для этого есть веская причина.

Виртуальный DOM — это не волшебное зелье

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

Во-первых, виртуальная модель основана на vanilla js. Она может обладать высокой производительностью только при выполнении большого количества обновлений в большой структуре глубоко вложенных HTML-элементов. Но не более!

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

Об этом в свое время уже писал один из известных американских разработчиков Джереми Вагнер. Он утверждает, что vanilla js на порядки быстрее React.

Использование чистого JavaScript не всегда означает «написание собственного фреймворка». Многие люди не могут понять, что существуют и другие способы создания сайтов, кроме как выбрать один из популярных фреймворков.

В результате, время от времени в интернете можно столкнуться с громкими, цепляющими, но абсурдными утверждениями вроде этого:

 

Если вы не используете фреймворк, вы пишете собственный, плохо документированный.

 

Зачем нужны JavaScript фреймворки?

На самом деле можно создавать сайты и даже большие приложения без фреймворков! Программирование на чистом JavaScript без фреймворка — вполне реально.

Один из распространенных подходов (используется такими известными компаниями, как GitHub и Basecamp) — это создание на первом этапе разработки серверных приложений. Каждый такой проект создается с помощью HTML-кода, отображаемого на сервере, с использованием любого серверного языка. Это может быть PHP, Ruby или даже серверном js (node.js).

Использование JavaScript улучшает взаимодействие пользователя с приложением. Речь идет, например, об использовании Ajax для отправки форм или для асинхронной выборки всего HTML с сервера при смене страницы или обновлении информации на ней. Иногда это действительно требует написания своего JavaScript фреймворка, и это нормально. Как в случае с Basecamp, например.

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

Backbone JS существовал еще до создания Angular компанией Google. Но это не помешало поисковому гиганту пойти на этот шаг. Затем Facebook представил миру React, хотя на тот момент многие разработчики уже активно использовали Angular. Несмотря на резкий рост популярности реакта, Эван Ю все же создал Vue.

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

Причины популярности фреймворков

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

  1. Из-за веры в то, что использование «новинок» привлечет в команду лучших разработчиков.
  2. Разработчики, принявшие техническое решение, хотят попробовать что-то новое.
  3. Руководство компании посетило одну из множества регулярных конференций, где им внушили необходимость фреймворков для масштабирования.
  4. Кто-то из конкурентов переделал свой сайт с помощью фреймворка.
  5. Если это делают такие гиганты, как Facebook, значит, та будет лучше.
  6. Наличие реальных проблем, которые фреймворк может помочь решить.

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *