Vaadin 첫인상: GWT를 대체한다는 것 이상의 메리트는 없어보여

(원문소스: http://www.gwtsushi.info/2010/08/initial-thoughts-on-vaadin.html)

2010년 8월 3일 화요일

Initial Thoughts on Vaadin : Not so much a GWT complement more of a replacement.

Vaadin 첫인상: GWT를 "대체"한다는 것 이상의 메리트는 없어보여
 

얼마간 Vaadin 프레임워크를 사용해보고 코맨트할 의도를 가지게 되었어. 이 툴킷 웹사이트의 플러그인과 데모들은 자신감이 배어져나왔거든. 내 마지막 포스트에 이 프레임워크를 사용해보기를 제안한 리플을 받은 후, 나는 이 충고를 받아들이고 튜토리얼을 따라해보았어.


주소록 튜토리얼은 프레임워크의 훌륭한 시작이었어. 이 데모 웹 어플리케이션은 아주 이해하기쉬웠고 아주  자유로운 표준의 코드들이었어. 내 완성된 어플리케이션을 여기서 http://thinktaxi.appspot.com 확인해보라구. 대부분 개발자들이 가지는, 그냥 어플리케이션 로직을 프로그래밍하면 프레임웍 추상화에 의해 아름답고 효율적인 표준의 코드들이 만들어지는, 완벽한 프레임워크의 꿈이 이루어져. 이건 성배찾기와 같은거라구...
물론, 내가 언젠가 바래왔던 프레임웍이 실제로 존재하고 있다는것만 빼면 말이지.

Vaadin은 "GWT 기반 위젯만들기, Vaadin 어플리케이션은 모든 Ajax를 지원하는 브라우저들을 플러그인없이 지원해."라고 광고해왔지. 이건 사실이야 그러나 튜토리얼을 마친후 나는 이것에 구체적 설명이 필요하다는걸 느꼈어.

Vaadin은 완전히 서버에서만 작동해. 컨테이너로서 GWT를 사용해서 말이지. GWT와 Vaadin의 통합은 아주 별도의 것으로 보여. 처음 문서를 속독할때 넌 Vaadin이 일반적인 GWT어플리케이션을 꾸미는데 사용되는 GWT 위젯의 일부라고 생각하게 될거야. 이 가정은 틀렸어. 하지만 나는 전적으로 "Vaadin은 거의 완벽하게 GWT와는 다르고, GWT의 일부로 간주되어서도 안된다"는 내 가정을 Vaadin전문가가 올바르게 고쳐주길 기대하고 있다고 말하고 싶어.

그래, Vaadin은 완전히 자바코드로 작성된 후, 서버에서 작동한다고. GWT와 비교했을때, 클라이언트코드에 어떠한 자바 라이브러리도 사용가능하다는 것은 하나의 "혜택"이지.
그러나 Vaadin에 포함된 무엇을하든 서버를 경유해야한다는건 좋지않아보여. 이것은 중대한 사항이고 질문을 야기하지. 만일 모든것이 서버를 왕복해야한다면 Vaadin은 효율적일까? 또하나 단점은 너는 GWT위에서 동작하는 하나의 완전하고 새로운 아키텍쳐 시스템을 익혀야한다는거야. 만일 너의 회사의 지식기반이 Vaadin에 한정된다면 향후 너의 솔루션의 제약사항이 될수있지.

아뭄튼, 내가 싫어하는게 아니라구. 물론 나는 GWT빠돌이지만 그렇기 때문에 Vaadin을 사랑하는 사람들을 사랑할 준비가 되어있지. 어떤 어플리케이션이든 Vaadin은 좋은 솔루션을 만들어내지. 아아 내 생각엔 딱 한 회사를 위한 인트라넷정도의 작은 유탈리티 타입의 어플리케이션으로 딱 좋은것같아.
비지니스적으론 일반적인 개발과 배포의 신속함이 어플리케이션이 얼마나 성능이 좋냐보다 중요할때 괜찮은것같아. 어플리케이션의 기능은 아마 100 유저 이상 동시접속하지않을때, 그래서 어플리케이션의 로딩 트래픽이 높지않을때도 좋을거야.
나는 튜토리얼을 통해 이 어플리케이션의 복잡성과 신속함이 매우 인상적이었어. 나는 RAD (rapid application development:빠른 어플리케이션 개발)에 많은 혜택을 볼수있었어. 

요약하자면 Vaadin은 작은 규모의 비니지스 개발에 좋아, 그러나 GWT프레임웍은 아니야. 그렇게 간주되어서도 안돼
 

8 리플:

Sami said...

내생각에 너가 맞아. Vaadin은 빠른 개발속도에 집중된 서버기반 컴포넌트 프레임워크야. GWT는Richful 인터페이스를 위한 클라이언트측 코드를 만들어주지. 이건 독립실행가능한 GWT위젯으로서 새로운 Vaadin 컴포넌트를 만들때 역시 좋은것같아. 두 프레임웍의 혜택을 다 보기위해 말이지.
 
수용성 분석(scalability analysis)은 여길봐줘: http://vaadin.com/blog/-/blogs/server-side-ria-scalability

August 3, 2010 10:47 AM

Luciano Vernaschi said...

나는 너의 생각을 공유해. 난 GWT라이브러리로서 Vaadin을 보진않아. 그러나 Vaadin이 코드를 만들어내는것은 매우 즐겁다는걸 동의한다구. 그럼에도 불구하고 순수한 GWT보다 많이 느리지만 말야..

난 Vaadin을 약간의 코드를 짜보기 위해 시도해봤어. 제품 어플리케이션을 만들어보지도 않았지.
그래도 성능이 충분히지않아서 수정이 필요한 경우를 생각해보면 GWT의 커스텀 컨포넌트를 만들기 두렵다고.
August 4, 2010 3:43 AM

Anonymous said...

Vaadin와 GWT의 관계는
1) Vaadin은 GWT를 랜더링을 구현할때 내부적으로 사용해
2) Vaadin은 GWT에 확장할수있어 - 새로운 재사용이 가능한 위젯을 구현할수있어

GWT와 Vaadin은 서로 다른것을 최적화하지: GWT는 클라이언트를 가능한 많이 움직이게 함으로서 서버의 로딩을 최소회하려고 하지. Vaadin은은 서버에 최대한 코드를 묶음으로서 개발시간을 최소화하려고 해. 대부분의 경우 서버기반 개발은 좋은 성능을 보장해줘, 그러나 어떤 상황(애니메이션, 그래픽관련..)에선 클라이언트 기반 프로그래밍이 필요해 - 이러한 상황들에서 새 Vaadin 위젯을 구현해야해 - 운좋게 이건 아주 쉽지.

Vaadin의 수용성(Scalability)의 서버기반 모델은 어플리케이션에 좌우되. 서버당 수천의 동시 접속자를 처리할수있는건 일반적인거라구. 너의 어플리케이션에 따라 이건 서버당 수백만의 일일접속자를 감당할수있어.

August 4, 2010 6:11 AM

Mark said...

내 생각엔, Vaadin은 두가지 측면으로 GWT를 사용해: 컴포넌트 개발과 마케팅 목적

Vaadin은 스스로 생명주기를 가져.  SmartGWT나 ExtGWT와 같은 서로 다른 벤더들에 의해 만들어진 GWT를 사용하기 힘들다는 의미야.

최악의 것은 GWT가 실로 의도하고 또 좋은것인 어떠한 클라이언트 코드도 쓸 수 있는 방법이 없다는거지.
이들 데모를 보면 어플리케이션 개발자가 할수있는 것은 오직 자바스크립트 코드를 클라이언트에 보내는 것 밖에 없어. 자바스크립트 코드는 어떠한 컴포넌트도 접근할 방법이 없지 (GWT name mangling (컴퍼일러가 선언된 이름을  바꾸는것)과 생명주기가 다르기 때문에 )

모든 어플리케이션 코드는 서버에서 동작해 만일 너가 컴포넌트를 만들지않는다면, GWT와 연결할 방법이 전혀 없는거지

August 6, 2010 7:45 PM

Anonymous said...

"비지니스적으론 일반적인 개발과 배포의 신속함이 어플리케이션이 얼마나 성능이 좋냐보다 중요할때 괜찮은것같아. 어플리케이션의 기능은 아마 100 유저 이상 동시접속하지않을때, 그래서 어플리케이션의 로딩 트래픽이 높지않을때도 좋을거야." 라고 말했지

나는 동의할수없어. 개발과 배포의 신속함은 중요해 그러나 너의 어플리케이션의 성능의 중요성은 그것보다 더 중요하지. 고객은 SLA (서비스 수준 협약서)  요구사항을 기본으로 깔고 어플리케이션을 구매한다고

August 7, 2010 12:09 PM

Gene said...

개발의 신속함 vs 어플리케이션의 성능:

 IT 어플리케이션의 어떤한 타입를 설계할때  성능은 항상 중요한 이슈지. 우선순위 리스트에서의 이 위치는 그 어플리케이션의 타입에 다라 달라.  회사내의 IT 소프트웨어를 맞춤생산하는 비지니스의 다양함을 겪어본후, 그들의 중요한 고려사항은 언제나 그 소프트웨어를 얼마나 빨리 개발할수있냐였어. 어플리케이션의 성능에의 필요는 언제나 두번째였지, 그것이 문제가 되지않으면, Vaadin은 이 분야의 이상적인 솔루션이야. 개발속도는 인상적이지. Gmail, Hotmail이나 Salesforce와 같은 어플리케이션을 가지는 더 큰 소프트웨어 개발세계에서 성능은 가장 최우선순위에 있지. 이 어플리케이션들은 수천명이 사용하니까.
그리고 성능은 모든 디자인의 의사결정에 핵심중의 핵심이 되어야 하지

내가 생각할땐 우리는 비슷한걸 얘기하고있어 그리고 나는 어떤 소프트웨어 어플리케이션에서 요구되는  성능의 최소레벨이 있다는걸 동의해. 프레임웍에 대한 우리 선택은 어떻게 어플리케이션이 사용되는가에 기초하잖아. 나는 그것이 필요할때만 서버에 접속하는게 아닌 서버중심의 프레임웍을 선택하는걸 경계하게 되.

너의 코맨트에 감사해 그리고 이 기사는 잼있었어
Gene

그러므로 내 결론은 Vaadin은 맞춤생산하는 소프트웨어에 유용하다는거야

August 7, 2010 12:59 PM

Sleeveen said...

나는 Vaadin에 대한 너의 생각에 동의해. 나는 최근에 큰 GWT 프로젝의 한 프레임웍을 선택해야해서 주시하고 있었어

많은 사용자가 없는 작은 어플리케이션이라면 난 빠른 개발이 이득이라고 봐. 그러나 난 네트워크 관리 어클리케이션을 만들려고 하니까 결과적으로 수백의 동시접속자가 있고 실시간 이벤트 알림같은것도 필요할거야 (comet이나 websocket등등을 읽어봐)

Vaadin은 매우 훌륭해. 그러나 너는 그 일에 적당한지 확신을 가져야할거야 
힘내셔잉!

August 18, 2010 8:58 AM