GWT와 Wicket은 모두 stateful 기반의 자바 객체 지향 객체입니다. GWT는 자바 스크립트 최적화, CSS 최적화와 같은 기능을 기반으로 완전히 클라이언트 기반이며 Apache Wicket을 처음 사용합니다.GWT와 Apache Wicket
더 많이 Wicket에 대해 읽으면 GWT와 비슷한 느낌이 듭니다.
그래서 내가 궁금한 점은 - GWT와 Wicket의 차이점은 무엇입니까? 아니면 사과와 오렌지를 비교합니까?
오렌지에는 사과가 많이 있습니다.
이 wiki entry은 몇 가지 유사점과 차이점 및 함께 사용하기위한 전략의 시작을 요약합니다. 이는 흥미로운 아이디어라고 생각합니다.
Wicket은 주로 Ajax를 지원하는 내장 서버 측 기술로, Ajax로 배선하기위한 후크입니다. Java를 GWT와 같은 JavaScript로 변환하지 않습니다. GWT가 클라이언트에서 상태를 유지하는 상태 서버 측을 유지 관리합니다.
두 가지 모두 구성 요소 기반이며 저에게 Swing 개발에 대한 느낌이 있습니다 (Wicket은 적어도 한 명의 다른 응답자에게 스윙하려는 느낌이 들지 않음).
Wicket은 서버 기반 프레임 워크입니다. GwT보다 JSf와 훨씬 비슷합니다. GWT는 개념적으로 스윙과 유사합니다. 전 스윙 개발자입니다. 스윙에서 스윙으로 마이그레이션하는 것은 매우 쉽습니다. 하지만 Wicket이나 JSF에서는 같은 말을 할 수 없습니다.
지금은 몇 년 동안 대규모 프로젝트에 GWT (1.x 및 2.x에서)와 개찰구 (1.4, 1.5) 모두를 사용하고 있고, 두 프레임 워크는 자신의 장점과 단점이있다. 두 제품 모두 멋지고 멋지며 용으로 디자인 된 제품에 사용되는 경우 입니다. 하지만 을 함께 사용하면 가장 좋은 결과를 얻을 수 있습니다..
개찰구 페이지 디자인 (HTML)와 자바 코드 사이의 적절한 분리와, 정말 좋은 CRUD 웹 사이트에 대한 강력하다. 강력한 클라이언트 기능을 필요로하지 않는 한, 약간의 코드가 주어지는 상금으로 매우 훌륭하게 작동합니다. 그러나 은 강력한 형식 인으로 지불해야합니다. "마법"은 없습니다. 리팩터링 및 구성 요소은 매력처럼 작동합니다. 대형 프로젝트의 경우 쉽게 디커플링 일 수 있으며 큰 팀과 함께 작동하도록 으로 잘 설계되어 있습니다. 사람들은 핵심 구성 요소 세트를 제공하고 프레젠테이션 레이어 등에 다른 요소를 집중할 수 있습니다 ... 유일한 단점은 복잡한 것입니다. 클라이언트 측에서는 여전히 마스터 자바 스크립트이 필요하며 쉽게 이되어 Wicket과 Javascript을 다소 복잡하게 만들 수 있습니다. 당신이 정말로 클라이언트 (Gmail은 같은 응용 프로그램)에 풍부한 행동 능력을 필요로 할 때
GWT은 좋은 것입니다. GWT의 주된 문제점은 종이 ("java in everything"패러다임)에서보기에는 너무 좋지 않지만 약속을 성취하지 못한다는 것입니다.은 확장이 잘되지 않습니다. : GWT는 대규모 응용 프로그램이 아닌 작은 기능 세트를 제공하는 작은 모듈에 적합합니다. 코드/컴파일/디버그주기가 다소 길며 모듈 크기가 너무 커지면 부담이됩니다. 또한 동일한 모듈에서 동시에 작업하는 큰 팀을 지원하지 않습니다. 요약하면
, 나는 사람들이 선택하는 것을 제안 :
미안하지만 나는 그것에 대해 완전히 반대하고 있습니다. 우리에게는 매우 큰 응용 프로그램이 있었으며 1200 페이지 이상의 동적 페이지 크기 조정에 문제가 없었습니다. 우리는 MVP 패턴을 사용하고 신속한로드를 위해 GWT.runAsync를 사용했습니다. 나는 또한 개찰구를 사용했고 GWT보다 자갈을 깐 프레임 워크가 더 많이 보인다. getModel과 getOriginalModel과 같은 것들이 성가시다. 단순히 DOM으로 작업 할 수 없다는 점이 Wicket에 대한 저를 정말로 막아 버렸습니다. IMHO Vaadin은 Wicket보다 더 나은 선택이 될 것입니다. 7.0이 두 세계의 장점을 제공하기 때문입니다. 그러나 나는 GWT를 고수 할 것입니다. –
내가 말하는 것은 GWT ** 모듈 **이 잘 확장되지 않는다는 것입니다. GWT는 자체적으로 모듈 크기를 제한하여 모듈 수를 곱하여 확장 할 수 있습니다. 그러나 GWT 모듈 크기가 너무 커지면 기술적 인 측면과 인간적인 측면 모두에서 정말 고통 스럽습니다. Btw Wicket'getOriginalModel()'이 무엇인지 모르겠습니까? –
모듈 크기가 왜 까다로운가요? 수퍼 데브 모드는 개발하는 동안 모든 것을 컴파일 할 필요가 없으며, 심지어 오래된 dev 모드도 훌륭했습니다. 다운로드 시간에 모듈 크기가 아프다면 다운로드 크기를 줄이기위한 많은 옵션이 있습니다. GWT가 모바일 GMAIL 앱 (Android 및 iOS)에 적합하다면 대규모 복잡한 애플리케이션을 자체적으로 처리 할 수 있다고 결론 내릴 수 있습니다. [Google이 다중 플랫폼을받은 편지함에서 수행하는 방법] (http://www.i-programmer.info/news/83-mobliephone/8010-how-google-does-multi-platform-in-inbox.html) –
이 스레드가 활성화되어 있고 GWT가 대부분 정체 된 지 6 년이되었습니다. 개찰구가 훨씬 더 적극적으로 개발되고 지원되는 것 같습니다. Wicket 또는 다른 옵션에 대한 새로운 의견이 있으십니까?
위젯은 서버 프레임 워크입니다. 그것은 당신이 필요한 HTML을 만들 수 있습니다. 프로젝트에서 역할 분리가 가능합니다. (웹 디자인 -> html/css-> java).
프로젝트에 GWT를 사용하려면 웹 디자이너가 필요하지 않을 것입니다.
GWT가 javascript를 생성합니다. 대부분의 로직은 브라우저 측에서 실행될 수 있습니다. 확장 가능한 응용 프로그램을위한 GWT가 더 좋습니다.
중복 : http://stackoverflow.com/questions/3569402/wicket-vs-gwt-advice-needed – Karussell