Интересно что вы скажите о Shadow DOM, который является логичным развитием современного веба.
Мне нравится идея Shadow DOM, но, к сожалению, я пока не могу представить, как его использовать для работы.
Мне кажется в шаблонах можно описывать логику отображения, иначе код превращается в абстракции ради абстракций.
Я большой противник абстракций, а уж тем более, ради абстракций. Люблю, когда код, который я написал год назад, могу понять. Матрешка, по крайней мере для меня, позволяет это делать, причем объем приложения не сильно влияет на понимание, так как каждый логический кусочек создан при помощи отдельного класса, каждый класс в отдельном файле, как и в Backbone (хотя эти кусочки там по-другому называются).
… кол-во шаблонного кода, который неизбежно приходится писать в Backbone и других подобных фреймворках
Вот вот. Я достаточно спотыкался о шаблонный код, хочу писать меньше, получать больше. Самым оптимальным вариантом для меня было создание своего фреймворка, которому, кстати говоря, около двух лет, но выложен в качестве опен-сорц сравнительно недавно.
Например в популярном php шаблонизаторе Twig есть подобная фишка twig.sensiolabs.org/doc/tags/for.html#adding-a-condition, вроде пользуются, никто не считает что это плохо.
Сравнение шаблонизатора для PHP и для клиентского JS, на мой взгляд, — неверно. PHP не манипулирует элементами динамически при наступлении каких-то событий, он генерирует статичный HTML. Ангуляр, на мой взгляд, — идеальный инструмент для простого вывода данных. Если требуется только лишь это + простые дополнения, типа события нажатия кнопки, лучше этого инструмента я и не знаю. В PHP, да и в любом другом серверном языке, я бы тоже использовал шаблонизатор.
Допустим, указание на то, что именно нужно вывести — приемлемо (хотя этого можно избежать), но указание на то, как фильтровать данные — лишнее. Этим должен заниматься JS код (опять же, по моему скромному мнению).
Это уже не шаблонизация, это — программировние. HTML код не должен знать какой модуль/контроллер управляет им. По идеологии Матрешки об этом знает только JS код.
В Матрешке нет шаблонизации. Если говорить о коллекции, то мы ей должны дать элемент, который будет отрендерен, а какие именно туда попадут свойства (что к чему должно быть привязано) определяется в JavaScript.
Вы правы, что опасаетесь новых, неопробованных инструментов. На сегодняшний день, вам остаётся мне верить или не верить наслово. Туториалы по Матрешке выходят редко, я стараюсь это исправить. Пока что, могу сказать одно: для того, чтоб написать неограниченное в размерах приложение, нужно соблюдать простое правило: один виджет — один класс. Это довольно старая (со времен появления ООП) и успешная практика. Скажу честно, о проблемах Ангуляра слышу впервые, возможно, из-за того, что не строил на нем чего-то большого.
Уверен, вы знаете, о чем говорите. Но из-за того, что не существует единственного правильного пути разработки приложения, у нас есть большой выбор среди фреймворков. Матрешка — фреймворк, созданный под влиянием Backbone (в первой статье даже есть упоминание о том, что часть кода, отвечающая за события позаимствован от туда) и решающий ряд проблем, с которыми, вы, видимо, еще не столкнулись: большое приложение требует неоправданно много человеко-мозго-часов. Взгляните на реализацию TodoMVC на Backbone: слишком много избыточного кода, и, как следствие, файлов. Несмотря на то, что вы не считаете TodoMVC показательным примером, я всё же настою, что каждая реализация, как раз-таки — лицо соответствующего фреймворка. Другое дело — Ангуляр. Несмотря на спорный подход (логика в HTML коде), этот фреймворк считаю, в целом, хорошим и интересным.
Проблема Backbone — излишние сущности. Нужно постоянно помнить о том, что, данные и вьюха связаны событиями в разных файлах. В Матрешке вы однажды задаёте правило, как свойство реагирует на привязанный элемент, и как элемент реагирует на изменения свойства (причем «монолитно»: в одном месте, одной функцией) и работаете исключительно с данными. Другими словами, Матрешка — замена Бекбона для ленивых :)
Я в курсе о проблеме изложения, сейчас думаю, как лучше структурировать обучающий материал: в виде статей, видеоуроков, книги и пр. для того, чтоб всем было просто разобраться в том, как строить неограниченные по масштабу SPA.
Спасибо за статью, я подозревал, что идея procrastinate не оригинальна, о чем упомянул в посте.
Лучше всего «было → стало» объяснит реализация TodoMVC. Так можно будет сравнить Матрешку с десяткамит других фреймворков (для тех, кто нге дочитал статью до конца, реализация будет представлена скоро).
Спасибо!
Было бы круто иметь возможность генерироватоь комиксы из кусочков в браузере. Можно получать SVG, затем конвертировать по что-нибудь другое с помощью Canvg.
Мне нравится идея Shadow DOM, но, к сожалению, я пока не могу представить, как его использовать для работы.
Я большой противник абстракций, а уж тем более, ради абстракций. Люблю, когда код, который я написал год назад, могу понять. Матрешка, по крайней мере для меня, позволяет это делать, причем объем приложения не сильно влияет на понимание, так как каждый логический кусочек создан при помощи отдельного класса, каждый класс в отдельном файле, как и в Backbone (хотя эти кусочки там по-другому называются).
Вот вот. Я достаточно спотыкался о шаблонный код, хочу писать меньше, получать больше. Самым оптимальным вариантом для меня было создание своего фреймворка, которому, кстати говоря, около двух лет, но выложен в качестве опен-сорц сравнительно недавно.
Сравнение шаблонизатора для PHP и для клиентского JS, на мой взгляд, — неверно. PHP не манипулирует элементами динамически при наступлении каких-то событий, он генерирует статичный HTML. Ангуляр, на мой взгляд, — идеальный инструмент для простого вывода данных. Если требуется только лишь это + простые дополнения, типа события нажатия кнопки, лучше этого инструмента я и не знаю. В PHP, да и в любом другом серверном языке, я бы тоже использовал шаблонизатор.
Допустим, указание на то, что именно нужно вывести — приемлемо (хотя этого можно избежать), но указание на то, как фильтровать данные — лишнее. Этим должен заниматься JS код (опять же, по моему скромному мнению).
Это уже не шаблонизация, это — программировние. HTML код не должен знать какой модуль/контроллер управляет им. По идеологии Матрешки об этом знает только JS код.
Без комментариев.
Пример из KnockoutJS:
Тоже без комментариев.
В Матрешке нет шаблонизации. Если говорить о коллекции, то мы ей должны дать элемент, который будет отрендерен, а какие именно туда попадут свойства (что к чему должно быть привязано) определяется в JavaScript.
Я в курсе о проблеме изложения, сейчас думаю, как лучше структурировать обучающий материал: в виде статей, видеоуроков, книги и пр. для того, чтоб всем было просто разобраться в том, как строить неограниченные по масштабу SPA.
procrastinateне оригинальна, о чем упомянул в посте.Лучше всего «было → стало» объяснит реализация TodoMVC. Так можно будет сравнить Матрешку с десяткамит других фреймворков (для тех, кто нге дочитал статью до конца, реализация будет представлена скоро).
Было бы круто иметь возможность генерироватоь комиксы из кусочков в браузере. Можно получать SVG, затем конвертировать по что-нибудь другое с помощью Canvg.