· 톺아보기

HTML 템플릿: client-side 렌더링 vs. server-side 렌더링

랜덤여신 ·

조회 9,897 · 공감 2 · 댓글 24

재작년에 트위터가 완전히 client-side 렌더링으로 바꿨죠. 저는 하나의 API로 모든 프론트엔드가 동작한다는 게 마음에 들긴 했지만, 속도 면에서는 부정적인 영향이 더 많을 거라고 생각해서 server-side 렌더링을 계속 써 왔습니다. 그런데 오늘 누가 지적한 게 뼈 아팠어요.

 

"동적으로 내용을 추가해야 할 때, jQuery나 순수 js로 HTML 객체를 만들어서 내용을 추가하는 건 anti-pattern이다. 클라이언트도 템플릿으로 체계적인 렌더링을 할 수 있어야 한다."

 

이 말을 듣고 마음이 확 흔들렸습니다. 그런데 이런 반박도 있어요.

 

"그렇다면 ajax 요청을 받을 때마다 서버에서 그 부분만 HTML 렌더링을 하고 그 결과를 보내주면 된다. 이렇게 하면 클라이언트에서 DOM을 조작할 필요가 없다."

 

이것도 맞는 얘기인 것 같습니다. 여러분은 어떠신가요?

댓글 24

  1. 도네민 ·
    freemarker vs handlebars 쯤 되려나요 ㄷㄷ
  2. 랜덤여신 ·
    아하... 자바쪽에서는 freemarker가 유명한가 보군요. 뭐 그렇지요.
  3. 머리에꽃을 ·
    갈수록 소위 리치 클라이언트화 되는게 더욱더 대세가 되리라 봅니다..
    사용자 경험 측면에서도 더 낫구요..
  4. 랜덤여신 ·
    사용자 경험쪽에서는 어떤 부분이 나을까요? 제 생각에는 렌더링 시간이 걸린다는 문제 때문에 경험이 비슷할 수는 있어도 더 나을 수는 없을 것 같은데요. 다른 측면들이 있나요?
  5. 머리에꽃을 ·
    서버에서 랜더링해서 화면에 뿌려준다면 정적인 부분이 크게 개선되지 않습니다.
    (html5의 가장 큰 변화 중 하나가 클라이언트의 자원을 활용한다는거죠.. 갈수록 그렇게 되리라 봅니다..)

    과거 액티브x나 플렉스까지는 아니지만 강력한 html5나 js를 사용해서 많은 기능과 컨트롤이 클라이언트 단에서 이루어지고
    서버랑은 단지 데이터 통신만 이루어지는 정도가 되지 않을까 합니다..
    한편으로는 일종의 과거 c/s처럼 되는거죠..
  6. 랜덤여신 ·
    아, 동적인 웹 사이트를 만들기 위해 DOM의 부분 부분을 업데이트할 일이 있다는 말씀이군요. 제가 그 정도로 예쁜(?) 사이트는 만들어 보지 않았지만 복잡해지면 충분히 그럴 만하군요.
  7. 머리에꽃을 ·
    서버는 브라우져에 일종의 클라이언트 프로그램을 내려준다는 느낌이죠.. 과거 액티브x나 플렉스 처럼요..

    그럼 대부분의 컨트롤은 클라이언트(브라우져) 단에서 다 이루어질 것입니다.. 서버와 if 하는 부분만 제외하구요..
  8. 머리에꽃을 ·
    지금도 그렇긴 하지만 웹개발도 클라이언트단(퍼블리셔들이 많이하죠) 그리고 서버단(흔히 뒷단) 으로 분리되어 개발될거라 봅니다..

    지금은 웹개발자혼자 디자이너 도움받아서 html, js, jsp, asp(소위 프리젠테이션단) 끄적이면서 개발하는 경우가 많았는데
    앞으로는 완전히 분리되어야 한다봅니다..
  9. 랜덤여신 ·
    둘 다 해야 하는 입장에서 한 부분에 집중할 수 있으면 더 편해질 것 같긴 하군요. ㅎㅎ
  10. Incago ·
    최근의 흐름이 증명하는거 아닐까요.
    저는 클라이언트 사이드 렌더링에 한표 던집니다.
  11. 랜덤여신 ·
    확실히 저 같은 서버 게이가 보기에도 무척 매력적으로 보입니다. 그런데 좀 hype 같은 느낌이 든달까요... 이게 일시적인 유행이 될 수도 있겠다는 생각이 듭니다.
  12. 미니멈 ·
    서버사이드에서 렌더링을 한다고 성능면에 장점이 있다고 말할 수 없을것 같아요.
    서버에 렌더링 부하가 집중되면 그 만큼 클라이언트가 몰렸을때 성능이 저하될 수 밖에 없지 않을까요.
    그리고 워낙에 클라이언트의 성능들이 좋아져서 느리지도 않더라구요.
    꼭 필요한 데이터만 주고 받는다는 점에서 네트워크 성능면에서도 장점이 많습니다.
  13. passby ·
    모바일의 경우에는 네트워크 속도가 일반적으로 pc보다 레이턴시가 훨씬 길고 속도가 느립니다.
    정말 복잡하거나 크지 않은 이상 ajax 통신을 통해 렌더링된 데이터를 가져오는 속도보다 모바일 클라이언트 사이드가 이점이 더 많습니다.
    생각보다 모바일에서 템플릿팅 하는 부하가 크지 않습니다.
  14. 랜덤여신 ·
    json과 html을 가져오는 데 latency는 똑같지 않나요? 아니면 혹시 html이 json보다 용량이 더 크니까 네트워크가 열악한 모바일에서 문제가 된다는 말씀이신가요?
  15. passby ·
    랜덤여신님//
    초기에 템플릿팅을 포함한 전제 웹 어플리케이션 로직이 로드되고 나면 그 이후로는 간단하게 json 으로 데이터를 주고받고 그 외의 대부분의 조작은 클라이언트에서 처리하는 것과

    무엇하나 바뀔때마다 서버 사이드로 리퀘스트를 날리고 기다려서 화면 전환을 하는것...

    점차 웹이 어플리케이션으로 인식될수록 인터랙션이 강조될텐데 그걸 구현하기위해 끊임없이 화면요소를 서버사이드에서 주고받는건 낭비인 것 같습니다.

    또 웹어플리케이션 라이브러리는 캐싱될수 있지만 각각의 화면요소들은 약간씩의 변형이 있기때문에 캐싱되기 어려운 문제도 있구요.

    딱 잘라서 무조건 클라이언트 사이드 템플릿팅이 옳다는 아니지만 흐름은 이미 넘어왔다고 보고 있습니다.
  16. Khire ·
    서버사이드 부분렌더링은 이미 꽤 전부터 쓰이지 않았나요?
    주로 asp.net을 썼었는데 ASP.NET Ajax 등의 기술에서도 모두 dom 특정 element 아래를 통째로 내려보내서 내용을 바꾸고 했던 것 같은데.. 성능적으로도 코딩하기에도 그다지 좋지는 않았던 것 같습니다. asp.net web forms 기반이라서 더욱 그랬겠지만서도..
  17. 혁군 ·
    IE8 시대면 성능 이야기가 있을 수 있긴 한데요.
    오늘날 JIT으로 돌아가는 브라우저들은 서버쪽 템플릿 엔진이 특출난게 아닌이상
    브라우저가 처리하는 속도나 서버가 처리하는 속도나 고만고만 합니다.
  19. 호떡 ·
    클라이언트사이드 렌더링이면 SEO는 어떻게될까요? 봇들은 자바스크립트 사용못하니 불리할꺼 같은데... ＊
  20. 랜덤여신 ·
    내용 전체를 client-side 렌더링하면 망하겠지만, 동적으로 렌더링하는 부분을 제외한 초기 페이지는 server-side 렌더링하고 동적인 부분만 client-side 렌더링하면 괜찮겠죠. 아니면 아예 검색 엔진용 페이지를 따로 만드는 것도 방법일 겁니다.
  21. coral ·
    랜덤여신님
    네 말씀대로 SEO나 웹접근성을 고려할 때 시멘틱한 부분은 서버사이드 상에서 이루어지는게 맞다고 봐요. 클라이언트 단에서 렌더링되는 디자인이나 동적 기능을 걷어냈을 때에도 문서의 내용과 의미가 전달되도록요.
    #CLiOS
  22. 설단이 ·
    먼가 글들이 멋있어요 ㅎㅎ
    #CLiOS
  23. MentalisT ·
    클라이언트 사이드의 성능 향상이 결국 서버 부하를 분산하고 예측했던것보디 성능저하 랜덩링 속도저하가 크게 발생하지 않아 사용자 경험 측면에서 부장적이지 않게 흘러가거 있은 추세가 아닐까요? 스펙은 계석 상승하고 있으니
    from CV
  24. 랜덤여신 ·
    뭐 트위터 같이 영리한 사람들도 그렇게 했으니까요. ㅎㅎ

    근데 약간 off-topic이긴 하지만, 고스펙만 믿고 가기엔 어딘가 불안하기도 해요. 뭔가 웹 초창기에 사람들이 고스펙만 믿고 플래시로 사이트 도배하다가 모바일 나오면서 된통 된서리를 맞았는데, 이게 모바일도 사양이 좋아지면서 다시 느슨해지고 있는 느낌이랄까요.

모두의공원 최근 글

모두의공원 목록 더 보기