Максим

Оберните название файла в блок и примените к нему стиль:
word-break: break-all;
Желательно блок выделить немного изменив фоновый цвет.

Если не нравится, то еще можно так:
text-overflow: ellipsis;

на html быстро, но некрасиво, на js - как захочешь, так и сделаешь, но обычно лениво :)

На JS можно проверять поддержку браузером HTML 5.
Если ок, то -- им. Если нет, то скриптом. Но любую клиентскую проверку можно обойти при желании. Так что единственная надежная проверка -- со стороны сервера.

HTML

Здравствуй, дорогой друг)

Вот вам кусочек с рабочего проэкта.
суть вот в чём.

Есть функция которая принимает 2 параметра
$template - это название файла с шаблоном в папке с шаблонами.
$args - Массив для замены значений в письме.

public function send_email( $template, $args ) {
				ob_start();
				include APA_PATH . "/templates/emails/{$template}.php";
				$content = ob_get_clean();
				foreach ( $args as $key => $value ) {
					if ( ! is_array( $value ) && ! is_object( $value ) ) {
						$search  = '{$' . $key . '}';
						$content = str_replace( $search, $value, $content );
					}
				}
				$message = $content;

				wp_mail( $this->getEmailTo(), $this->getEmailSubject(), $message, $header );
			}

Получаем содержимое файла с шаблоном и сохраняем в переменную $content

ob_start();
include APA_PATH . "/templates/emails/{$template}.php";
$content = ob_get_clean();

Проходимся по массиову и ищем плейсхолдеры формата {$user_name} заменяем на реальные значения с массива и заменяем в переменной $content

foreach ( $args as $key => $value ) {
					if ( ! is_array( $value ) && ! is_object( $value ) ) {
						$search  = '{$' . $key . '}';
						$content = str_replace( $search, $value, $content );
					}
				}

И финальный шаг: отсылаем письмо

$message = $content;
wp_mail( $this->getEmailTo(), $this->getEmailSubject(), $message, $header );

PS. wp_mail() - это функция из вордпресс

вы сравниваете запорожец с ферари и удивляетесь?
на сервере кроме вас еще сотни акаунтов/сайтов, которые жрут ресурсы.

виртуальные дешевые сервера по сути ничтожны по производительности?

С просветлением вас.

Я больше знаком с Python экосистемой, поэтому могу быть несправедлив в отношении PHP.

PHP:
- проще с работой
- проще с хостингом
- язык для веб-разработки

Python:
- проще с отладкой кода
- проще с читаемостью кода
- проще с безопасностью кода
- язык общего назначения
- много самых разных библиотек

Производительность обоих языков сопоставима и заметно улучшена как в PHP 7, так и в Python 3.6.

Максим, всё описанное ниже я пишу исходя из личного опыта, с некоторыми моими утверждениями можно поспорить :)

Так или иначе, но самая ресурсоёмкая задача, почти всегда, это работа с базой.

Несколько лет назад я делал бенчмарки Python, PHP, Node, Go.
Для меня были важны две вещи:
1 - скорость ответа сервера/кол-во запросов в секунду
2 - объём сервиса в памяти, т.к. от этого зависит стоимость ресурсов

На тесте, где сервисы не делали запросы в базу - из всех четверых лучше всего отработал Go с приличным отрывом, цифры, к сожалению, уже не помню.

Но вся эта разница сошла на нет, как только добавился всего один простой SQL запрос в базу, в таблицу с 10 строками. И на этом фоне разница по скорости ответа была меньше 10%.

Иными словами если ваш сервис работает с базой - критической разницы по скорости работы между Go/Rust/PHP/Node/Java, увы, не будет.

Но другое дело если для нас важно сколько памяти "съедает" каждый сервис.

Например у вас пошли нагрузки и вам нужно горизонтально масштабирватся, т.е. запустить, скажем 100-10000 эксемпляров вашего сервиса.

Вот тут уже становится интереснее :)

Один экземпляр Go занимал в памяти порядка 6мб, при том, что Pytho+Django порядка 60мб.
Node уже не помню сколько, но что-то близкое к Python'у.
Вот тут уже, когда серверов у вас будет много - количество серверов с Go у вас будет в 10 раз меньше :)
Знаю случаи, когда с почти 40 серверов с API на Node перешли на 2 сервера с Go.

От части по этому и еще по ряду причин, последние несколько лет я использую Go и Python.
Лично я просто в мега восторге от Go :)
Еще Go идеально подходит для написания сетевых сервисов, CLI утилит и т.д.
Например Docker, Kubernetes и еще куча всего написаны на Go.
Я делал подобные вещи на разных языках, и ни на чём, как на Go не получался такой красивый и понятный код, который при этом работает достаточно хорошо.

Про PHP, если знаете его, можете писать на нём, если не знаете - учить не советую, как минимум потому, что есть Python, на нём код куда более читабельный получается, возможностей, вакансий с нормальной з\п больше.

На C# писать не довелось, сказать о нём ничего не могу.

Писал на Java несколько лет, но она мне очень не нравится :) Особенно, когда есть Go :)
Если будете учить Java - готовьтесь к тому, что вы будете обслуживать Legacy код, или скорее ...нокод :)
Но вакансий с хорошей з/п по Java тоже много. Как минимум без денег не останетесь точно.

Rust имеет смысл использовать, когда у вас очень большая нагрузка и для вас критична latency.
Например для показа рекламы нужно ответить за 100мс иначе вашу рекламу просто не покажут.
Вот тут Rust выиагает у Go за счёт того, что у Go будут периодические "провалы" во время сборки мусора.
В остальном, по моему мнению, Rust проиграет за счёт большего времени по разработке, худшей читаемости кода.

С другой стороны, если у вас есть рабочий сервис на Node, то вместо перехода на Rust, явно буде лучше сделать просто модуль на C/C++ для Node и всё будет летать + полный контроль выделения и освобождения памяти.

Я такую схему с модулями на C/С++ не раз использовал на Perl'е.
Очень помогало особенно там, где нужно было чётко освобождать память, чтобы скрипты со временем не пухли.

Надеюсь вам это как то поможет определиться :)

Ты путаешь нестрогую типизацию с динамической. Да и дело не в этом. JS всегда работал криво и был слишком странным языком. Это вот, последние 5 лет он выбрался со дна - появился ES6, появился тайпскрипт и фронтендеры начали учиться программировать. Но даже при всем этом, в нормальный JS сложней вкатиться, чем в питон. Уж очень много изменений, какие-то вебпаки, npm, yarn, nodejs, deno, где-то import, где-то require. А после этого ещё TypeScript изучай. В питоне все просто - есть третий питон, есть нетретий питон. Ставишь джангу или fastapi, хуяк-хуяк и деплой.

А производительность языка в разрезе веба несущественна, особенно с тех пор, как в питоне есть асинхронщина - все равно всегда упираешься в IO.

В действительности люди чаще используют то, что удобно им. Python все же более дружелюбен и начать программировать на нём немного, но легче, чем на js. В реальности на бэкэ довольно тяжело упереться в скорость работы, которую ограничивает язык ( иначе все бы писали на С ), поэтому, легко изучив питон, люди переходят на фласк или django ( сам лично встречал 2 таких людей, которые за пару месяцев изучения питона перешли на бэк)

Клиент принимает либо данные, либо html. В первом случае клиент сам строит представление, а во втором данные ему не нужны, потому что они уже превращены в представление.

Так что нет, не следует смешивать.

Да. Ну, кроме call-back

Кто сказал, что я замеряю время работы программы? Я измерил и знаю кол-во итераций при разной длине массива. Если быть точным, то в моей ситуации формула кол-ва итераций будет 2,5*n*n/10.
Где n - длина массива. Это какая сложность будет? Допустим 2,5 можно отбросить, остается n* n/10.
n/10 тоже можно отбросить, так как n/10 меньше чем n в 10 раз, а значит уже не имеет значения.
Правильный ответ это O(n) ?

O(n) - неправильный ответ
Если 2.5*n*n/10 - точная формула тогда надо писать следующим образом
2.5*N^2/10 = 2.5/10 * N^2 => O(N^2)

Например так, как реализовано здесь: https://planetcalc.ru/5992/
Только учтите, что многие наборы данных могут одновременно одинаково хорошо (или одинаково плохо) описываться функциями разного вида.