나만 그런 건가, Hyperscript가 정말 못생겼나?

개발
1

여기서 그냥 불만 좀 털어놓겠습니다. Jinja2, ERB, FTL, XSLT, JSX, Handlebars 등 기억하기 싫을 정도로 많은 템플링 언어를 사용해 봤는데, Hyperscript는 작업하기가 정말 끔찍합니다.

특정 순서 없이, 이 언어가 깨뜨리는 것들은 다음과 같습니다:

  • 코드 이식성(컨버터를 거치지 않고 HTML 스니펫을 복사/붙여넣기할 수 없음)
  • 문법 하이라이팅(모든 것을 거대한 덩어리로 만듦) 예:
    01
    01654×148 4.1 KB
    vs
    56
    56606×118 9.52 KB
  • 코드 완성 기능이 엉망이며, https://emmet.io 같은 시간 절약 도구는 말할 것도 없습니다.

PHP의 나쁜 옛날 시절을 그리워하게 될 것이라고는 생각도 못 했는데, Hyperscript가 그걸 해버렸습니다!

저만 그런 건가요?

4

네, 동의합니다. 특히 HTML을 예상대로 작성할 수 있는 handlebars(우리가 이것도 함께 사용 중)와 비교했을 때, 이걸로 작업하는 것이 가장 좋지는 않다고 생각해요.

성능을 개선해야 하는 부분에서는 virtual-dom/virtual-hyperscript를 사용하기 시작했습니다. 여러 템플링 시스템을 사용하는 문제는 최근 팀 내에서 논의하기 시작한 주제입니다. 아직 구체적인 계획은 없지만, 단순화하는 것이 좋은 아이디어라는 것을 인식하고 있습니다. 아마도 virtual-hyperscript를 더 이상 사용하지 않게 될 수도 있겠죠. 시간이 말해 줄 겁니다.

5

문법을 처음 접할 때 약간 낯설 수 있습니다. 처음에 디스커스 테마를 작성할 때 이 문법 때문에 꽤 헤맸던 기억이 나지만, 결국 어떻게 동작하는지 파악할 수 있었습니다. 위젯을 통해 원시 HTML을 생성하는 것도 가능합니다.

무엇을 어디에 사용할지 판단하는 데는 가장 능숙하지는 않지만, 커스텀 작업을 하거나 위젯을 작성해야 하고 virtual-hyperscript 사용에 어려움을 겪고 있다면 고려해 볼 만한 옵션입니다.

6

알아두면 좋은 정보네요. 감사합니다! HTML 조각을 수동으로 다시 작성하는 데 1~2시간을 썼지만, 이 방법과 html2hyperscript를 합치면 몇 가지 옵션을 가지고 놀 수 있게 되었어요 :slight_smile:

7

흥미롭네요… 에임버의 큰 장점 중 하나가 GlimmerVM의 속도라고 생각했는데, 가상 DOM 성능이 Glimmer보다 그렇게 큰 차이가 있나요?

8

glimmer이 가능해지기 전에 virtual-dom을 사용하기 시작했던 것 같습니다. @eviltrout 님이 저보다 훨씬 잘 아실 거예요.

또한, glimmer를 사용하는 위젯에서 handlebars를 사용하는 것도 가능하다는 것을 떠올리게 했습니다… FEATURE: Use Glimmer compiler for widget templates · discourse/discourse@dffb1fc · GitHub 커밋부터 가능해졌죠.

9

Discourse는 2013년에 시작되었습니다. 우리는 2015년에 Android 성능에 대해 불만을 제기하기 시작했고, 2016년에 virtual-dom을 도입했으며, Glimmer는 2017년에 발표되어 현재 Ember에 적극적으로 통합되고 있습니다.

10

알겠습니다. 그 타임라인이 도움이 되네요. 감사합니다! 그러면 가장 쉬운 방법은 Glimmer의 성능이 virtual-dom과 동등해질 때까지 기다렸다가, Glimmer를 버리고 순수 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

음, 안타깝게도 현재로서는 하이퍼스크립트 대신 핸들바를 사용하려는 시도가 더 많은 문제를 일으킬 것 같습니다.

15

현재 템플릿 시스템을 합리화하는 방법에 대해 브레인스토밍을 진행 중입니다. 며칠 내로 구체적인 문제에 대한 답변을 드리겠습니다.

16

좋아요 – 감사합니다 :slight_smile:

그 논의에 참여하거나 다른 방법으로 기여하는 방법을 찾아보는 것도 기꺼이 해보겠습니다 :slight_smile:

17

우리가 무엇을 하고 싶은지에 대한 실질적인 논의는 없습니다. 우리는 완전한 HBS를 원합니다. 문제는 다음과 같습니다:

  • 현재 성능이 충분히 좋은가?
  • 기존 것을 이 방식으로 전환하는 방법은?
18

아.. 알겠습니다.

네. 전환 과정이 좀 까다로울 수 있겠네요. 원칙적으로는 html2hyperscript의 역방향 등가물을 만들 수 있지만, 실제로는 대부분의 하이퍼스립트가 위젯의 JS와 너무 긴밀하게 얽혀 있어서 금세 악몽 같은 상황이 될 수 있습니다.

가장 간단한 해결책은 하이퍼스립트 지원을 당분간 유지하다가, 추후에 비추천(deprecate) 처리하는 것 아닐까요?

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>MY TEMPLATE</p>
  `
});

[wrap] 및 WidgetGlue를 사용하여 게시글에서 사용:

02
02654×290 14.7 KB

22

@edL 백트레이스에서 withPluginApi를 확인했습니다 - 테마의 <script> 태그 안에서 hbs 컴파일러를 사용하려는 건가요? 안타깝게도 위젯 handlebars 컴파일러는 해당 시나리오에서 작동하지 않습니다.

@j.jaffeux가 위에 언급한 import 문을 사용하여 위젯을 별도의 모듈로 정의해야 합니다. 테마에서는 멀티파일 JavaScript 지원을 통해 이를 수행할 수 있습니다.

23

아, 이제 이해했어요. 정말 도움이 되네요! 데이비드 씨, 감사합니다 :slight_smile: