Еще в повседневных условиях понравился aiohttp — но он скорее альтернатива фласку чем джанге
Сравнивая меч Хаттори Ханзо, сравнивай его с любыми другими мечами — не Хаттори Ханзо
Сравнивая фреймворк на эвентлупе, надо сравнивать его с любым другим фреймворком на эвентлупе — не с синхронным фреймворком.
Потому что virtualdom уже стал мейнстримом благодаря в основном реакту, а shadow dom, мне кажется, пока нет. Во всяком случае такого же хайпа вокруг него не наблюдаю, а значит и жизнь вокруг него не кипит :) Даже проектов с ним пока не видел.
Пока кажется что подход недостаточно зрелый, чтобы взять его в любой проект, не зная куда его выведет кривая меняющихся требований или просто заведомо большой. IMHO
В то время как для приложений с реактом уже всё в достаточной мере стабилизировалось, не в последнюю очередь по части построения архитектуры (не одним реактом, ясное дело, а в плане куда его встраивать, какого должна быть его роль, что нужно кроме него и для чего etc). Грубо говоря, уже на всё готовые рецепты. Плюс бумирующее коммьюнити.
Кроме того, чтобы начать строить приложение с веб-компонентами и shadow dom нужно в очередной раз сломать мозги в направлении новой, скажем так, парадигмы :)
Как до этого было при появлении (очень утрированно)
— ajax (вау, не надо перезагружать страницу, можно что-то подгрузить),
— mvc (вау, всё как в бекэнде),
— mvvm (ого, так можно не фигачить императивно в/из DOM, а декларативно описывать связи между данными и DOM),
— frp (ого, а потоки данных то дают колоссальное упрощение)
и теперь вот virtualdom стал откровением для многих, кто пропустил что-то из этого списка в свое время :)
В корне не согласен с автором и вот почему: jsfiddle.net/00o9mh4d
(полный пример решения задачи со спиннерами, прелоадерами и 2мя состояниями на BB+Epoxy).
Стало так обидно за BB что не поленился импементировать задачу. А автор мог бы и привести полный код на реакте, чтобы было с чем сравнить.
По-моему, всё очень показательно. Различия с точностью до «декларативные биндинги vs. коллбеки в шаблоне». Другими словами, от решения на реакте отличается только отсутствием JSX со всеми вытекающими. И сдается мне, в этом и есть суть претензий к BB. Но во-первых, помнится от JSX долго все морщились, а во-вторых, как тут уже несколько раз написали, BB чуть более комплексный инструмент, в отличии от библиотеки-реализации virtualdom (не в обиду, просто же разные инструменты с акцентами на разные аспекты).
Работаю с backbone больше 3х лет и часто приходится делать такого рода функционал, не имея возможности делать слишком радикальные изменения в проекте. Там где тяжелые и запутанные состояния — положение спасают потоки данных и биндинги.
Конечно, когда пришел virtualdom и jsx, странно брать что-то другое в новый проект, но и существующие инструменты позволяют отлично решать задачи и не стоит так категорично их оценивать. И вообще, BB тем и славен, что чрезвычайно гибок и масштабируем: сколько одних только расширений для него.
Сравнивая меч Хаттори Ханзо, сравнивай его с любыми другими мечами — не Хаттори ХанзоСравнивая фреймворк на эвентлупе, надо сравнивать его с любым другим фреймворком на эвентлупе — не с синхронным фреймворком.
Потому что virtualdom уже стал мейнстримом благодаря в основном реакту, а shadow dom, мне кажется, пока нет. Во всяком случае такого же хайпа вокруг него не наблюдаю, а значит и жизнь вокруг него не кипит :) Даже проектов с ним пока не видел.
Пока кажется что подход недостаточно зрелый, чтобы взять его в любой проект, не зная куда его выведет кривая меняющихся требований или просто заведомо большой. IMHO
В то время как для приложений с реактом уже всё в достаточной мере стабилизировалось, не в последнюю очередь по части построения архитектуры (не одним реактом, ясное дело, а в плане куда его встраивать, какого должна быть его роль, что нужно кроме него и для чего etc). Грубо говоря, уже на всё готовые рецепты. Плюс бумирующее коммьюнити.
Кроме того, чтобы начать строить приложение с веб-компонентами и shadow dom нужно в очередной раз сломать мозги в направлении новой, скажем так, парадигмы :)
Как до этого было при появлении (очень утрированно)
— ajax (вау, не надо перезагружать страницу, можно что-то подгрузить),
— mvc (вау, всё как в бекэнде),
— mvvm (ого, так можно не фигачить императивно в/из DOM, а декларативно описывать связи между данными и DOM),
— frp (ого, а потоки данных то дают колоссальное упрощение)
и теперь вот virtualdom стал откровением для многих, кто пропустил что-то из этого списка в свое время :)
(полный пример решения задачи со спиннерами, прелоадерами и 2мя состояниями на BB+Epoxy).
Стало так обидно за BB что не поленился импементировать задачу. А автор мог бы и привести полный код на реакте, чтобы было с чем сравнить.
По-моему, всё очень показательно. Различия с точностью до «декларативные биндинги vs. коллбеки в шаблоне». Другими словами, от решения на реакте отличается только отсутствием JSX со всеми вытекающими. И сдается мне, в этом и есть суть претензий к BB. Но во-первых, помнится от JSX долго все морщились, а во-вторых, как тут уже несколько раз написали, BB чуть более комплексный инструмент, в отличии от библиотеки-реализации virtualdom (не в обиду, просто же разные инструменты с акцентами на разные аспекты).
Работаю с backbone больше 3х лет и часто приходится делать такого рода функционал, не имея возможности делать слишком радикальные изменения в проекте. Там где тяжелые и запутанные состояния — положение спасают потоки данных и биндинги.
Конечно, когда пришел virtualdom и jsx, странно брать что-то другое в новый проект, но и существующие инструменты позволяют отлично решать задачи и не стоит так категорично их оценивать. И вообще, BB тем и славен, что чрезвычайно гибок и масштабируем: сколько одних только расширений для него.