Говоря про производительность я говорю вот про что.
Возьмём для примера простой код:
<div class="details">
<span class="summary">Details</span>
<p class="hidden">Lorem ipsum dolor sit amet consectetur adipisicing elit. Optio temporibus aliquam at tempora repellat consectetur eos voluptate facilis tempore obcaecati laborum animi sunt, rem quis. Dolore, ipsa. Tempora, soluta quaerat!</p>
</div>
Производительность хуже. Вы должны самостоятельно реализовывать функционал который уже встроен в браузеры. То есть лишние стили, лишние скрипты лишняя работа для браузера. В некоторых случаях браузеру сложнее пересчитать шаблон и перерисовать страницу. При использовании встроенного элемента браузер знает о его возможностях и может более эффективно отрисовать страницу.
Реализация не всегда настолько хороша. Скажем, вы задумывались о том, что контрол, по клику на который должен переключиться класс должен реагировать не только на клик мышкой, тап по экрану но и на клавиатуру? Задумывались о том, что он должен быть доступен при проходе табуляцией? Конечно, если для этого использовался <button> то всё более менее хорошо, но ведь очень часто используют какой-либо другой элемент, который только выглядит как кнопка, скажем
<span class="btn">
И это ужасно. Ведь, если не используете мышь, то вы никогда не сможете использовать этот контрол. При использовании встроенных элементов вам о таких вещах думать не нужно. Об этом позаботятся браузер и ОС.
Семантика и контекст. Если вы воспринимаете страницу не визуально (как это делают многие люди и абсолютно все боты и программы) то для вас крайне важно понимать контекст. Для вас <div> или <span> не говорят ничего. Даже <button> — это просто кнопка без привязки к чему либо. <details> же указывает на то, что это интерактивный элемент, у которого есть оглавление и при желании можно раскрыть детали. Конечно есть aria-атрибуты, но далеко не многие разработчики об этом задумываются. Даже мои примеры сделаны не лучшим образом с точки зрения семантики. На эту тему советую посмотреть доклад "Семантика для циников, Вадим Макеев"
Простота — важна.
Но, суть в том, чтобы не тратить время и в процессе ожидания асинхронного ответа выполнить максимум работы. Выполнить все операции с DOM, добавить элементы где нужно, проставить классы если нужно, применить стили и т.д. Чтобы когда асинхронная операция закончится у вас уже всё было готово. Это не обязательно предложенная мною «выключенная форма».
Поэтому до того как загрузятся данные форма заблокирована. Суть в том, чтобы выполнить максимальное количество работы пока загружаются данные. Чтобы когда они загрузились — осталось выполнить минимум. Если отображать прелоадер, то потом его нужно удалять и заменять формой. Лучше всего показать форму, с прелоадером внутри. Но это уже детали выходящие за пределы темы материала.
Полагаю, Если бы такой функционал вошел в стандарт, то это повлияло бы на дальнейшее развитие протокола HTTP и браузеров. Такой веб, отличался бы от нашего. Проблемма множественных запросов к серверу там была бы не актуальна. Там были бы свои, не понятные нам, сложности :)
1. Это бесконечный цикл, который будет выполнять один запрос за другим, до тех пор, пока в ответе приходит новый УРЛ. Это весьма утрированный пример, но он, как мне кажется, отлично демонстрирует общий алгоритм. В более реальном сценарии, это был бы какой-нибуть импорт большого числа коментариев на сервер (вам нужно получить ID созданного коментария, прежде чем импортировать дочерние), или скажем, обход всех страниц пагинации (вам нужно получить ссылку на следующую страницу, прежде чем загрузить записи).
2. Не совсем понял ваш вопрос. Мой пример тоже полностью основан на промисах.
я продаю код который можно дальше без болезненно развивать.
Так в том то и дело, что болезненно. Я смотрю на ситуацию, с точки зрения WordPress разработчика, который придёт на проект после вас и не видел этой статьи. Пытаюсь представить себя на его месте. И описываю вам те мысли и проблемы возникающие у меня.
Предположим я открыл ваши исходники. Изучил их. Досконально понимаю что за что отвичает.
И у меня в такой ситуации остаётся один вопрос — а зачем? Я как сторонний человек, без вашего объяснения, смотря только на ваше решение, не пойму в чем принципиальное отличие между
$traderoomScriptFiles = array(
(new Migesco\WebResource(ECRYPTEX_JS))
->setSource('/e-cryptex.js'),
(new Migesco\WebResource('child_realforex'))
->setSource('/child_realforex.js')
->setDependency(array(ECRYPTEX_JS))
И что ж мне тогда делать? Оставить ваше решение? Я не могу его просто так удалить, вы ж его для чего-то написали. Связаться с вами для пояснения? Подключать часть файлов по вашему а часть по моему? Или использовать ваше решение? А что если в процессе появится какия-то проблема? Дебадить? Допиливать его?
Даже если игнорировать все замечания по коду, все люди, написавшие комментарии пытаются донести до вас мысль — что вы таким образом, усложнили жизнь людям, которые будут поддерживать проект дальше. Увеличили время на выполнение простых задач. Увеличили стоимость проекта для заказчика.
Мотивация. Если я правильно понял, то вы пытались сделать код более «универсальным и гибким». Но в итоге только усложнили ситуацию.
человек не знакомый с WordPress ни чего не поймёт
Ваш проект — плагин для WordPress. Какова вероятность, что его поддержку доверят человеку который не знаком с этой CMS? Это ж как доверить доработку сайта на php человеку, который не знаком с php.
Кроме того, открыть справку по функции WP, куда проще, чем лезть в чужой код и пытаться розобраться в его работе.
В итоге, я, как потенциальный исполнитель после вас, буду вынужден потратить несколько часов на то, чтобы просто понять что это за код, что он делает и почему не использовались общепринятые решения.
Результат, даже менее гибок, чем изначальный.
Предположим, что я — разработчик, которому передали проект. Я человек ответственный и решил, действовать по вашему сценарию. Весь новый функционал вынес в отдельный файл. И подключать буду так же, как вы, чтобы соблюдать общий подход.
Мне нужно подключить файл в подвал страницы. И как мне это сделать? Судя по вашему коду, это не возможно, так как ваш код не предусматривает передачу параметра $in_footer в wp_enqueue_script.
Или например, как мне указать версию для файла? Вот у меня в ТЗ указано, что при подключении файла обязательно необходимо указывать его версию. В вашем решении такой возможности нет.
В итоге, при здаче, я смогу отметить 20 часов работы как «Отрефакторил код предыдущего разработчика, и привёл его к виду в соответствии с стандартами разработки под WordPress». Хоят по факту — я просто удалю ваше решение и заменю его на два вызова wp_enqueue_script
Говоря про производительность я говорю вот про что.
Возьмём для примера простой код:
Браузер должен:
В случае использования встроенных элементов, браузеру нужно всего-то
Я понимаю, что разница мизерная. Но Великое берёт начало с малого.
Производительность хуже. Вы должны самостоятельно реализовывать функционал который уже встроен в браузеры. То есть лишние стили, лишние скрипты лишняя работа для браузера. В некоторых случаях браузеру сложнее пересчитать шаблон и перерисовать страницу. При использовании встроенного элемента браузер знает о его возможностях и может более эффективно отрисовать страницу.
Реализация не всегда настолько хороша. Скажем, вы задумывались о том, что контрол, по клику на который должен переключиться класс должен реагировать не только на клик мышкой, тап по экрану но и на клавиатуру? Задумывались о том, что он должен быть доступен при проходе табуляцией? Конечно, если для этого использовался
<button>то всё более менее хорошо, но ведь очень часто используют какой-либо другой элемент, который только выглядит как кнопка, скажемИ это ужасно. Ведь, если не используете мышь, то вы никогда не сможете использовать этот контрол. При использовании встроенных элементов вам о таких вещах думать не нужно. Об этом позаботятся браузер и ОС.
Семантика и контекст. Если вы воспринимаете страницу не визуально (как это делают многие люди и абсолютно все боты и программы) то для вас крайне важно понимать контекст. Для вас
<div>или<span>не говорят ничего. Даже<button>— это просто кнопка без привязки к чему либо.<details>же указывает на то, что это интерактивный элемент, у которого есть оглавление и при желании можно раскрыть детали. Конечно есть aria-атрибуты, но далеко не многие разработчики об этом задумываются. Даже мои примеры сделаны не лучшим образом с точки зрения семантики. На эту тему советую посмотреть доклад "Семантика для циников, Вадим Макеев"А вы, установив кривое приложении на свой пк, ругаете авторов ОС или конкретного софта?
Клиент смотрит со своего iPhone и пишет: у тебя дата не работает.
Но, суть в том, чтобы не тратить время и в процессе ожидания асинхронного ответа выполнить максимум работы. Выполнить все операции с DOM, добавить элементы где нужно, проставить классы если нужно, применить стили и т.д. Чтобы когда асинхронная операция закончится у вас уже всё было готово. Это не обязательно предложенная мною «выключенная форма».
2. Не совсем понял ваш вопрос. Мой пример тоже полностью основан на промисах.
Так в том то и дело, что болезненно. Я смотрю на ситуацию, с точки зрения WordPress разработчика, который придёт на проект после вас и не видел этой статьи. Пытаюсь представить себя на его месте. И описываю вам те мысли и проблемы возникающие у меня.
Предположим я открыл ваши исходники. Изучил их. Досконально понимаю что за что отвичает.
И у меня в такой ситуации остаётся один вопрос — а зачем? Я как сторонний человек, без вашего объяснения, смотря только на ваше решение, не пойму в чем принципиальное отличие между
и
И что ж мне тогда делать? Оставить ваше решение? Я не могу его просто так удалить, вы ж его для чего-то написали. Связаться с вами для пояснения? Подключать часть файлов по вашему а часть по моему? Или использовать ваше решение? А что если в процессе появится какия-то проблема? Дебадить? Допиливать его?
Даже если игнорировать все замечания по коду, все люди, написавшие комментарии пытаются донести до вас мысль — что вы таким образом, усложнили жизнь людям, которые будут поддерживать проект дальше. Увеличили время на выполнение простых задач. Увеличили стоимость проекта для заказчика.
Ваш проект — плагин для WordPress. Какова вероятность, что его поддержку доверят человеку который не знаком с этой CMS? Это ж как доверить доработку сайта на php человеку, который не знаком с php.
Кроме того, открыть справку по функции WP, куда проще, чем лезть в чужой код и пытаться розобраться в его работе.
В итоге, я, как потенциальный исполнитель после вас, буду вынужден потратить несколько часов на то, чтобы просто понять что это за код, что он делает и почему не использовались общепринятые решения.
Предположим, что я — разработчик, которому передали проект. Я человек ответственный и решил, действовать по вашему сценарию. Весь новый функционал вынес в отдельный файл. И подключать буду так же, как вы, чтобы соблюдать общий подход.
Мне нужно подключить файл в подвал страницы. И как мне это сделать? Судя по вашему коду, это не возможно, так как ваш код не предусматривает передачу параметра
$in_footerвwp_enqueue_script.Или например, как мне указать версию для файла? Вот у меня в ТЗ указано, что при подключении файла обязательно необходимо указывать его версию. В вашем решении такой возможности нет.
В итоге, при здаче, я смогу отметить 20 часов работы как «Отрефакторил код предыдущего разработчика, и привёл его к виду в соответствии с стандартами разработки под WordPress». Хоят по факту — я просто удалю ваше решение и заменю его на два вызова
wp_enqueue_script