но мы лучше будем оптимизировать на спичках

тут холивары были жесткие

Вот я и пытаюсь вспомнить аргументацию

Господи как же печёт, что вскод не может нормально блоки сворачивать,ну за чтоо

аргументацию + или -

В минус

восновном - не удобно читать

господи, если у вас компьютеды - то потеря производительности минимальна

Сейчас бы обсуждать производительность в чате про js-фронтенд-фреймворк

А вот реально, кто на vscode сидит, пробовали проблему со сворачиванием блоков решать?

Блин это поголовная мода забивать на оптимизацию, все у вас спички видите ли и жирные клиенты, ещё скажите что только топовые смартфоны показывают ваш сайт и мощные пк

Го в чат по Rust'у или Go лучше

Сейчас бы обсуждать производительность в чате про js-фронтенд-фреймворк

не вижу проблемы

народ хелп, вставляю приложение вуе в iframe, в консоле могу увидеть функциюю parent, но вызвать не могу

В итоге по спичке в каждой функции проебано и у мобилки батарейку сажают некоторые сайты как игры

В итоге по спичке в каждой функции проебано и у мобилки батарейку сажают некоторые сайты как игры

бред какой-то

Блин это поголовная мода забивать на оптимизацию, все у вас спички видите ли и жирные клиенты, ещё скажите что только топовые смартфоны показывают ваш сайт и мощные пк

Это не мода, а требования бизнеса. Стоимость поддержки "высокооптимизированного" кода в разы больше. Оптимизировать надо а) когда это необходимо б) по результатам профилирования

бред какой-то

Видимо у вас не было больших проектов и можно херачить по модному и не экономить цпу и ram

а сэкономленные 20ms в code path, который выполняется раз в секунду нерационально

(раз в секунду это крайне оптимистичная оценка, если мы говорим о фильтрации менеджеров)

скорее раз в десятки-сотни секунд

и поверьте, у меня были большие проекты :)

Мы говорим про отношение к коду в целом. Не просят, не оптимизируем. Как вы сказали, постфактум с профилировщиком вам сидеть приятнее, чем писать сразу нормально

нормально - это читабельно и поддерживаемо

производительность чаще всего в ущерб читаемости и поддерживаемости

нормально - это читабельно и поддерживаемо

В частности код не стал бы менее понятен от использования цикла и ватчера

Видимо у вас не было больших проектов и можно херачить по модному и не экономить цпу и ram

толсто, я бы сказал что нет таких сайтов которые садят батарейку как игры, разве что парсинг js у вас все время нахождения на сайте + воспроизведение видео

стал бы. У вас есть поле шаблона - вам надо понять откуда оно берется. В случае с декларативным подходом (компьютеды) у вас ЯВНО описано как оно получается в случае с использованием watch у вас императивный код, который может быть на три экрана ниже, что затрудняет поддержку и изменение кода

Пишем блог на webassembly

современное программирование (не только фронт) не просто так идет в сторону декларативных описаний

стал бы. У вас есть поле шаблона - вам надо понять откуда оно берется. В случае с декларативным подходом (компьютеды) у вас ЯВНО описано как оно получается в случае с использованием watch у вас императивный код, который может быть на три экрана ниже, что затрудняет поддержку и изменение кода

На 3 экрана ниже! Как тяжело скроллить, мои соболезнования

Не переутомитесь там

еще в модных IDE есть переходы к методам по имени... ну это так.. если совсем устанете скроллить

И как вам в этом случае поможет переход по имени?

Такое себе развлечение открывать профиль и смотреть как твой сайт жрет ресурсы как прокажённый

у вас есть побочный эффект, который вызывается при совершенно другом действии. Чтобы найти этот побочный эффект - его надо искать, и "переход к методу по имени" не поможет в этом

И как вам в этом случае поможет переход по имени?

watch свойство к которому можно переключиться (по крайней мере в моем стареньком саблайме это работает)

так у нас на основании вотча другого свойства наполняются те, которые нас интересуют

(обратная операция)

касаемо именно этого кейса, я не делал бы вообще ватчер и computed, а фильтровал в момент получения единожды, не думаю, что этот список пользователей обновляется как-то динамично и на него нужно реагировать вообще

это слишком простая операция, чтобы вообще обсуждать сложность ее поддержки

а вот мне проще "не думать" и написать два компьютеда, которые покроют возможные рефакторинги поведения в будущем

да я вижу, что вам проще "не думать"

из простых операций и складывается сложность поддержки проекта

да, в этом суть профессионального подхода к программированию

максимально тупой и надежный код

боюсь у вас просто максимально тупой код) надежности тупость не добавляет)

А где можно ознакомиться с примерами вашего надежного кода? чтобы поучиться

@dstrokov я бы был осторожнее в выражениях ?, учитывая что вы похоже не в курсе с кем говорите

В курсе)

Просто когда топят за "не думать", писать "максимально тупой" код это прям, хз.. наверное проще надо относится

Чем больше таких, тем дороже фронты которые выберут оптимизированные решения сразу)

@dstrokov я бы был осторожнее в выражениях ?, учитывая что вы похоже не в курсе с кем говорите

Все ок :) я то спокойно к этому отношусь

тем более тут же есть аспекты и бизнесовые, и "девелоперские"

это нормально отстаивать другую точку зрения

?

Чем больше таких, тем дороже фронты которые выберут оптимизированные решения сразу)

Я думаю тебе тогда не стоит холиварить =) Твой ценник получается в данный момент растет ведь? ?

Мой тоже

дабл профит

кто-нибудь встраивал в iframe vue приложение?

дабл профит

Ну по идее да =) Надежность и простота VS Оптимизация и производительность

лично я считаю что код и правда должен быть максимально простым для понимания и внесения правок. множество мелких отступлений от этого - в итоге делает сложную махину стоимость изменения в котором растет с ростом проекта

лично я считаю что код и правда должен быть максимально простым для понимания и внесения правок. множество мелких отступлений от этого - в итоге делает сложную махину стоимость изменения в котором растет с ростом проекта

Простой код должен при этом не проседать по производительности.

Ну я из другого лагеря, возможно меня просто зае... За десять лет писать просто и тупо, хочется изысков и скорости

Простой код должен при этом не проседать по производительности.

это да, само собой

Так я с ноды сервисов, перелез на go)

На GO?

ERROR: S client not available

Давно?

hello guys

Простой код должен при этом не проседать по производительности.

несомненно. А горячие места надо оптимизировать

Ну частично, да у нас 3сервиса на го сменили ноду)

Но мы работаем в экосистеме где стоимость одной операции с DOM сравнима с ~1000 операций с JS

Ну частично, да у нас 3сервиса на го сменили ноду)

А сколько у старых сервисов на ноде был рекорд без падений?

поэтому оптимизировать такие вещи - просто бесполезно

А сколько у старых сервисов на ноде был рекорд без падений?

Макс аптайм у меня был 270дней

холиварщики дорогие, можете скинуть ссылку в тг на js чат, раз тут по iframe никто не в курсе

холиварщики дорогие, можете скинуть ссылку в тг на js чат, раз тут по iframe никто не в курсе

смотри в шапке

и это не холивар, а точки зрения разных людей

холивар это реакт против вью )

смотри в шапке

спасибо, как скажете, мне все равно)

я не любитель псевдодебатов

холивар это реакт против вью )

Кстати вот где вью точно затащил , так на миграции старого проекта. На реакте только с нуля переписывать пришлось бы. Вью же отлично вклинился)

Ну вроде в доке реакта сказано что можно интегрировать реакт в готовое приложение и постепенно перепимывать легаси на реакт

Я правда сам реакт не трогал, только доку полистал

application seeds называется подход

Ну вроде в доке реакта сказано что можно интегрировать реакт в готовое приложение и постепенно перепимывать легаси на реакт

А если проект не собирается нодой?) хрен тогда вклинишь)

и он работает для любых фреймворков

И очень монолитный

А если проект не собирается нодой?) хрен тогда вклинишь)

вклинишь

А если проект не собирается нодой?) хрен тогда вклинишь)

А как тогда туда же вью вклинить?

для сборки будет отдельный сервис с нодой просто

А как тогда туда же вью вклинить?

без однофайловых компонентов

скажите, почему это работает? const actions: ActionTree<Logs, RootState> = { info({ commit }, param: any): any { const payload: Log = { message: param.message, }; commit("addLog", payload); setTimeout(() => { payload.message = "---"; }, 2000); }, я меняю поле объекта, который уже прошёл мутацию и срабатывает реактивность, обновляя html. разве так можно делать?

без однофайловых компонентов

какая разница однофайловые или нет

какая разница однофайловые или нет

Нельзя ноду на проект тащить. Чем их еще собирать?

тебе все равно нода нужна будет

однофайловые или нет

+