дрочка на "дубли", что ж ещё 😂 нубы такие смешные...
минимум необходимых свойств нормального генератора сайтмэп:
- сайтмэп с отсутствием указания приоритетов - мало полезный калека. если внешний скрипт будет определять приоритеты тупо по уровню вложенности и/или дате создания файла - калека вдвойне;
- генератор должен создавать кэш сайтмэп, а не тупо отрабатывать при каждом обращении, ну а сторонний сервис без кеша просто ляжет. если кто то готов для этого предоставлять полные права стороннему сервису вместо минимального мозгового усилия - флаг в руки;
- кэш должен автоматом оперативно обновляться при изменении контента, о чем знает система изнутри, для внешнего скрипта это слегка проблематично. запуск внешнего сервиса по таймеру полная лажа;
в общем, у кого хватило образования на понимание работы сайтмэп найдётся час на поиск и установку плагина под свою СМС или тот же час на написание роскошной самоделки. но если хотите/готовы работать исключительно на орлов, пачками плодящих ГС под сапу - ваше дело/время, этот сервис, как и его аналоги, будет как раз под их уровень вменяемости...
просто это не проблема ;)
к сожалению сервисы/скрипты создания сайтмэп тупо через парсинг внутренних ссылок, метатегов и роботс ущербны изначально вне зависимости есть там ограничения по объёму или нет...
не более чем разговоры о "стандартном" сайте. поточное штампование вне темы, а б/м серьёзный проект в настоящее время стандартным быть не может.
почему же без статики? всё было сказано:
всё дело в продуманной организации данных...
на самом деле для любого уникального проекта в очень широком диапазоне. уже сейчас практически любой серьёзный проект требует создания уникальной MVC концепции: от нормального корпоративного сайта до маленького, но специфического ИМ, а интерактива навалом даже в визитках.
как раз лепить всё подряд на ядре уродцев вроде битрикса или, прости господи, вордпресса выглядит как раз неадекватно, а большинство "заточек" CMS под конкретный проект по уровню реализации не лучше детсадовского конструктора.
аргумент, что это и так реализуется привычными средствами не катит абсолютно, хотя бы потому что можно или уметь находить заказчиков на эксклюзив, или для лохов на потоке собирать гуано из шлакоблоков - у каждого своя "ниша".
просто покурить ангуляр. прикинуть где и как ходит юзер и где и как шарятся боты и то что им и "шаблонизации" как таковой не нужно по сути при нужной организации данных. проблема (которой нет) на самом деле стоит только для морды ;) а потом "проблема" как всегда вдруг становиться фичей - на странице только уник, никаких дублей, никаких мусорных страниц, всё под нечувствительным и строгим контролем...
я и говорил, что командам занимающимся только версткой и установкой готовых CMS эта технология не нужна (пока не появится CMS на её основе).
для уник движков всё более чем юзабельно по всему спектру параметров. Yii2 на серваке и Angular на клиенте это чистый термояд 😂 а проблема SEO решается более изящно и проще чем полная двойная шаблонизация.
без полного тестирования новых компонентов/модулей даже к стандартной CMS можно обойтись только опустив качество продукта до обычного гуано из опен-соурса ;) и брать за такое копейки. ну его нафиг...
ну если больше замечаний нет и то хорошо :)
по идее гугл должен быть в курсе этих прописных истин, как считаете? тем более, что "в массы" он их и внедрил.
а его команда имела время более чем адекватно оценить все минусы/плюсы до выкладывания пакета в паблик.
ЗЫ: я сам страдаю перфекционизмом ;) но доводить каждую толковую методику до абсурда не стоит в любом случае...
богоносец, со всем уважением. ну сколько раз повторять что это пример из пошагового туториала 😂 ? он и должен быть не оптимизирован и все скрипты должны быть в полных исходниках и подгружаться они должны поодиночке для ознакомления.
нашили к чему цепляться, чес слово: как раз таки ангуляр декларирует в продакшн использовать и гугловский JS компилятор и LESS в обязательном порядке - всё по PageSpeed. не стоит гуглу его же "истины" вещать ;) ...
что мешает просмотреть исходники примера? ;)
а хоть чуть чуть абстрагироваться от конкретного примера ни как не получается? обратить внимание на принципы и возможности?
а разве кто то сказал, что пример это мобильное приложение? не считаете, что view для мобильного трафика должна быть отличной от десктопного? хотя и так ежу понятно, что в выигрыше по объёму трафика точно можно не сомневаться, хотя бы на "пару спичек" :)
для ангуляра здесь всё не так просто, скрипты капитально сокращаются за счёт работы с HTML dependency injection. получается так на так - сокращается и капитально упрощается код MVC конструкций за счёт внедрения иньекций в HTML шаблоны. зато с системщика снимается вся возня работы с верстальщиком, который кроме HTML знать ничего не хочет. там где работало всегда 2 человека, нечувствительно справиться один, хоть и более дорогой из них.
ну а дизайнерскую обвязку шаблонов интерфейса можно доверить и кому подешевле, всё одно это обычно так и происходит - css фреймвоки в помощь.
так что для нас - капитальное упрощение (читай удешевление) процесса. команды с другой структурой могут выиграть только по времени (что то же деньги в принципе), команды ориентированные только на верстку + CMS в минусе, но оно им и не надо, пусть пачками клепают вордпрессы с битриксами.
вообщем всё как всегда - универсальной магии пока не придумали.
а вот себистоимость сопровождения, сроки тестирования и внедрения дополнений по крайней мере не изменяться, в большинстве случаев сильно уменьшаться: самая зубодробительная и объёмная часть разработки и тестов - отладка интерактива, и она на одной стороне и в одних руках. уже в пакете есть и модульные и e2e тесты, MVC код более чем адекватный и всё на виду в HTML так что выигрыш в упрощении поддержки проекта огромный...
