Comments 52
Ещё у него есть убер визуализатор для basis.js, которые вроде как можно настроить для Rx/Beacon/Kefir, но тут лучше он уточнит ;]
Спасибо, Костя :)
Для других библиотек нужно встраивать поддержку. Пробовал с knoсkout'ом подружить https://github.com/lahmatiy/knockout-data-flow
Думаю в ближайшие пару месяцев станет возможно сделать этот визуализатор более независимым, как потребитель json. То есть вы или ваша библиотека должны сгенерировать описание графа в JSON (постороение специфично для библиотеки/фреймворки), а он его построит. Собственно он уже так работает, но пока в составе последнего basis.js. А делалось это в рамках новых remote tools https://www.youtube.com/watch?v=j6q3gsWOpgM
Скоро по такому же принципу будет работать Component Inspector. А вот визуализатор потоков данных пока нет планов выносить, по крайней мере до тех пор пока не будут реализованы основные запланированные фичи для него.
Live Coding / Hot Reload?
Используем basis.js + basis.js inspector
Так же, просмотрщик компонентов/блоков позволяет не плодить всё новые и новые «кнопочки», при получении задачи, вы просто компонуете уже имеющиеся блоки и получаете результат. Зачастую вам даже не нужен дизайнер. Кроме этого, когда вы редактируете блок в GUI, вы видите все варианты использования и как на них влияют ваши изменения.
Инспектор, позволяет разобраться в приложении на лету. Вы видите проблемное место и инспектируете его: на основе каких данных он отображен, какие блоки используются и в один клик попадаете в нужны шаблон, который вы можете опять же на лету отредактировать и увидеть изменения.
И так далее. На такие вещи сложно повесить метрику. Вот у нас блок из четыре файлов, можно было бы просто написать в README пример и человек копи-пастом бы создавал файлы. Но даже если бы один, всё равно это время, прочитать, скопировать, узнать куда путь до папки с блоками и создать там файл. А можно всего этого не писать и создать тулзу, которая сделает это. Можно пойти дальше, и с делать GUI, которые буду создавать все необходимые файлы и по завершению открывать IDE с нужным файлов. Этим шагом вы не просто сделаете удобный инструмент, но и не навязчиво покажете разрабу, где же лежат эти шаблоны ;]
В целом, всё это не так сложно сделать, многое уже сделано, главное желание, ну а если вы используете какое-нибудь популярное решение, то скорей всего это уже есть ;]
при старте приложение читает README.md, парсит список опций и их описания и, если вы используете неизвестную или недокументированную опцию, выдаёт ошибку.
Readme Driven Development? Довольно странное и сложное решение. Не лучше ли вытягивать документацию из кода, а не вытягивать код из документации?
Live Coding / Hot Reload?
Нет, потому, что:
- Во время активного редактирования файлов комп тормозит, гудит и жарит яичницу, так как каждый браузер, в котором открыта страница, в фоне что-то там "перезагружает".
- Стоит сохранить сломанный код и приложение напрочь ломается — приходится его перезагружать, чтобы не глючило.
- Состояние, полученное такими вот "горячими патчами" не идентично, получаемому "холодным стартом". Код может работать здесь и сейчас, но сломаться после перезагрузки.
- Перезагрузка одного лишь отредактированного файла не дружит со статической типизацией и переиспользованием CSS (примеси, константы и тп).
Раньше dev-страница загружалась примерно за 4-7сек, плюс вам нужно было потратить ещё какое-то время, чтобы получить нужное состояние приложения.
Попробуйте лучше делать страницы, которые загружаются менее чем за секунду и не теряют состояние при перезагрузке — тогда вам не потребуются никакие "горячие замены".
Readme Driven Development? Довольно странное и сложное решение. Не лучше ли вытягивать документацию из кода, а не вытягивать код из документации?
Для этого нужно узнать, а как запустить? Или у вас под рукой только доступ к gitlab/github, что делать? Дублировать доку?
Попробуйте лучше делать страницы, которые загружаются менее чем за секунду
В собранном состоянии, холодный старт приложения меньше ~800ms, а вот в dev не используются бандлы и холодный старт не такой быстрый, да, тут есть ещё над чем работать.
и не теряют состояние при перезагрузке — тогда вам не потребуются никакие "горячие замены".
Хм, т.е. нужно, чтобы после f5, даже раскрытый dropdown сохранял своё состояние? Допустим, но проблема с f5 останется. Каждый раз при редактировании, вам придется тратить на alt+tab / cmd+tab, нажать f5 и ждать. После загрузки страницы, браузер ещё должен промотать её в нужное место, это будет заметно, резкий и неприятный скачек, графика должна так же прогрузится. И если говорить про состояния, то вам придется хранить ещё все scrollTop для overflow: scroll/hidden и как-то сохранить какой элемент был в фокусе и восстановить его…
Может расскажите, как вы видите решение этой задачи, а то я чет написал и не верю, что можно добиться такой восстанавливаемости на чём-то хоть чуть-чуть сложнее todo-app :]
Для этого нужно узнать, а как запустить? Или у вас под рукой только доступ к gitlab/github, что делать? Дублировать доку?
Я вот тоже думаю, что должно быть наоборот command -h > README.md. Но эта дискуссия навела на мысль, что в command -h можно добавлять ссылку на подробное описание команд/флагов...
в dev не используются бандлы и холодный старт не такой быстрый
В dev-сервер'е basis.js для решения проблемы делается динамический бандл. По сути это просто JSON файл, где ключ – это имя файла, значение – его контент. Сервер внедряет этот скрипт (который сохраняет объект в некоторую глобальную переменную) в каждую отдаваемую html-страницу. Когда модульная система делает запрос к серверу за файлом (через xhr), она добавляет спец-заголовок. По этому заголовку сервер понимает, что это ресурс приложения и добавляет в бандл + начинает watch'ить этот файл, и при изменениях обновляет контент в бандле. При следующем обращении к бандлу, если в нем были изменения делается 'window.globalVar = ' + JSON.stringify(bundle). Модульная система инициализирует свой кэш бандлом (если есть). И если запрашиваемый ресурс есть в кэше, то берет оттуда или делает запрос к серверу. Так же есть коннект к серверу через ws, через который прилетают обновления по ресурсам, которые обновляют кэш модульной системы (если ресурс еще не инициализировался) или уже используемый, если его можно апдейтить. Первая загрузка страницы после старта сервера получается так же медленно (но не так медленно, как если собирать все приложение, так как запрашивается только необходимое), но последующие загрузки происходят почти так же быстро, как если бы это было собранно. Еще к серверу могут подключится клиенты, которые уже используют определенные файлы – тогда клиент присылает список файлов, а сервер их прогревает и наполняет бандл ресурсов, но это уже лирика…
Когда начинал писать думал, что все гораздо проще – просто уже давно работает, и об этом не задумываешься :)
не верю, что можно добиться такой восстанавливаемости
Я вот тоже не верю. И более того, даже если добиться этого на "сферических конях", то получится настолько сложное решение (и сложно поддерживаемое), что лучше его будет не использовать.
Курица или яйцо, да :] С документацией давно экспериментирую, в другом проекте, она генерируется на основе jsdoc в MD, но примеры находятся именно в markdown, т.е. они сначала вытягиваются из него, и компонуются с описаниями функция. Просто в писать примеры jsdoc совсем вырви глаз получается и не удобно жутко. Конечно можно полностью в код запихать, особенно с учетом появления template string, но всё же это не markdown и писать доку в коде, то ещё удовольствие.
Бандлы у нас есть, обираются r.js и это долго, но планы по оптимизации давно есть и ждут своего часа.
Бандлы у нас есть, обираются r.js и это долго
В том то и суть, что это не совсем бандл – то есть никакого разбора или анализа не делается. При этом ограничений на модульную систему не накладывается, она может быть какой угодно, как и формат файлов.
Думаю это правильнее называть ленивым клиентским кешем, чтобы не было путаницы.
Для этого нужно узнать, а как запустить? Или у вас под рукой только доступ к gitlab/github, что делать? Дублировать доку?
Например, для работы с API и бизнес-логикой у нас есть внутренняя JSSDK, документация которой генерируется на основе JSDoc3.
В собранном состоянии, холодный старт приложения меньше ~800ms, а вот в dev не используются бандлы и холодный старт не такой быстрый, да,
Ну так используйте бандлы, какие проблемы? :-)
Хм, т.е. нужно, чтобы после f5, даже раскрытый dropdown сохранял своё состояние?
Да, и состояние фокусировки, выделения, введённое значение в инпуте.
Каждый раз при редактировании, вам придется тратить на alt+tab / cmd+tab, нажать f5 и ждать.
Именно в этот момент я могу секунду подождать. А вот когда редактируешь файл, а система в этот момент лагает так как каждый браузер пытается перекомпилировать шаблоны — не очень приятно.
После загрузки страницы, браузер ещё должен промотать её в нужное место, это будет заметно, резкий и неприятный скачек
Не будет там никаких скачков. Например: http://nin-jin.github.io/chart/
Может расскажите, как вы видите решение этой задачи, а то я чет написал и не верю, что можно добиться такой восстанавливаемости на чём-то хоть чуть-чуть сложнее todo-app :]
Просто при реализации компонент делаем им поведение по умолчанию — хранить рантайм состояние в sessionStorage. Только для этого у компонент должен быть уникальный рантайм идентификатор, не меняющийся при перезагрузке.
Ну так используйте бандлы, какие проблемы? :-)
r.js медленно их собирает, но мы работает над этим.
каждый браузер пытается перекомпилировать шаблоны
Перекомпилировать только один маленький шаблон, который моментально доставляется через WS.
Не будет там никаких скачков. Например: http://nin-jin.github.io/chart/
Ну простая же страничка, добавьте графику, список побольше, походы в api и всё уже не так радужно.
Просто при реализации компонент делаем им поведение по умолчанию — хранить рантайм состояние в sessionStorage
Я так то же могу написать, но от этого реальностью мои слова не станет. Во-вторых, представим, что чудо произошло и всё получилось, но эта функциональность нужна только в dev-режиме, потом что в бою dropdown не должен после f5 остаться раскрытым, значит придется дополнительно программировать/конфигурировать эту логику.
r.js медленно их собирает, но мы работает над этим.
И я даже знаю почему — чтобы склеить все файлы в один ему приходится каждый файл транспилировать в другой формат модулей. Если вы сразу будете писать имя модуля в самом модуле, то r.js можно будет с лёгкостью заменить на какой-нибудь concat-with-sourcemaps, который соединяет файлы практически мгновенно.
Перекомпилировать только один маленький шаблон, который моментально доставляется через WS.
А потом он применяется к списку на 10000 элементов и привет тормоза. Я не спорю, что в некоторых простых случаях этим можно пренебречь, но если мы говорим о большом и сложном приложении, то экономия нажатий клавиш не окупает постоянное насилие над процессором.
Ну простая же страничка, добавьте графику, список побольше, походы в api и всё уже не так радужно.
Ничего принципиально не изменится, на самом деле. Я бы показал демку, но она сейчас сломана. :-) Чуть позже починю. Но суть простая — перемещаем скроллинг сразу после того как отрендерили контент.
в бою dropdown не должен после f5 остаться раскрытым
Обоснуйте. На самом деле это интересная фича — вы можете обновлять пользователю приложение, пока он с ним работает и он ничего даже не заметит :-)
И я даже знаю почему — чтобы склеить все файлы в один ему приходится каждый файл транспилировать в другой формат модулей.
Ноу, просто r.js использует есприму для получения конфигов и разбора define, но это не главное, в целом он написан и работает крайне не оптимально.
А потом он применяется к списку на 10000 элементов и привет тормоза.
Это ваши домыслы. Обновить 10К элементов быстрей, чем обновить всю страницу и создать те же 10К, а так же остальные 50К элементов, но кроме этого, ещё и сервер нагрузить, который тоже нужно написать конечно быстрым, это я уже понял ;]
Обоснуйте.
Обосновать что? Что dropdown после f5 должен быть закрыт? Ну не знаю, наверно чтобы просто не выглядеть глюком.
Окей, возьмем dropdown и будем хранить его состояние в sessionStorage, как вы и предложили, при f5 нужно восстанавливать его состояние в dev-окружении, но так же при горячем апдейте в бою. Окей, возможно мы больше не считаем глюком его раскрытое состояние при F5, пусть будет так. Но что делать с этим состоянием, если я перешел на другую страницу, sessionStorage не обнулится, или его сбрасывать при изменении маршрута? Возможно, возможно есть ещё какие-то факторы, которые я просто не могу учесть.
Даже сейчас, вырисовывается какая-то хрупкая картина для одного элементарного состояния, что не скажешь про горячую замену, где просто получили новый шаблон и обновил все блоки, это очень просто.
Ноу, просто r.js использует есприму для получения конфигов и разбора define, но это не главное, в целом он написан и работает крайне не оптимально.
Я разве не то же самое сказал? :-)
Обновить 10К элементов быстрей, чем обновить всю страницу
Не обновлять страницу — ещё быстрее. Я ещё раз повторяю, тут проблема в загрузке системы бесполезной работой и тормозах при редактировании кода вплоть до заикания курсора, а не в том, что "долго" приходится ждать, пока страница перезагрузится, когда это требуется.
Обосновать что? Что dropdown после f5 должен быть закрыт? Ну не знаю, наверно чтобы просто не выглядеть глюком.
На мой взгляд — приятная особенность, но никак не глюк. Например, открыл я дропдаун, а там нет нужного пункта меню, так как нет прав. Открыл отдельную вкладку, дал права (или админу написал), вернулся на текущую и обновил — опа, появился нужный пункт.
Но что делать с этим состоянием, если я перешел на другую страницу, sessionStorage не обнулится, или его сбрасывать при изменении маршрута?
Да, очевидно состояние дропдауна лучше хранить не в sessionStorage, а в history state.
Не обновлять страницу — куда быстрее.
Ха-ха, «нет», как будем выяснять, чьё НЕТ сильней? :]
Давайте так, создать один элемент Х, запуск приложения и создание остальных элементов (которые мы не рассматриваем) пусть будет Y, обновление одного элемента U, притом U <= X (обновляются только измененные участки). Итого получаем:
- F5, всегда
X*10K + Y - HOT, первый запуск:
X*10K + Y, обновления:U*10K
М?
На мой взгляд — приятная особенность, но никак не глюк.
Да, именно на ваш.
Например, открыл я дропдаун, а там нет нужного пункта меню, так как нет прав. Открыл отдельную вкладку, дал права (или админу написал), вернулся на текущую и обновил — опа, появился нужный пункт.
Очень странный пример, такие вещи правильно сделать через WS, просто обновив состояние приложения.
Да, очевидно состояние дропдауна лучше хранить не в sessionStorage, а в history state.
Пока мне очевидно, что мы на ходу выдумываем сложноконь, но забавный, я бы посмотрел на боевую реализацию.
F5, всегда X10K + Y
HOT, первый запуск: X10K + Y, обновления: U*10K
Подкину ещё дровишек — ленивый рендеринг, позволяет мгновенно открыть страницу любой сложности. например: http://eigenmethod.github.io/mol/app/supplies/
Да, именно на ваш.
Как будем выяснять чей взгляд правильный? :-)
Очень странный пример, такие вещи правильно сделать через WS, просто обновив состояние приложения.
Не менее странный кейс — когда я открыл дропдаун, прицелился на нужный пункт, а он улетел куда-то, потому, что список в реальном времени обновился. С рилтаймовыми обновлениями тоже нужно быть осторожными.
Подкину ещё дровишек
А это тут причем? Мы тут говорим про обновление 10К элементов, как не крути, как не «ленись», но обновить их быстрей, чем создать заново.
При том, что я уже не раз повторял:
Я ещё раз повторяю, тут проблема в загрузке системы бесполезной работой и тормозах при редактировании кода вплоть до заикания курсора, а не в том, что "долго" приходится ждать, пока страница перезагрузится, когда это требуется.
А вы опять про скорость доставки обновлений, которая совершенно не критична, если не превышает секунды. А с ленивым рендерингом секунду она не превышает.
Ну не верю, вы уж простите.
Поймите, я говорю о системе, которая работает, быстро и просто, изменения происходят за доли секунд, лучше сказать мгновенно. А вы меня пытается убедить, что это не правда.
Как ленивая загрузка решить проблему 10К элементов? Никак. Значит у вас будут эти 10К как-то по частям добавляться и потом лениво инициализироваться. Ну так, у себя в приложении я тоже не дурак, и делаю умные списки, которые отображают только видимую часть, но это не из-за того, что HOT обновления медленные, дело в мобилках и количестве DOM-элементов.
В целом странный диалог получается, такое ощущение, что вы на ходу выдумываете, вот уже до ленивой загрузки до брались, дальше можно про инлайн данных, кэширование через localStorage, потом умное кэширование через ServiceWorker и так далее… без обид, но я так не играю.
Поймите, я говорю о системе, которая работает, быстро и просто, изменения происходят за доли секунд, лучше сказать мгновенно.
Мгноверно происходит разве что манкипатчинг объектов. Далее половина приложения должна обновить своё состояние в соответствии с новой реализацией методов. Одно неосторожное движение и каждый браузер уходит в бесконечный цикл, отжирая по одному ядру процессора. Подобные приколы хотрелоада просто вымораживают.
Как ленивая загрузка решить проблему 10К элементов?
Ленивый рендеринг, а не ленивая загрузка.
Ну так, у себя в приложении я тоже не дурак, и делаю умные списки, которые отображают только видимую часть
Ага, всё ручками. "Умное дерево" тоже будете каждый раз вручную реализовывать?
дальше можно про инлайн данных, кэширование через localStorage, потом умное кэширование через ServiceWorker и так далее…
Давайте про эту ерунду не будем :-)
Одно неосторожное движение и каждый браузер уходит в бесконечный цикл
Одно неосторожнее движение и после F5 вы уходите в бесконечный цикл. Откуда вы все эти доводы берете, это личный опыт или домысел?
Ленивый рендеринг, а не ленивая загрузка.
А что такое ленивый рендеринг? Какой смысл вы вкладываете в эти слова?
Ага, всё ручками. "Умное дерево" тоже будете каждый раз вручную реализовывать?
Что значит каждый раз? Я не понимать. А как не каждый раз? Написать базовый функционал, которые расширять под проект, ну ок. Или что?
Одно неосторожнее движение и после F5 вы уходите в бесконечный цикл. Откуда вы все эти доводы берете, это личный опыт или домысел?
Это не страшно, ибо в этот момент я тестирую приложение в конкретном браузере и могу остановить работу в любой момент. Страшно — когда эта фигня происходит в фоне. Это мой и не только мой опыт от использования горячей перезагрузки.
А что такое ленивый рендеринг? Какой смысл вы вкладываете в эти слова?
Очевидно, рендериг лишь того, что возможно попадает в видимую область.
Что значит каждый раз?
В каждом месте, где выводятся большие объёмы данных, чтобы не тормозило.
А как не каждый раз?
Очевидно, так, чтобы решение не полагалось на то, что разработчик не дурак и навелосипедил умный список. В идеале — чтобы ленивость была по умолчанию и не требовала от разработчика особого к себе внимания.
Это мой и не только мой опыт от использования горячей перезагрузки.
Сочувствую, но мы пока не столкнулись с подобной проблемой. Возможно наш «велосипед» безопасен, да и сам код пишем прямо ;] Конечно, бывает и падает (при обновлении JS), но не зависает. С шаблонами и CSS никогда не было проблемы, даже не могу представь, откуда они могут быть.
Очевидно, рендериг лишь того, что возможно попадает в видимую область.
В каждом месте, где выводятся большие объёмы данных.
В идеале — чтобы ленивость была по умолчанию и не требовала от разработчика особого к себе внимания.
Не согласен, частная реализация всегда лучше общей. Кроме этого, все эти разговоры про умный рендер сводятся к какому-нибудь простецкому списку и монитору с крошечным разрешением, выводя максимум 20-30 строк.
Сочувствую, но мы пока не столкнулись с подобной проблемой. Возможно наш «велосипед» безопасен, да и сам код пишем прямо ;]
Я бы с удовольствием почитал, как вы решили описанные мной проблемы.
Не согласен, частная реализация всегда лучше общей.
Поэтому вы пилите свой фреймворк.
Кроме этого, все эти разговоры про умный рендер сводятся к какому-нибудь простецкому списку и монитору с крошечным разрешением, выводя максимум 20-30 строк.
Не уловил какую мысль вы тут пытаетесь донести.
Поэтому вы пилите свой фреймворк.
Нооу, ну зачем вы так меня :[ Никаких фреймворков, боже упаси, хотя очень много своего кода, но тут специфика самого проекта.
Не уловил какую мысль вы тут пытаетесь донести.
Я говорю, рендер видимой зоны по умолчанию только в сказках, в реальности все примеры, на которых это показывают, очень упрощены.
Как же хочется, чтобы вот это кончилось, чтобы браузер сам всё это решал, чтобы не было этих vdom и умных «списков» и т.п. Не нужен мне ServiceWorker, обойдусь :]
Никаких фреймворков, боже упаси, хотя очень много своего кода, но тут специфика самого проекта.
У вас фреймворкофобия? :-)
Я говорю, рендер видимой зоны по умолчанию только в сказках, в реальности все примеры, на которых это показывают, очень упрощены.
Чуть выше я уже привёл "сказочный" пример. Можете так же глянуть более наглядный пример: http://nin-jin.github.io/todomvc/examples/mol/ — подобавляйте задач и обратите внимание на пропадание футера с определённого момента.
Ну вот два ярких примера, о чем я говорю, на экран влезает максимум 20-30 строчек, в ваших примерах ещё меньше.
- http://eigenmethod.github.io/mol/app/supplies/ — притормаживает, скролл неплавный, таймлайн тоже показывается просадку fps
- http://nin-jin.github.io/todomvc/examples/mol/ — ну это очередной todos-mvc, слишком просто и к реальности не имеет отношения.
Ну вот два ярких примера, о чем я говорю, на экран влезает максимум 20-30 строчек, в ваших примерах ещё меньше.
Совершенно не важно сколько влезает на экран. Важно, что время открытия страницы не пропорционально числу строк.
притормаживает, скролл неплавный, таймлайн тоже показывается просадку fps
Я работаю над этим. Скроллинг подтормаживает только если его дёргать мышью за скроллбар. Если использовать колесо или палец, то всё плавно. Думаю троттлинг должен помочь.
ну это очередной todos-mvc, слишком просто и к реальности не имеет отношения.
обратите внимание на пропадание футера с определённого момента. И для этого не написано ни единой дополнительной строчки кода. То есть рендерер сам понял, что футер (который находится вообще говоря вне списка задач) точно не попадает в видимую область и исключил его из DOM. А так как компонент не рендерится, то и данные для него не подготавливаются и не загружаются. Что даёт в том числе и ленивую загрузку без каких-либо телодвижений со стороны разработчика.
На маке нет скрола, притормаживает на трекпаде (не сильно, но заметно)
Совершенно не важно сколько влезает на экран. Важно, что время открытия страницы не пропорционально числу строк.
Как раз это и важно, если у вас в видимую часть умещается 10К элементов, как не крути, вам придется их вывести.
обратите внимание на пропадание футера с определённого момента.
Интересно выглядит, да. Существующие решения все заточены под списки, общей реализации наверно только у вас и видел. Но примеры слишком простые, а приложение выше уже показывает проблемы.
Но, я думаю вы правильною тему исследуете, потому что если судить по таким статьям, браузер этому учить никто не собирается.
А можете вкратце описать, как именно вы понимаете, что ноду нужно не нужно вставлять?
Как я понял, вам умный рендер сейчас работает только на отсекание нижней части или умеет и верхушку? Хотя не важно, низ тоже интересен, как именно у вас происходит решение, что ноду, нужно вставить? Каждый раз запрашиваете позицию у parent.lastChild? Или умнее?
Запрашивать позицию элемента дорого и не надёжно (при ресайзе блока всё поедет, а отслеживать размер блока — дорого). У меня там реализована простейшая логика:
- За базовую высоту вьюпорта берётся размер окна.
- Компонент "скроллер" увеличивает размер вьюпорта для дочерних компонент на смещение скролла.
- Для любой компоненты может быть задана минимальная высота — формулой или константой.
- Компонент "листер" задаёт себе минимальную высоту как сумму минимальных высот вложенных компонент. Кроме того, рендерит внутри себя лишь те компоненты, суммарная минимальная высота которых превышает высоту вьюпорта.
Таким образом получается отсечение снизу с некоторой избыточностью. Отсечение сверху уже сложнее реализовать.
Чёрт, хабр, что ты делаешь… продолжу
Как будем выяснять чей взгляд правильный? :-)
Никак, вы можете делать в своё приложении как хотите. Просто окружающий мир ведет себя именно так, «дродауны» не открыты после restart'а системы. Какие-то части всё же сохраняют состояния, но не повально, это поведение продумано заранее.
Не менее странный кейс — когда я открыл дропдаун, прицелился на нужный пункт,
Вы же говорили про нехватку прав, он просто раздизаеблится.
Просто окружающий мир ведет себя именно так, «дродауны» не открыты после restart'а системы.
Реальный мир как раз так себя и ведёт — если я открыл книгу, вышел погулять, а потом вернулся, то книга останется открытой.
Вы же говорили про нехватку прав, он просто раздизаеблится.
Мы говорим о решениях и их поведениях в различных кейсах.
Реальный мир как раз так себя и ведёт — если я открыл книгу, вышел погулять, а потом вернулся, то книга останется открытой.
В реально мире, если вы закроете и отроете книгу, то только на рандомной странице, чтобы открыть на нужной, вам закладку нужно использовать. Во-вторых, под реальный миром я имел ввиду мир OS и приложений, декстопные, мобильные, неважно.
Мы говорим о решениях и их поведениях в различных кейсах.
Нет, вы с самого начала говорите о несуществующем единороге, который лучше и быстрей чем горячая замена.
Читаем первоисточник:
Incremental DOM is a library for building up DOM trees and updating them in-place when data changes. It differs from the established virtual DOM approach in that no intermediate tree is created (the existing tree is mutated in-place).
ИМХО, с таким набором инструментов быстро стартовать сможет только разработчик, который с ними всеми знаком. Неподготовленному ещё нужно будет потратить кучу времени, чтобы разобраться, как работают инструменты (особенно велосипеды), прежде чем начать разбираться с тем, как работает приложение.
Статья написана на основе реального опыта, так что новому разработчику нужно потратить ровно 5-10 минут на чтение README.md, больше от него ничего не требуется. А так как у нас разработчики частенько ротируются между проектами, проверенно не однократно. Поймите, все эти инструменты сделаны именно для того, чтобы не тратить время, если бы это было не так, зачем бы они тогда были нужны?
Сейчас на рынке есть инструменты на любой вкус и цвет, кроме этого Feast всё же создан для решения наших задач. Так что нет, не буду отвлекать людей :] Я только хотел показать, что из готовых кирпичиков можно создать решение именно под себя и свой проект, а не тратить бесценное время на попытку прогнуть ваш проект под очередное коробочное решение.
Frontend: Разработка и поддержка (+голосование)