É só comigo ou o Hyperscript é horrível?

Dev
1

Aqui é só um desabafo, mas, tendo usado mais linguagens de template do que eu gostaria de lembrar (Jinja2, ERB, FTL, XSLT, JSX, Handlebars, etc.), acho Hyperscript simplesmente horrível de trabalhar.

Sem ordem específica, os problemas que ele causa incluem:

  • Portabilidade do código (não é possível copiar/colar trechos de HTML sem passá-los por um conversor)
  • Realce de sintaxe (transforma tudo em um grande amontoado), por exemplo:
    01
    01654×148 4.1 KB
    vs
    56
    56606×118 9.52 KB
  • Autocompletar de código está completamente quebrado, quanto mais recursos que economizam tempo como https://emmet.io

Nunca imaginei que algo me faria sentir saudades dos velhos e maus dias do PHP, mas o Hyperscript conseguiu!

Sou só eu?

4

Sim, concordo que não é o melhor para trabalhar, especialmente em comparação com o Handlebars (que também usamos), onde você pode escrever HTML como espera.

Começamos a usar virtual-dom/virtual-hyperscript em lugares onde precisávamos melhorar o desempenho. O tópico de nossos múltiplos sistemas de template tem sido algo que começamos a discutir dentro da equipe recentemente; ainda não temos planos concretos, mas percebemos que seria uma boa ideia simplificar. Talvez isso signifique que não usaremos mais virtual-hyperscript? O tempo dirá.

5

A sintaxe é um pouco estranha para se acostumar. Lembro-me de ter ficado bastante confuso com ela quando comecei a escrever temas para o Discourse, mas acabei entendendo como funciona. Também é possível gerar HTML bruto por meio de widgets.

Não sou o mais habilidoso para dizer quando e onde usar cada coisa, mas é uma opção a considerar se você está fazendo algum trabalho personalizado, precisa criar um widget e está tendo dificuldade em usar o virtual-hyperscript.

6

Isso vale a pena saber — obrigado! Passei uma hora ou duas reescrevendo manualmente fragmentos de HTML, mas entre isso e o html2hyperscript, tenho algumas opções para explorar :slight_smile:

7

Interessante… Eu achava que uma das grandes vantagens do Ember era a velocidade do GlimmerVM. O desempenho do virtual-dom é realmente tão superior ao do Glimmer?

8

Acho que começamos a usar virtual-dom antes do Glimmer ser uma possibilidade? @eviltrout saberia muito melhor do que eu.

Isso também me lembrou que é possível usar Handlebars em widgets usando Glimmer… a partir de FEATURE: Use Glimmer compiler for widget templates · discourse/discourse@dffb1fc · GitHub

9

O Discourse é de 2013, começamos a reclamar sobre o desempenho do Android em 2015, adicionamos o virtual-dom em 2016 e o Glimmer foi anunciado em 2017 e está sendo ativamente integrado ao Ember.

10

Entendi. Essa linha do tempo ajuda — obrigado! Então, supõe-se que o caminho mais fácil seria esperar até que o desempenho do Glimmer seja equivalente ao do virtual-dom, descartá-lo e voltar ao Ember puro?

11

Essa funcionalidade é legal, mas estou tendo algumas dificuldades para fazê-la funcionar. Já fiz o require de discourse/widgets/hbs-compiler, mas ainda recebo o erro: hbs não é uma função

29
291282×334 62.5 KB

Alguma ideia do porquê?

Estou na versão 2.4.0beta5 e usando o theme-cli, caso ajude.

12

Tentei usar templates dentro de widgets, mas descobri que isso tinha utilidade limitada, sem suporte aparente para helpers:

Isso foi irritante, pois você não podia reutilizar código padrão existente em outras partes da base de código.

13

Sim, infelizmente, acho que tentar usar Handlebars em vez de Hyperscript está dando mais trabalho do que vale a pena no momento.

15

Temos algumas discussões em andamento sobre como racionalizar nossos sistemas de template. Vou analisar isso e responder à sua questão específica nos próximos dias.

16

Legal, obrigado! :slight_smile:

Ficarei feliz em participar dessa discussão e/ou encontrar outras formas de ajudar! :slight_smile:

17

Não há uma discussão real sobre O QUE queremos fazer; queremos hbs completo. A questão é mais:

  • a performance está boa o suficiente agora?
  • como fazemos a transição do existente para isso?
18

Aah… ok.

Sim. A transição pode ser um pouco complicada. Em princípio, poderíamos criar o equivalente reverso do html2hyperscript, mas, na prática, a maior parte do hyperscript provavelmente estará tão entrelaçada com o JS do widget que isso poderia rapidamente se tornar um pesadelo.

Acho que a solução mais simples é manter o suporte ao hyperscript por um tempo e, talvez, descontinuá-lo mais tarde.

19

Vale a pena esperar pelo Octane antes de investir mais nessa área?

20

Eu diria, na verdade, exatamente o oposto: ter racionalizado nosso uso de templates antes do Octane nos ajudará a migrar para a sintaxe de ângulo (angle bracket) com mais facilidade quando desejarmos.

21

Vou dar um exemplo mais detalhado em alguns dias, mas posso confirmar que funciona.

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

export default createWidget("foo", {
  template: hbs`
    <p>MEU MODELO</p>
  `
});

Usado em uma postagem com [wrap] e WidgetGlue:

02
02654×290 14.7 KB

22

@edL Vejo withPluginApi no seu backtrace — você está tentando usar o compilador hbs dentro de uma tag <script> de um tema? Infelizmente, o compilador Handlebars de widgets não funciona nesse cenário.

Você precisa definir o widget em um módulo separado usando as instruções import que @j.jaffeux incluiu acima. Você pode fazer isso em um tema usando o suporte a JavaScript multiarquivo.

23

Ah, agora entendi — isso é realmente útil! Obrigado, David :slight_smile: