Vaadin Framework를 사용해야합니까?

Vaadin Framework를 사용해야합니까?

---

방금 Vaadin Framework 로 게임을 시도했지만 사용하기가 매우 쉽습니다. 또한 그의 프레임 워크에서 내가 좋아하는 점은 Google Web Toolkit (GWT) 위에 구축되었다는 것입니다 .

이 프레임 워크를 계속 사용해야합니까, 아니면 GWT를 사용하는 것이 더 낫다고 생각하십니까?

---

야. 면책 조항으로 Vaadin을 개발하는 회사에서 일합니다.

Vaadin은 GWT에서 사전 컴파일 된 구성 요소 세트를 갖는 방식으로 GWT를 사용합니다. 물론 원한다면 추가로 직접 컴포넌트를 만들 수도 있습니다. 그러나 구성 요소 세트는 매우 완전하며 종종 자신의 필요에 맞게 사용자 정의 할 수 있습니다. 즉, 애플리케이션을 변경할 때마다 Java에서 JavaScript로 코드를 다시 컴파일 할 필요가 없습니다. 이미 사용 가능한 구성 요소를 결합하면됩니다.

프레임 워크는 서버 중심이므로 모든 논리는 서버 측에서 처리됩니다. 구성 요소에는 클라이언트와 서버 파일의 두 부분이 있습니다. 클라이언트 쪽은 구성 요소에 대한 더미 "보기"입니다. 당신이 그것과 상호 작용하면, 서버에 이것 또는 눌렸거나 쓴 것 등의 메시지를 서버에 보냅니다. 그런 다음 서버는 수행 할 작업을 결정합니다. 이는 자바 스크립트에서 요청을 보내기위한 작은 API 만 사용할 수 있으므로 로직을 "해킹"할 수 없기 때문에 보안이 강화 된 것입니다. 이것은 경우에 따라 응용 프로그램 속도와 약간의 균형을 이룰 수 있지만 그렇게 나쁘지는 않다고 생각합니다. 최악의 속도 충돌은 일반적으로 db 쿼리 왕복과 같은 것이며 UI 프레임 워크 선택과 관련이 없습니다. 제안 된 데모의 부진은 서버에서 멀리 떨어져 있거나 현재 많은 사용자가 방문했습니다. 자체 환경에서 사용해보고 응용 프로그램의 최종 응용 프로그램을 닫아 응용 프로그램의 성능을 확인하십시오. 테스트하기 위해 배포 할 수있는 몇 가지 준비된 응용 프로그램이 있습니다.

나는 선택이 당신이하려는 일로 귀결된다고 생각합니다. Vaadin은 일반적인 Java 응용 프로그램을 작성하고 동적 웹 UI를 쉽게 수행 할 수 있으므로 웹 응용 프로그램에 적합합니다. 사용자가 페이지를보기 만하는 기존의 웹 사이트를보다 적극적으로 사용하는 것보다 적극적으로 상호 작용하는 경우 Vaadin이 최선의 방법은 아닙니다. 레일 또는 PHP 프레임 워크와 같은 다른 무료 프레임 워크와 함께 사용하십시오. 지금 GWT를 사용하고 있다고 제안함에 따라 응용 프로그램을 더 많이 수행하고 있다고 생각하므로 Vaadin이 좋습니다.

여기 Vaadin 포럼 또는 irc 채널 #vaadin @freenode에서 더 많은 질문을하면 누군가 Vaadin을 사용하는 이유 또는 이유에 대해 더 많은 이유를 알려줄 수 있습니다.

---

거의 1.5 년이 지나서 MVP, EventBus, CommandPattern 등과 같은 마지막 Google I / O에서 배운 모든 모범 사례를 사용하여 그리 크지 않은 GWT 응용 프로그램을 개발 한 후 며칠 동안 노력하면서 UiBinder가 출시 된 후에도 Vaadin은 기술적으로나 시각적으로 원하는 방식으로 작업을 수행하기 위해 터널 끝의 빛처럼 내게왔다.

명령 패턴, 천 명의 발표자 및 뷰 및 천 개의 이벤트 처리기 등에 대해 거의 수천 개의 상용구 작업을 작성한 후 이러한 클래스의 거의 75 %를 처리 할 필요가없고 여전히 양호한 패턴 접근 방식 (설명 애드온)을 유지해야합니다. 약간의 네트워크 오버 헤드가 허용됩니다. 기본적으로 Vaadin을 사용하면 훌륭한 위젯, 페이징, 데이터 바인딩, 완벽한 레이아웃을 얻을 수 있습니다. 이 모든 것이 무엇입니까? 서버 측에서 더 많은 메모리 소비.

다음 페이스 북이나 무언가를 만들지 않기 때문에 이것이 받아 들일 수 있다고 생각합니다. 나는 여전히 중간 서버 당 수천 명의 동시 사용자를 처리하면서 지연 시간이 적은 왕복을 유지할 수 있습니다.

Vaadin을 사용하면 거의 절반의 코드 줄로 멋진 앱을 만들 수 있지만 여전히 응용 프로그램이 더 완벽 해 보입니다. :-)

!! 2011 년 2 월 23 일 업데이트 : 각 프레임 워크의 한계를 어떻게 인식해야하는지 강조 할 수 없습니다. Vaadin도 다르지 않습니다. Vaadin은 모든 형태의 HTML 또는 JavaScript를 추상화합니다. 또한 결과 HTML은 매우 무거 우므로 히스토리 상태 변경을 직접 처리해야합니다. 따라서 프로젝트를 빌드 할 때 이러한 오버 헤드에주의하십시오.

---

면책 조항 : 나는 이후에 언급 된 도서관과 관련이 없지만 그 주변의 길을 잘 알고 있습니다.

당신처럼, 나는 새로운 프로젝트에 사용할 스택 / 프레임 워크를 숙고 할 때이 포스트를 우연히 발견했습니다. Play에 대한 경험이 풍부했습니다! (스칼라에서는 괜찮지 만 여기서는 관련이 없지만) 강력한 위젯과 서버 측과의 완벽한 통합 + 개발과 같은 스윙은 내 관심을 끌었습니다. 그것은 2010 년 말에 이루어졌으며, 그 대답으로 Vaadin을 시험해 보겠다고 확신하면서 다시 돌아와서 여기에서 읽고 싶었던 답을 적어보기로 결정했습니다. 질문은 오늘날에도 여전히 관련되어 있습니다. 한편 Vaadin은 몇 가지 주목할만한 개선 사항 인 Play! 버전 1에서 2로 갔고 I (+ 소규모 팀)는 두 프레임 워크 모두에서 소수의 성공적인 프로젝트를 완료했습니다.

두 프레임 워크 때문에 비교가 흥미 롭다고 생각합니다

1. JVM에서 실행되며 풍부한 에코 시스템을 활용할 수 있습니다
2. 웹 응용 프로그램에 대한 접근 방식과 개발자가 관심을 기울여야 할 내용에 더 이상 맞설 수 없었습니다.
3. Java EE와의 관련성에 대해 설명합니다.

칭찬

한 문장으로, 기본 HTTP 요청 / 응답 메커니즘에서 완전히 추상화 된 상태에서 데스크탑 애플리케이션을 브라우저로 포팅한다는 아이디어를 발견하면 Vaadin이 아마도 웹 애플리케이션을 만드는 후보가 될 것입니다. 프로그래밍에 대한 Swing과 같은 접근 방식은 HTML 및 JavaScript의 저수준에서 가장 멀리 떨어져있는 사람들에게는 산들 바람이 될 수 있습니다. 앱에 대한 새로운 요청은 실제로 새 인스턴스를 시작하고 나머지 흐름은 귀하와 귀하의 논리에 달려 있습니다. 링크는 탐색을 위해 좋은 이전 버튼으로 돌아가며 HTML 또는 CSS를 조정할 필요없이 많은 내장 템플릿을 사용하여 레이아웃을 자유롭게 작성할 수 있습니다. API는 일반적으로 상당히 일관되고 잘 문서화되어 있습니다 ( Vadin 의 책).강제로 읽습니다. 예를 들어 많은 것들을 쉽게 이용할 수 있도록 철저히하십시오. 컴포넌트와 유효성 검사기에 빈 바인딩 ...). 위젯은 전체 브라우저 간 호환성이 우수하므로 광범위한 클라이언트에서 애플리케이션의 일관된 동작을 보장합니다.

현실 점검

우리는 Vaadin 앱을 개발하고 테스트하는 데 즐거운 시간을 보냈습니다. 첫 번째 버전을 출시하고 피드백을 수집하기 시작했을 때 상황이 더 명확 해지고 미묘 해졌습니다. 우리 는 실제로 몇 가지 근본적인 방법으로 편향되어 있음을 깨달았습니다 .

1. 201x에서 대부분의 사용자는 웹을 사용해온 오랜 역사를 가지고 있으며 실제로 더 이상 데스크톱 앱을 거의 사용하지 않는 사용자는 거의 없습니다. 여기서 핵심은 브라우저가 하이퍼 텍스트 링크, 뒤로, 앞으로 및 다시로드 버튼, 유비쿼터스 탭 및 때때로 창, 대부분의 작업이 HTTP 요청을 트리거하고 응답을 기다리는 기본 개념으로 UX 상호 작용을 표준화했다는 것 입니다. 이는 웹 사이트가 구축 한 웹 사이트를 준수하는 암묵적인 계약입니다. 따라서 사용자가 이전 / 뒤로 버튼을 사용할 수 없거나 탭이 예상대로 작동하지 않는다고 불평했을 때 놀라지 않아야합니다. 그리고 우리는 동의했다. 우리는 보이지 않는 계약 구속력이있는 사용자와 브라우저를 파기했습니다. 사실, 우리 자신은 내재적으로Vaadin 앱에서 브라우저를 다른 웹 사이트에서 사용한 방식으로 사용하지 않습니다. 물론, 앞서 언급 한 책으로 돌아가서 URL 조각으로 웹 탐색 환경을 복제하는 것에 대해주의 깊게 읽으면 Vaadin 앱이 상태 저장되어 있기 때문에 예상보다 실제로 관련되어 있음을 알 수 있습니다. 또한 MVC 또는 MVP 패러다임은 Play!와 달리 개발자에게 느슨하게 부과됩니다. 사실상 다른 옵션이없는 곳. 가볍게 생각하지 말고 뇌를 페이지 변경 후 1 초 동안 밝은 흰색 화면에 사용하십시오. 사용자가 클릭하여 새 페이지를 가져올 것으로 예상되면 브라우저는 모래 시계 (또는 그 변형)를 표시하여 확인합니다. AJAX를 사용하면 요청이 뒤에서 이루어집니다. 오늘날 작고 거의 외과적인 AJAX 공격이 표준이되었지만 아직 주요 UI 업데이트에는 적합하지 않습니다.

2. 스테이트 풀 (Stateful) 앱은 자신의 몫과 문제를 가져옵니다. 하나에 대한 부하 분산 (관심이있는 경우)은 더 복잡합니다. Vaadin 세션은 많은 요청에 걸쳐 있기 때문에 트랜잭션의 개념은 완전히 다르므로 REST 기반 접근 방식과 달리 길지만 UX 측면에서는 상대적으로 수명이 짧습니다. 실제로 사용자가 몇 시간 전에 시작한 양식으로 돌아가 작업을 완료하는 것은 드문 일이 아닙니다 . 이것은 이론적으로 Vaadin에서도 작동 할 수 있지만, 오랫동안 메모리가 차단 된 상태에서 세션을 오랫동안 유지해야하며 동시 사용자를 확장 할 수 있는지 신중하게 생각해야합니다.

   상태 저장 페이지는 북마크는 말할 것도없고 사용자가 공유하기가 더 어렵습니다 (URL 조각을 처리했다고 가정 함).

3. 마지막으로 UI가 일반적으로 서버에있는 로직으로 인해 더 느리다는 인상을 공유합니다. 물론 왕복 횟수를 줄이기 위해 클라이언트 측 JavaScript로로드 된 위젯을 항상 만들 수 있지만 서버에서 UI 업데이트를 수행해야 할 수밖에 없습니다. JS는 이미 내 경험에서 해석하기에 상당히 무겁고 모바일 장치에서의 경험이 적습니다. 또한 요청이 게시 된 후 (즉, UI 업데이트를 가져 오는 것과 유사한 클라이언트 측의 사용자 작업) UI 스레드가 활성화되며 다양한 리스너를 통해 액세스 할 수 있습니다. 그러나 백그라운드 스레드에서 UI를 업데이트하는 것은 더 복잡합니다 (예 : 업데이트 푸시). Vaadin 7은 이런 점에서 상황을 개선했습니다.비교적 가벼운 HTML이 생성되었습니다. HTTP 압축을 설정하기 만하면 UI 반응성이 크게 개선되었습니다.

결론

그래서 우리는 잠시 멈추고 Vaadin의 접근 방식에서 무엇이 그렇게 매력적이라고 ​​생각하는지 궁금했습니다. 초기 개발은 비교적 순조로운 승차감으로 빠른 결과를 얻었지만 웹 UX 기대치를 수용하기 위해 일부 개념을 재 작업하여 조수에 맞서 헤엄 치는 강한 인상을 받았습니다. 우리는 HTTP 요청 / 응답 메커니즘에서 추상화 (모호한?)라는 유혹적인 아이디어가 웹 앱과 데스크톱 앱 간의 실제 임피던스 불일치를 드러내는 양날의 검이라는 결론을 내 렸습니다.

웹이 또 다른 계층 인 척하는 대신, 우리는 웹이 작동하는 방식을 받아 들여야한다고 강하게 느꼈고 이것은 URL 중심 애플리케이션 (Rails / Django / Play에 의해 부과됨) 을 갖는 것으로 시작됩니다 . 누군가 데이터가 애플리케이션보다 오래 간다는 말을 들었을 것입니다. 요즘 데이터는 URL 리소스에 의해 참조되므로 URL이 데이터보다 오래 살아 있다고 안전하게 말할 수 있습니다. 결국 그들은 사람들이 북마크하는 것입니다. 따라서 기본적인 우려 분리도이 수준에서 적용되어야합니다. 이것이 아마도 웹이 처음에 그렇게 인기를 얻은 이유 일 것입니다. 그래서 우리는 행동에 응답하는 중앙 컨트롤러 주위에 더를 구조화하는 우리의 응용 프로그램 재 방문 라 플레이 à 별개의 자원 경로에 따라 만들어진합니다.

현재 우리는 Vaadin 앱을 유지하고 있지만 이러한 제약과 근본적인 패러다임 전환으로 인해 새로운 프로젝트를 시작하지 않을 것입니다. 그러나 웹 내부 작업에 대한 지식이 거의 필요하지 않은 기술적으로 일관되고 일관되고 잘 문서화 된 360 ° Java 웹 프레임 워크를 구축 한 팀에게 감사드립니다. 오히려 그들은 컨설팅 서비스를 판매하는 회사로 프레임 워크를 뒷받침하기도합니다. 나는 경험과 웹 애플리케이션에 대한 내 견해를 재평가하게 된 방법에 감사합니다. 나는 그것의 진화를 면밀히 모니터링 할 것이지만 우리는 확실히 더 많은 제어와 세분성이 필요합니다.

바라건대 Vaadin은 자신의 HTTP 서버에 의존하는 전체 서블릿 아키텍처에서 벗어날 수 있기를 바랍니다. 프레임 워크에 더 깊이 뿌리를 둔 MVC 디자인이 더 좋습니다. 그러나 그것은 EE에 의해서만 맹세하는 노련한 기업 자바 고릴라들 사이에서 수익성이 좋은 틈새 시장을 찾은 것으로 보이므로 가까운 미래에는 다소 가능성이 낮습니다. 빛나.

TL; DR : Vaadin은 웹앱이 무엇인지, 더 중요한 것은 웹앱이 어떻게 작동해야하는지에 대한 요점을 놓친다고 생각합니다. 프로그래머가 웹을 받아 들일 때와 사용자가 웹과 상호 작용하는 방식 (예 : 뒤로 버튼, 다시로드 버튼, 탭 및 북마크)에 관한 것입니다. 웹 앱이 HTTP 요청 및 의미 체계 (동사)에 가까울수록 사용자 기대치와 일치 할 가능성이 높아집니다. 그게 핵심입니다.

---

편집 : Python 경험이 있다면 URL 중심, REST 기반 웹 응용 프로그램 프로그래밍의 맛을 얻으려면 Flask를 사용해 보는 것이 좋습니다.

2 편집: 어떤 이유로 든 전체 스택 Vaadin과 같은 프레임 워크를 사용해야한다고 생각한다면 Meteor를 사용해보십시오. WebSocket을 통해 발생하는 비동기 통신 (따라서 요청 / 응답보다 지연 시간이 짧음)으로 Node.js에서 실행되는 JavaScript 기반 (프론 드 및 백엔드 모두) 프레임 워크이며 기본적으로 반응 적입니다. Vaadin에서 내가 싫어하는 많은 것들이 Meteor에서 해결되었습니다. 예를 들어 UI 업데이트를위한 로직은 클라이언트에서 실행되므로 Vaadin보다 훨씬 더 반응이 좋습니다. JavaScript와 Java 커뮤니티의 사람들은 많이 교차하지 않지만 처음 들었을 때 Vaadin과의 유사점이 저를 즉시 쳤습니다. 현재 Vaadin을 인기있게 만든 이유와 비슷한 이유로 커뮤니티에서 상당한 추진력을 누리고 있습니다. 데스크톱과 같은 웹 앱을 만드는 기능. Java가 향후 웹 앱의 그림에 그다지 속하지 않는다는 사실을 알게되거나 새로 고침을 누르기 만하면되는 긴 배포주기에 지친 경우에도 시도해보십시오. 그러나 전체 앱을 하나의 라이브러리에 묶기 전에 두 번 생각하십시오.

---

Vaadin에 대한 일반적인 이야기는 위젯 세트와 클라이언트와 서버 간의 왕복 통신에 대한 걱정입니다.

하지만 제 생각에는 이것은 Vaadin의 가장 중요한 (아마도 혁명적 인) 측면을 간과합니다. 일반적으로 AJAX 애플리케이션에 필요한 클라이언트-서버 통신 (AJAX의 "A"및 "X")을 설계하고 구현하는 작업을 완전히 제거합니다. .

Vaadin을 사용하면 DTO (데이터 전송 객체), 프로토콜 기반 보안 문제, Hibernate 지연 로딩 예외 등을 완전히 잊을 수 있습니다.

어떤 의미에서는 일반적인 Java Swing 데스크톱 응용 프로그램을 작성하고 있으며 Swing과 다른 UI 툴킷을 사용하고 있습니다.

---

내 경험에 비추어 볼 때 GWT는 복잡하고 풍부한 UI를 빌드 할 때 많은 상용구 코드가 필요하고 느립니다. 일반적으로 우리는 많은 지속 가능한 도메인 객체를 보유하는 매우 복잡한 애플리케이션 모델을 다룹니다. 이 모든 데이터를 클라이언트로 가져 오려면 별도의 클라이언트 모델을 도입하고 데이터 변환 메커니즘을 제공해야합니다. 우리는 이러한 목적으로 Dozer를 사용했으며 각 파일을 매핑하고 사용자 지정 변환기를 만들고이 모든 것을 테스트하는 데 많은 시간이 걸립니다.

반면에 오버 엔지니어링에 빠지지 않고 애플리케이션이 그다지 복잡하지 않은 경우 클라이언트 리소스를 활용하여 서버에 대한 부하를 줄일 수 있습니다. 이러한 방식으로 서버와의 통신을 극적으로 최소화하고 훨씬 더 응답 성이 뛰어난 소프트웨어를 얻을 수 있습니다.

Vadin은 매우 개발자처럼 보입니다. :) 그러나 저는 서버에 대한 "대규모 AJAX 공격"을 조금 두려워합니다. 저는 ZK에 대한 경험이 있으며 서버와의 통신이 필요하기 때문에 UI의 사소한 작업이 느리게 작동 할 때 종종 성능 문제에 직면했습니다.

Wicket은 또 다른 좋은 프레임 워크이지만 웹 사이트에 더 적합합니다. AJAX를 사용하거나 사용하지 않고 작동 할 수 있으며 검색 엔진에서 색인화 할 수 있습니다. 그리고 깔끔한 HTML 코드를 다루는 가장 매력적인 점은 사용자 정의 태그, 제어 구조, 우려 사항의 엄격한 분리 및 구성 요소에 대한 특정 wicketid namigs입니다.

주로 귀하의 필요에 따라 다릅니다.

1. 매우 빠르고 간단한 애플리케이션이 필요한 경우-GWT를 사용하고 클라이언트 리소스를 활용하세요.
2. 응용 프로그램이 Vaadin보다 상당히 복잡한 경우 더 나은 옵션으로 보입니다.
3. 애플리케이션이 공개되어 있고 Wicket을 선택한 것보다 SEO를 위해 색인을 생성 할 수있는 기능이 필요한 경우.

---

문제는 진지한 개발을 위해 dtos는 말할 것도없고 아무것도 잊을 수 없다는 것입니다. 나는 이음새와 서버 측 UI 개념을 버리고 있습니다. 단지 내가 전선에서 진행되는 일을 더 잘 제어하기를 원하기 때문입니다 .. vaadin의 문제는 나에게 서버 측에 상태를 갖는 것입니다.

---

Vaadin 및 서버 측 처리에 대한 주장과 유사한 구성 요소 상태 및 확장 성을 관리하기 위해 세션을 사용하는 Wicket에 대해 "우려"가있었습니다. 지난 10 년 동안 Java 커뮤니티는 웹 프레임 워크의 잠재력을 측정하는 방법에 대해 일반적으로 잘못되었다는 사실을 알게되었습니다. JSF에서 Grails에 이르기까지 프로덕션 애플리케이션을 실행하려면 일반적으로 수백 GB의 메모리와 겹치고 비효율적 인 기능을 가진 12 개 이상의 오픈 소스 jar 파일이 필요합니다. 주변을 둘러 보면 대부분의 웹 호스팅 회사가 자바 기술이 웹 프레임 워크에 대해 취한 불규칙한 경로로 인해 실용적인 자바 옵션을 제공하지 않는 것을 볼 수 있습니다. GWT 2.1은 컴파일 속도 때문에 여전히 사용하기 힘들고 처음부터 거기에 있었어야했던 MVP 및 데이터 테이블이 심각 해지고 있습니다.

---

보기 좋은 UI를 만들려면 이것이 갈 길이라고 말하고 싶습니다. 또한 매우 잘 문서화되어 있습니다.

---

나는 몇 주 동안 그것을 사용해 왔고 지금까지 정말 좋아합니다. 코드는 견고하고 문서는 훌륭하고 논리적 구조이며 최종 결과는 훌륭합니다.

나는 모든 데이터베이스 지루함을 분류하기 위해 Hibernate와 함께 그것을 좋아합니다.

게다가 배포가 쉬움 (Tomcat을 사용하면 웹 인터페이스를 통해 단일 .WAR 파일을 업로드 할 수 있습니다. 이보다 쉬울 수는 없습니다)

---

또한 구성 요소 지향 Java 웹 UI 프레임 워크의 강력한 대안으로 Apache Wicket 을 고려할 가치가 있습니다. Vaadin은 훌륭하게 들리며이 토론에서 벗어나고 싶지는 않지만 선택은 좋은 것입니다. 홈 페이지와 WicketStuff 사이트에 링크 된 소스가있는 몇 가지 예가 있으며 Manning의 훌륭한 책은 훌륭한 타사 문서를 구성합니다.

---

Maven을 사용한 Vaadin 데모 빌드를 살펴보십시오. http://asolntsev.blogspot.com/2009/11/vaadin-demo.html

---

나는 Wicket이 앞으로 나아갈 길이라고 생각했고, 효율적으로 작동하도록 노력하고 우울증 (농담)을 시작했습니다. 그런 다음 GWT로 전환했는데 멋져 보였지만 작성해야 할 보일러 플레이트 코드가 너무 많고 문서가 그다지 좋지 않습니다 ...-> 빛은 Vaadin에서 나왔습니다 : 간단하고 작동하며 지금까지 버그가 없습니다 ... !!!

---

주로 큰 Java SW 하우스 인 우리 회사에서 새로운 웹 기반 제품을 만들 수있는 기회가 생겼습니다. 그것은 일련의 제품이었고이를 개발하는 3 개국에 많은 팀이있었습니다. 우리 팀에 관해서는 자바 개발 경험을 활용하기 위해 Vaadin을 사용하기로 결정했고, 결정에 도움이되도록 Google을 검색했습니다. 나는 또한이 포스트를 읽었다; 그러나 다른 많은 팀이 Vadin을 선택했지만 Vaadin을 사용하지 않기로 결정했습니다. 다음은 제품을 시작하기 전에 내가 보낸 메일의 이유입니다 (Vaadin 또는 Not). 이것은 내 개인적인 관점에서 볼 수 있으며 일반적으로 프레임 워크에 대한 불신은 항상 다양한 정도에서 나에게 있습니다. 그래서 독자들에게이 질문에 대해 또 다른 의견을주고 싶었습니다.

우리는 HTML, CSS, CSS 선택기, 멋진 언어 JavaScript 및 JS libs, JQuery 및 YUI를 배우고 제때에 완전한 GUI 및 성능 준수를 갖춘 웹 제품을 만들었습니다. 개인적으로 저는 행복하고 팀은 물론 사용자입니다.

Vaadin 방식으로 갔던 다른 팀들도 제 시간에 그들의 제품을 만들었고 나는 똑같이 행복하다고 생각합니다. (그들 만 JavAScript의 기쁨을 모르고 있습니다 :)).

누군가가 말했듯이 모든 추상화는 유출 된 추상화이며 Vaadin 6에서 Vaadin 7로 마이그레이션해야했을 때 꽤 많은 재 작업을해야했고 생각했던 것보다 더 많은 시간이 걸렸습니다. 물론 그들은 그것을 갈고 다듬을 수 있었다. 그래도 이로 인해 약간의 지연이있었습니다. 또한 Vaadin 7을 지원하지 않는 InvientCharts 애드온에 문제가있어 팀이 관련 Vaadin Charts 애드온을 구매 ($$)하고이를 변경했습니다 ....

Vaadin 또는 Not

Vaadin을 사용하면 기본 JavaScript, HTML 및 CSS가 Java Swing 유형 응용 프로그램에서 동적으로 생성되는 것처럼 보입니다. 편견적이고 어리석은 순수 주의적 관점에서 볼 때 이러한 "나는 당신을 위해 코드를 생성 할 것입니다"라는 태그 라인은 좋은 디자인 냄새를주지 않습니다. 추상화가 필요한 경우가 아니라면 다른 프레임 워크와 연결해야합니다. 모든 코드 생성 프레임 워크와 마찬가지로 Vaadin이 염두에 둔 추상화에 가장 적합해야하지만 그다지 유연하지는 않습니다. 우리가 웹 기술을한다면 다른 수준의 추상화 인 Vaadin 프레임 워크에 의존하는 것보다 기술이 촉발 한 도구와 언어, 즉 HTML, CSS 및 JavaScript / JavaScript 라이브러리에서하는 것이 가장 좋다고 생각합니다. 전문가 GWT 또는 Vaadin 개발자에게는 Google 컴파일러가 손으로 코딩 한 것보다 가장 최적화 된 자바 스크립트를 생성하고 여러 팀간에 코드를 더 잘 관리하는 데 도움이된다고 생각하므로 (대부분 꽤 큰 웹 애플리케이션을 개발할 때) 더 나은 개발자라고 생각할 수 있습니다. 생산성, 손쉬운 디버깅 등. 그러나 Vaadin 용 Java로 구성 요소를 작성하고 JS로 자동 변환하는 것은 많은 개발자가 웹 개발 용 JavaScript와 같은 매우 중요한 프로그래밍 언어를 배우지 않을 것이라는 점에서 옳지 않다고 생각합니다. 서버 측 – Node.js). 프레임 워크에 의존하여 JavaScript를 올바르게 사용하면 해당 언어에서 결코 뛰어나지 않을 것입니다. 제품 기반 회사의 경우 웹 언어를 직접 배우는 것이 중요하다고 생각합니다. 누군가 언급했듯이 Java는 작년의 COBOL과 비슷해졌으며 JavaScript와 같은 다른 중요한 언어를 배우기 위해서는 역량을 구축하는 것이 필수적입니다. 그러나 내가 가진 짧은 시간 동안 JS에서 작업 한 결과, 우리가 어떤 규율 (모듈 패턴)으로 코딩하고 모든 로직 (JavaScript 단위-JSTestDriver)을 테스트하고 JSHint를 실행하면 작업하기에 다소 강력한 언어라는 것을 알았습니다. , 일단 배우면 생산성이 Java보다 향상됩니다. 또한 대부분의 중요한 구성 요소 예 – OpenLayers는 JS로 작성되었으며이를 확장하거나 최적으로 작업해야하는 경우 JavaScript 또는 D3.js와 같은 강력한 라이브러리를 알아야합니다. 간단히 말해서 많은 이점이 있습니다. Vaadin과 프레임 워크를 사용할 때 장기적으로 JavaScript를 사용하는 것이 중요할까요? 나는 우리가 어떤 규율 (모듈 패턴)로 코딩하고 모든 로직 (JavaScript 유닛 – JSTestDriver)을 테스트하고 JSHint를 실행하면 작업하기에 다소 강력한 언어이며 일단 배우면 Java보다 생산성이 향상된다는 것을 알게되었습니다. 또한 대부분의 중요한 구성 요소 예 – OpenLayers는 JS로 작성되었으며이를 확장하거나 최적으로 작업해야하는 경우 JavaScript 또는 D3.js와 같은 강력한 라이브러리를 알아야합니다. 간단히 말해서 많은 이점이 있습니다. Vaadin과 프레임 워크를 사용할 때 장기적으로 JavaScript를 사용하는 것이 중요할까요? 나는 우리가 어떤 규율 (모듈 패턴)로 코딩하고 모든 로직 (JavaScript 유닛 – JSTestDriver)을 테스트하고 JSHint를 실행하면 작업하기에 다소 강력한 언어이며 일단 배우면 Java보다 생산성이 향상된다는 것을 알게되었습니다. 또한 대부분의 중요한 구성 요소 예 – OpenLayers는 JS로 작성되었으며이를 확장하거나 최적으로 작업해야하는 경우 JavaScript 또는 D3.js와 같은 강력한 라이브러리를 알아야합니다. 간단히 말해서 많은 이점이 있습니다. Vaadin과 프레임 워크를 사용할 때 장기적으로 JavaScript를 사용하는 것이 중요할까요?

---

나는 Vaadin도 사용하고 있습니다. 응용 프로그램이 크지는 않지만 API가 일관되고 일반적으로 잘 문서화되어 있고 새로운 도구로 개발하고 있다는 점을 감안할 때 매우 까다로운 클라이언트를위한 작업을 동시에 처리 할 수 있다는 점이 정말 좋았습니다 . 또는 어떤 경우에는 이전에 사용한 도구보다 더 나은 기간이 있습니다.

문제가 거의 없습니다. 현재 유일한 것은 클라이언트가 IE 7을 사용한다고 주장하고 (묻지 마세요) 더 멋진 눈 사탕 중 일부가 애드온 구성 요소 (차트) 에서 완전히 100 % 작동하지 않는다는 것 입니다.

BTW 나는 Vaadin에서도 일하지 않습니다 :-)

---

나는 Wicket과 Vaadin을 둘 다 시도했고, 만약 당신이 정말로 얼마 동안 둘 다 시도한다면, 한 달 안에 Vaadin이 Wicket이 아니라가는 길이라는 것을 알게 될 것입니다. -Dheeraj G

---

제가 일하는 Wicket을 살펴 봤지만 9,000 개가 아닌 30,000 개가 넘는 파일을 발견했습니다. 우리는 핵심 금융 서비스 애플리케이션으로 거의 1,000 개의 화면을 가지고 있으며 Wicket이 훌륭해 보이지만 Struts 1.3 코드를 Wicket으로 변환하는 것은 매우 어렵습니다. 우리의 설계자는 POC 프로젝트를 수행했고 단 3 개의 화면 만 수백 개의 클래스를 추가했습니다 (많은 것들이 재사용을위한 것임). HTML이 자바 코드와 일치해야하고 그 반대의 경우도 마찬가지이기 때문에 Wicket으로 화면을 프로토 타입하는 것도 어렵습니다.

Vaadin은 유망 해 보이지만 팀에게 힘든 판매가 될 것입니다.

PS 프레임 워크가 아무리 훌륭하더라도 업계에서 사용되지 않으면 아무도 배울 수 없습니다. Wicket은 한동안 사용되었지만 사용하는 회사는 거의 없습니다. 내가 이야기하는 대부분의 개발자는 이력서에 쓸모없는 새로운 프레임 워크를 배우는 데 관심이 있습니다.

핵심은 Vaadin이 Swing과 유사한 디자인을 사용한다는 점이며 Swing을 사용하여 Java로 시작하는 데 도움이됩니다.

---

저는 Vaadin을 사용하여 제가 일하는 회사 (Vaadin이 아님)에서 기프트 어드바이저를 개발했습니다.

Vaadin을 사용하면 실제 구성 요소 화 된 Swinglike 웹 애플리케이션을 구축 할 수 있습니다.

클릭 할 때마다 클라이언트-서버 왕복이 걱정되는 경우 다음과 같이 말할 수 있습니다. 예, mouseover에서 버튼 모양을 변경하는 mouseover 버튼을 만들었습니다. 이를 위해 프레임 워크는 서버로 이동해야합니다. 그리고 충분히 빠르게 작동합니다. 내가 의미하는 바를 확인하려면 http://www.cadeau.nl/sophie 를 참조 하십시오 .

나는 Vaadin을 좋아하고, 그것은 내 요구를 충족시키고 웹 개발을 쉽게 만듭니다.

감사합니다, Rob.

---

저는 Vaadin으로 불과 이틀 전에 시작했고 OSGi에서 모듈성, 데이터 바인딩, 지속성을위한 OSGi 서비스를 갖춘 작은 CRUD 애플리케이션을 구축 할 수있었습니다. 정말 좋은 점 중 하나는 전체 UI가 118 줄의 코드에 불과하고 간단한 Java Bean 구조에 대한 완전한 CRUD 작업을 지원한다는 것입니다.

Vaadin이 OSGi에서 완벽하게 작동하는 것도 좋습니다. 이미 번들이며 OSGi에서 vaadin을 매우 쉽게 사용할 수 있도록하는 Neil Bartlet의 작은 다리를 발견했습니다.

이 작업 목록은 예제를보고 있습니다.

---

서버 측에서 상태를 사용해도 괜찮습니다. 그것은 그 목적을 달성합니다. 클라우드 컴퓨팅을 통해 오늘날 스토리지 및 대역폭이 저렴 해지고 있습니다. 그러나 예, 특히 애플리케이션을 RESTify하려는 경우 좋은 디자인 관점에서 귀하의 요점을 볼 수 있습니다. 그러나 나는 Vaadin 등에 관한 단점보다 더 많은 장점이 있다고 생각합니다. 한 가지 중요한 점은 특정 브라우저에 대해 웹 앱을 많이 조정할 필요가 없다는 것입니다. 특히 나 같은 백엔드를 지향하는 경우 특히 자바 스크립트 / CSS 복잡성을 위해 IE라고 부를 수 있습니다. 모든 웹앱은 걱정할 필요없이 브라우저에서 호환됩니다. 개발자 시간은 스토리지 및 대역폭보다 더 비싸다는 것을 기억하십시오. 제 의견입니다. =)

참고URL : https://stackoverflow.com/questions/1183801/should-i-use-vaadin-framework