Comments 10
Просто оставлю это здесь: Микропаттерны оптимизации в Javascript: декораторы функций debouncing и throttling
В целом интересно, но вот не покидает ощущение, что слишком сложно, как API, так и использование. Сделали бы пример, как это упростило вам жизнь (было → стало).
В целом интересно, но вот не покидает ощущение, что слишком сложно, как API, так и использование. Сделали бы пример, как это упростило вам жизнь (было → стало).
Спасибо за статью, я подозревал, что идея
Лучше всего «было → стало» объяснит реализация TodoMVC. Так можно будет сравнить Матрешку с десяткамит других фреймворков (для тех, кто нге дочитал статью до конца, реализация будет представлена скоро).
procrastinate не оригинальна, о чем упомянул в посте.Лучше всего «было → стало» объяснит реализация TodoMVC. Так можно будет сравнить Матрешку с десяткамит других фреймворков (для тех, кто нге дочитал статью до конца, реализация будет представлена скоро).
В том то и дело, TodoMVC непоказательно, оно больше подходит для MV* решений (да и то очень спорно), чем не является матрешка, которая больше похожа на сборник «полезных инструментов», а не базы для создания SPA. В статье вы упоминаете работу с формами, чем не отличный пример, чтобы разобрать.
Пример работы с формой есть в статье «Matreshka.js — Наследование».
Я в курсе о проблеме изложения, сейчас думаю, как лучше структурировать обучающий материал: в виде статей, видеоуроков, книги и пр. для того, чтоб всем было просто разобраться в том, как строить неограниченные по масштабу SPA.
Я в курсе о проблеме изложения, сейчас думаю, как лучше структурировать обучающий материал: в виде статей, видеоуроков, книги и пр. для того, чтоб всем было просто разобраться в том, как строить неограниченные по масштабу SPA.
Спасибо, про Object.defineProperty не знал.
Сложновато для понимания, но идея интересная. К сожалению все примеры которые есть на сайте демонстрируют больше сложность, чем применимость. Вот взять к примеру Backbone, там на основе модели рисуется вид. У вас на основе переменных делается тоже самое, но Backbone легче применить.
Сложновато для понимания, но идея интересная. К сожалению все примеры которые есть на сайте демонстрируют больше сложность, чем применимость. Вот взять к примеру Backbone, там на основе модели рисуется вид. У вас на основе переменных делается тоже самое, но Backbone легче применить.
Проблема Backbone — излишние сущности. Нужно постоянно помнить о том, что, данные и вьюха связаны событиями в разных файлах. В Матрешке вы однажды задаёте правило, как свойство реагирует на привязанный элемент, и как элемент реагирует на изменения свойства (причем «монолитно»: в одном месте, одной функцией) и работаете исключительно с данными. Другими словами, Матрешка — замена Бекбона для ленивых :)
Что-то вы не то говорите, в Backbone как раз всё на своих местах. Модель/Коллекция и View (вот родной View можно заменить на что-то получше c data-binding), можно даже подружить с React. Помимо этого, описание взаимодействия точно также находится в одном «файле», т.е. модуле… ну так далее.
Уверен, вы знаете, о чем говорите. Но из-за того, что не существует единственного правильного пути разработки приложения, у нас есть большой выбор среди фреймворков. Матрешка — фреймворк, созданный под влиянием Backbone (в первой статье даже есть упоминание о том, что часть кода, отвечающая за события позаимствован от туда) и решающий ряд проблем, с которыми, вы, видимо, еще не столкнулись: большое приложение требует неоправданно много человеко-мозго-часов. Взгляните на реализацию TodoMVC на Backbone: слишком много избыточного кода, и, как следствие, файлов. Несмотря на то, что вы не считаете TodoMVC показательным примером, я всё же настою, что каждая реализация, как раз-таки — лицо соответствующего фреймворка. Другое дело — Ангуляр. Несмотря на спорный подход (логика в HTML коде), этот фреймворк считаю, в целом, хорошим и интересным.
Я специально обратил внимание на то, что родной View у Backbone нужно заменить и как только мы это делаем, всё становиться на свои месте. Все эти человеко-часы точно также будут и у любого человека, с любым FW, если он его не знает. Ангуляр тоже на первых парах прост и удобен, но чем дальше в лес, тем больше проблемы, о чем говорят многочисленные статьи. Тоже самое будет и с вашим инструментом, когда его будет использовать другой человек, а может и хуже, кто знает.
Вы правы, что опасаетесь новых, неопробованных инструментов. На сегодняшний день, вам остаётся мне верить или не верить наслово. Туториалы по Матрешке выходят редко, я стараюсь это исправить. Пока что, могу сказать одно: для того, чтоб написать неограниченное в размерах приложение, нужно соблюдать простое правило: один виджет — один класс. Это довольно старая (со времен появления ООП) и успешная практика. Скажу честно, о проблемах Ангуляра слышу впервые, возможно, из-за того, что не строил на нем чего-то большого.
Sign up to leave a comment.
(Архив) Matreshka.js v0.2