Это только мне так кажется, или Hyperscript ужасен?

Разработка
1

Просто выплескиваю эмоции, но, проработав с большим количеством языков шаблонизации, чем я хочу вспоминать (Jinja2, ERB, FTL, XSLT, JSX, Handlebars и т. д.), я нахожу Hyperscript совершенно ужасным в работе.

В произвольном порядке, вот что в нём ломается:

  • Переносимость кода (нельзя скопировать/вставить фрагменты HTML без их прогона через конвертер)
  • Подсветка синтаксиса (превращает всё в огромную кашу), например
    01
    01654×148 4.1 KB
    против
    56
    56606×118 9.52 KB
  • Автодополнение кода — полный провал, не говоря уже о таких инструментах экономии времени, как https://emmet.io

Я никогда не думал, что что-то заставит меня тосковать по старым плохим дням PHP, но Hyperscript сумел это сделать!

Это только у меня так?

4

Да, я согласен, что с этим не так удобно работать, особенно по сравнению с Handlebars (который мы тоже используем), где можно писать HTML так, как ожидается.

Мы начали использовать virtual-dom/virtual-hyperscript в тех местах, где требовалось повысить производительность. Тема использования нескольких систем шаблонов — это то, о чём мы недавно начали говорить внутри команды; у нас пока нет конкретных планов, но мы понимаем, что было бы неплохо всё упростить. Возможно, это означает, что мы больше не будем использовать virtual-hyperscript? Время покажет.

5

Синтаксис немного непривычен. Я помню, что в начале работы над темами Discourse сам был сильно озадачен, но со временем разобрался, как это работает. Также через виджет можно генерировать «сырой» HTML.

Я не самый опытный в том, чтобы точно сказать, когда и где что использовать, но это вариант, который стоит рассмотреть, если вы занимаетесь кастомизацией, пишете виджет и испытываете трудности с использованием virtual-hyperscript.

6

Это стоит знать — спасибо! Я потратил час или два на ручное переписывание HTML-фрагментов, но с помощью этого и html2hyperscript у меня теперь есть несколько вариантов, с которыми можно поэкспериментировать :slight_smile:

7

Интересно… Я думал, что одним из главных преимуществ Ember была скорость GlimmerVM. Неужели производительность virtual-dom настолько превосходит Glimmer?

8

Кажется, мы начали использовать виртуальный DOM ещё до того, как появился Glimmer? @eviltrout знает об этом гораздо лучше меня.

Это также напомнило мне, что использование Handlebars в виджетах с Glimmer возможно… начиная с FEATURE: Use Glimmer compiler for widget templates · discourse/discourse@dffb1fc · GitHub

9

Discourse существует с 2013 года, мы начали жаловаться на производительность Android в 2015 году, добавили virtual-dom в 2016 году, а Glimmer был анонсирован в 2017 году и сейчас активно интегрируется в Ember.

10

Понятно. Это помогает с таймлайном — спасибо! Значит, пожалуй, самый простой вариант — подождать, пока производительность Glimmer станет сопоставимой с virtual-dom, а затем отказаться от неё и вернуться к чистому Ember?

11

Эта функция крутая, но у меня возникают проблемы с её запуском. Я подключил discourse/widgets/hbs-compiler через require, но всё равно получаю ошибку: error: hbs is not a function

29
291282×334 62.5 KB

Есть какие-то идеи, почему это происходит?

Я использую версию 2.4.0beta5 и theme-cli, если это имеет значение.

12

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

Это было неприятно, так как в результате нельзя было переиспользовать существующий стандартный код в других частях кодовой базы.

13

Да, к сожалению, я думаю, что сейчас попытка использовать Handlebars вместо Hyperscript — это больше проблем, чем пользы.

15

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

16

Круто — спасибо :slight_smile:

Я с радостью приму участие в этом обсуждении и/или найду другие способы помочь :slight_smile:

17

Нет настоящего обсуждения того, ЧТО мы хотим сделать — мы хотим полноценные hbs. Вопрос скорее в следующем:

  • достаточно ли хороша производительность сейчас?
  • как перейти на это с существующей системы?
18

Ах… хорошо.

Да. Переход может оказаться непростым. В принципе, мы могли бы создать обратный аналог html2hyperscript, но на практике большинство сценариев hyperscript, скорее всего, так тесно переплетено с JS виджета, что это быстро превратится в кошмар.

Полагаю, самое простое решение — временно сохранить поддержку hyperscript, а возможно, со временем поместить его в статус устаревшего?

19

Стоит ли ждать Octane, прежде чем вкладывать дополнительные средства в эту область?

20

На самом деле, я бы сказал прямо противоположное: рационализация использования шаблонов до Octane поможет нам легче перейти на синтаксис с угловыми скобками, когда мы этого захотим.

21

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

import hbs from 'discourse/widgets/hbs-compiler';
import { createWidget } from "discourse/widgets/widget";

export default createWidget("foo", {
  template: hbs`
    <p>МОЙ ШАБЛОН</p>
  `
});

Используется в посте с [wrap] и WidgetGlue:

02
02654×290 14.7 KB

22

@edL Я вижу withPluginApi в вашем трассировке стека — вы пытаетесь использовать компилятор hbs внутри тега <script> темы? К сожалению, компилятор Handlebars для виджетов не работает в этом сценарии.

Вам нужно определить виджет в отдельном модуле с использованием операторов import, которые @j.jaffeux привёл выше. Вы можете сделать это в теме, используя поддержку JavaScript с несколькими файлами.

23

А, теперь я понял — это действительно полезно! Спасибо, Дэвид :slight_smile: