Комментарии 48
Главное, всё же, — стандартизация, ограничения в использовании разных методов, поддержка единых способов выполнения типовых задач, в которые входит и синхронизация.
Автор оригинальной статьи прямо Капитан Очевидность. Я бы даже сказал, Маршал Очевидность.
Мы пришли к необходимости использовать angular (react-а тогда ещё не было в проекте), когда поняли что совершенно невозможно выжимать данные из 50 input-ов через jQuery, равно как и обновлять эти input-ы данными, полученными с сервера.
Не уверен, что в этом обстоятельстве есть что-то неочевидное широким народным массам и, как следствие, предмет для написания статьи.
И вы-таки удивитесь, но есть просто гора проектов, где вполне себе можно на жуквери написать за 15 минут. Всё зависит от контекста.
Я не адепт жуквери, не. Но использовать клиентский MVVM, когда у тебя формочка из двух полей и кнопка submit — это всё же перебор.
А вот о том, в каких ситуациях надо применять какие инструменты — что-то статьи не пишут.
Я о том и говорю, что вопрос подбора инструментов — он более важный. Но все статьи о JS-фреймворках пишутся обычно так, что необходимость использования инструментов сама по себе под сомнение не ставится. Раз за разом — любая статья о React/Angular/Vue/<смешной вариант> прямо кричит мне из экрана, что вот так вот делать надо и это — единственный возможный путь реализации ВСЕГО. И ладно бы одному мне — я дядька бородатый, разберусь что к чему. Но невольно эти крики долетают до горе-менеджеров и горе-CTO, который начинают бугуртить а-ля "вон Васька-то уже в своем стартапе давно на реакт перешел, а мы всё ещё нет! а ну срочно внедрить современные технологии!". Что и порождает попытки впихнуть MVVM туда, где он объективно оверкилл. А потом пишутся оправдательные статьи на хабр/медиум о том, почему мы внедрили реакт и почему это — единственный возможный путь для нашей системы. Которую читает другой горе-менеджер или CTO. Тут круг замыкается.
Так вижу.
Тот же React "из коробки" не предполгает глобального стейта, только локальные для каждого компонента или вообще без него.
Задачу синхронизации вы могли решить и без фреймворка, пользуясь средствами jquery для получения информации из DOM и его обновления, а задачу синхронизации решив если не самостоятельно, то с помощью библиотек типа redux, mobx или rxjs.
По вашему комменту скорее можно сделать вывод, что вы пытались размазать состояние приложение по DOM, сделав его условно stateless, пришли к выводу, что состояние должно быть отделено от UI и обнаружили, что есть фреймворк в котором это заложено в архитектуру. Ну и ещё какие-то плюшки единого фреймворка убедили вас использовать для разделения состояния и UI (модели и видаов с контроллерами в терминах MVC) именно его.
В нашей команде в основном довольно неглупые люди, которые на примере .NET и MVC уже 10 лет как прекрасно знали о том, что UI и модель надо разделять. jQuery на клиенте обосновывался в основном "дедлайнами", которые и подвели систему к kind of фундаментальному рефакторингу клиентской части. Так что вывод неправильный, мазать мы ничего не собирались :)
Надо было назвать статью так — "Трактат О Главнейшей причине существования современных JS-фреймворков" :)
Автор избрал самый длинный способ синхронизации стейта и UI)
Про использование innerHTML и опасность XSS — слышу звон, да не знаю где он)
А наверно самое главное, что дают фремворки — это то, что на vanilla js можно писать без всякого представления об архитектуре, а с фреймворком так не получится. Придется потрудиться, чтобы сделать все в соответствии с тем, как это принято в конкретном фреймворке, но зато результат будет гарантированно лучше.
Согласен. Статья неплохая, но суть вопроса преувеличена. Фактически, речь о простом MVC-движке и о том, что это самое главное, а компоненты, сообщество, готовые решения — глубоко второстепенны. Но это не так. Простой MVC-движок легко написать самостоятельно и применить к конкретной задаче, но он не станет универсальным тиражируемым решением, пока в нём не появится достаточно дополнительного функционала, решающего актуальные задачи разработки. А как только этот функционал появится — будет готов ещё один велосипед (возможно даже и хороший), но до той поры это будет просто библиотечкой синхронизации состояния-отображения, находящейся в другой весовой категории, чем полнофункциональный фреймворк.
А я вижу причину существования фреймворков в убогости всего современного Web. Дело не только в JS с его прототипированным наследованием, не в медленном DOM, а в подходе в целом.
Каждый производитель делает свой браузер, со своими особыми уличными фишками и реализацией всплывания событий. У кого-то вообще свой диалект JS (я молчу про Dart, CoffeeScript и другие "заменители"). В итоге вместо того, чтобы переделать Web с нуля пишут очередной 1488-ой фреймворк, который должен сделать поддержку всех браузеров лучше, добавить статическую типизацию (привет, TypeScript) и соответствовать стандартам лучше других (Babel? Babel). А сами эти стандарты что?
Сколько нужно сделать лишних действий, чтобы сохранить дату на сервере в нужном формате? Как насчёт асинхронной подгрузки модулей? Сколько способов это сделать вы можете с ходу назвать?
В целом современный Web — это нагромождение костылей. Каждый новый фреймворк говорит, что уж теперь-то вам не надо с ними бороться, а в итоге получаем ещё большую сложность, чем раньше.
пишут очередной 1488-ой фреймворк, который должен сделать поддержку всех браузеров лучше, добавить статическую типизациюКак «поддержка браузеров» и статическая типизация связаны с фреймворками?
Сколько нужно сделать лишних действий, чтобы сохранить дату на сервере в нужном формате?Ноль? Когда преобразование одного формата данных в другой стало лишним действием?
Как насчёт асинхронной подгрузки модулей? Сколько способов это сделать вы можете с ходу назвать?Один — import(), который в будущем войдет в стандарт, и кроме него ничего больше не надо.
В целом современный Web — это нагромождение костылей.Вы путаете свой код и весь web.
Все смешалось — Babel, CoffeeScript, TS, фреймворки. А потом приходишь на новый проект и из глаз начинает идти кровь, когда смотришь на эти поделки «разобравшихся» в web'е.
У вас устаревшая информация. Есть тройка основных фреймворков, и этот список не меняется уже больше года.
Если что-то новое и появляется, то потеснить эти три пока не может.
Банан Компоненты велики, но MV* больше!
Боюсь задать глупый вопрос (весьма далек от всего этого), но все же.
Что мешает сделать каноничный MVC (например, с Active Model)?
Заводим:
- Модель со стейтом и событиями (в данном случае — NewAddress, DeleteAddress), реализующая шаблон Observer.
- Вью, подписанную на изменения модели (в данном случае — добавление некоторого html на NewAddress и удаление на DeleteAddress).
Это будет очень быстро (максимально быстро, я бы сказал), можно менять модель командами с сервера, модель ничего не знает про вьюшки (меняй их как хочешь, заводи сколько угодно и пр.), все события рядом, и вообще это правильно же.
?
Именно так современные js-фреймворки и работают (опуская особенности реализации).
Не уверен. В них (и в примере в статье) нет доменных событий,
зато есть метод render, относящийся не пойми к чему, и якобы "декларативный" подход.
Как же нет если есть? Рендер в реакте вызывается при изменении стейта, changeDetection в ангуляре — аналогично.
> зато есть метод render, относящийся не пойми к чему
Метод рендер это и есть: «Вью, подписанную на изменения модели». modelChanges.subscribe(render), если хотите.
Нет, речь о раздельных доменных событиях, а не об одном-единственном update. А это очень разные вещи. MVC — это об определенном направлении зависимостей и контроля, когда модель прямо говорит, что в ней изменилось и когда. Метод render же, грубо говоря, вообще по таймеру можно вызывать.
Почему-то JavaScript фреймворки пошли по этому пути (и соответственно, необходимости делать кучу дополнительной работы с вытекающими тормозами). Плохо то, что они называют его MVC.
Впрочем, мы уже видели такую массовую подмену понятий — толстые контроллеры, выдаваемые за MVC, или целая экосистема Rails, тоже выдаваемая за MVC.
Так это уж ваше дело выделять доменные события. Фреймворк ведь о них знать не может. И выделить их за вас — тоже не может.
> MVC — это об определенном направлении зависимостей и контроля, когда модель прямо говорит, что в ней изменилось и когда.
Ну вот в ангуляре модель прямо говорит, что изменилось и когда. Для того, чтобы она это могла сказать — приходится проводить change detection, который в итоге тормозит не сильно меньше, чем перерендер мира в реакте.
> Плохо то, что они называют его MVC.
Ну а почему не называть, если это MVC и есть?
В MVC не регламентируется механизм попадания данных из модели в вид. Классическая реализация, да, использует pub/sub, но в целом механзм не регламентируется. Вид должен получать данные из модели, но по своей инциативе или по таймеру он будет забирать или модель в него будет пушить — деталь реализации паттерна, но не часть паттерна.
c two-way-binding'ом вроде knockoutJS. От фреймверка мне нужна в первую очередь модульность и структуризация кода. В таком случае не существовало бы велосипедов вроде React+Angular.
Если кто-то не может, ну ок, используйте новые фреймворки, которые заставят вас это сделать.
Но не заставляйте остальных использовать то, что завтра перестанет быть модным.
Фре́ймворк (иногда фреймво́рк; англицизм, неологизм от framework — остов, каркас, структура)…
где любая конфигурация программы строится из двух частей:
1. Постоянная часть — каркас, не меняющийся от конфигурации к конфигурации и несущий в себе гнёзда, в которых размещается вторая, переменная часть;
2. Сменные модули (или точки расширения).
При этом React, Vue и другие «компоненты» — это вторая часть, а первая часто не жесткая, точнее зависит от других фреймворков, используемых в приложении.
Итого часть приложения может следовать принципам построения React(компоненты по своим папочкам), часть — Redux(как-то что-то группируем, вариантов много), BEM(чисто наименование), и так далее.
Очень часто главного фреймворка, который бы определял как это все сочетать и нет. В итоге любые два приложения будут разными.
И это главная причина существования фреймворков — работы поле непаханное, есть куда развернуться. Вот они и разворачиваются.
Самое главное тут — «фреймворк» может не содержать свой собственный код, а просто правильным образом настраивать, регламентировать или управлять нижележащими библиотеками.
Фреймворк — как приложение построено, а не как написано.
Как я раньше жил без vuejs?! Это так удобно! Спасибо.
3+ месяца сомневались можно ли воспринять как сарказм или нет, а потом собрались силами и уточнили? :)
Просто я каждый раз делаю что-то с Vue в IDE от Jetbrains и вот прям радуюсь, какие люди молодцы. Хорошо помню кровавые слёзы от сложных форм на чистом Js.
О главнейшей причине существования современных JS-фреймворков