Text/Template это какой-то активный что ли шаблон?

html/template

активный это с управляющими конструкциями - циклами, if и тп. пассивный - без оных. text(html)/template это неистовая шляпа на рефлекте, которую подключать стоит только если в ней действительно есть потребность в этих шаблонах и всем этом функционале. ничего против fmt.Sprintf не имею - но с ним тоже надо правильный %-аргумент выбирать - некоторые из них задействуют все тот же рефлект.

как будто Sprintf без рефлекта

там switch в зависимости от того какой %-аргумент указан. не везде reflect

Да ну камон, куча кодогенерации на нем) я уже молчу про хелм)

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

Да, помню помню. Ну это инструмент)

точно лучше PHP, который hypertext preprocessor-ом сам себя называет, хотя бы потому что html/template из коробки экранирует весь контент в зависимости от контекста в котором выводится текст (название html-узла, атрибут или контент )

В php уже давно никто не использует <? внутри html

Да уже давно никто шаблоны не использует

да их с самого начала использовать было нельзя 🙂

Почему?

В смысле «нельзя»? Если вспомните, что было «можно» в то время, поймёте, что это был прорыв

отвечу на примере плюсов html/template, упомянутых ранее - при выводе текста через стандартный синтаксис PHP, надо применять разное экранирование в зависимости от контекста. Если выводится аттрибут - одно экранирование, имя html-узла - другое, контент - третье. При наличии миллиона функций escapespecialchars* и без внятного гайда в документации самого PHP, почти каждый, кто это пытался, стрелял себе в ногу. Я лично использовал XSLT шаблонизатор - получение данных с помощью XPATH еще времена когда даже JQuery еще не существовал; опять же экранирование выводимых данных в зависимости от контекста и быстрая работа (даже с учетом оверхеда на формирование входного XML) - тк это фактически старый код на C, как и все хорошее от PHP.

Не очень понятно, причём здесь получение данных и xpath, но да ладно

при том, что XPATH намного удобнее, чем циклы в PHP или подобное для перебора данных для вывода.

Вы делали хтмл файл и в него xpath-селекторами вставляли данные?

XSLT несколько сложнее, чем "вставлять данные". Там есть матчеры, это XPATH, их можно задавать в различных местах, либо получить данные для вывода, либо проверить логическое условие, либо можно определить шаблон с селектором, который по данному селектору автоматически заменяет результатом своей работы какой-то узел в исходном XML. Скажем так, мне довелось довольно много лет проработать на PHP в компании, где вся шаблонизация и писем и веба была  XSLT и это было одно из лучших архитектурных решений на тот момент. Но тк XSLT на вход принимает XML, который надо готовить, это казалось лишним шагом; была предпринята попытка реализовать такой же интерфейс шаблонизации на чистом PHP, но во-первых без селекторов XPATH код разростался значительно, во-вторых даже оверхед с формированием XML не давал практически никакого проседания в скорости, так что отказываться от XSLT было просто бессмысленно.

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

А, все, я вспомнил про xslt))) ну что ж, не завидую верстальщикам в таком случае)

Это все код xslt. Деление только в том, что исходный xml с данными для вывода формируется на стороне PHP. Исходный XML это грубо говоря массив с сырыми данными. Xslt может даже distinct сделать,сгруппировать, ему вообще ничего не надо, только сунуть нечто в исходный XML

Можно сколько угодно говорить, что вставка кода в шаблон 15 лет назад была плохой идеей, но это не отменит успех Wordpress, который в том числе потому и стал таким популярным, что набросать дизайн в верстку под него было проще простого. А сидеть и переводить верстку в пхп код, и потом это все поддерживать, это врагу не пожелаешь)

Все развивается. Когда-то потратить день, чтобы увидеть форму на html было невероятно. Теперь с го после 20 страниц тура мы можем сходу писать приложения с конкуррентностью и шаблонами, где отличное экранирование из коробки, пусть с небольшим налетом рефлекта

Да, согласен