dizel3d
0
Поясню свой пример. Вы хотите, чтобы X использовал либо A, либо B. А я предлагаю инверсию зависимостей: A и B конфигурируют X. По сути получаете тот же результат: подключаете скрипт X и либо A, либо B.
dizel3d
0
Это решается с помощью CommonsChunkPlugin. Вот пример.
dizel3d
0
1. Суммарный пожатый фрондент весит 3.2 МБ. Релизы происходят по-разному: бывает раз в неделю, бывает раз в день.
2. Regular 3G 750 Кб/с грузит всю статику за 22 сек. Загрузка сопровождается прогресс-баром.
3. Зачем перегружать весь фронтенд, когда нужно обновить только часть? Только потому что TARS не может иначе?
dizel3d
0
Я говорю о браузере конечного пользователя.
dizel3d
0
И главный вопрос: при обновлении одного шрифта браузеру придется обновить всю статику?
dizel3d
0
Мне не нравится идея изменять названия папок и файлов. На то есть причины:
  • нельзя простым способом задеплоить ASP.NET проект, потому что невозможно добавить в проект файлы собранного фронтенда (пути к этим файлам меняются). Также получаем сложности с роутингом.
  • если меняются названия файлов, то отладчик в браузере будет закрывать старые версии этих файлов, будут теряться брейкпоинты, маппинг на файловую систему, позиция курсора.

Куда лучше добавлять хеш в query string.
dizel3d
0
По поводу кеширования шрифтов: а зачем хеш для них нужен?

Иконочные шрифты периодически обновляются, например, materialdesignicons или font-awesome, которые устаналиваются через bower или npm. Иногда в них меняются коды иконок. И если cache-busting применяется только к стилям, то клиент вместо "галочки" видит "крестик", вместо "котика" — "собачку" и т.п.
К тому же, кроме шрифтов, вы не применяете cache-busting к картинкам background-image.
dizel3d
0
Также в TARS неполностью реализован cache-busting: файлы шрифтов в стилях остаются без хеша.

dizel3d
0
В TARS мне не нравится:

  • отсутствие модульности (я говорю commonjs)
  • отсутствие тестирования
  • громоздкий

Ранее использовал gulp-starter от Vigetlabs, когда он еще на browserify был (теперь на webpack). Потом перешел на wepack + минимум gulp.

Как ни крутите, но гапловскими задачками вы вряд ли соберете фронтенд качественнее, чем webpack'ом. Также хочу предостеречь от browserify. С одной стороны, освоить его проще, но с другой — он ограниченный, бажный и потихоньку затухает.
dizel3d
0
Надо, наверное, смотреть в сторону кооперативных потоков, (Stackless Pyhton, например). Есть ли в питоне что-то похожее на GNU Pth для C?
dizel3d
0
RTOS. Сервер на C под uCLinux без поддержки динамической линковки и pthreads. Программа реализует некий интерфейс для настройки ряда устройств, посредством которого можно мгновенно в любой момент времени изменить их конфигурацию. Действительно же применение новой конфигурации занимает некоторое время и представляет собой довольно сложный процесс взаимодействия с утройствами, который сильно зависит от текущего состояния устройств и применяемых настроек.
Стоит заменить, что до применения QP софт не раз переписывался, т.к. сложность алгоритма конфигурирования постоянно приводила к почти полной потере расширяемости и изобилию багов.
Применение UML диаграмм состояний и последовательности позволило решить эти проблемы. В итоге получилось 4 класса сущностей (один из которых имел 5-ти-уровневую диаграмму состояний!). QP помог реализовать эти сущности, превратив их соответственно в 4 класса активных объектов.
Ядро кооперативной многозадачности мы использовали свое, сделанное на основе предлагаемого фреймворком легковесного Vanilla Kernel (хотя, проще и лучше было бы прицепить GNU Pth).
dizel3d
0
Рад стараться. В моей компании эта штука сильно помогла решить ряд проблем одного важного проекта. Удивило, что о QP на хабре всего один пост.