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