앞으로 HTML 자체에서 JavaScript 없이도 모든 HTTP verb(put, delete 등)를 지원하고, 드롭다운·멀티셀렉트·날짜·시간 같은 입력 컨트롤을 기본 제공하며, 페이지 전체 리로드 없이 폼을 제출할 수 있기를 바람
처음 htmx라는 이름을 들었을 때 그런 걸 기대했지만, 실제로는 intercooler 수준이었음
이런 기능은 브라우저 벤더들의 폭넓은 지원이 필요함
htmx의 아이디어 일부를 HTML 스펙에 직접 통합하려는 작업을 진행 중임
관련 내용은 Triptych 프로젝트에서 볼 수 있음
JavaScript 프레임워크를 직접 만들어본 입장에서 Marko는 과소평가받고 있다고 생각함
컴파일 타임 최적화가 매우 인상적이며, 세밀한 번들링 설명 문서도 훌륭함
실제로 Kanban 보드 성능 비교에서도 좋은 결과를 보였음
RSC와 SSR 유행은 누군가의 승진 명분이나 새 회사를 차리기 위한 구실 같았음
React는 Next.js와 결합하며 플랫폼의 본질을 배신했고, 이제는 선택할 이유가 거의 없음
정적으로 하이드레이션된 React가 CDN 위에서 돌아가던 시절이 훨씬 나았음
SvelteKit을 새 프로젝트에 자주 쓰는데, 기능·개발 경험·성능의 균형이 좋음
그래도 Marko도 살펴봐야겠다는 생각이 듦
Electron 같은 데스크톱 프레임워크 쪽도 이런 깊이 있는 분석이 있으면 좋겠음
React를 좋아하는 이유는 단순히 “그냥 JavaScript” 이기 때문임 <let>이나 <for> 같은 문법은 보기 싫음
JSX도 사실 순수한 JavaScript는 아님
너무 익숙해져서 그렇지, 새로운 프레임워크를 볼 때는 이 점을 기억해야 함
예전에도 좋은 템플릿 문법이 있었고 지금도 있음 {% for user in users %}나 {#each users as user} 같은 형태가 훨씬 명확함
JSX도 완벽하지 않음 — {users.map(...)} 구문은 여전히 장황함
예전에 Marko를 써봤는데, 원래 eBay 내부 프로젝트로 시작해 2015년쯤 오픈소스로 전환되었음
사람마다 다르지만, 이런 템플릿 기반 문법이 마음에 드는 이들도 있음
Vue나 Svelte가 인기 있는 이유도 그 때문임
참고로 Vue는 원하면 JSX만으로도 작성 가능함
React는 이미 오래전부터 “그냥 JS”가 아님
DSL이 점점 비대해지고, useFormStatus나 useActionState 같은 훅이 늘어나면서 복잡해졌음
반면 Marko의 문법은 직관적이고, 함수는 함수처럼, 변수는 변수처럼 보여서 이해하기 쉬움
HTML 안에 JS를 넣는 방식이 꽤 신선함
Ryan Carniato가 이 프로젝트에 참여했다가 나중에 SolidJS를 이끌게 되었는데, 왜 다시 HTML-in-JS 스타일로 돌아갔는지 궁금함
Ryan은 Solid를 eBay/Marko 합류 전부터 진행 중이었음
두 프로젝트는 서로의 아이디어를 공유하며 발전했고, 지금도 교류 중임
JSX를 선택한 이유는 단순함
많은 개발자가 익숙하고, 에디터와 TypeScript 지원이 이미 잘 되어 있음
“JS inside HTML”이라니, 마치 1995년 Netscape 시절로 돌아간 느낌이라 농담처럼 들림
20년 넘게 프론트엔드가 돌고 돌아 결국 JSP 시절의 패러다임으로 회귀한 느낌임
당시엔 ‘촌스럽다’며 외면했지만, 결국 그게 옳았던 것 같음
기술은 순환하지만, 매번 미묘한 개선이 있음
어떤 건 사라지지만, 다음 세대의 창의성이 새로운 걸 만들어냄
JSF도 기억남 — 서버 사이드에서 상태를 복원할 수 있었고, 복잡한 폼 기반 웹사이트를 빠르게 만들 수 있었음
다만 대규모 확장성에는 주의가 필요했음
“옳은 패러다임”이라는 말엔 동의하기 어려움
상황에 따라 다른 접근이 더 적합할 수 있음
SPA를 선택한 이유를 “옛 기술이 싫어서”로 단정하는 건 너무 단순함
당시엔 모바일 앱과 API 중심 구조가 필요했고, SPA는 그 요구에 맞았음
지금은 JSP로의 회귀가 아니라 양쪽의 균형점을 찾는 과정임
Marko는 이미 eBay에서 검증된 기술임
수년간 써왔지만 문제를 겪은 적이 없음
반면 React 기반의 Facebook, Instagram, Messenger는 UI 버그가 끊이지 않음
실제 대규모 서비스에서의 결과를 보면 Marko의 안정성이 돋보임
Hacker News 의견
앞으로 HTML 자체에서 JavaScript 없이도 모든 HTTP verb(put, delete 등)를 지원하고, 드롭다운·멀티셀렉트·날짜·시간 같은 입력 컨트롤을 기본 제공하며, 페이지 전체 리로드 없이 폼을 제출할 수 있기를 바람
처음 htmx라는 이름을 들었을 때 그런 걸 기대했지만, 실제로는 intercooler 수준이었음
이런 기능은 브라우저 벤더들의 폭넓은 지원이 필요함
관련 내용은 Triptych 프로젝트에서 볼 수 있음
JavaScript 프레임워크를 직접 만들어본 입장에서 Marko는 과소평가받고 있다고 생각함
컴파일 타임 최적화가 매우 인상적이며, 세밀한 번들링 설명 문서도 훌륭함
실제로 Kanban 보드 성능 비교에서도 좋은 결과를 보였음
React는 Next.js와 결합하며 플랫폼의 본질을 배신했고, 이제는 선택할 이유가 거의 없음
정적으로 하이드레이션된 React가 CDN 위에서 돌아가던 시절이 훨씬 나았음
그래도 Marko도 살펴봐야겠다는 생각이 듦
Electron 같은 데스크톱 프레임워크 쪽도 이런 깊이 있는 분석이 있으면 좋겠음
React를 좋아하는 이유는 단순히 “그냥 JavaScript” 이기 때문임
<let>이나<for>같은 문법은 보기 싫음너무 익숙해져서 그렇지, 새로운 프레임워크를 볼 때는 이 점을 기억해야 함
{% for user in users %}나{#each users as user}같은 형태가 훨씬 명확함JSX도 완벽하지 않음 —
{users.map(...)}구문은 여전히 장황함Vue나 Svelte가 인기 있는 이유도 그 때문임
참고로 Vue는 원하면 JSX만으로도 작성 가능함
DSL이 점점 비대해지고, useFormStatus나 useActionState 같은 훅이 늘어나면서 복잡해졌음
반면 Marko의 문법은 직관적이고, 함수는 함수처럼, 변수는 변수처럼 보여서 이해하기 쉬움
HTML 안에 JS를 넣는 방식이 꽤 신선함
Ryan Carniato가 이 프로젝트에 참여했다가 나중에 SolidJS를 이끌게 되었는데, 왜 다시 HTML-in-JS 스타일로 돌아갔는지 궁금함
두 프로젝트는 서로의 아이디어를 공유하며 발전했고, 지금도 교류 중임
많은 개발자가 익숙하고, 에디터와 TypeScript 지원이 이미 잘 되어 있음
20년 넘게 프론트엔드가 돌고 돌아 결국 JSP 시절의 패러다임으로 회귀한 느낌임
당시엔 ‘촌스럽다’며 외면했지만, 결국 그게 옳았던 것 같음
어떤 건 사라지지만, 다음 세대의 창의성이 새로운 걸 만들어냄
다만 대규모 확장성에는 주의가 필요했음
상황에 따라 다른 접근이 더 적합할 수 있음
당시엔 모바일 앱과 API 중심 구조가 필요했고, SPA는 그 요구에 맞았음
지금은 JSP로의 회귀가 아니라 양쪽의 균형점을 찾는 과정임
Marko는 이미 eBay에서 검증된 기술임
수년간 써왔지만 문제를 겪은 적이 없음
반면 React 기반의 Facebook, Instagram, Messenger는 UI 버그가 끊이지 않음
실제 대규모 서비스에서의 결과를 보면 Marko의 안정성이 돋보임
Marko는 예전부터 여러 번 HN에 등장했음
2023년 1월, 2017년 8월, 2015년 2월에도 관련 스레드가 있었음
JSX보다 훨씬 개선된 문법처럼 보임
특히 Pug 스타일의 간결한 문법이 마음에 드는데, 왜 문서 깊숙이 숨겨놨는지 의문임
Concise Syntax 문서
하지만 문서의 하이라이팅 오류나 속성 구분 방식이 마음에 들지 않았음
최근엔 Svelte를 주로 쓰지만, 여전히 더 우아한 문법을 기다리고 있음
공백 기반 문법은 괜찮지만,
--같은 표기나 파싱 난이도는 아쉬움Marko 팀이 Marko 6을 소개하기 위해 Hacker News 클론을 직접 만들어 공개했음
GitHub 예제 보기
데모용으로 만든 언어라 그런지, “HTML-based”, “building web apps” 같은 그라데이션 텍스트가 안 보이는 건 좀 웃김