Об этом и речь, то что фактически большая часть листа вне view port не важно, ведь тестируется не это, а работа с большим количеством DOM объектов, они могли нарисовать таблицу где каждая ячейка-пиксель и ее отрисовывать. На то он и бенчмарк, он тестирует конкретный аспект.
Беру код из вашего бенчмарка, переношу на последнюю версию и все по нулям https://github.com/krausest/js-framework-benchmark Оказывается вы под себя бенчмарк переписали чтобы smol лучше себя показал? Ну ок, удачи с таким подходом
Т.е у яндекс станции с zigbee все еще нет нативной интеграции в home assistant? Мне кажется для гиков которые собирают умный дом (а умный дом это все еще занятие для гиков) это был бы большой плюс, чтобы купить яндекс станцию, а не home pod.
Ведь в HomeKit через bridge все устройства появляются в экосистеме apple и управляются без облака почти со всех устройств. С HomePod можно слушать музыку с любым приложением с iphone и не тратить деньги на подписку яндекс.музыку
А что современное не изотерическое посоветуете, чтобы бандл минимальный (соглашусь на два разных фреймворка для двух разных кейсов: для большого приложения, например 1000 компонентов и для маленького: десятки копмонентов) и в бенчмарках быстрый.
400 км/ч максимальная скорость и это на открытом воздухе, перегрузок каких-то в вагоне нет, все очень плавно, можно ходить по вагону, даже ремней нет
Когда 400 км/ч быстрее чем 7 минут насколько я помню
А вот если вы ездили в тесле, то там ремни нужны, а дальше возникает трэйдофф: мы делаем электричку как маглев где можно стоять в проходе или поезд-болид как теслу, где нужны стюарды и всех пристигнуть к сиденью
Просто нужно помнить что микросервисы это организационный, а не технический паттерн. Можно считать что один репозиторий – одна команда. Если до этого это команда зачем-то комитила код в больше чем один репозиторий на постоянной основе, т.е практически любое изменение превращалось в несколько MR/PR в разные репозитории (кейс команды куда я пришел), то "монорепо" правильное решение, от ревью до сборки все упрощается. А хороший билд тул с кешированием (gradle в нашем случае) решает проблему времени сборки.
Единственное, что в итоге в команде осталось разделено на отдельные репозитории – фронтенд от бекенда и несколько стабильных библиотек.
Нагло врете!) только wasm часть весит 1.6мб, еще 400кб js Но кого это волнует, подход такой что серверная часть запущена на клиенте и можно хостить хоть 100мб бандлы
Обновился ради интереса на самую свежую версию:
"@automerge/automerge": "^2.1.1",
Все работает, webpack 5, firefox 118.0b9
если вы попробуете использовать его как любой redux-лайк стор
Зачем его использовать как стор? Упрощенно это готовая реализация редьюсера с поддержкой синхронизации в CRDT. Получаем ивент, мутируем документ внутри automerge, получаем новый immutable документ, который мапим на redux стор. В mobx так не получится, потому что мутируются сразу объекты, а нам нужно получать поток изменений. Можно конечно руками в mobx туда-сюда мапить объекты, но тогда никаких преимуществ от mobx не остается.
Причем automerge как раз таки любит когда внутри него мутируется стейт, а не просетовается полностью новый объект (как, скорее всего, пришлось бы делать с mobx).
Ну и вишенка, через те же action получаем поток ченджей с других клиентов. И мапим так же на стор.
ни какого отношения к Redux не имеющий даже близко
Кроме того факта, что почему-то (странно, ведь отношения никакого нет) практически любой redux-лайк стор отлично кладется на него, да и реализация на rust уже достаточно быстрая https://automerge.org/blog/automerge-2/
Прям из документации одного из двух самых популярных CRDT библиотек:
Immutable state. An Automerge object is an immutable snapshot of the application state at one point in time. Whenever you make a change, or merge in a change that came from the network, you get back a new state object reflecting that change. This fact makes Automerge compatible with the functional reactive programming style of React and Redux, for example.
Так и тут, где-то будет удобнее event sourcing (redux, etc) – offline/local first приложения
А почему эту часть проигнорировали? Экшены в Redux это практически CRDT, вот и получается то что в mobx пришлось как-то костылить, в Redux "нативно" работает
Ну и в целом строгость Redux-like подходов может нравиться команде, быть идеологически правильной, а не "я тут мутировал, а там взорвалось". На redux с эффектами на rxjs можно делать очень интересные вещи.
ps. Я согласен, что в среднем по индустрии mobx вполне себе, у нас сейчас на фронте как раз он (я правда не занимаюсь написанием фронтового когда), но в pet проекте у меня redux, потому что он local first
Как обычно: it depends. Для размышления: в микросервисах есть множество паттернов коммуникации, от синхронных вызовов, до event sourcing. И нет одного "лучшего" способа. Так и тут, где-то будет удобнее event sourcing (redux, etc) – offline/local first приложения, где-то mobx, где-то zustand или вообще достаточно встроенного useSyncExternalStore и наколеночный стор.
Графики все-таки нужно с 0 делать, почему-то только у tivi это так, а дальше нужно напрягать мозг и смотреть на цифры, потому что картинка теряет смысл
А вообще вывод который я для себя сделал: самый cost-effective mac - air, собственно с него и пишу. Скажу еще что после mbp 16" i7 производительность air порадовала.
В целом действительно софт от Synology мусорный, что веб версия, что клиенты для десктопа и мобилки. Да и сделать дома 10Gbit сеть, иметь внешний канал хотя бы в 1Gbit да еще и отдать кучу денег за такой Synology далеко не все могут себе позволить.
Я попользовался своим DS416J 5 лет (недавно обновился до DSM7) и собрал в итоге NAS в Full Tower корпусе с UnRaid. Synology до сих пор отлично работает для торрентов и plex, бекапа в glacier. Теперь буду использовать только для resilio sync чтобы сбекапить самое важное с основного NAS и оставлю бекап в glacier - все таки это сделано удобно на Synology.
Об этом и речь, то что фактически большая часть листа вне view port не важно, ведь тестируется не это, а работа с большим количеством DOM объектов, они могли нарисовать таблицу где каждая ячейка-пиксель и ее отрисовывать. На то он и бенчмарк, он тестирует конкретный аспект.
Ну ок, удачи с таким подходом
Беру код из вашего бенчмарка, переношу на последнюю версию и все по нулям https://github.com/krausest/js-framework-benchmark
Оказывается вы под себя бенчмарк переписали чтобы smol лучше себя показал?
Ну ок, удачи с таким подходом
@gmtd@nin-jin
$mol не подходит по критерий изотеричости
JQuery под критерий современности, да и ценности в нем никакой нет, лучше уже на ваниле писать
solid.js - и по бенчмаркам хорош (кстати $mol там нет, я думаю автору $mol стоит добавить https://krausest.github.io/js-framework-benchmark/2024/table_chrome_127.0.6533.72.html), но темплеты с
<For,<Indexконечно ужасно смотрятся. В итоге опять либо брать Inferno/React, либо вообще простые вещи пишешь на htmx/vanillaИ оставите такие же разводы и пыль будет прилепать с удвоенной скоростью.
Только влажная микрофибра с водой из-под осмоса/дистиллированная вода
Т.е у яндекс станции с zigbee все еще нет нативной интеграции в home assistant? Мне кажется для гиков которые собирают умный дом (а умный дом это все еще занятие для гиков) это был бы большой плюс, чтобы купить яндекс станцию, а не home pod.
Ведь в HomeKit через bridge все устройства появляются в экосистеме apple и управляются без облака почти со всех устройств.
С HomePod можно слушать музыку с любым приложением с iphone и не тратить деньги на подписку яндекс.музыку
В общем яндекс впереди планеты всей :)
А что современное не изотерическое посоветуете, чтобы бандл минимальный (соглашусь на два разных фреймворка для двух разных кейсов: для большого приложения, например 1000 компонентов и для маленького: десятки копмонентов) и в бенчмарках быстрый.
400 км/ч максимальная скорость и это на открытом воздухе, перегрузок каких-то в вагоне нет, все очень плавно, можно ходить по вагону, даже ремней нет
Когда 400 км/ч быстрее чем 7 минут насколько я помню
А вот если вы ездили в тесле, то там ремни нужны, а дальше возникает трэйдофф: мы делаем электричку как маглев где можно стоять в проходе или поезд-болид как теслу, где нужны стюарды и всех пристигнуть к сиденью
Сервисы в SOA точно так же скейлятся, а шина отвечает за распределение нагрузки по инстансам (google: ultraesb round robin).
Все технологии необходимые для микросервисов были еще в эпоху расцвета SOA, от того что стек стал моднее SOA не мог же стать микросервисами?
Просто нужно помнить что микросервисы это организационный, а не технический паттерн. Можно считать что один репозиторий – одна команда. Если до этого это команда зачем-то комитила код в больше чем один репозиторий на постоянной основе, т.е практически любое изменение превращалось в несколько MR/PR в разные репозитории (кейс команды куда я пришел), то "монорепо" правильное решение, от ревью до сборки все упрощается. А хороший билд тул с кешированием (gradle в нашем случае) решает проблему времени сборки.
Единственное, что в итоге в команде осталось разделено на отдельные репозитории – фронтенд от бекенда и несколько стабильных библиотек.
Нагло врете!) только wasm часть весит 1.6мб, еще 400кб js
Но кого это волнует, подход такой что серверная часть запущена на клиенте и можно хостить хоть 100мб бандлы
Обновился ради интереса на самую свежую версию:
"@automerge/automerge": "^2.1.1",Все работает, webpack 5, firefox 118.0b9
Зачем его использовать как стор? Упрощенно это готовая реализация редьюсера с поддержкой синхронизации в CRDT. Получаем ивент, мутируем документ внутри automerge, получаем новый immutable документ, который мапим на redux стор. В mobx так не получится, потому что мутируются сразу объекты, а нам нужно получать поток изменений. Можно конечно руками в mobx туда-сюда мапить объекты, но тогда никаких преимуществ от mobx не остается.
Причем automerge как раз таки любит когда внутри него мутируется стейт, а не просетовается полностью новый объект (как, скорее всего, пришлось бы делать с mobx).
Ну и вишенка, через те же action получаем поток ченджей с других клиентов. И мапим так же на стор.
Кроме того факта, что почему-то (странно, ведь отношения никакого нет) практически любой redux-лайк стор отлично кладется на него, да и реализация на rust уже достаточно быстрая https://automerge.org/blog/automerge-2/
Погуглив нашел даже такое: https://github.com/local-first-web/state
Прям из документации одного из двух самых популярных CRDT библиотек:
А почему эту часть проигнорировали? Экшены в Redux это практически CRDT, вот и получается то что в mobx пришлось как-то костылить, в Redux "нативно" работает
Ну и в целом строгость Redux-like подходов может нравиться команде, быть идеологически правильной, а не "я тут мутировал, а там взорвалось". На redux с эффектами на rxjs можно делать очень интересные вещи.
ps. Я согласен, что в среднем по индустрии mobx вполне себе, у нас сейчас на фронте как раз он (я правда не занимаюсь написанием фронтового когда), но в pet проекте у меня redux, потому что он local first
Как обычно: it depends.
Для размышления: в микросервисах есть множество паттернов коммуникации, от синхронных вызовов, до event sourcing. И нет одного "лучшего" способа. Так и тут, где-то будет удобнее event sourcing (redux, etc) – offline/local first приложения, где-то mobx, где-то zustand или вообще достаточно встроенного useSyncExternalStore и наколеночный стор.
Вот так вот одна технология во всем лучше, чем другая? Нашли ту самую серебряную пулю стейтменеджмента?
Почему было не взять готовый парсер .exec файлов jacoco, который не требует включения xml репорта?
mvn это хорошо, но если бы сделали еще jar с корной функциональностью, можно было бы написать таск в три строки для gradle, ну или плагин в 10 строк
проект на .ru домене будет достаточно тяжело затащить в компанию (отпугнет многих), было бы лучше использовать com/org координаты
Тем временем gradle перешел на Kotlin DSL по-умолчанию, так что закапывайте стюардессу)
Графики все-таки нужно с 0 делать, почему-то только у tivi это так, а дальше нужно напрягать мозг и смотреть на цифры, потому что картинка теряет смысл
А вообще вывод который я для себя сделал: самый cost-effective mac - air, собственно с него и пишу. Скажу еще что после mbp 16" i7 производительность air порадовала.
В целом действительно софт от Synology мусорный, что веб версия, что клиенты для десктопа и мобилки. Да и сделать дома 10Gbit сеть, иметь внешний канал хотя бы в 1Gbit да еще и отдать кучу денег за такой Synology далеко не все могут себе позволить.
Я попользовался своим DS416J 5 лет (недавно обновился до DSM7) и собрал в итоге NAS в Full Tower корпусе с UnRaid. Synology до сих пор отлично работает для торрентов и plex, бекапа в glacier. Теперь буду использовать только для resilio sync чтобы сбекапить самое важное с основного NAS и оставлю бекап в glacier - все таки это сделано удобно на Synology.