#html rendering

맨 마지막에 인용한 박규현(@drypot) 님의 트윗이 내가 하고 싶은 말의 일부를 담고 있다. 뒤로 버튼도 문제지만 현재 페이지의 URL을 복사해서 메신저나 Facebook 등에 붙일 수 있어야 하는데 그렇지 못하게 된다는 점도 큰 불편함이다. 물론 다들 알겠지만 pushState 같은 것들을 쓰면 브라우저 히스토리를 직접 조작해서 뒤로 버튼을 기능하게 만들 수 있다. 하지만 박규현 씨가 설마 pushState 같은 게 있다는 걸 몰라서 하는 소리는 아닐 것이다. 저 트윗이 말하고자 하는 것은 아마 “브라우저가 이미 다 구현해둔 히스토리 기능을 pushState까지 써가며 내 손으로 다시 발명하기 귀찮고 짜증난다” 정도가 아닐까? 이건 내가 예전에 CPS의 가장 큰 문제라고 지적했던 것과도 닿아있다. “왜 언어가 이미 ‘제대로’ 구현해둔 반복문과 `break`, 예외 등의 핵심적인 기능을 쓰지 못하고 자기 손으로 같은 기능을 더 무식하고 형편없고 불편한 방식으로 만들어서 써야 하냐.” 웹 사이트를 pushState로 치덕치덕 발라서 만드는 것도 마찬가지 이유에서 힘든 것 같다. “왜 웹 브라우저가 이미 ‘제대로’ 만들어둔 히스토리 기능을 못 쓰고 내가 같은 걸 다시, 부정확하게 만들어야 하냐.” 다행히 JavaScript MVC 프레임워크들이 그런 처리를 많이 해주고는 있지만 우리가 오래 전부터 웹 브라우저에서 느꼈던 경험의 일부는 여전히 누리지 못한다. Twitter나 SoundCloud (Next라는 이름으로 일부 사용자에게만 공개되어 있지만) 등의 웹사이트가 pushState를 이용해서 브라우저 주소창도 그럴듯하게 바꿔주고 뒤로 버튼도 동작하게 해놨지만 여전히 그런 웹 사이트에서는 뭔가 붕 뜬 느낌이 들어서 불편함을 느낀다. 마치 Mac에서 X 띄워서 그 안에서 GIMP 쓰는 느낌 같다고나 할까. 링크한 글에서 클라이언트 측 렌더링의 장점으로 두 가지를 들고 있는데, > - 서버측은 단일한 API Endpoint만 제공하도록 단순화시킬 수 있다 > - 클라이언트/서버간 데이터 전송량이 상대적으로 적다 서버 측이 단순해지는 만큼 클라이언트 측이 복잡해지므로 첫번째는 (적어도 내게 있어서는) 크게 와닿지는 않는 장점이고 (게다가 링크한 글의 결론에 나온 ‘둘을 짬뽕한다’를 실행하게 되면 서버측 복잡도가 딱히 사라지지도 않게 되어서 장점이 사라진다), 그나마 두번째 장점이 모바일 웹이 활성화된 시대에 큰 의미가 있지 않나 생각한다. 하지만 SPDY가 출동하면 어떨까? (웃음)