Game Boy 전용으로 출시되는 최초의 JavaScript 라이브러리, htmx 4.0

 (swag.htmx.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • htmx 4: the game은 휴대용 Game Boy에서 HTMX를 체험할 수 있는 25달러짜리 게임임
  • 총 4개 레벨을 돌며 피클을 수집하는 방식으로 진행함
  • 클라이언트 측 JavaScript를 최소화하고 slop을 피하는 것이 주요 목표임
  • 마지막에 Warren을 물리치면 htmx 4.0 소스 코드를 잠금 해제할 수 있음
  • 주문 제작 상품으로, 인쇄 오류나 눈에 보이는 품질 문제는 교환·환불되지만 일반 반품과 크기 관련 반품은 받지 않음

Game Boy에서 만나는 htmx 4.0

  • htmx 4: the game은 HTMX를 휴대용 Game Boy에서 체험하도록 만든 게임이며 가격은 25달러임
  • 4개 레벨에 걸쳐 피클을 수집하면서 클라이언트 측 JavaScript를 작게 줄이고 slop을 피해야 함
  • Warren을 물리치면 htmx 4.0 소스 코드가 잠금 해제됨

품질 보증과 반품 조건

  • 인쇄 오류나 눈에 보이는 품질 문제가 있으면 제품을 교환하거나 환불함
  • 주문 제작 상품이므로 일반 반품과 크기 관련 반품은 허용되지 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • htmx를 3년간 사용하면서 서버 측 템플릿 언어와 결합할 때 웹 소프트웨어를 만드는 새로운 방식을 발견했음
    더 인상적인 건 상점 운영자의 대응력임. 예전에 8온스짜리 머그가 너무 작다고 Twitter에 불평했더니 다음 날 48온스짜리 초대형 머그를 추가했고, 그 후 매일 그 머그를 쓰고 있음

    • 학술·학회 운영처럼 비교적 틈새 용도의 웹사이트를 가끔 개발하는 수준이지만 HTMX의 빠르고 단순한 방식에 매료됐음
      JavaScript 중심 배포의 비대함 없이 방문자 부담이 적은 반응형 사이트를 빠르게 만들 수 있고, 호환성 문제와 장애 지점도 줄었으며 Google 속도 점수가 60~80에서 100으로 올랐음. 디버깅도 쉬워지고 JavaScript에 낭비하던 시간을 디자인과 기능 개선에 쓸 수 있게 됐음
      사용자 동의 없이 임의의 웹사이트가 사용자 기기에서 무거운 연산과 분석을 실행하는 관행은 애초에 허용되지 말았어야 함
    • 3~4년 전 서버 측 템플릿과 htmx를 도입해 B2B SaaS의 JavaScript 중 3분의 2를 제거했으며 훨씬 단순해졌음
      웹 앱을 만드는 단순한 방식으로 돌아가자는 철학에 공감함
    • HTMX의 백엔드로 AWS Step Functions를 쓰기 시작했는데 어렵지만 즐거움
      요즘 Step Functions는 기묘하고 거친 텍스트 템플릿 엔진처럼 활용할 수 있어, 불편함을 다듬을 DSL 계층을 구상 중임
    • htmx로 프로젝트를 하나 더 출시했는데, 이 정도의 개발 속도는 이기기 어려워 보임
    • 1.25리터면 유럽인 감각으로는 머그가 아니라 통임

  • HTMX의 분위기가 훌륭함. 기술적으로 좋고 단순하며 다양한 상황에 유용하지만 스스로를 지나치게 진지하게 여기지 않음
    intercooler.js 시절부터 업무와 개인 프로젝트에서 사용해 왔으며 여전히 좋아함. NROL-39를 떠올리게 하는 광기 어린 유니콘 레이저 눈 머그도 마음에 듦: https://swag.htmx.org/collections/octohorse, https://en.wikipedia.org/wiki/USA-247

    • NROL-39 임무 패치는 특히 좋아하는 디자인임. 승인 문서의 손글씨 메모를 찾아 읽어보면 아주 웃김
    • 오랫동안 HTMX에 반대했지만 Claude가 간단한 프로젝트에서 쓰는 걸 보고, React에도 지치고 싫증 난 상태라 이제는 꽤 괜찮아 보임

  • Big Sky Dev Con에서 Game Boy 게임이 공개되는 순간 에뮬레이터를 이용한 속임수인 줄 알았다가, 모두가 실물 카트리지를 가져갈 수 있다는 말에 입이 벌어졌음
    지금껏 본 판촉 행사 중 가장 즐거운 축에 들며, HTMX 팀이 모든 작업에서 완성도와 재미를 얼마나 중시하는지 잘 보여줌

  • HTMX를 좋아해 여러 프로젝트에서 쓰지만, 옛것이 다시 새것이 되는 현상이 재미있음
    .NET Framework의 Web Forms는 이미 2005년에 UpdatePanel로 웹페이지 일부 렌더링을 지원했고 .NET 바깥에서는 많은 비판을 받았음. HTMX는 어느 정도 이를 훨씬 세련되고 강력하게 확장한 형태임

    • 그 방식조차 C#의 선조 격인 Delphi IntraWeb이 Delphi 7 시절부터 제공하던 해법을 이어받은 셈임
      픽셀 단위로 맞춘 PSD를 HTML 테이블이나 Flash 애플릿으로 옮기던 시대에는 스타일링과 양립하기 어려워 이 개념이 사라졌지만, 오래된 IntraWeb 업무 앱을 보면 구성요소와 이벤트 등을 유행하기 훨씬 전에 이미 해결했음을 알 수 있음
      현대 웹 스택용 RAD 도구가 다시 나오길 바라지만 변화 속도가 너무 빠르고, 이제 프런트엔드와 백엔드가 분리된 전문 분야라 투자할 가치가 낮아 보임
    • HTMX는 예전에 LAMP 스택으로 웹사이트를 만들던 방식과 비슷하지만 개발 편의성이 더 좋음
    • React, Angular, Vue 프런트엔드를 10년간 개발한 뒤 전통적인 서버 측 렌더링 방식인 Ruby, Elixir, 심지어 PHP로 돌아가니 오히려 자연스러움
      AI 덕분에 PHP처럼 보기 싫은 언어와 상호작용하기 쉬워졌고, 깊은 생태계와 실행 속도, 매우 짧은 빌드 시간을 활용할 수 있음. PHP 문법과 정적 타입 부재를 싫어하면서도 SPA 난립 환경보다 생산적임
      새로고침 없이 앱 같은 경험을 준다는 클라이언트 측 렌더링의 명분은 사실상 2010년대 논리이며, 웹과 브라우저 기술은 이미 크게 발전했음

  • 홈 서버의 여러 오픈소스 웹 앱을 HTMX + Go + PostgreSQL로 다시 만들었음
    데스크톱과 모바일에서 모두 가볍고 빠르게 동작하면서 복잡성은 최소화됐고, 코드도 이해하고 수정하기 쉬움. 현재는 몇 달 간격으로 사소한 버그만 고치며, 성숙한 앱은 필수 업그레이드 간격이 수년에서 수십 년까지 늘어날 것으로 기대함

    • 공개한 오픈소스가 있는지 궁금함. Go·htmx·PostgreSQL 조합을 몇 번 가볍게 시도했지만 느낌이 좋지 않았고, 특히 Go의 서버 측 템플릿이 불편해 적절한 패턴이나 라이브러리를 놓친 것인지 알고 싶음
    • 이 정도도 과도한 설계로 보임. 스키마 변경 중 무중단이 반드시 필요한 사이트가 아니라면 WAL2 모드 SQLite로 충분함
      PostgreSQL도 버전 업그레이드 때 상당한 중단을 피하려면 복제 환경과 복잡한 전환 절차가 필요하므로 선택이 단순하지만은 않음

  • HTMX가 처음 알려졌을 때부터 만족스럽게 사용하고 Grug 글도 널리 전달해 왔으며, 소프트웨어 개발을 재미있게 유지하는 문화 덕분에 이번 상품도 바로 구매했음

  • Grug-brained developer 글과 HTMX를 같은 사람이 만들었는지 궁금함

    • 맞음
    • 그가 Lulu 책도 썼음

  • HTMX도 결국 JavaScript 라이브러리이며, 스크립트를 끈 환경을 위한 자동 대체 동작이 충분하지 않다는 점이 싫음
    이 때문에 개발자들이 정적 콘텐츠 페이지조차 모두 HTMX로 처리하려 함. 오래된 방식의 포럼을 호스팅하려고 PHP와 MySQL 부담을 피해 Python 기반 PunkwebBB를 찾았지만, 스크립트를 끄자 일부 버튼이 아무 동작도 하지 않았고 기능상 불필요한 HTMX를 사용하고 있었음
    포크해서 불필요한 JavaScript를 제거하기엔 작업량이 너무 커서, 결국 Python Django 기반 무JavaScript 포럼을 직접 만들고 있음

    • 내 Next.js 사이트는 JavaScript를 꺼도 링크와 HTML이 서버에서 렌더링돼 작동함. 클라이언트에서 실행되는 도구는 멈추지만 정적일 수 있는 페이지는 정적으로 유지됨
      다만 최근 캐시 컴포넌트를 도입한 뒤 이 특성이 퇴행한 것을 이제야 발견해 답답함
    • HTMX의 설계 전체가 일종의 자동 대체 동작처럼 느껴짐. hx-get, hx-post 같은 속성을 이해하지 못하는 브라우저를 고려해 처음 보내는 HTML 자체를 정상 작동하도록 설계하면 됨
    • 그래서 Turbo(https://turbo.hotwired.dev/)를 더 선호함
      Turbo는 올바른 HTML에서 시작해 풍부한 동작을 덧붙이는 점진적 향상 철학을 따름. HTMX는 React와 마찬가지로 JavaScript 라이브러리이며 그 자체가 잘못은 아니지만, 모든 것을 JavaScript에 의존하는 안티패턴에 빠지기 더 쉬움
      이제는 JavaScript 없이 작동해야 한다는 논거보다 서버 렌더링된 의미론적 HTML이 접근성·SEO·LLM 및 자동화 도구에 중요하다는 점이 더 강력함. HTMX로도 훌륭한 HTML을 만들 수 있지만, HTML 속성 안에 조용히 JavaScript 앱을 만들고 있지 않은지 알아차릴 규율과 경험이 필요함

  • htmx 4.0을 Game Boy와 Game Boy Color용 게임으로 출시함
    Mario Bros.에서 영감을 받은 진짜 게임으로, 세 생물군에 걸친 네 레벨을 통과해 최종적으로 슬롭 공장에서 온라인상 라이벌이자 실제 친구인 보스 Warren Buffering과 싸우게 됨. 이기면 htmx 4.0 소스 코드가 해제됨
    Stephen Mitchell(scum)이 크게 맞춤화한 GB Studio로 직접 제작했으며 제작기를 곧 공개할 예정임. Jarason Banes가 카트리지 제작과 표지 디자인을 맡았고, Ash(https://www.fiverr.com/ae1996/)가 표지 그림과 https://hypermedia.systems의 소프트커버 그림을 담당했음

    • GB Studio 제작자임. 이 프로젝트에 사용된 모습을 보니 멋지며 다음 버전용 기능도 개발 중임: https://www.youtube.com/watch?v=q8UKwV1gJAI
    • GB Studio 내장 사운드 엔진을 썼다면 그 코드는 내가 작성한 것임. 이런 프로젝트에서 내 코드가 등장하면 늘 즐거움
    • 카트리지와 다른 상품도 주문했으며, https://brickboy.xyz/가 도착하면 바로 시작할 생각임
    • 첫 개봉·플레이·리뷰 영상이 기대됨
    • 실제 물리 카트리지인지, 마지막에 소스 코드를 어떻게 꺼내는지 궁금함
      Git 저장소용 암호를 보여주는 방식인지, 소스 접근 권한을 주는 NFT 같은 형태인지 알고 싶음

  • 비판자가 끼어들어 HTMX가 왜 안 되는지 설명하지 않는 HTMX 스레드라니 놀라움
    React 애호가조차 Game Boy 출시는 인정할 수밖에 없어 보임

답변달기