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

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

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

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

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

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

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

Во-первых, виртуальная модель основана на vanilla js. Она может обладать высокой производительностью только при выполнении большого количества обновлений в большой структуре глубоко вложенных HTML-элементов. Но не более! В большинстве же повседневных случаев она медленнее и менее производительна, как в период начальной загрузки страницы, так и в процессе обновления пользовательского интерфейса. В этом плане она уступает чистому JavaScript. Об этом в своем блоге уже писал один из известных американских разработчиков Джереми Вагнер. Он утверждает, что нативный язык на порядок быстрее 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 js.

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

Читайте также: Оператор опциональной последовательности в JavaScript.

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

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

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

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

Заключение

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