Hacker News 의견

• Vanilla JS vs. Signals 예제

  • Vanilla JS 예제가 더 읽기 쉽고 작업하기 편하다고 느끼는 사람이 나 혼자인가?
    • 설정이 복잡하고 보일러플레이트가 많다고 생각됨.
    • 카운터 값이 변경되었을 때 필요하지 않은 연산과 렌더링이 발생할 수 있음.
    • UI의 다른 부분이 카운터 업데이트 시에만 렌더링하려면 상태 관리 방법을 변경해야 할 수도 있음.
    • UI의 다른 부분이 isEven이나 parity에만 의존하는 경우, 전체 접근 방식을 변경할 필요가 있을 수 있음.

• Promises와 JavaScript의 변화

  • 처음에는 new Promise를 자주 써야 할까 걱정했지만, 실제로는 거의 사용하지 않았음.
  • 대신 .then을 많이 사용하게 되었고, 이는 다양한 서드파티 라이브러리와의 인터페이스를 단순화함.
  • Signal 제안이 반응형 UI 프레임워크에 유사한 효과를 가져다준다면 찬성함.

• 언어의 일부로서의 Signals

  • Signals가 언어의 일부가 될 필요는 없으며, 라이브러리로 충분함.
  • 현재의 JS UI 라이브러리가 설계한 Signals가 언어의 일부가 될 정도로 좋다고 생각하는 것은 오만함.
  • 모든 유행을 언어 런타임에 추가하는 것은 단기적인 시각으로 보임.

• 애플리케이션에서의 이벤트 사용

  • 애플리케이션 전반에 걸쳐 이벤트를 사용하여 신호를 보냄.
  • window.dispatchEvent와 window.addEventListener를 통해 이벤트를 발생시키고 구독함.

• DOM 상태 관리와 업데이트의 어려움

  • 수십 년 동안 사람들이 상태 관리와 DOM 업데이트를 어려워하는 이유를 이해하려고 함.
  • 간단한 DOM 함수를 복잡하게 만드는 것 같아 의아함.

• Promises와 비동기 프로그래밍

  • Promises는 성공적인 사례이지만, async/await 없이는 표준화할 필요가 없었음.
  • 다양한 라이브러리 저자들이 이 제안에 대해 어떻게 생각하는지 궁금함.

• S.js와 Signals

  • Signals를 좋아하며 UI 제작 시 다른 기본 요소보다 선호함.
  • 그러나 JavaScript 언어에 포함되어야 한다고는 생각하지 않음.

• MobX와 유사한 Signals

  • MobX는 가장 좋아하는 JS 효과 시스템임.
  • MobX 버전의 코드 예제 제공.

• 표준 라이브러리에 프레임워크 추가

  • 현재 선호하는 프레임워크를 표준 라이브러리에 추가하자는 것과 유사함.

• Signal 제안에 대한 이해와 문제점

  • Signal 제안의 예제를 이해하는 데 어려움을 겪음.
  • effect 함수가 어떻게 parity 변경을 감지하는지, 어떤 신호 변경에도 이 람다를 호출하는지 등에 대한 질문.
  • Signal 아이디어는 타당하지만, 복잡한 애플리케이션에서 이벤트 추적이 어려워질 수 있음.