• Как библиотека MobX помогает управлять состоянием веб-приложений. Лекция в Яндексе
    0
    В общем, из того, что все данные изменились не следует, что изменилось все виртуальное дерево.
  • Как библиотека MobX помогает управлять состоянием веб-приложений. Лекция в Яндексе
    0
    KasperGreen, прошу прощения, проглядел. vintage не прав — по настоящим DOM-узлам Реакт, конечно, бегать не будет.

    Но и вы не правы — перерисовывать все Реакт тоже не будет, иначе это приведет к побочным эффектам, о которых я писал.

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

    Куда лучше добавлять хеш в query string.
  • TARS, сделай уровень frontend-рутины 0%
    0
    По поводу кеширования шрифтов: а зачем хеш для них нужен?

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

  • TARS, сделай уровень frontend-рутины 0%
    0
    В TARS мне не нравится:

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

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

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