Re: 웹사이트 랜더링, 클라이언트에서 하나 서버에서 하나?
예전에는 당연히 서버측에서 했으니 별 논쟁이 없었는데 2000년대 초중반 쯤부터 클라이언트에서 자바스크립트로 랜더링을 하는 옵션이 점점 그럴듯 해지는 바람에 논쟁이 있는 모양이다.
…
글 자체만 봤을 때는 응 맞아 맞아
이상의 생각은 하지 못했는데, 오늘 다른 분들이 이 글의 내용을 보고 쓴 트윗들을 좀 보고 나서 할 말이 생겼다. 아래는 관련된 트윗 대화이다.
@alankang 나도 양쪽으로 다 많이 시도해봤는데 코드양을 재보면 대체로 서버 쪽이 유리한 듯. 리스트 동적로딩 같은 경우는 서버쪽이 훨씬 유리하고 채팅 류는 json 응답이 유리한 듯.
— Pak Youngrok (@pakyoungrok) December 21, 2012
@pakyoungrok @alankang 언제부터 성능 그렇게 따졌다고.. ㅋㅋ 스노 개발자들이 이런글 써도 되는건가요? ㅋㅋㅋ 난 생산성 때매 클라이언트 올인. 그런데 섞어 쓰면 머리 아프지 않나요? 물론 프바프가 정답이겟지만
— swizard (@swizard) December 21, 2012
@swizard 스프링노트는 자바스크립트로 아무리 떡칠을 했어도 견고한 fallback이 있었죠. 성능이 주요 이슈라기 보다는 폴백없는 클라이언트 랜더링은 올바르지 못하다는 느낌이 들어서요. @pakyoungrok
— Alan Kang (@alankang) December 21, 2012
@alankang @swizard 그 올바른 웹 사상은 아직 그대로군 ㅎㅎ 이봐 이제 웹 2.0의 시대는 끝나고 웹앱의 시대가 왔다구~
— Pak Youngrok (@pakyoungrok) December 21, 2012
오로지 back button 처리 문제 때문에 전 클라이언트 랜더링 깔끔히 포기했습니다. @pakyoungrok @free1002 @swizard @alankang
— 박규현 (@drypot) December 22, 2012
맨 마지막에 인용한 박규현(@drypot) 님의 트윗이 내가 하고 싶은 말의 일부를 담고 있다. 뒤로 버튼도 문제지만 현재 페이지의 URL을 복사해서 메신저나 Facebook 등에 붙일 수 있어야 하는데 그렇지 못하게 된다는 점도 큰 불편함이다.
물론 다들 알겠지만 pushState 같은 것들을 쓰면 브라우저 히스토리를 직접 조작해서 뒤로 버튼을 기능하게 만들 수 있다. 하지만 박규현 씨가 설마 pushState 같은 게 있다는 걸 몰라서 하는 소리는 아닐 것이다. 저 트윗이 말하고자 하는 것은 아마 브라우저가 이미 다 구현해둔 히스토리 기능을 pushState까지 써가며 내 손으로 다시 발명하기 귀찮고 짜증난다
정도가 아닐까?
이건 내가 예전에 CPS의 가장 큰 문제라고 지적했던 것과도 닿아있다. 왜 언어가 이미
웹 사이트를 pushState로 치덕치덕 발라서 만드는 것도 마찬가지 이유에서 힘든 것 같다. 제대로
구현해둔 반복문과 break
, 예외 등의 핵심적인 기능을 쓰지 못하고 자기 손으로 같은 기능을 더 무식하고 형편없고 불편한 방식으로 만들어서 써야 하냐.왜 웹 브라우저가 이미
다행히 JavaScript MVC 프레임워크들이 그런 처리를 많이 해주고는 있지만 우리가 오래 전부터 웹 브라우저에서 느꼈던 경험의 일부는 여전히 누리지 못한다.제대로
만들어둔 히스토리 기능을 못 쓰고 내가 같은 걸 다시, 부정확하게 만들어야 하냐.
Twitter나 SoundCloud (Next라는 이름으로 일부 사용자에게만 공개되어 있지만) 등의 웹사이트가 pushState를 이용해서 브라우저 주소창도 그럴듯하게 바꿔주고 뒤로 버튼도 동작하게 해놨지만 여전히 그런 웹 사이트에서는 뭔가 붕 뜬 느낌이 들어서 불편함을 느낀다. 마치 Mac에서 X 띄워서 그 안에서 GIMP 쓰는 느낌 같다고나 할까.
링크한 글에서 클라이언트 측 렌더링의 장점으로 두 가지를 들고 있는데,
- 서버측은 단일한 API Endpoint만 제공하도록 단순화시킬 수 있다
- 클라이언트/서버간 데이터 전송량이 상대적으로 적다
서버 측이 단순해지는 만큼 클라이언트 측이 복잡해지므로 첫번째는 (적어도 내게 있어서는) 크게 와닿지는 않는 장점이고 (게다가 링크한 글의 결론에 나온 ‘둘을 짬뽕한다’를 실행하게 되면 서버측 복잡도가 딱히 사라지지도 않게 되어서 장점이 사라진다), 그나마 두번째 장점이 모바일 웹이 활성화된 시대에 큰 의미가 있지 않나 생각한다.
하지만 SPDY가 출동하면 어떨까? (웃음)