Антон Губарев: честно говоря уже точно все не помню, но вроде бы проблема решилась когда я обновил прошивку на роутере. у меня dlink-300 4годовалой давности
Причина есть, я сам активно их использую, но я же написал, что в данном случае этот вариант отпадает. т.к. будут пользователи с разными правами доступа, зачем грузить всю пачку, когда пользователю будет всего доступно 10-20 модулей. Ну и собственно с таким условием мне поставили задачу.
FeNUMe: Не, я так понимаю, он использует системный браузер. только он открывает окно внутри приложения, а не отельным приложением. Вроде так. Насчет ангуляра понял. А что насчет стилей, делать по первому варианту? или все таки писать основу самим?
Спасибо за ответ. По поводу веса в SPA я не переживаю. Смотрите. Само приложение предназначено для работы с финансами, счетами. И как раз SPA. сейчас уходит на второй план, т.к. уже пока имеется приложение для работы. И сейчас нужно написать лендинги которые будут доступны через бота в телеграмм. И как я это вижу. Например я хочу быстро увидеть график расходов за какой-то период. С бекендом там все норм. За это можно не волноваться. Мне дают JSON, и все я кручу и веру как хочу. Вопрос в другом. Пользователь должен получить график расходов за период а также иметь возможность менять период. График например будет геннерироваться на клиенте через какой нибудь chart.js. И больше никакого функционала.
И вот я могу например сейчас взять за основную готовые варианты, и для каждого такого виджета выпиливать все лишнее. Но они будут будут слишком самостоятельными, и фактически при разработке SPA нужно будет пилить по новой отдельно все эти же компоненты.
А если использовать 3 вариант, я смог сделать так, что у нас будут отдельные лендинги, без всех лишних зависимостей, под каждый частный случай, но при этом они в dev версии будут частью SPA.
А если мы забиваем на все и пилим SPA, и бот будет отправлять постоянно на него я думаю это не очень хорошая идея. т.к. телеграм открывает окно браузера не отдельно, а внутри себя. Поэтому насчет кеширования если честно не знаю, возможно ли его использовать.
Я почему то считаю, очень важно, максимально минимизировать все, что если контент сумарно будет весить 400 кб вместо 2-3000 кб, будет очень существенно.
смотрите, да потом нужен будет дашборд (я и писал про них это как раз 1 вариант). Сейчас отдельные компоненты. Понятно что можно взять и выпилить для конкретного компонента все не нужно. но тогда это будут независимые дубликаты которые. которые по отдельности надо будет править. то есть у нас будет отдельный компонент. И будет дашборд со всеми. я предвижу что будут проблемы с их совмещением, и поддержкой. Будет крайне неудобно работать в таком режиме. а в 3 варианте, я смогу организовать так что у нас будет общая система сборки на том же Gulp, которая будет хранить общую структуру и параллельно будет сохранять отдельно виджеты с видами и зависимостями. то есть при первом варианте будет больше проблем потом, при 3м варианте больше времени на начальном этапе.
честно говоря, проблема решилась но точно сказать не смогу как им образом, когда перезагрузил комп и попробовал еще раз клонировать у меня все получилось, подозреваю. что это связанно как то с опенсервером, который после перезагрузки был отключен.
та даже если это малые проекты. Я вчера наконец то закончил свою сборку, и был в восторге от потенциала. раньше реально накаляло использовать JADE+SASS, постоянно вручную нужно было ватчеры запускать.. Теперь же все делается одной командой... Я уже молчу и о других плюшках, и bower.
@alexeykiselev а как же, клиенты и сейчас есть, и большинству все равно какая будет cms. И приходиться делать им на всяких джумлах и т.д. А если получиться ее разработать, именно так как я и задумал, и реализовать не нестандартные идеи по созданию данной CMS. то это вообще будет замечательно. То есть по факту, я как минимум, в перспективе смогу улучшить кпд на этапе разработке сайтов для клиентов.
