Vaadin Framework를 사용해야 할까요?

https://stackoverflow.com/questions/1183801

19-09-2019
|

문제

방금 같이 놀려고 했는데 Vaadin 프레임워크 사용하기가 매우 쉬운 것 같습니다.게다가 내가 그의 프레임워크에서 좋아하는 점은 그것이 프레임워크 위에 구축된다는 것입니다. Google 웹 툴킷(GWT).

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

해결책

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

Vaadin은 GWT를 GWT에 선행하는 일련의 구성 요소를 갖는 방식으로 GWT를 사용합니다. 물론 원하는 경우 자체 구성 요소를 추가로 만들 수 있습니다. 그러나 구성 요소 세트는 매우 완전하며 종종 자신의 요구에 맞게 사용자 정의 할 수 있습니다. 즉, 응용 프로그램을 변경할 때마다 코드를 Java에서 JavaScript로 다시 컴파일 할 필요가 없습니다. 이미 사용 가능한 구성 요소를 함께 결합합니다.

프레임 워크는 서버 구동이므로 모든 로직은 서버 측에서 처리됩니다. 구성 요소에는 클라이언트 및 서버 파일의 두 부분이 있습니다. 클라이언트 측은 구성 요소의 더미 "보기"입니다. 일단 상호 작용하면 서버 에이 또는 눌린/서면/등을 서버에 보내는 메시지를 보냅니다. 그런 다음 서버는 수행해야 할 작업을 결정합니다. 이는 보안 증가를위한 것입니다. 이는 요청을 보내기위한 작은 API만이 JavaScript에서 사용할 수 있기 때문에 논리를 "해킹"할 수 없기 때문에 보안을위한 것입니다. 이것은 어떤 경우에는 응용 프로그램의 속도와 약간의 상충 관계 일지 모르지만, 나는 그것이 그렇게 나쁘다고 생각하지 않습니다. 최악의 속도 범프는 일반적으로 DB 쿼리 왕복 트립이며 UI 프레임 워크의 선택과 관련이 없습니다. 제안 된대로 데모의 부진은 서버에서 멀지 않거나 현재 높은 사용자 히트가 있기 때문일 수 있습니다. 자체 환경에서 시도하고 응용 프로그램의 최종 응용 프로그램을 닫아서 얼마나 잘 수행되는지 확인하십시오. 테스트하기 위해 배포 할 수있는 준비된 응용 프로그램이 있습니다.

나는 선택이 당신이하려는 일로 요약 된 것 같아요. Vaadin은 일반적인 Java 응용 프로그램을 구축하고 동적 웹 UI를 쉽게 수행 할 수 있으므로 웹 응용 프로그램에 적합합니다. 사용자가 페이지를 보는 것만 보는 전통적인 웹 사이트를 더 많이 수행하는 경우 (적극적으로 상호 작용하는 것 이상) Vaadin이 가장 좋은 방법이 아닙니다. Rails 또는 PHP 프레임 워크 등과 같은 다른 무료 프레임 워크와 함께 가십시오. 나는 당신이 지금 GWT를 사용하고 있다고 제안 할 때 더 많은 응용 프로그램을하고 있다고 생각하므로 Vaadin이 좋을 것입니다.

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

다른 팁

MVP, EventBus, CommandPattern 등과 같은 지난 Google I/O에서 배운 모든 모범 사례를 사용하여 그리 크지 않은 GWT 애플리케이션을 거의 1.5년 동안 개발한 후입니다.나는 진심으로 이렇게 말합니다.UiBinder가 출시된 후에도 우리 팀과 고객이 기술적으로나 시각적으로 원하는 방식으로 일을 해결하려고 노력한 후 Vaadin은 터널 끝의 빛처럼 나에게 왔습니다.

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

나는 차세대 페이스북 같은 것을 구축하는 것이 아니기 때문에 이것이 수용 가능하다고 말할 수 있다고 생각합니다.저는 여전히 중형 서버당 수천 명의 동시 사용자를 처리하면서도 짧은 대기 시간의 왕복을 유지할 수 있습니다.

Vaadin을 사용하면 거의 절반의 코드 줄로 멋진 앱을 구축할 수 있으며 여전히 애플리케이션이 더 완벽해 보입니다.:-)

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

부인 성명: 나는 이후에 언급 된 도서관과 관련이 없지만 내 길을 잘 알고 있습니다.

당신처럼, 나는 새로운 프로젝트에 어떤 스택/프레임 워크를 사용할 것인지 숙고 할 때이 게시물을 우연히 발견했습니다. 나는 놀이에 대한 확실한 경험을 가졌다! (좋아요, 스칼라에서는 있지만 여기에는 관련이 없습니다) 그러나 강력한 위젯과 서버 측 + 스윙과 같은 원활한 통합은 내 관심을 끌었습니다. 그것은 2010 년 말에 있었고, 답변이 Vaadin에게 시도해 보라고 설득했을 때, 나는 돌아와서 여기서 읽고 싶었던 답을 썼다. 문제는 오늘날에도 여전히 관련이 있습니다. 한편, Vaadin은 버전 6에서 7에서 7 번으로 갔다. 버전 1에서 2로 갔고 I (+ 소규모 팀)은 두 프레임 워크를 모두 갖춘 소수의 성공적인 프로젝트를 완료했습니다.

두 프레임 워크 모두이 비교가 흥미 롭다고 생각합니다.

JVM에서 실행하여 풍부한 생태계를 활용할 수 있습니다.
웹 애플리케이션에 대한 접근 방식과 개발자가 신경을 써야 할 것, 그리고
더 적은 정도로, 그들이 Java ee와 어떻게 관련되는지.

칭찬

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

현실 점검

우리는 Vaadin 앱을 개발하고 테스트하는 데 즐거운 시간을 보냈습니다. 첫 번째 버전을 출시하고 피드백을 수집하기 시작했을 때 상황이 더 명확하고 미묘하게되었습니다. 우리는 그것을 깨달았습니다 우리는 실제로 꽤 근본적인 방식으로 편향되었습니다., 즉 :

201X에서 대부분의 사용자는 웹을 사용한 오랜 역사를 가지고 있었으며 실제로는 실제로 데스크톱 앱을 거의 사용하지 않았습니다. 여기서 핵심 요점은 그 것입니다 브라우저는 하이퍼 텍스트 링크, 백, 전방 및 재 장전 버튼, 유비쿼터스 탭 및 때로는 Windows와 UX 상호 작용을 표준화했으며 대부분의 작업이 HTTP 요청을 유발하고 응답을 기다리는 기본 아이디어를 표준화했습니다.. 이것은 웹 사이트가 구축 된 웹 사이트를 준수하는 암시 적 계약입니다. 따라서 사용자가 익숙한 후면/전진 버튼을 사용할 수 없거나 탭이 예상되는 방식으로 작동하지 않는다고 불평했을 때 놀라지 않아야합니다. 그리고 우리는 동의했다. 우리는 보이지 않는 계약 구속력있는 사용자와 브라우저를 깨뜨 렸습니다. 사실, 우리 자신이 그랬습니다 암시 적으로 Vaadin 앱과 함께 브라우저를 사용하지 않으면 다른 웹 사이트에서 사용하는 방식이 있습니다. 물론, 당신은 앞서 언급 한 책으로 돌아가 URL 조각으로 웹 탐색 경험을 복제하는 것에 대해주의 깊게 읽을 수 있으며, 그것이 예상보다 실제로 더 관여한다는 것을 알 수 있습니다. Vaadin 앱은 상태가 많기 때문입니다. 또한, MVC 또는 MVP 패러다임은 플레이와 달리 개발자에게만 느슨하게 부과됩니다! 사실상 다른 옵션이없는 곳. 이것을 가볍게 받아들이지 않지만 뇌는 페이지 변경 후 1 초의 일부로 표시된 밝은 흰색 화면에 사용됩니다. 사용자가 클릭하고 새 페이지를 찍을 것으로 예상되면 브라우저는 모래 시계 (또는 그 변형)를 표시하여 인정합니다. Ajax를 사용하면 요청이 무대 뒤에서 배치됩니다. 오늘날에는 거의 작고 거의 외과적인 Ajax 파업이 표준이되었지만 아직 주요 UI 업데이트는 아닙니다.
상태의 앱은 도전과 문제를 가져옵니다. 하나에 대한로드 밸런싱 (걱정 된 경우)이 더 복잡합니다. Vaadin 세션이 많은 요청에 걸쳐 있기 때문에 거래의 개념은 전적으로 다르므로 REST 기반 접근과 대조적이지만 UX 측면에서는 비교적 짧았습니다. 실제로 사용자가 시작한 양식으로 돌아가는 것은 드문 일이 아닙니다. 몇 시간 전 그들의 과제를 끝내기 위해. 이론적으로는 Vaadin과의 협력도 할 수 있지만, 메모리가 오랫동안 오랫동안 세션을 유지해야하며, 메모리가 막히고 오랫동안 세션을 유지해야하며, 이는 WRT 동시 사용자를 확장 할 것이라고 신중하게 생각해야합니다.

Stateful Pages는 북마크는 물론 사용자가 공유하기가 더 어렵습니다 (URL 조각을 처리했다고 가정합니다).
마지막으로, 우리는 UI가 일반적으로 서버에있는 논리에 더 부진하다는 인상을 공유합니다. 물론 클라이언트 측 JavaScript가 장착 된 위젯을 만들어 왕복 수를 줄일 수 있지만 필연적으로 서버에서 UI 업데이트를해야합니다. JS는 이미 내 경험에서 해석하기에 상당히 무겁고 모바일 장치에 대한 경험을 덜 만듭니다. 또한 요청이 게시 된 후 UI 스레드가 활성화되어 있음을 명심하십시오 (예 : UI 업데이트를 당기는 것과 유사한 클라이언트 측의 사용자 조치). 다양한 청취자를 통해 귀하에게 액세스 할 수 있습니다. 그러나 백그라운드 스레드에서 UI를 업데이트하는 것이 더 복잡합니다 (예 : 업데이트 푸시). Vaadin 7은이 점에서 상황을 개선했습니다. 비교적 가벼운 HTML이 생성되었습니다. 단순히 HTTP 압축을 켜면 UI 반응성에 대한 상당한 개선이 눈에 띄었습니다.

결론

그래서 우리는 멈추고 Vaadin 접근 방식에서 우리가 무엇을 매력적으로 발견했는지 궁금해했습니다. 초기 개발은 비교적 원활한 승차감이 빠른 속도로 빠른 결과를 얻었지만 웹 UX 기대를 수용하기 위해 일부 개념을 재 작업하면 조류에 대한 수영에 대한 강력한 인상이 생겼습니다. 우리는 HTTP 요청/응답 메커니즘에서 추상화 된 (가려진?)에 대한 유혹 아이디어가 웹 앱과 데스크탑 앱 사이의 실제 임피던스 불일치를 공개 한 이중 엔드 칼로 입증되었다고 결론 지었다.

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

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

바라건대 언젠가 Vaadin은 자체 HTTP 서버를 갖기 위해 의존하는 전체 서블릿 아키텍처에서 벗어날 수 있기를 바랍니다. 프레임 워크에 더 깊은 MVC 디자인이 더 나을 것입니다. 그러나 예측 가능한 미래에는 EE에 의해서만 맹세하는 노련한 기업 자바 고릴라들 사이에서 유리한 틈새 시장을 발견 한 것처럼 보일 것입니다. 빛나십시오.

tl; dr: Vaadin은 WebApps가 무엇인지, 그리고 더 중요한 것은 그들이 어떻게 행동 해야하는지를 놓치고 있다고 생각합니다. 프로그램 프로그램이 시간과 사용자가 웹과 상호 작용하는 방법 (예 : 뒤로 버튼, 다시로드 버튼, 탭 및 북마크)에 대한 시간에 관한 것입니다. 웹 앱이 가까워 질수록 HTTP 요청 및 시맨틱 (동사)에 고정 될수록 사용자의 기대치와 일치 할 가능성이 높습니다. 그리고 그게 핵심입니다.

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

편집 2: 어떤 이유로 든 풀 스택 바드 딘과 같은 프레임 워크를 사용해야한다고 생각하면 유성에게 시도해보십시오. WebSocket을 통해 비동기 통신 (요청/응답보다 더 작은 대기 시간)을 통해 Node.js에서 실행되는 JavaScript 기반 (Frond and Back End) 프레임 워크이며 기본적으로 반응합니다. Vaadin에서 내가 싫어하는 많은 것들이 유성에서 해결되었습니다. 예를 들어, UI 업데이트에 대한 논리는 클라이언트에서 실행되므로 Vaadin보다 훨씬 더 반응이 좋습니다. JavaScript와 Java 커뮤니티의 사람들은 많이 교차하지 않지만 처음 들었을 때 Vaadin과의 평행이 즉시 나를 때렸습니다. 그것은 현재 Vaadin을 대중화 한 사람들과 비슷한 이유로 지역 사회에서 상당한 모멘텀을 누리고 있습니다. 데스크탑과 같은 웹 앱을 만드는 기능. Java가 미래의 웹 앱의 그림에 속하지 않거나 새로 고침을 치는 데 필요한 긴 배포주기에 지쳤다는 사실을 깨닫게된다면 시도해보십시오. 그러나 전체 앱을 하나의 라이브러리로 묶기 전에 두 번 생각하십시오.

Vaadin에 대한 일반적인 이야기는 위젯 세트와 관련하여 고객과 서버 간의 왕복 통신에 대한 걱정입니다.

그러나 내 생각에 이것은 Vaadin의 가장 중요한 (아마도 혁신적인) 측면을 간과합니다. 그것은 Ajax 응용 프로그램에 일반적으로 필요한 클라이언트-서버 커뮤니케이션 (Ajax의 "a"및 "x")에 필요한 클라이언트-서버 커뮤니케이션을 설계하고 구현하는 작업을 완전히 제거합니다. .

Vaadin을 사용하면 DTO (데이터 전송 개체), 프로토콜 기반 보안 문제, 최대 절전 모드 게으른로드 예외 등을 완전히 잊을 수 있습니다.

당신은 어떤 의미에서 정기적 인 오래된 Java Swing 데스크탑 응용 프로그램을 작성하고 있습니다. 스윙과 다른 UI 툴킷을 사용하고 있습니다.

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

반면에 과잉 가방에 빠지지 않고 응용 프로그램이 그리 복잡하지 않은 경우 클라이언트 리소스를 활용하는 데 도움이되고 서버에서로드가 적을 수 있습니다. 이러한 방식으로 서버와의 통신을 극적으로 최소화하고 훨씬 더 반응이 좋은 소프트웨어를 얻을 수 있습니다.

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

개찰구는 또 다른 좋은 프레임 워크이지만 웹 사이트에 더 적합합니다. Ajax와 유무에 관계없이 작동 할 수 있으며 검색 엔진에서 색인화 할 수 있습니다. 그리고 가장 매력적인 것은 깨끗한 HTML 코드를 다루는 것 - 사용자 정의 태그, 제어 구조 없음, 엄격한 우려 사항 분리 및 구성 요소에 대한 특정 개찰 Namigs만이 다루고 있습니다.

그것은 주로 당신의 필요에 따라 다릅니다.

매우 빠르고 간단한 응용 프로그램이 필요한 경우 - GWT를 사용하고 클라이언트 리소스를 활용하십시오.
응용 프로그램이 Vaadin보다 상당히 복잡한 경우 더 나은 선택이 될 것 같습니다.
응용 프로그램이 공개되어 있고 개찰구보다 SEO에 대한 색인을 인덱싱하는 기능이 필요한 경우.

문제는 진지한 발전을 위해 DTO를 제외하고는 아무것도 잊을 수 없습니다. 나는 이음새를 버리고 있으며 서버 측 UI 개념은 제 와이어에 무슨 일이 일어나고 있는지에 대한 더 미세한 제어를 원하기 때문에 .. Vaadin의 문제가 나에게 나에게 문제가 있습니다. 정확히 서버 측에 상태가 있습니다 ..

부품 상태를 관리하기 위해 세션을 사용하여 개찰구와 Vaadin 및 서버 측 처리에 대한 인수와 유사한 확장성에 대한 "우려"가있었습니다. 나는 지난 10 년 동안 Java 커뮤니티가 일반적으로 웹 프레임 워크의 잠재력을 측정하는 방법에 대해 틀렸다는 것을 배웠습니다. JSF에서 성배에 이르기까지 일반적으로 생산 애플리케이션을 실행하기 위해 겹치고 비효율적 인 기능을 갖춘 최소 수백 GB의 메모리와 최소 12 개의 오픈 소스 JAR 파일이 필요합니다. 주변을 둘러 보면 대부분의 웹 호스팅 회사가 웹 프레임 워크를 위해 취한 불규칙한 경로로 인해 실용적인 Java 옵션을 제공하지 않는다는 것을 알 수 있습니다. GWT 2.1은 컴파일 속도로 인해 여전히 사용하기 어려운 고통이며 처음부터 존재했던 MVP 및 데이터 테이블로 진지 해지고 있습니다. 나는 개찰구를 좋아하지만 Vaadin은 유망한 것처럼 보입니다 ... 그러나 Java 프레임 워크가 어떻게 진행되는지 알고, 나는 그들이 어느 시점에서 발로 촬영할 것이라고 확신하지만 서버 측면 처리로 인해 발생할 것이라고 확신합니다.

잘 생긴 UI를 구축하기 위해서는 이것이 갈 길이라고 말할 것입니다. 또한 그것은 매우 잘 문서화되어 있습니다.

나는 몇 주 동안 그것을 사용해 왔고 나는 진짜 지금까지. 코드는 견고하고, 문서는 좋은, 매우 논리적 인 구성이며, 최종 결과는 우수합니다.

나는 모든 데이터베이스 지막을 정리하기 위해 최대 절전 모드와 함께 그것을 좋아합니다.

플러스 - 배포하기 쉽습니다 (Tomcat을 사용하면 웹 인터페이스를 통해 단일 .war 파일을 업로드 할 수 있습니다. 더 쉽지 않습니다).

또한 고려할 가치가 있습니다 아파치 개찰구 구성 요소 지향 Java Web UI 프레임 워크를위한 강력한 대안. Vaadin은 훌륭하게 들리며이 토론을 방해하고 싶지는 않지만 선택은 좋은 일입니다. 소스가 홈페이지에서 링크 된 몇 가지 예가 있으며 개찰구 사이트에는 더 많은 예가 있으며 Manning의 훌륭한 책은 훌륭한 타사 문서를 형성합니다.

Maven과 함께 Vaadin 데모 빌드를 살펴보십시오.http://asolntsev.blogspot.com/2009/11/vaadin-demo.html

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

주로 대형 Java SW House (무엇보다도) 인 우리 회사에서는 새로운 웹 기반 제품을 만들 기회가 생겼습니다. 제품 세트였으며 3 개국의 많은 팀이이를 개발했습니다. 우리 팀에 관해서는 Java Development Experience를 활용하기 위해 Vaadin을 사용하여 선택을 선택했습니다. 나는 또한이 게시물을 읽었다. 그러나 많은 다른 팀이 Vadin을 선택했지만 Vaadin 사용에 반대했습니다. 다음은 제품을 시작하기 전에 그 당시에 보내는 메일의 이유입니다 (Vaadin이든 아니든). 이것은 내 개인적인 견해와 프레임 워크의 불신에서 일반적으로 다양한 정도로 나에게 있습니다. 그래서 독자 에게이 질문에 대해 또 다른 테이크를주고 싶었습니다.

우리는 학습 Spree Learning HTML, CSS, CSS Selector, 훌륭한 언어 JavaScript 및 JS Libs, JQuery 및 Yui를 통해 전체 GUI 및 성능 준수로 웹 제품을 제 시간에 만들었습니다. 저는 개인적으로 행복하고 팀은 사용자뿐만 아니라 사용자뿐만 아니라입니다.

Vaadin 방식으로 갔던 다른 팀도 제 시간에 제품을 만들었고 나는 똑같이 행복하다고 생각합니다.

누군가가 말했듯이, 모든 추상화는 새는 추상화이며 Vaadin 6에서 Vaadin 7으로 마이그레이션해야 할 때 약간의 재 작업을해야했으며 누군가가 생각하는 것보다 더 많은 시간이 걸렸습니다. 물론 그들은 갈아서 그것을 갈아 입을 수있었습니다. 여전히 이로 인해 약간의 지연이있었습니다. 또한 Vaadin 7을 지원하지 않은 InvientCharts Addon에 약간의 문제가 있었는데, 팀이 관련 Vaadin 차트 애드온을 구매하고 ($$) 변경하고 변경했습니다 ....

Vaadin에게

Vaadin을 사용하면 기본 JavaScript, HTML 및 CSS가 Java Swing 유형 애플리케이션에서 동적으로 생성되는 것으로 보입니다. 편견이 있고 어리석은 순수한 관점에서, "나는 당신을위한 코드를 생성 할 것"태그 라인은 좋은 디자인 냄새를 제공하지 않습니다. 추상화가 필요하지 않으면 또 다른 프레임 워크와 관련이있는 이유. 모든 코드 생성 프레임 워크와 마찬가지로 Vaadin이 염두에 두었던 추상화에 가장 잘 작동하지만 유연하지는 않습니다. 우리가 웹 기술을 수행한다면 기술이 자극 한 도구와 언어, 즉 HTML, CSS 및 JavaScript/JavaScript 라이브러리 (다른 수준의 추상화) - Vaadin 프레임 워크에 의존하는 것이 가장 좋습니다. Google Compliers가 손으로 코드화 된 것보다 가장 최적화 된 JavaScript를 생성하고 여러 팀 간의 코드를 더 잘 관리하는 데 도움이되는 전문 GWT 또는 Vaadin 개발자에게는 순진한 느낌이들 수 있습니다. 생산성, 더 쉬운 디버깅. 서버 측 - node.js). JavaScript를 올바르게 얻기 위해 프레임 워크에 의존 할 때는 그 언어로 결코 뛰어나지 않을 것입니다. 제품 기반 회사의 경우 대신 웹 언어를 직접 배우는 것이 중요하다고 생각합니다. 누군가가 언급했듯이 Java는 어제 Cobol처럼되었으며 JavaScript와 같은 다른 중요한 언어를 배우기 위해서는 역량이 쌓여 있어야합니다. 그러나 내가 가진 작은 시간 동안 JS에서 일한 후, 우리가 징계 (모듈 패턴)로 코딩하고 모든 논리 - JavaScript 유닛 - Jstestdriver 및 Jshint를 테스트하면 작업하기에 다소 강력한 언어입니다. , 생산성은 자바가 배운 후에는 Java보다 나아집니다. 또한 중요한 구성 요소 예제의 대부분 - OpenLayers는 JS로 작성되며이를 확장하거나 최적으로 작업 해야하는 경우 JavaScript를 알아야합니다. Vaadin 및 프레임 워크를 사용하면 장기적으로 JavaScript를 사용하는 것이 중요합니까?

나는 Vaadin도 사용하고 있습니다. 응용 프로그램이 크지는 않지만 경험에 대해 정말로 좋아하는 것은 API가 일관되고 일반적으로 잘 문서화되어 있으며 새로운 도구로 개발하고 있다는 점에서 나는 매우 이전에 사용한 도구보다 동일하거나 경우에 따라 클라이언트를 요구합니다.

거의 문제가 거의 없습니다. 현재 유일한 것은 고객이 IE 7 (묻지 말고)을 사용한다고 주장하는 것입니다. 애드온 구성 요소에서 (차트).

btw 나는 vaadin에서도 일하지 않습니다 :-)

나는 개찰구와 Vaadin을 모두 시도해 보았습니다. 만약 당신이 한 달에 두 시간 동안 둘 다 시도한다면, 한 달 안에 Vaadin이 개찰구가 아니라 기간이 아니라는 것을 알게 될 것입니다. -Dheeraj g

우리는 내가 일하는 곳에서 개찰구를 살펴 보았지만 9,000 파일 대신 30,000 개가 넘는 파일을 찾을 수있었습니다. 우리는 핵심 금융 서비스 응용 프로그램과 거의 1,000 개의 화면이 있으며 개찰구는 훌륭해 보이지만 Struts 1.3 코드를 개찰구로 변환하는 것은 매우 어렵습니다. 우리의 건축가는 POC 프로젝트를 수행했으며 단 3 개의 화면 만 수백 개의 클래스를 추가했습니다 (대부분은 재사용 할 것입니다). HTML이 Java 코드와 일치하고 그 반대의 어느 정도와 일치해야하므로 개찰구가있는 화면을 프로토 로피하기가 어렵습니다.

Vaadin은 유망한 것처럼 보이지만 팀에게는 어려운 판매가 될 것입니다.

추신 : 프레임 워크가 아무리 훌륭하더라도 업계에서 사용되지 않으면 아무도 배우지 않을 것입니다. 개찰구는 잠시 동안 주변에 있었지만이 회사를 사용하는 회사는 거의 없습니다. 내가 이야기하는 대부분의 개발자들은 이력서에서 쓸모없는 새로운 프레임 워크를 배우는 데 관심이 있습니다.

핵심은 Vaadin이 스윙과 같은 디자인을 사용하고 스윙을 사용하여 Java에서 시작하는 데 도움이된다는 것입니다.

나는 Vaadin을 사용하여 내가 일하는 회사 (Vaadin이 아님)에서 GiftAdvisor를 개발했습니다.

Vaadin을 사용하면 실제 구성 요소화 된 스윙 유사 웹 응용 프로그램을 구축 할 수 있습니다.

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

나는 Vaadin을 좋아하고, 그것은 나의 요구를 제기하고 웹 개발을 바람으로 만듭니다.

안부, Rob.

나는 이틀 전에 Vaadin으로 시작하여 Modularity, Data Binding, OSGI 서비스가 포함 된 OSGI에 소규모 CRUD 응용 프로그램을 구축 할 수있었습니다. 정말 좋은 점 중 하나는 내 완전한 UI가 118 줄의 코드이며 간단한 Java Bean 구조에 대한 완전한 CRUD 작업을 지원한다는 것입니다.

Vaadin이 Osgi에서 완벽하게 작동하는 것도 좋습니다. 그것은 이미 번들이며 Neil Bartlet에서 약간의 다리를 발견하여 Vaadin을 Osgi에서 매우 쉽게 사용하기 쉽게 만들었습니다.

보다 작업 목록 Vaadin 예제

서버 측에서 상태를 사용하지 않습니다. 그것은 그 목적을 달성합니다. 클라우드 컴퓨팅으로 오늘날 스토리지와 대역폭이 저렴 해지고 있습니다. 그러나 예, 나는 당신이 당신의 응용 프로그램을 쉬고 싶다면 특히 좋은 디자인 관점에서 당신의 요점을 볼 수 있습니다. 그러나 나는 Vaadin 등에 관한 단점보다 더 많은 장점이 있다고 생각합니다. 한 가지 중요한 점은 특정 브라우저에 대한 웹 애플에 대해 많은 것을 조정할 필요가 없습니다. 특히 JavaScript/CSS 복잡성을 위해, 특히 나와 같은 백엔드를 향해 지향하는 경우 IE를 IE라고 부릅니다. 모든 WebApps는 걱정할 필요없이 브라우저에서 호환됩니다. 개발자 시간은 스토리지 및 대역폭보다 더 비싸다는 것을 기억하십시오. 그게 내 의견입니다. =))

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow