Когда видишь только агрегирование данных, без промежуточных переменных, куда сложнее держать в голове всю цепочку действий, тогда как с промежуточными переменными легче понимать что творится в коде.
Не холивора ради, но таки подобные задачи еще лучше решаются через декомпозицию. Если ваша функция состоит из нескольких шагов, которые совершенно очевидно делятся на части пресловутыми промежуточными переменными, то вы очевидно сможете разбить ее на несколько функций, каждая из которых будет удовлетворять условию.
После изменения имени страница классического сайта просто перезагрузится :)
Заставив нас ждать пинга сервер-клиента, рендера на сервере, рендера на клиенте, репейнта… А в нашем случае, может быть, надо было только два слова всего поменять. Конечно, раз на раз тут не приходится, но сценарий, когда действие пользователя меняет несколько достаточно удаленных друг от друга частей сайта, но незначительно — в моей практике встречался слишком часто.
на бэке тратятся ресурсы
Вы вырвали цитату из контекста. Привожу полную цитату:
Для отрисовки на бэке[ПАУЗА] тратятся ресурсы networking'а
Ресурсы бэка, конечно, не особо тратятся (зависит от). Но вот когда сервер в Лондоне, а юзер в Монголии…
видимой на глаз разницы в производительности [...] не замечал
Зависит от сайта, разумеется. Мне доводилось замечать такую разницу на всякого рода b2b-ресурсах.
(Не считая случаев, когда сайт таким образом написать в принципе невозможно и нужен интерактив на JS, но ведь такие сайты по пальцам можно пересчитать)
Прикиньте, сколько в мире есть сайтов-визиток, блогов, форумов, которые кроме гифок статичны чуть более чем полностью
То, что в мире много сайтов-визиток с морем статики, никак не подтверждает аргумент, что других сайтов — по пальцам пересчитать.
Я лично считаю, что серебряной пули нет. Реакт не панацея (и мне лично вообще Vue больше нравится например), и толкать его повсюду — это та же мода на сложение чисел с помощью jquery только в профиль. Если ваш фронт, которому надо сделать лендинг для разовой акции, тянет туда реакт, возможно, он не очень компетентен. Если ваш бэкендер, который пилит условный trello, морщится при слове реакт и хочет все сделать на GWT/ASP.NET — про него можно сказать то же самое.
Да, вы правы, я действительно ошибся. Но тем не менее аргумент мой остается тем же самым — код с промисами гораздо сложнее для чтения и обрастает морем ненужных скобок, если нам нужно логирование или дополнительные действия.
Как бывший фронтенд разработчик, который ныне сидит на бэке, отвечаю =)
1. Рисовать HTML на бэкенде все еще можно, но такой подход не умеет решать ряд важных проблем. Например, если юзер взаимодействует с элементом, который меняет контент во многих разных частях приложения, скажем, отредактировал свое имя, которое должно успешно замениться повсюду на странице.
2. Для отрисовки на бэке тратятся ресурсы networking'а, и это имело бы смысл, будь генерация HTML'а чем-то сложным и непроизводительным, но это совсем не так — любой современный шаблонизатор работает с ast, и на клиенте это все будет работать во многих случаях быстрее чем один только пинг до сервера.
3. Отрисовка кусмана HTML'а на клиенте — это более трудозатратный процесс, чем использование DOM API, как раз потому, что снова выделяются ресурсы на парсинг и валидацию. Современные фреймворки/либы стараются использовать virtual dom, чтобы по возможности оптимизировать эти процессы.
4. Еще, конечно, обилие мобильных клиентов требует уменьшения трафика. Готовый HTML практически всегда будет весить больше чем JSON API.
Сайтов, которым нужны сложные взаимодействия на клиенте, точно не по пальцам пересчитать. Прикиньте, сколько в мире есть CRMок, облачных приложений, прибавьте сюда практически весь b2b-стек — почти каждая такая система выглядит и работает лучше, когда часть нагрузок передана на клиент.
К сожалению, не очень хорошо разбираюсь в подкапотной работе V8 в оптимизации async/await, но немножко могу про C#, и там компилятор очень умеет оптимизировать код. Скажем, когда результаты функций должны использоваться совместно:
let a = await _a()
let b = await _b()
let c = await _c(a, b)
console.log(c)
В мире с промисами это будет выглядеть как-то вот так:
Может быть и ничего так, но гораздо сложнее для чтения и понимания, а если между строками ставить еще какие-нибудь логи или вызовы синхронных функций, то код на промисах станет гораздо сложнее.
В C# эти страшные «промисы» (Task) резолвит внутренний оптимизатор, по сути оно во что-то такое и превращается, но пользоваться этим гораздо удобнее, имхо.
Определенно можно. Когда в C# появился синтаксис async/await, у меня лично весь асинхронный код стал гораздо симпатичнее и понятнее. Дичайше обрадовался тому же синтаксису в JS, они молодцы что выбрали именно C# в качестве примера для подражания.
Говоря точнее, «мне за еще и хобби не доплачивают». И тут позиция уже более понятная: отчет еще посмотреть не успел, но сомневаюсь, что в большинстве — программисты, для которых это исключительно хобби =).
Ну хотя метод и прост на первый взгляд, под использованием foreach (если это C#) спрятаны вызовы GetEnumerator, Next, Current — которые могут быть переопределены и сделаны вообще специально для того чтобы помогать вам разбираться с коллизиями в духе
var a = ['a']
a.filter(i => { a.push('b'); return Math.random() > 0.5 })
Трусы за рубль двадцать будут несколько проще таки. И оптимизировать тут есть что.
Да, сам заглянул туда и удивился. Все-таки, впрочем, в «модном» подходе с UDF vue-resource никаким особым профитом не обладает в сравнении с прочими перечисленными — поскольку отпадает нужда в инъекции в компоненты.
«Встроенная» никак не тянет на определение. Я согласен, впрочем, что обратный перевод скорее превращается в embedded.
Вопрос на засыпку — а как перевести «inline» на русский язык?
Vue-resource не поддерживается уже достаточно давно. Обычно можно встретить использование axios, на крайняк reqwest. Но конечно jquery это мягко говоря оверкилл.
Возможно, распишусь в собственной неполноценности, но думаю, что для меня этого было бы недостаточно. И не думаю, что это так уж плохо. В конце концов, программисты в реальности сильно отличаются от голливудских программистов. Никто и никогда не сидит с таймером, чтобы в последние десять секунд успеть написать квиксорт, чтобы остановить ядерный взрыв (или даже задеплоить хотфикс). Если программисту для подобных вещей надо будет заглянуть в гугл, это не страшно, на мой взгляд.
Я имел в виду, что используя vue-loader, вы можете использовать другие loader'ы для разных частей ваших компонентов. В числе которых может оказаться и jsx. Спасибо, что поправили!
Я кодер, но и у меня мешанина js и html отбивает все на свете. Впрочем, для адских поклонников jsx в Vue есть vue-loader для вебпака, с которым вполне можно писать на Vue темплейты на jsx.
Не холивора ради, но таки подобные задачи еще лучше решаются через декомпозицию. Если ваша функция состоит из нескольких шагов, которые совершенно очевидно делятся на части пресловутыми промежуточными переменными, то вы очевидно сможете разбить ее на несколько функций, каждая из которых будет удовлетворять условию.
Вы вырвали цитату из контекста. Привожу полную цитату:
Ресурсы бэка, конечно, не особо тратятся (зависит от). Но вот когда сервер в Лондоне, а юзер в Монголии…
Зависит от сайта, разумеется. Мне доводилось замечать такую разницу на всякого рода b2b-ресурсах.
То, что в мире много сайтов-визиток с морем статики, никак не подтверждает аргумент, что других сайтов — по пальцам пересчитать.
Я лично считаю, что серебряной пули нет. Реакт не панацея (и мне лично вообще Vue больше нравится например), и толкать его повсюду — это та же мода на сложение чисел с помощью jquery только в профиль. Если ваш фронт, которому надо сделать лендинг для разовой акции, тянет туда реакт, возможно, он не очень компетентен. Если ваш бэкендер, который пилит условный trello, морщится при слове реакт и хочет все сделать на GWT/ASP.NET — про него можно сказать то же самое.
1. Рисовать HTML на бэкенде все еще можно, но такой подход не умеет решать ряд важных проблем. Например, если юзер взаимодействует с элементом, который меняет контент во многих разных частях приложения, скажем, отредактировал свое имя, которое должно успешно замениться повсюду на странице.
2. Для отрисовки на бэке тратятся ресурсы networking'а, и это имело бы смысл, будь генерация HTML'а чем-то сложным и непроизводительным, но это совсем не так — любой современный шаблонизатор работает с ast, и на клиенте это все будет работать во многих случаях быстрее чем один только пинг до сервера.
3. Отрисовка кусмана HTML'а на клиенте — это более трудозатратный процесс, чем использование DOM API, как раз потому, что снова выделяются ресурсы на парсинг и валидацию. Современные фреймворки/либы стараются использовать virtual dom, чтобы по возможности оптимизировать эти процессы.
4. Еще, конечно, обилие мобильных клиентов требует уменьшения трафика. Готовый HTML практически всегда будет весить больше чем JSON API.
Сайтов, которым нужны сложные взаимодействия на клиенте, точно не по пальцам пересчитать. Прикиньте, сколько в мире есть CRMок, облачных приложений, прибавьте сюда практически весь b2b-стек — почти каждая такая система выглядит и работает лучше, когда часть нагрузок передана на клиент.
В мире с промисами это будет выглядеть как-то вот так:
Может быть и ничего так, но гораздо сложнее для чтения и понимания, а если между строками ставить еще какие-нибудь логи или вызовы синхронных функций, то код на промисах станет гораздо сложнее.
В C# эти страшные «промисы» (Task) резолвит внутренний оптимизатор, по сути оно во что-то такое и превращается, но пользоваться этим гораздо удобнее, имхо.
Трусы за рубль двадцать будут несколько проще таки. И оптимизировать тут есть что.
Вопрос на засыпку — а как перевести «inline» на русский язык?