JavaScript 템플릿 엔진을 벗어나고 싶은 이유, React 와 Angular 2 사이의 갈등 중간 정리

올 초부터 찔끔찔끔 고민해온 React vs Angular 2 사이의 고민에 끝이 보이질 않는다. 

 

고민해온 기간은 꽤 오래되었음에도 정작 실 구현 테스트는 둘 다 제대로 진행하지 않은 게으름을 우선 깊이 반성하며, 

그럼에도 입과 공상만 살아있을 수밖에 없었던 핑계를 정리해두고 실 구현을 위한 마음가짐을 다시 한번 잡아보고자 한다.

(그리고 그 사이 Angular 2 는 정식 릴리즈 됐다. 고민만 하다 강산이 변할 기세..)

 

1. Java Serverside Template 을 벗어나려는 이유

 

하나의 기능을 위해 분리된 두 형태의 코드를 짜야하는 것을 참을 수 없다.

 

Thymeleaf, Freemarker, Velocity, JSTL 등.. 어떤 템플릿 라이브러리를 사용해도 이 굴레에서 벗어날 수 없다. 

정말 허무할 정도로 간단한 로직(..)이라 할 지라도 결국 일을 두번해야 한다.

 

예를 들자면..

 

관리자 페이지에서 이벤트의 상태가 (예정 / 준비 / 종료 / 보류) 라는 값을 가질 수 있고,

이벤트 상태에 따라 보류 toggle 기능을 하는 버튼이 존재한다고 치자.

 

다행히 출력되어야 하는 버튼의 text 가 Toggle 로 고정되어 있으면 문제가 없는데,

이벤트 상태가 예정 / 준비 면 '보류' 가 출력되어야하고, 보류 일 경우 '보류 해제' 가 출력되는 것이 요구사항이라면..

 

템플릿에서 IF 태그로 분기쳐서 서버 렌더링 될 때의 출력 텍스트를 지정해야 할 것이고,

그 버튼을 누른 후에는 ajax 로 서버로 toggle 시킨 후 응답 값에 따라 javascript 에서 별개의 텍스트 처리 코드를 짜야한다.

 

어떻게 보면 별것도 아닌 이 분리된 코드 까짓거 그냥 짜면 되는 것 아닌가? 라는 의문이 들기도 하겠지만,

별 것도 없는 똑같은 기능의 저 코드가 분리되어 있는 것 자체로 추후 수정 시 또 두개의 코드를 수정해야 한다.

 

만약 요구사항이 수정된다면, 기능이 어떻게 더 복잡하게 바뀔지 모르는데, 

당장 간단한 요구사항 처리하면 그만이라며 코드가 이원화 된 상태를 놔두는건 정말 찝찝함의 극치가 아닐 수 없다.

 

하물며 애초에 복잡한 기능이라면.. 양쪽에 파악하기 힘든 (사실 템플릿 코드가 복잡해 봤자긴 하지만) 코드가 존재하는 셈.

 

javascript 코드가 view 템플릿 파일에 곁가지로 들어갈 수 밖에 없는 지저분한 케이스가 자주 (항상) 발생한다.

 

당연히 view 페이지의 대부분의 기능은 javascript 가 핵심을 전담한지 오래이니, 

중요 상태값은 javascript 가 인식해야하는데, 여기서 또 지저분하게

 

<script>var state = ${reference};</script>

 

같은 코드가 view template 파일에 더덕더덕 붙는다.

 

그나마 state 로 사용하려는 값이 String 이나 Numeric 이면 저렇게 간단히 써도 되지만, Value Object 라면..

템플릿 라이브러리는 controller 로부터 받아온 session 의 데이터를 java object 형태로 보관하기에 

이를 Json 으로 변환하기 위한 장치도 마련해야 한다. 라이브러리를 쓴다던가 커스텀 클래스를 생성하던가.

 

어찌되었건 분리된 javascript 파일만으로는 원하는 기능을 온전히 구현할 수 없다. 

-> 파일 여러개를 훑어야 한다. -> 난 내 눈알이 바쁘게 왔다갔다 하는게 싫다.

 

 

2. Angular 1

 

Backbone, Ember ... Angular 로 대표되는 JS View 프레임워크는 분명 위의 대안이 될 수 있다고 여겼지만,

몇가지 문제점들이 있고, 이같은 약점들은 섵불리 Serverside Template 을 대체하기 어려운 상황을 만들어 낸다.

 

사실 관리자 페이지같은 기업용 싸이트에선 위 문제점들이 자체로는 큰 이슈가 되지 않을 수도 있지만,

다른이들 (팀원) 에게 새로운 개발 방법에 적응해보자고 설득하고자 하는 입장에서 명분이 약해진다.

특히 퍼포먼스는 용도에 따라선 충분히 용납할 수준임에도 개발자 집단이라는 특수성 때문에 반박의 여지가 없다.

 

 

3. React vs Angular 2

 

동일한 JavaScript 코드로 Server side 에서 HTML 을 렌더링한다는 동형 자바스크립트 (Isormophic JavaScript) 의 개념은 Angular 1 으로 대표되는 1세대? JS View 프레임워크의 가장 뼈아픈 부분을 시원하게 긁어주는 구세주와도 같다. 드디어 Serverside template 라이브러리를 버리자고 호소할 때가 온 것이다.

 

React 와 Angular 2 는 모두 동형 자바스크립트의 개념을 지원하고, 그렇기에 두 프레임워크 사이에서 갈등이 펼쳐지는데..

 

문제는 둘 다 아직까지 좀 애매하다. 각기 장단점을 꼽아보면

 

React..

현재 가장 Hot 한 JS View Library. 

- 그만큼 적용 사례가 풍부하다.

동형 자바스크립트 지원. 

- 서버사이드 언어 Java 도 지원!

프레임워크가 아닌 라이브러리를 천명함. 

- 좀 제대로 쓰려면 Redux (Flux 구현체) 를 붙여야 함. 자체의 복잡성. (하나로 해결하고 싶다)

JSX ..개발자 only 라면 모를까, 

- 퍼블리셔 혹은 markup 담당자와의 협업으로 결과물을 내기가 불편함. HTML 뼈대는 분리되었으면 좋았잖아.

 

Angular 2..

프레임워크. 하나로 풍부한 기능이 제공됨. 

- 하나로 해결한다.

Markup 과 로직 코드의 분리. 

- 분리된 마크업이 custom attribute 가 포함될지라도 script 코드에 markup 이 포함되는 JSX 와는 비교 불가

다시 패권에 도전하는 전대 왕. 

- 이건 장점일 수도 단점일 수도 있는데.. 분명 대세가 될 여건은 갖췄지만 React 가 워낙 반향이 좋음

동형 자바스크립트 지원. 

- 서버사이드 언어 Node 만 현재 지원. Java 지원 예정. (Serverside 를 Node 로 바꾸자고? 팀에서 쫓겨나고싶나)

-> 이는 현재 Google 측 뿐 아니라 Spring 측에서도 지원을 위한 준비를 하고 있음. 

-> 허나 Spring 5 스펙이고 우선순위는 높지 않아 보임.

-> Spring 을 제외하고 보면 이미 J2V8 로 구현된 예제가 있긴하다. 다만 이슈가 약간 있고... 

-> 이걸 Spring 에 붙인 예제가 나왔으면.. (귀찮다고 쓰고 나는 스프링 개발자니까! 라고 읽는다. =_=)

TypeScript

- Angular 2 만 해도 새로운 방법인데 거기에 TypeScript 까지? 나도 버겁고 이걸로 하자고 말하는건 더 버겁다.

 

안정성에 중점을 둔다면 검증된 React 가 땡기긴 하지만, 

Angular 2 도 프레임워크 성능이나 기능상으로 아직까지 이슈는 없어보이고, 

그런 측면에서 Spring 에 붙기만 한다면 Angular 2 가 그래도 현재로썬 마음이 더 간다.

Spring 5 에서 ScriptTemplateView 에 Nashorn 이 아닌 J2V8 이 정식으로 붙고, 거기에 Angular 2 만 붙으면 딱인데..

 

하지만 Spring 5 는 Reactive 가 메인 컨셉이잖아? 안될꺼야 난.. (Spring 4 에서 붙여줘.. ㅠㅠ)

 

여러모로 현실적으로는 React 이긴 한데..

JSX 가 문제다. JSX.. markup 수정될 때 그걸 적용하는 과정이 또다른 구렁텅이가 될 것 같은 느낌

 

덧붙여 Java 의 동형 자바스크립트 지원을 사용한다는 전제가 깔릴 때 생기는 하나의 명분.

JDK8 갑시다. JDK8. 

 

사실 JDK 판올림은 족쇄가 될 소지가 더 크긴한데, 호환성의 불안함에 의한 족쇄는 정말 논의의 답이 없다.

보안성 향상이니 구현체 로직의 향상이니 하는.. 그렇다고는 하는데 사실 대부분의 개발자 레벨에서 느끼기 어려운 장점보단

개발자 수준에서 needs 가 뚜렷한 JavsScript Engine Nashorn 은 JDK8 을 주장할 확실한 명분이 아닐까 싶다.