Если я правильно понял, получится что-то очень сильно напоминающее инкрементальный ребилд, который есть во всех основных инструментах сборки.
Выгода будет только при первой сборке таким образом, но при этом мы получаем возможность совершенно фантастических ошибок с кэшированными файлами, дебажить такое бывает непросто.
Сложность выглядит избыточной когда есть уже готовые инструменты, которые работают молниеносно и всё что мне требуется там уже есть :)
Были вопросики к module federation (давно не смотрел за обновлениями), но это не критично.
Привет! Спасибо за конструктив, я уж думал зря всё это писал :)
К сожалению, даже сейчас ещё на странице остаётся старый фронт с фильтром и для него всё ещё используется старый Angular. Надеюсь, скоро дойдёт и до него очередь.
Поэтому да, грузятся обе библиотеки одновременно.
Впрочем мы и React на страницу не добавляли - он там присутствует уже для других отдельных фронтов, например для шапки сайта.
Спорить не готов, потому как если честно, не очень сильно меня они беспокоят :) Просто лёгкое раздражение от избыточности.
Что смогу - отвечу.
С иммутабельными файлами - да, всё верно. Смущает, что таким образом мы добавляем два места с потенциальными ошибками - вычистка старых версий и передача бэкенду информации об имени сборки. Способов там довольно много, но даже самый (для нас) экономный приводит к лишнему чтению с диска.
Сейчас мы обычно используем часто подход с SSI включением html, который генерируется вместе с фронтом и содержит <script src> на нужные файлы.
Но всё-таки хотелось бы жить без подобных костылей.
Исходные имена и хэш отлично, но (я понимаю, это звучит немного упорото) я экономил байты :) Как раз для этого изначально определены приоритеты проекта были.
Про переиспользование.
У нас 13 команд, в которых есть фронт и фронтендеры. CSS Modules дали свободу в плане "не портить друг другу жизнь больше никогда", это большой плюс.
Но и это же (в совокупности с рядом других проблем, вроде множества версий одинаковых компонентво) привело к тому, что на любой странице сайта можно найти пять-десять стилей одинаковых для кнопки, например. Это уйма мусорного траффика.
Поэтому сейчас мы двигаемся в сторону разделения визуала и поведения - библиотека компонентов + свой css-framework, которые в ближайшем будущем будут заменять все старые компоненты так, чтоб стили были определены и подгружены единожды.
Понятно, что при этом индивидуальные какие-то истории останутся в проектах.
И там будут всё те же хэшированные имена, как и везде.
Никогда себе такой шлем не куплю.
1) не доверю череп непонятной оболочке.
2) многие из тех, кто на мотоцикле ковырялся в носу и говорил по телефону — уже не с нами.
3) лучше лишний раз в зеркала посмотреть, чем на мультики на стекле.
Все бывает по разному. Можно устроить прекрасное сообщество, которое в активном сотрудничестве напишет замечательную программу. А можно не уследить, набегут гоблины и получиться конвульсивно умирающая, когда-то хорошая, полукаркасина. В коммерческом - то же самое, только в других формах. Я собственно только потому и написал.
А вообще, открытые исходники - это конечно замечательно, особенно с точки зрения программиста. Чего тут спорить :)
Коммерческое - то за счет чего вся отрасль так быстро выросла.
Открытое - возможно, следующая всеобщая стадия.
Кстати существует множество таких устройств. Причем действующих не только в квартире, но и, допустим, в саду.
Правда за работоспособность не поручусь, не проверял :)
В сети можно найти.
я про него узнал пять секунд назад ¯\_(ツ)_/¯
спасибо, однозначно стоит попробовать
мне нравятся штуки, дающие лёгкий и быстрый профит
ага, теперь понял.
Не могу сказать за всех, но мне бы так не хотелось работать в данном случае.
Если бы эти компоненты активно использовались ещё где-то - тогда есть понятные резоны.
А так, текущий процесс: поправил любой файл, переключился на браузер - посмотрел изменения.
Переходим на пакеты: поправил любой файл, git commit, git push, билд пакета, пуш пакета, npm i, ребилд проекта, пошёл посмотрел изменения.
Да, можно всё это костылями как-то обложить, чтоб работало само, но зачем.
Если я правильно понял, получится что-то очень сильно напоминающее инкрементальный ребилд, который есть во всех основных инструментах сборки.
Выгода будет только при первой сборке таким образом, но при этом мы получаем возможность совершенно фантастических ошибок с кэшированными файлами, дебажить такое бывает непросто.
Сложность выглядит избыточной когда есть уже готовые инструменты, которые работают молниеносно и всё что мне требуется там уже есть :)
Были вопросики к module federation (давно не смотрел за обновлениями), но это не критично.
Привет! Спасибо за конструктив, я уж думал зря всё это писал :)
К сожалению, даже сейчас ещё на странице остаётся старый фронт с фильтром и для него всё ещё используется старый Angular. Надеюсь, скоро дойдёт и до него очередь.
Поэтому да, грузятся обе библиотеки одновременно.
Впрочем мы и React на страницу не добавляли - он там присутствует уже для других отдельных фронтов, например для шапки сайта.
Спорить не готов, потому как если честно, не очень сильно меня они беспокоят :)
Просто лёгкое раздражение от избыточности.
Что смогу - отвечу.
С иммутабельными файлами - да, всё верно. Смущает, что таким образом мы добавляем два места с потенциальными ошибками - вычистка старых версий и передача бэкенду информации об имени сборки. Способов там довольно много, но даже самый (для нас) экономный приводит к лишнему чтению с диска.
Сейчас мы обычно используем часто подход с SSI включением html, который генерируется вместе с фронтом и содержит <script src> на нужные файлы.
Но всё-таки хотелось бы жить без подобных костылей.
Исходные имена и хэш отлично, но (я понимаю, это звучит немного упорото) я экономил байты :)
Как раз для этого изначально определены приоритеты проекта были.
Про переиспользование.
У нас 13 команд, в которых есть фронт и фронтендеры. CSS Modules дали свободу в плане "не портить друг другу жизнь больше никогда", это большой плюс.
Но и это же (в совокупности с рядом других проблем, вроде множества версий одинаковых компонентво) привело к тому, что на любой странице сайта можно найти пять-десять стилей одинаковых для кнопки, например. Это уйма мусорного траффика.
Поэтому сейчас мы двигаемся в сторону разделения визуала и поведения - библиотека компонентов + свой css-framework, которые в ближайшем будущем будут заменять все старые компоненты так, чтоб стили были определены и подгружены единожды.
Понятно, что при этом индивидуальные какие-то истории останутся в проектах.
И там будут всё те же хэшированные имена, как и везде.
С лёгкостью можно с помощью этой техники отстрелить себе ногу.
Помогут хорошие практики: делить работу на мелкие части, гигиена (удаление неактуального)
И речь тут про сложность и чистоту кода.
Скорость проекта работающего с базой будет упираться в походы в базу, не в if.
Всё так, добавил. Спасибо :)
Пока ещё не собирает. Это из заделов на будущее. Но если поставишь задачу - начнёт собирать :)
Результаты бенчмарков вдохновляют, без капли иронии.
Расстраивает необходимость держать html в строках.
Это не то чтобы блокер, но для работы с html написана масса инструментов, которые в таком случае использовать не выйдет.
Когда речь идёт про отзывчивость интерфейса и скорость загрузки, DX хорошо бы отодвигать на второй план. Не все готовы, к сожалению.
Делают по слепку из силикона в некоторых конторах, продающих слуховые аппараты.
1) не доверю череп непонятной оболочке.
2) многие из тех, кто на мотоцикле ковырялся в носу и говорил по телефону — уже не с нами.
3) лучше лишний раз в зеркала посмотреть, чем на мультики на стекле.
sparkviewengine.com/
Уже поставил, играюсь - ковыряюсь
Все бывает по разному. Можно устроить прекрасное сообщество, которое в активном сотрудничестве напишет замечательную программу. А можно не уследить, набегут гоблины и получиться конвульсивно умирающая, когда-то хорошая, полукаркасина. В коммерческом - то же самое, только в других формах. Я собственно только потому и написал.
А вообще, открытые исходники - это конечно замечательно, особенно с точки зрения программиста. Чего тут спорить :)
Коммерческое - то за счет чего вся отрасль так быстро выросла.
Открытое - возможно, следующая всеобщая стадия.
Ясное дело, что во втором случае вы будете писать его качественнее. Чтобы не опозориться. И чтобы другие разобрались.
В хорошей, грамотной команде эти факторы как раз сильнее работают.
Я естественно, не буду утверждать, что много где сложились такие команды. :)
Правда за работоспособность не поручусь, не проверял :)
В сети можно найти.
Хотя прокат живого существа не шибко этичен - с такой экзотикой как хамелеоны это наверняка сработало бы.