자바스크립트 템플릿 엔진 비교

어떤 템플릿 엔진을 써야할까?

평소에는 레식 사마가 만들었던 micro-template 을 변형해 만든 JSTools의 pre-compile 기능을 주로 써왔었는데,.. 아무래도 일반적이지 않다보니 (물론 난 pre-compile이 좀더 익숙하지만) 대중적으로 어떤 템플릿 엔진들이 있는지 좀 알아봤다. 역시나 나와 같은 고민을 하는 사람이 이미 전세계에 수없이 많고, 그중에서 LinkedIn에서 공유한 자료가 꾀나 괜찮았다. 정리해보자. 템플릿 엔진은 크게 두 가지로 분류할수있다.

1. 자바스크립트 로직을 품는 레식 사마의 micro-template 계열

존레식이 처음 제안했던 마이크로 템플릿은 jQuery-Template 에 포함되면서 발전해봤고,  이제는 다른 엔진에 밀려 deprecated 된다는 얘기가 있어서 최종적으로는 underscore.js 로 귀결되는 듯싶다. 마이크로템플릿의 장점은 learning-curve가 거의 없다. Syntax가 간단하고 직관적이어서 딱 3가지만 알면된다.  다음은 underscroe.js의 문법이다.

  • < % 자바스크립트 코드 %> 
  • < %= 치환될 데이터 변수 %>
  • < %- escaped 데이터 변수 %>

기본적으로 자바스크립트 로직을 템플릿에서 쓸수 있기 때문에 루프라든가 조건문을 자유롭게 쓸수 있다.  단, 템플릿에 자바스크립트 로직이 들어가기 때문에 다소 보기가 어려울수도 있지만 확실히 배우기 쉽다.  

2. 자바스크립트 로직이 없는  logic-less의 mustache 계열

템플릿 문법에 자바스크립트 로직이 없기 때문에 반복문이나 조건문 같은 로직을 템플릿 자체 문법을 가지고 해결한다.  다음은 간단한 dust.js 템플릿 코드다.

{?tags}
  <ul>
    {#tags}
      <li>{.}</li>
    {/tags}
  </ul>
{:else}
  No Tags!
{/tags}

템플릿 엔진을 선택할때 고려해야할 요소

다음은 LinkedIn에서 고민했던 요소들이다.

  1. DRY: how DRY is the templating technology? is there support for code-reuse and partials?
  2. i18n: is there support for translations and multiple languages?
  3. Hot reload: are changes visible immediately or is there a compile/deploy cycle?
  4. Performance: how long does it take to render in the browser and server?
  5. Ramp-up time: how is the learning curve?
  6. Ramped-up productivity: once you’ve ramped-up, how fast can you build things?
  7. Server/client support: can the same template be rendered both client-side and server-side?
  8. Community: is there an active community using this project? Can you google issues?
  9. Library agnostic: are there dependencies on other JS libraries, such as jQuery or Mootools?
  10. Testable: how hard is it to write unit and integration tests?
  11. Debuggable: is it possible to step through the code while it’s running to track down errors?
  12. Editor support: is there an editor with auto-complete, syntax highlighting, error checking, etc?
  13. Maturity: is this a relatively stable project or still experimenting and churning?
  14. Documentation: how is the documentation?
  15. Code documentation: do the templates encourage/require documentation/comments?

위와 같은 요소들을 다 고려하기에 내 프로젝트가 너무나 초라하다? 라고 생각된다면 고민할 필요도 없다. 그냥 underscore.js 를 쓰면되겠다.  위와 같은 많은 고민을 해야하는 경우는 프로젝트의 사이즈가 큰 경우라고 보면 된다. 프로젝트 사이즈가 크지 않을 경우에는 배우기 쉽고 쓰기 쉬운 underscore.js 를 강력 추천한다. 하지만 내가 진행하는 프로젝트가 어느정도 규모가 있고 템플릿을 적극적으로 쓸 의지가 확고하다면, Logic-Less 계열의 템플릿 엔진도 고민해봄직하다. 기본적으로 템플릿 자체에 로직이 없기 때문에 훨씬 더 간결한 템플릿을 만들어 낼 수 있다. 즉, 더 적고 더 효율적인 코드를 생산해 낼수있다는 얘기다. 특히 모바일 플랫폼이라면 사이즈도 적이다!

템플릿 엔진 최적화

엔진마다 최적화 방법이 서로 다르고, 이미 각 엔진마다 Best Practice가 있으므로 문서를 보고 잘 따라하면 된다. 가령, 최적화의 끝판이라고 불리는 precompile 기능도 요즘엔 기본으로 문서에 추가되는 분위기다. 물론 템플릿 자체 최적화도 중요하지만 얼마나 효율적으로 템플릿을 나누고 구성하느냐는 전적으로 개발자 몫이다. 아무리 좋은 도구를 가지고 있다한들 제대로 활용을 못하면 무용지물인것 처럼 템플릿을 어떻게 구성해야하는지는 경험에 기인하는 경우가 많다. 따라서 지금이라도 당장 템플릿 사용 경험을 쌓는것이 좋다!  

References
[1] http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more [2] http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates [3] http://coenraets.org/tutorials/mustache/
[4] http://akdubya.github.io/dustjs/  

아파치 디렉토리 설정

아파치 서버 한대를 이용해 여러 프로젝트나 서로다른 사이트를 구성하고자 할때, 가령 나처럼 개인블로그와 공식블로그 기타 웹사이트등등.. 자질구레하게 여러 사이트를 운영하게 될때, 아파치 디렉토리 설정이 중요하다. 특히, 상위 폴더에 디렉토리 설정을 지정하면 자동으로 하위에도 영향을 받기 때문에 주의가 필요하다. 생각없이 지정했다가 살짝 멍때린 기억이 있다. 정리해보자!

최상위 루트 폴더의 접근 제어 설정의 예

<Directory />
   Options FollowSymLinks
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>

특정 하위 폴더를 설정하고 싶은 경우

<Directory /www/test>
   Options FollowSymLinks
   AllowOverride FileInfo
   Order allow,deny
   Allow from all
</Directory>

Options 항목에 지정 가능한 설정

  • None 어떤 옵션도 이용할 수 없다.
  • All 지정한 directory에서 모든 명령을 이용할 수 있다.
  • Indexes URL에 지정된 디렉토리에 (index.html 같은) 지정된 파일이 없을 경우 디렉토리의 파일 목록을 보여주는 옵션.
  • Includes 서버측의 추가적인 정보를 제공할 수 있게 한다.
  • IncludesNoExec 서버측의 추가적인 정보를 제공할 수 있게 하지만, 어떠한 실행 파일을 실행하는 것을 방지한다.
  • FollowSymLinks 디렉토리상의 심볼릭 링크를 사용가능하게 한다.
  • ExecCGI CGI 스크립트를 실행할 수 있게 한다.
  • MultiViews All 옵션이 설정되었을 때만 지정된 목록의 multiviews를 허용한다.

AllowOverride 항목 설정

.htaccess파일을 디렉토리마다 따로 만들어 접근을 제어 할수 있다. 참고로 해당 디렉토리에 .htaccess 파일이 있으면 서버 전체에 작용하는 access.conf 보다 우선권을 가진다.

  • None .htaccess파일을 읽을 수 없게 한다.
  • All 모든 지정에 대해 가능하게 한다.
  • Options 규정된 디렉토리 형식을 콘트롤하는 지정의 사용을 허락한다.
  • FileInfo 문서형식을 콘트롤하는 지정의 사용을 허용한다.
  • AuthConfig 사용자 인증 지정의 사용을 허용한다. 사용자 인증 변수를 사용한다.
  • Limit 호스트 접근을 콘트롤하는 지정을 허용한다.

Order 와 Allow 그리고 Deny 항목 설정

order 항목은 접근을 통제하는 순서를 나타낸다. allow와 deny 순으로 지정하면 allow 기능을 먼저 수행하고, deny기능을 나중에 수행하라는 의미다.

  • deny, allow – deny 지시자 부터 검사하고 allow 지시자를 검사
  • allow, deny – allow 지시자 부터 검사하고 deny 지시자를 검사
  • mutual-failure – allow목록에 없는 모든 host에게 접속을 거부

allow from 항목 다음에 쓸수 있는 항목은 아래와 같다.

  • 사용 가능한 주소는 도메인 네임
  • 호스트 이름 주소
  • 호스트 ip 주소
  • ip 주소의 앞부분 3바이트
  • 모든 주소일 경우 all을 사용한다.

deny from 항목은 allow from과 반대다.

 

자료 출처: http://toy0box.tistory.com

아~ 이게 뭔짓인가?

서버가 자꾸 죽길래,..
얼마전에 아파치 설정을 최적화 한다고 몇군데 손을 봤다.

<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>

이렇게 하면 좋다고, 아무생각없이 설정했다가,…
내 블로그의 모든 링크가 먹통이 되는 어처구니 없는 상할을 맞이했다.
최근 몇주간 방문 카운터가 1~2를 왔다갔다.
오버라이드 None을 설정하니까… .htaccess 설정이 제대로 안먹드라.. 

암튼 그래서 제대로된 설정을 추가했다.
휴우~.. 이래서 제대로 모르고 설정하면 낭패~ -_-;;
뭐든 알더라도 제대로 알아야겠다는 생각이 든다.