HTML 우선 사이트를 구축해 하룻밤 사이 사용자를 두 배로 늘린 방법

 (mohkohn.co.uk)
1P by GN⁺ | ★ favorite | 댓글 2개
  • HTML 우선 접근은 공공 서비스 신청 폼을 자바스크립트 없이도 작동하게 만들고, 열악한 기기·브라우저·네트워크에서도 사용자가 신청을 완료할 수 있게 함
  • 기존 React 앱은 고객 불만으로 3일 만에 내려갔고, 로딩 스피너·전역 자바스크립트 상태·접근성 문제·localStorage 5MB 한계에 걸린 이미지 저장 방식이 문제였음
  • 새 구현은 Astro 기반으로 각 폼 단계를 별도 페이지로 만들고, 제출 데이터와 업로드를 백엔드 세션에 단계마다 저장해 입력 데이터 손실을 막음
  • 폼 검증은 브라우저 내장 HTML 검증을 감싼 웹 컴포넌트로 처리했고, 실패 시 브라우저 기본 검증과 백엔드 API 검증으로 이어지는 점진적 향상 구조를 사용함
  • 출시 후 폼 완료자가 두 배로 늘었고, 자바스크립트 실패로 이탈한 사용자는 자바스크립트 기반 분석 패키지에 잡히지 않는다는 점이 드러남

문제 배경과 실패한 이전 시도

  • 고객은 유틸리티 회사였고, 서비스 신청은 웹사이트의 오래된 ASP 폼이나 수동 절차를 통해 가능했음
  • 수동 절차는 회사에 더 비쌌고, 고객 만족도가 96% 아래로 떨어지면 수백만 파운드 벌금이 발생할 수 있는 규제 독점 상황이었음
  • 문제 해결을 위한 이전 시도는 두 번 실패했고, 가장 최근 시도에서는 다른 나라의 계약자들이 React 앱을 만들었음
  • React 앱은 온라인 공개 3일 뒤 고객 불만 때문에 내려갔음
  • 해당 앱은 로딩 스피너와 전역 자바스크립트 상태가 뒤섞여 있었고, 접근성을 갖추지 못했음
  • 이미지 업로드가 폼의 핵심 기능이었지만, 이미지와 모든 폼 데이터를 5MB 제한이 있는 localStorage에 저장하려 했음

HTML 우선으로 정한 기준

  • 새 사이트는 Astro로 구축됐고, HTML 우선 구조를 채택함
  • 자바스크립트는 웹 컴포넌트 안에서만 사용됐고, 자바스크립트 없이도 정상 작동하는 웹사이트를 점진적으로 개선하는 역할을 맡음
  • 공공 서비스는 가능한 모든 기기에서 작동해야 한다는 기준이 적용됨
  • 연결 상태가 나빠도 작동해야 한다는 기준이 적용됨
  • 한 번 입력된 폼 데이터는 절대 사라지지 않아야 한다는 기준이 적용됨
  • Terence Eden의 사례는 GOV.UK의 단순 HTML 페이지가 느리고 메모리 부족이 잦은 PlayStation Portable 브라우저에서도 주거 급여 정보를 읽을 수 있게 했다는 점을 보여줌
  • GOV.UK 페이지는 가볍게 설계된 단순 HTML로 작성됐고, 형편없는 브라우저에서도 작동해야 했음

폼 구조와 데이터 보존 방식

  • 폼의 각 세션은 고유 ID를 가져야 했음
  • 폼 마법사의 모든 단계에서 제출 데이터와 업로드 파일은 백엔드에 저장돼야 했음
  • 자바스크립트 없이도 폼 완료가 가능해야 했음
  • 오래되고 성능이 낮은 웹 브라우저에서도 폼 완료가 가능해야 했음
  • 접근성은 WCAG 기준을 충족해야 했고, 팀은 AAA가 아니라 AA를 목표로 정했음
  • 자바스크립트와 최신 CSS는 경험을 향상하는 데 사용돼야 했음
  • 최종 구조에서는 폼 마법사의 각 단계가 별도 페이지가 됐고, 사용자가 다음을 누르면 폼이 제출됐음
  • API가 데이터를 유효하다고 판단하면 브라우저가 다음 단계로 리디렉션됐음
  • 폼 제출과 리디렉션은 오래된 웹 애플리케이션 패턴이며, Remix 덕분에 작은 현대적 부흥을 겪었음
  • 이 서비스는 실시간 데이터를 보여주는 앱이 아니라 큰 폼이었고, 렌더링 전에 20MB 자바스크립트를 보내는 방식은 부적절했음

폼 검증과 점진적 향상

  • 폼 검증과 폼 오류 렌더링은 React 검증 라이브러리 때문에 팀들이 여러 인월을 쓰는 영역으로 다뤄짐
  • 브라우저에는 이미 검증 시스템이 포함돼 있고, 별도 라이브러리 관리가 필요한 낮은 품질의 모방 구현보다 적은 작업으로 활용 가능함
  • 구현된 HTML 웹 컴포넌트는 기존 HTML을 감싸는 단순한 커스텀 요소였음
  • 이 웹 컴포넌트는 섀도 DOM을 쓰지 않았고, 자바스크립트 안에서 HTML을 거의 렌더링하지 않았음
  • 컴포넌트는 HTML 폼을 감싸고 HTML 검증을 가져와 현대적인 형태로 표시했음
  • HTML 검증 팝업 툴팁은 막고, 필드와 연결된 aria-describedby 요소 안에 오류를 배치했음
  • 현재는 aria-errormessage 사용이 권장됨
  • 입력 중 유효한 상태가 되면 검증을 지우고, blur와 제출 시점에 다시 평가했음
  • 이 사용자 경험은 1KB 미만으로 제공됐고, 실패 시 브라우저 기본 검증으로 되돌아갔음
  • 브라우저 기본 검증도 실패하면 백엔드 API가 검증을 처리했음
  • 검증 문제는 사용자의 브라우저가 허용하는 가장 이른 시점에 알려졌고, 실패해도 항상 수용 가능한 경험으로 폴백됐음
  • 이후 일반 사용을 목표로 새 버전의 웹 컴포넌트가 처음부터 다시 작성됐고, 이름은 validation-enhancer임
  • 사용 예시는 validation-enhancer가 HTML 폼을 감싸고, input type="email", required, aria-errormessage를 그대로 활용하는 구조임
<validation-enhancer>
<form>
<label for="my-email">Email</label>
<input type="email" name="my-email" aria-errormessage="my-email-error" required />
<div id="my-email-error"></div>
<button type="submit">Submit</button>
</form>
</validation-enhancer>

출시 결과와 결론

  • 출시 후 폼을 완료한 사람 수가 두 배가 됨
  • 분석 담당자들은 이 사용자들이 어디서 왔는지 알지 못했음
  • 자바스크립트 기반 분석 패키지는 자바스크립트 실패로 이탈한 사용자를 보지 못함
  • 백엔드 세션을 유지하고 사용자 데이터를 절대 잃지 않는 접근은 효과를 냈음
  • 한 사례에서는 사용자가 폼을 시작한 지 한 달 뒤 완료했음
  • 계약 업무가 끝난 뒤 후임자는 자바스크립트 없이도 항상 작동하는 구조가 팀에 더 많은 일을 만든다고 반응했음
  • 오래된 브라우저 사용자, 나쁜 네트워크 연결 사용자, 보조 기술 사용자들을 배제하는 것은 독점 공공 서비스에서 받아들일 수 없음
  • 소프트웨어 산업의 확장기에 나타난 거칠고 미성숙한 방식을 계속 밀어붙이는 흐름은 내려놓아야 함
  • PlayStation Portable과 3G 연결에서도 작동하는 웹 애플리케이션을 만들면 모든 사용자에게 작동하고, 30년 뒤에도 작동할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 비웹 개발자로서 궁금한데, 왜 이 방식이 일이 더 많아지는지 모르겠음
    글에서 설명한 접근은 꽤 단순해 보임: 폼용 표준 컴포넌트를 만들고 아래에 제출 버튼을 두면 됨. 오래전에 개인 웹사이트 만들 때도 그렇게 했고 그렇게 어렵지 않았음. 이 분야를 잘 몰라서 그런 걸 수도 있지만, 화려한 프런트엔드를 만드는 쪽이 훨씬 더 어려워 보임

    • 몇 년 전부터 일부 주니어·미드레벨 엔지니어들이 무거운 단일 페이지 앱 프레임워크가 아닌 방식으로 웹사이트를 만들 수 있다는 가능성을 한 번도 진지하게 생각해본 적이 없다는 걸 깨달았음
      멍청해서가 아님. “React 없이 웹사이트 만들 수 있나요?”라고 직접 물으면 당연히 “예”라고 답할 것임. 하지만 새 웹사이트를 만들라고 하면 익숙함과 일을 끝내고 싶은 마음 때문에 별생각 없이 새 React 프로젝트를 시작함
      일부는 정말로 다른 방법을 모름. 순수 HTML을 보내는 평범한 HTTP 서버를 세우는 법도, JavaScript 없이 검증·제출되는 폼을 만드는 경험도 없음. 이런 사람들은 HN에 글 쓰는 사람들이 아니고, 새 도구나 기술, 혹은 오래된 도구와 기술에 대한 온라인 토론에도 참여하지 않음. 부트캠프나 대학의 웹앱 과목 하나에서 취업에 필요한 만큼만 배운 뒤, 고용주가 요구하거나 팀의 누군가가 고른 특정 도구만 그때그때 배워온 경우임
      나이 든 입장에서는 이걸 알아차리는 데 시간이 좀 걸렸지만 이제는 이해됨. 경력 경로에 따라 어떤 사람은 HTML, CSS, 순수 JavaScript의 가장 단순한 부분을 각 기술의 복잡한 프레임워크 전용 부분보다 나중에 접하게 됨. 그래서 그들에게는 더 비전문적이 아니라 오히려 더 난해하고 고급이거나 부차적인 지식처럼 느껴짐
      “그건 우리 일이 훨씬 많아진다”는 말도 꼭 의도적으로 틀린 주장은 아닐 수 있음. 익숙하지 않은 도구로 작업을 수행하면, 그 도구가 덜 복잡하더라도 실제로 일이 훨씬 많게 느껴질 가능성이 큼
    • 2년 전 새 회사를 시작하면서 무거운 JavaScript 단일 페이지 앱 프레임워크를 쓰지 않기로 처음부터 정했음. 단순한 서버 렌더링 HTML을 유지했고, JavaScript는 점진적 향상 방식으로만 사용함
      앱은 빠르고 단순했지만 대가도 있었음. 풍부한 UI 요소를 npm 패키지로 바로 가져다 쓰는 능력이 제한됐고, 좋은 사용자 경험을 제공하려면 훨씬 더 많은 작업이 필요했음. 모든 것이 더 오래 걸렸고 결과적으로 사용자 경험도 나빠졌음. 신경은 썼지만 끝까지 챙길 시간이 없을 때도 있음
      회사는 실패했고 React가 그걸 구했을 거라고 생각하지는 않음. 하지만 “단순함”에 대한 도덕적 집착도 도움이 되지는 않았다고 직접 말할 수 있음. 언제나 트레이드오프임
    • 다른 사람이 쓴 코드를 많이 읽는 입장에서, 많은 사람에게 새로운 방식 배우기는 세상에서 가장 어려운 일처럼 받아들여진다고 확신함
    • 한쪽 이야기만 듣는 게 문제라고 봄
      누군가는 대부분이 떠올릴 해법보다 더 단순하고 합리적인 해법을 제공했다고 말하고, 인수인계받은 사람은 만족하지 않았음
      넘겨받은 코드 품질이 높았는지 알 수 있나? 그 사람이 “React가 아니다”라는 사실에 반응한 걸까? 회사에서 앱을 만드는 방식에 대해 강제하는 템플릿이 있었을 수도 있나?
      알 수 없음
    • 사람들이 익숙한 기술과 관련이 있을 가능성이 큼. 웹앱을 만들 때 JavaScript 생태계만 알아온 웹 개발자 세대가 몇 번 있었고, 그래서 순수 JavaScript 해법이 아닌 것은 낯설게 보일 수 있음

  • 한동안 많이 듣지는 못했지만, HTML Triptych 제안은 언젠가 브라우저에 들어가길 여전히 바라는 것 중 하나임. HTML 폼이 REST 엔드포인트와 대화하는 방식은 좋은 패턴임
    사용자 보조 검증은 입력 속성으로 처리하고, 실제 검증은 요청 반대편에서 처리하며, 흐름은 GET /form => POST /thing => GET /thing/1이 되는 형태임. triptych 기능이 구현되면 훌륭한 패턴이 될 것임
    [0] https://triptychproject.org/

  • React 사이트를 전혀 좋아하지 않지만 이해 안 되는 건, 이런 사이트들은 지연 로딩을 전혀 안 하나 싶음
    큰 단일 페이지 앱도 컴포넌트를 필요할 때만 불러오면 매우 빠름
    Angular1 -> Vue2 -> Svelte2를 거쳐 섀도 DOM 없는 순수 웹 컴포넌트에 정착했는데, 작업하기 즐겁고 빠름

  • 요즘 대부분의 앱은 단순히 HTMX + Go + SQLite로 만듦
    대부분 프로젝트에는 충분하다고 느꼈음
    내 사이트 중 하나는 이미지가 많고 월 10TB 트래픽을 처리함. 이 경우 구성은 다음과 같음: 1. 신뢰할 수 있는 데이터 저장소가 필요해서 S3 사용 2. 앞단에 Cloudflare를 두고 Tiered Cache를 켬. 이렇게 하면 POP들이 원본보다 Cloudflare에서 가져오기를 선호함. 브라우저와 Cloudflare 양쪽에서 1년간 모든 것을 캐시하고, 원본 캐시 정책과 쿼리 문자열을 무시하는 규칙을 설정했으며, 리비전이 필요한 불변 객체만 사용함 3. 그 앞에 BunnyCDN을 둠
    Cloudflare만으로 이미지가 많은 사이트를 운영하게 해주지는 않아서, 이 방식으로 비용을 크게 줄임. 정책상 주로 이미지에 쓰면 안 되고 HTML, CSS, JavaScript와 기타 사이트 콘텐츠에 사용해야 함
    S3만 쓰면 비용이 엄청 커짐
    다만 최근에는 모바일 앱을 만들고 있음. PWA는 한계가 있음. 운영체제가 IndexedDB 저장소를 회수할 수 있어서, 회원가입이나 백엔드 개입 없이 앱 안에서 신뢰할 수 있는 데이터 저장소를 제공할 수 없음
    결국 Android에서는 Flutter로 옮길 수밖에 없었지만 또 다른 고통이 있었음. 앱 업데이트가 “심사 중”으로 오래 걸릴 때가 있어 답답함. 같은 앱의 웹앱은 비교하면 업데이트가 매우 빠름
    왜 JavaScript, HTML, CSS로 앱을 만들게 해주고 안정적인 저장소까지 큰 노력 없이 제공하는 모바일 운영체제가 없는지 궁금함. PWA 앱을 빠르게 업데이트할 수 있는 점은 좋음

    • 그런 모바일 운영체제는 있었음. 2009년에 Palm이 webOS를 출시했을 때로 시간여행만 하면 됨
      시간여행은 쉬운 부분이고, 그다음에는 Palm의 몰락과 webOS가 스마트폰 운영체제로서 잊히는 일을 어떻게든 막아야 함
      2009년이 너무 멀다면 2012년의 Firefox OS에 운을 걸어볼 수도 있음
      농담은 제쳐두고, 사람들과 회사들이 시도한 적은 있음. 하지만 나쁜 타이밍과 여러 사건이 겹쳐 우리 시간선에서는 그 현실이 일어나지 못했음
    • Go는 서버 앱에 정말 좋음. 훨씬 더 일찍 알았어야 했음
      C처럼 쓸데없는 부담이 없으면서도, Java처럼 비즈니스 로직에 집중할 수 있게 길을 비켜주는 정확한 최적 지점에 있는 느낌임. Rust와는 다름
      모든 작업에 좋은 건 아님. 특히 추상화를 만드는 능력 부족은 아쉬움. 하지만 비즈니스 로직이 많은 서버 앱에는 훌륭함. 모든 걸 다 하려는 언어가 아니라 그 분야에 특화된 느낌임
    • 월 10TB 트래픽은 CDN, 광고 중개, 포르노, 대형 전자상거래 사이트가 아니면 상상이 잘 안 됨. 뭘 하길래 월 10TB 트래픽이 나오는지 궁금함
    • 나랑 같은 사람인가 싶음. 요즘 HTMX + Go + SQLite로 이것저것 만드는 데 빠져 있음. 나에게 잘 맞는 지루한 기술 3종 세트 같음. 배포는 일반적인 bash 스크립트로 코로케이션 서버에 함
      SQL과 HTMX/웹/OAuth 부분을 추상화하려고 라이브러리도 몇 개 만들었음. 이제 내 앱들은 서로 매우 비슷해서 기능을 옮겨 붙이기 쉬움
      https://github.com/cattlecloud/webtools
      https://github.com/cattlecloud/litesql
    • 요즘 10TB는 별것도 아님. Hetzner의 유럽 가상 서버는 모두 월 20TB 트래픽이 포함되어 있고 초과분도 TB당 2달러 미만임. 전용 서버는 무제한 공정 사용인데, 여러 달 평균으로 보면 아마 월 200TB 정도일 것임

  • 반론으로는 In Defence of the Single Page Application이 있음
    https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...

    • 재미있게도 모바일 인터넷 연결에서 열었더니 로딩 스피너에서 멈췄음. 내 인터넷 문제인지, 아마 아닐 것 같지만, 모바일 지원 문제인지 몰라서 내용조차 읽을 수 없음
    • 충분히 발전한 패러디는 현실과 구별할 수 없음
    • 당시에도 논의됐음
      In Defence of the Single Page Application - https://news.ycombinator.com/item?id=31275178 - 2022년 5월, 댓글 32개
    • 내가 본 건 “loading” 애니메이션뿐이었음. 10초 뒤 포기함. 그래서 반론이 아니라 글의 논지를 확인해주는 사례임

  • 이 글은 좋고, 문제를 가져와서 적절한 기술과 적절한 깊이로 해결한 훌륭한 예시임. 고객의 도메인 지식을 온전히 갖고 있으면 정말 도움이 됨
    다만 “단순 HTML이 React보다 낫다”는 식의 프레이밍은 마음에 들지 않음. 같은 이야기를 React 개발자로서도 똑같이 할 수 있기 때문임
    서버 기반 세션 저장과 브라우저 기반 저장의 복잡성과 미묘함 등, 이 글에서 대충 넘어간 많은 이야기를 끝없이 할 수도 있지만 너무 길어질 것임
    HTML에서 단순한 것들은 React에서도 단순함
    말 그대로 같은 코드임. React에서 브라우저 기반 HTML 검증을 쓰지 못하게 막는 것은 없음. React에서 복잡해지는 코드, 예를 들어 과하게 복잡한 검증 로직은 Astro에서도 복잡해짐. Astro도 스키마 검증 등에 관한 자체 방식이 있고, Astro 사이트에 통합하려면 클라이언트 라우터 등을 통합해야 해서 거기서도 과하게 복잡해지기 매우 쉬움
    비교 대상도 아마 불완전한 지식을 가진 해외 외주팀이고, 프로젝트 구조상 가능한 한 빨리, 가능한 한 적은 시간에, 가능한 한 큰 복잡성으로 해법을 만들 유인이 있음
    마지막 지점은 교묘함. 외주사가 의도적으로 그렇게 한다는 뜻은 아니지만, 인센티브 구조상 과하게 복잡한 것이 실제로 그들에게 이익이 되므로 단순한 방식으로 갈 직접 유인이 없음
    어쨌든 당면한 문제를 직접 다루는 단순한 해법이 언제나 더 낫고, 어떤 스택을 고르든 마찬가지임
    Astro의 폼 검증에 반감이 있는 건 아니고, “네이티브 HTML 브라우저 검증” 이상의 이야기가 있다는 점을 강조하려던 것임

    • LLM도 그 마지막 지점을 받아들이는 것처럼 보임

  • 훌륭한 글이지만 이런 영감을 주는 글을 읽을 때마다 늘 갈등함. 말이 완전히 맞고, 잘 작동하고 빠르게 로드되며 최신 브라우저에 의존하지 않는 단순한 사이트라는 아이디어가 마음에 듦
    그러다 이게 내가 React나 그때그때 유행하는 멋진 기술을 이해할 만큼 똑똑하지 않아서 그런 건 아닌지 생각하게 됨
    넘을 수 없는 이해의 한계선이 있는 느낌임. Sublime 같은 단순한 편집기를 주고 웹페이지를 만들라고 하면, JavaScript가 있어도 행복한 공간임. VSCode나 Zed, 여기저기 붙은 Claude/Copilot/ChatGPT 플러그인, React 튜토리얼을 주면 머리가 흐물흐물해짐

    • 위안이 된다면, 화려한 프레임워크 같은 걸 쓰는 사람들도 대체로 그걸 이해할 만큼 똑똑하지는 않음
    • 복잡성과 그것이 왜 나쁜지에 관한 이 글을 좋아할 수도 있음: https://tengstrand.github.io/blog/2019-09-14-the-origin-of-c...
      단순하게 유지하는 건 나쁜 일이 아니고, 오히려 과하게 복잡하게 만들지 않을 만큼 똑똑해야 가능한 경우가 많음
    • 웹을 좋아함. React 광신도들이 웹에 한 짓은 싫어함
      Embrace Extend Extinguish는 실제이고, 거기에 동조하는 사람들은 더 빠르게 거짓말하고 쓰레기 코드를 뱉는 LLM으로 대체돼도 마땅함

  • 거의 15년 전이 떠오름. Grails에서 백엔드 세션 관리를 쓰고, 반응형 CSS와 “약간의” JS로 향상한 HTML 폼을 사용했음
    그때와 다른 점은 브라우저 기술이 지금처럼 발전하지 않았다는 것임. 여러 브라우저를 신경 써야 했고 IE7, 심지어 IE6까지 다뤄야 해서 어려웠으며 광범위한 QA가 필요했음. BrowserStack은 나중에야 나왔음
    JavaScript 라이브러리가 진화한 데는 이유가 있음. npm도 없었고 bower조차 없었음. 그러다 Backbone.js가 나왔고 좋아했음. AngularJS는 놀라웠고, 그다음 Angular 버전은 큰 호환성 깨짐이 있었고, 이후 React, Polymer 등이 나왔음
    요즘 네이티브 브라우저는 많은 걸 할 수 있고 기능 향상도 쉬움. 하지만 항상 그랬던 건 아님. 당시 React를 쓰기로 한 결정은 여러 이유로 타당했고, 여기서도 그랬을 수 있음

  • 10년도 더 전에 법무부를 위해 GOV.UK에서 이런 앱들을 만들었음. 긴 폼을 단계별로 검증하고 여러 페이지로 나눌 수 있게 자체 폼 마법사 라이브러리를 만들었음. Ruby on Rails가 기본으로 지원하지 않았기 때문임
    당시에는 사용자가 어떤 환경으로 접근하든 모두가 디지털 서비스를 이용할 수 있어야 한다는 원칙이 매우 중요했음

    • 애플리케이션 전체를 다시 시작하지 않고 문서를 업로드할 수 있는 기본 HTML 페이지를 늘 좋아했음. 일반 폼에서도 훌륭한 실천임
      각 세션 ID마다 다중 페이지 애플리케이션의 페이지와 그 세션 ID를 대조할 수 있으므로, 필요하면 사용자가 직접 입력할 수도 있음. 하지만 IP 주소, 업로드 날짜, 브라우저, 운영체제 같은 충분한 정보가 있으면 판별할 수 있어야 함. 다만 가장 정확한 세션은 브라우저 안에 있어야 해서, 단일 신청서의 쿠키가 PlayStation Portable을 쓰는 친척 같은 다른 신청자와 섞이지 않게 해야 함
    • gov.uk 웹사이트는 실제로 인상적임. 최소한이고 목적에 딱 맞음
      모바일 앱에는 어떤 기술을 쓰는지 궁금함. 완전한 모바일 앱은 아니고 웹뷰를 쓰는 게 아닐까 추측함

  • 이건 “React 앱을 HTML 폼으로 바꿨더니 성능이 좋아졌다”가 아님. “나쁜 웹페이지를 좋은 웹페이지로 바꿨더니 성능이 좋아졌다”임
    이걸 브라우저 경험을 구동하는 기술 탓으로 돌리는 건 어리석음. React로도 훌륭한 사용자 경험을 만들 수 있고, 순수 HTML로도 끔찍한 웹사이트를 만들 수 있음
    개선은 기술이 아니라 설계 변경에서 온 것임

    • HTML 우선 방식이라는 제약이 이전에 쓰던 나쁜 패턴을 피하게 도와줬다고 볼 수도 있음
      하지만 맞는 말임. 사용자 측 변화는 사용 기술이 아니라 설계를 고친 데서 왔음
      이건 나쁜 이력서 bullet point와 많이 닮았음. 누군가 “웹사이트를 HTML 우선으로 다시 작성해 방문자 수 100% 증가”라고 사업 성과가 코드 변경 덕분인 것처럼 주장하는 식임. 그 항목을 물어보면 결국 디자인 문제를 고치거나 기능을 추가하기 위해 사이트 전체를 재설계했고, 방문자 증가는 그게 이끌었다고 인정하게 됨
    • 순수 JavaScript를 곁들인 평범한 HTML이 정확히 성공의 구덩이는 아니지만, React는 절망의 구덩이에 훨씬 가까움. 전자는 투박하지만 효과적인 경향이 있고, 후자는 가능성을 얻으려면 복잡성 회피 박사학위가 필요함
      Douglas Crockford의 JavaScript: The Good Parts는 우스울 만큼 짧은 책임. React: The Good Parts는 그보다 더 짧을 것임
    • 물론임. 다만 React로는 100배 더 어렵고, 실패하면 팬들은 기술이 아니라 당신을 탓할 것임
    • 표준적인 답은 어떤 기술은 한쪽을 다른 쪽보다 더 어렵게 만든다는 것임. 원리상 어느 정도 맞지만, 예를 들어 React가 정말로 평범한 HTML 페이지보다 좋은 결과를 만들기 더 어렵다는 논증이 필요함
      재미있게도 원문은 지난 10년쯤 거의 못 본 다중 페이지 마법사 스타일 폼을 설명함. 그런데 내가 그런 걸 볼 때마다 대개 끔찍한 엔터프라이즈 시스템이었음. 마지막으로 본 건 경비 처리를 위한 Oracle 제품 같은 것이었음
      그런 것들의 문제는 항상 작업 중간이 느리다는 데 있음. 버튼 하나마다 몇 초씩 기다려야 함. 한두 단계 뒤로 돌아가야 하면 두 배로 짜증남. 잘못 만든 단일 페이지 앱은 시작이 느린 경향이 있음. 로드하는 데 시간이 걸리지만, 일단 로드되고 나면 보통 성능은 괜찮음
답변달기
GN⁺   [-]
Lobste.rs 의견들

  • 사람을 위해 제대로 동작하는 걸 만드는 건 당연히 일이 더 듦. 하지만 그게 결국 전체 업무의 핵심이기도 함

    • 이상하게 느껴짐. 계속 운영하는 데 드는 노동, 예를 들어 JavaScript 생태계의 버전 churn을 따라가는 비용까지 고려하면, 단순 HTML보다 React 앱이 거의 확실히 더 많은 일임
      후임들이 정말 말하고 싶었던 건 웹 플랫폼의 기본을 잘 모른다는 뜻에 가까워 보임
    • 자본주의 사회에서 일의 목적은 보통 돈을 버는 것임. 돈을 버는 것과 구형·드문 클라이언트 환경에서도 동작하는 소프트웨어를 만드는 일은 자주 정반대 방향으로 감
      이게 바람직하다는 뜻은 아니고, 지금 현실이 그렇다는 얘기임

  • “폼 제출과 리다이렉트”를 동료들에게 설명하는 데 시간이 걸렸다는 대목이 씁쓸함. 모두가 클라이언트 중심 웹 앱에 익숙해진 탓임
    지금 웹 개발은 정말 안타까운 상태이고, 다시 가르쳐야 할 일이 많아짐

  • 이런 접근을 정당화하는 데 그렇게 높은 수준의 호환성까지 필요하지 않다고 봄. 글에서도 말하듯, 세상에 그냥 폼일 뿐임
    그래서 나라면 어떤 경우든 그렇게 만들 것 같음

  • 글에서 설명한 것처럼 사이트를 만드는 일을 해보고 싶음. 거의 모든 브라우저에서 돌아가야 하고 접근성도 챙겨야 하는 아주 작은 다운로드라는 제약은 꽤 재미있는 도전처럼 들림
    이런 쪽을 전문으로 하는 회사가 있는지, 채용은 하는지 궁금함. 그냥 예전의 단순했던 방식이 그리운 나이 든 사람일지도 모르겠음

    • 직업은 아니지만 이미 그 안에 있음. 오늘 아침 이런 부분을 더 잘하기 위한 기능 요청을 올렸음
      기능이 충분히 잘 격리돼 있어서 재사용 가능한 라이브러리로 뽑아내기 아주 쉬운 수준이고, 아직 할 일이 많음. 이런 걸 웹 프레임워크 기본값으로 넣고 싶어짐. 정말 좋은 글임

  • 약간 아이러니하게도 Firefox에서 어떤 스타일 때문에 본문이 완전히 보이지도 선택되지도 않아서 읽기 모드로 전환해야 했음. 제목, 분홍색 인용 표시, 코드 블록은 보였지만 나머지는 보이지 않았음
    수정: 아래를 보니 아마 내 환경 문제인 듯함. 맥락을 위해 남겨둠
    글 자체는 잘 읽었음. 개발자든 최종 사용자든 우리 모두 React의 “민첩성” 비용을 치르고 있음. 회사에서 다른 스택을 쓸 수 있으면 좋겠다고 여러 번 생각했음
    또한 저자의 공감 능력과 그걸 “모두가 이기는” 구조로 설계한 점이 인상적임. 신경 쓰는 태도는 결국 보상을 줌

    • 나도 같음. Debian Trixie에서 Firefox 152.0b9 사용 중임
    • 이상하게도 내 Firefox에서는 사이트가 잘 동작함

  • 크게 공감됨. 예전에 JavaScript가 극도로 많은 블로그를 만들었는데, JS 기반 기능들 때문에 거의 반란이 일어날 정도였음
    아직 HTML 우선 방식으로 옮길 시간이 없었지만, 겉으로는 대체로 HTML 우선 웹페이지처럼 보이게 해두었음
    내 분석 데이터에서도 비슷한 결과를 봤음. 이탈률은 80%에서 약 50%로 내려갔고, 이후 글들의 신규 방문자는 거의 두 배가 됨
    처음에 JS로 만든 엉망인 구현 때문에 얼마나 많은 사람이 내 도메인을 평생 피하게 됐을지 생각하면 아찔함. 웹페이지나 블로그라면 이게 가장 중요한 조언 중 하나임

  • 이런 방식은 자동 폼 채우기에도 도움이 됨. 예전에 폼 전체가 동적이고 각 부분을 식별할 속성이 없어서 자동 입력을 만들 수 없었음
    기능보다 예쁘게 보이는 데 과하게 설계된 셈이라 아쉬웠고, 그래서 사용자 우선 설계에 관한 이 글이 즐겁게 읽혔음

  • 여기에 SSE 스트리밍과 morph 라이브러리를 더하면 동적·실시간·멀티플레이어 기능도 꽤 멋지게 만들 수 있음

답변달기