Алексей Волегов: что за пессимизм? =) Как правило, проблема не в технологии, а в неверном понимании технологии. Например, использовать AMD только для того, чтобы вынести загрузку модулей за DOMContentLoaded, или использовать БЭМ только ради того, чтобы избавиться от каскадов. В первом случае кто-то может вываливать все свои модули в глобал скоуп и плести паутину зависимостей, а потом страдать от конфликтов с партнёрскими кодами и от dependencies-hell. А потом вдруг окажется, что виновата технология. =) А во втором случае человек может взять и наплодить взаимозависимых в JS блоков, попутно запихнув туда бизнес-логику. А потом мы вдруг обнаружим, что получили ни что иное, как бизнес-логику в представлении. Но будет уже поздно. Суть в том, что прежде чем пихать что-то в продакшн, необходимо серьёзно проникнуться идеей и понять её до конца. Чтобы потом не было мучительно больно.
Vicom: во-первых, веб постоянно развивается, и Ваши знания с такой же скоростью теряют актуальность. Во-вторых, совершенству нет предела и без этого. Если бы 10 лет назад веб был бы в том же состоянии, что и сейчас... Не знаю, что бы я делал всё это время. =)
Сергей Протько: ну, или создавать образ и пихать туда приложение (то есть, каждый деплой — новый образ, его распространение по нодам, остановка старых и запуск новых).
Сергей Протько: но если делать npm install на хост-машине, то это же уменьшает переносимость приложения (появляется зависимость от ноды на хосте)? На мой взгляд, это странно. Я думаю, разумнее было бы просто обрабатывать фейл npm install, не?
- Не нужно указывать путь до файла шаблона, не нужно прописывать полное имя элемента — конструкция вставки элемента сама определяет имя блока.
- Логика подстановки атрибутов инкапсулирована в библиотеку — это избавляет от необходимости реализовывать её в каждом подшаблоне индивидуально.
- JS, а не миксины потому, что JS более гибок. Я считаю, что реализовывать логику библиотеки на языке шаблонов — это издевательство над здравым смыслом.
Я обновил todo — в план реализации фич включено создание Express middleware и интерфейса для Gulp (кстати, в реализации этих фич была бы полезна чья-то ещё помощь). Если есть вопросы, фич-реквесты и баг-репорты, прошу писать в Issues, чтобы я ничего не упустил.
> А если есть общее для нескольких пользователей состояние то вам придется часть бизнес логики вынести на сервер. Он будет выступать в роли единого источника правды.
Я вижу необходимость в этом только для ACL или для логики, которая будет использовать что-нибудь типа вебсокетов. То есть, совместный доступ к данным — это юрисдикция ACL. а обмен состоянием — это, в абстрактном представлении, условно-P2P-взаимодействие, где бэкенд при необходимости должен нагружаться только проксирующей (и, возможно, валидирующей) логикой, но не сверх необходимости. Или я что-то упустил?
Спасибо, это полезная информация. Только мой вопрос был ещё и о том, насколько эффективно кеширование в контексте этой проблемы. И что Вы подразумевали под конкурентами AMD?
Дмитрий Беляев: Вы меня не поняли. Я говорил о том, что каталоги индексировать не нужно, а достаточно ограничиться пререндером полезного контента и sitemap.
Дмитрий Беляев: в большинстве случаев каталоги и фильтры можно не индексировать, а вместо этого генерировать sitemap с перечнем конечных сущностей (страниц, статей в бложике там, товаров в магазине и т.д.). Всё равно, поисковикам нужен уникальный контент, и делать пререндер, чтобы запихивать им в индекс списки — это напрасные усилия.
Не могу согласиться с этим.
Да, это так.
При этом, это можно продать дёшево, можно продать дорого. Жизнь несправедлива — можно с этим смириться, а можно что-то делать.