왜 GWT일까요?이 RIA Framework를 사용할 경우의 장점과 단점
저는 GWT에 대한 "가장 높은 투표율"의 질문들을 많이 읽어왔습니다. 이 질문들 중 몇 가지는 GWT의 함정이나 문제에 대해 이야기합니다.
기사 내용:어떤 Javascript 프레임워크(jQuery vs Dojo vs …)와 가장 큰 GWT 함정? 일부 포스터는 GWT가 충분히 가볍지 않거나 사용할 수 있는 더 나은 대안이 있음을 시사하는 것 같습니다.
여러분 대부분이 GWT 2.0에서 수정되지 않은 GWT에 문제가 있다고 느끼십니까?새로운 프로젝트에 보다 심플한 프레임워크를 사용하는 것을 제안하고 싶습니까?
GWT는 어느 정도 미래에 대비해야 하지 않을까(출시마다 크게 변화할 염려가 없고, 구글이 뒷받침하고 있기 때문에)?
이 질문에 대한 답은 여러분이 무엇을 하고 싶은지, 무엇을 만들고 싶은지에 따라 크게 달라진다는 것을 알고 있습니다.저는 이것을 수백만 명의 사용자가 사용하게 될 새로운 웹 어플리케이션을 시작한다는 관점에서 보고 있습니다.
트레이드오프
우선 제가 생각해 낼 수 있는 모든 균형점부터 말씀드리겠습니다.
- 자바 사용 중 - Webdevs의 Javascript 실력이 그다지 유용하지 않다는 것을 의미합니다(JSNI에 손을 대면 도움이 됩니다).
- 검색 엔진에 의한 인덱싱 문제 - IMHO, 이것은 GWT 또는 일반적으로 순수 JS 웹 애플리케이션을 사용할 때 가장 큰 단점이 될 것입니다.컨텐츠, 레이아웃, 모든 것이 JS에서 "즉시" 작성되기 때문에 검색 엔진은 매우 짧은 HTML 페이지만 볼 수 있습니다. 즉, 사용자가 직접 처리해야 합니다(예: 클로킹 사용).구글은 마침내 이에 대한 해결책을 찾기 시작했지만, 나에게는 매력적이지 않은 것 같다.
업데이트: Google이 마침내 이 문제를 해결했습니다.그러나 어플리케이션을 크롤 가능케 하려면 다른 프레임워크보다 더 많은 노력이 필요하기 때문에 트레이드오프로서 남겨두겠습니다.적어도 이제 우리는 따라야 할 "표준"을 가지고 있고 (클로킹과 같은) 의심스러운 기술을 사용할 필요가 없다. - (특히 GWT의 초보자, 특히 HTML/JS 배경에서 온 사람이 오브젝트 지향적인 경험을 너무 많이 하지 않고) 모든 것을 "와, 이 '오브젝트'들은 너무 멋지다"라고 말하는 것은 쉽다.
<div>물론이 없는 가 제대로 된 프로그래머를 넣을 수 것은 .WidgetHandlersFlexTable...그리고 나서 그는 왜 어플리케이션이 느리다고 느끼는지 궁금해하며 많은 시간을 낭비하게 될 것이다.) tl;dr: GWT의 초보자들은 문서/샘플/상식에 부합하는 것처럼 보이는 코드를 작성함으로써 어플리케이션을 "피투성이"로 만들기가 쉽다.
제가 생각할 수 있는 단점은 여기까지입니다.추가하고 싶은 분이 있으면 코멘트를 추가해 주세요.
이점
이제 장점을 알아보겠습니다.국제화, 무료 브라우저 호환성, 다른 구글 라이브러리와의 손쉬운 통합 등은 생략하겠습니다.왜냐하면 그것들은 명확하고 이해하기 쉽기 때문입니다.강조되지 않지만 여전히 매우 중요한 기능에 초점을 맞추도록 하겠습니다.
- 컴파일러 - 현재 GWT에 대해 이야기한 대부분의 사람들은 GWT의 이 부분이 얼마나 놀라운지 깨닫지 못하고 있다 - 우선 지난해 구글 IO에서 이 프레젠테이션을 사용해 본다.컴파일러는 애플리케이션 전체를 볼 수 있습니다.
따라서 다음과 같은 작업을 최적화할 수 있습니다.
public class ShapeExample implements EntryPoint {
private static final double SIDE_LEN_SMALL = 2;
private final Shape shape = new SmallSquare();
public static abstract class Shape {
public abstract double getArea();
}
public static abstract class Square extends Shape {
public double getArea() { return getSideLength() * getSideLength(); }
public abstract double getSideLength();
}
public static class SmallSquare extends Square {
public double getSideLength() { return SIDE_LEN_SMALL; }
}
public void onModuleLoad() {
Shape shape = getShape();
Window.alert("Area is " + shape.getArea());
}
private Shape getShape() { return shape; }
}
..이것에 대해서:
public class ShapeExample implements EntryPoint {
public void onModuleLoad() {
Window.alert("Area is 4.0");
}
}
그리고 이걸 난독화하고 최소화해또한 이러한 방식으로 실행되므로 gzip을 통해 결과 파일을 더 압축할 수 있습니다.
- Java를 사용하고 있습니다.Java를 좋아하든 좋아하지 않든, Java가 매우 좋은 객체 지향 언어이며, 유지보수가 쉽고 테스트 가능한 코드를 쓸 수 있습니다(JavaScript에서는 불가능하다고 생각합니다).좋은 가이드라인을 따르면 자신뿐만 아니라 다른 개발자도 이해할 수 있는 코드에 도달할 수 있습니다.또 하나 언급할 가치가 있는 것은 "순수한" 자바에서 작동하는 멋진 디자인 패턴 등이 모두 여기서도 작동한다는 것입니다.
- GWT의 장점 중 하나는 거의 모든 새로운 프레임워크 릴리스에서 성능 향상과 새로운 기능을 무료로 얻을 수 있다는 것입니다.JavaScript로 컴파일 되어 있기 때문에 새로운 컴파일러의 최적화를 이용하거나 새로운 기능(GWT 1.5에서 도입된 접근성 지원 등)을 얻으려면 재컴파일만 하면 됩니다.
- debugging - IDE의 디버거를 사용하여 GWT 앱을 다른 Java 애플리케이션과 마찬가지로 디버깅할 수 있습니다(그리고 :).그리고 일반적으로 내가 본 자바 디버거는 자바스크립트 디버거보다 더 고급이다.
- UiBinder - UiBinder를 사용하면 XML을 사용하여 위젯을 쉽고 직관적으로 설계할 수 있습니다(Java에서는 이 작업을 수행해야 했던 2.0 이전 방식과는 달리).HTML과 GWT의 위젯을 조합하는 것은 지금까지 없었던 쉽고 즐거운 일입니다.
- 물론 GWT는 항상 CSS를 채택하고 있지만 GWT 2.0(및 UiBinder)의 도입으로 CSS를 한 단계 더 끌어올렸습니다.일반적인 웹 어플리케이션에서 CSS 파일을 보겠습니다.수백 행, 수천 행, 네비게이트가 어려운 스타일도 있습니다.다만, 전혀 사용되지 않는 스타일도 있어, IE6/7을 만족시킬 필요가 있어, 악몽을 꾸게 됩니다.GWT를 사용하면 CSS용 JS 코드에 대해 수행했던 것과 동일한 작업을 수행하도록 지시할 수 있습니다.따라서 미사용 CSS 스타일은 모두 삭제되고 필요에 따라 Marge되며 클래스 이름은 최소화 및 난독화됩니다(CSS 파일 내의 조건, 상수 등).스타일을 각각의 UiBinder의 XML 파일에 보관하는 것이 좋습니다.이것에 의해, 보다 간단하게 정리하고 검색할 수 있습니다.마지막으로 CSS 스타일의 이름을 잘못 입력했을 때 오류가 발생합니다.Firebug 등의 툴을 사용하여 같은 이름을 입력하려고 하는 경우보다 번거롭지 않습니다.
- OOPM - 프로세스 외 호스트 모드에서는 GWT의 가장 큰 단점 중 하나가 수정되었습니다.이제 선택한 브라우저에서 호스트 모드를 사용할 수 있습니다(Firefox, Safari, IE 또는 Chrome 중 하나를 선택할 수 있지만 최소한 원하는 버전을 사용할 수 있습니다).또한 OOPM 설계로 VM에서 Windows를 실행하고 IE에서 호스트 OS(Linux/MacOS)로 실행되는 호스트 모드까지 접속할 수 있습니다.해킹이나 컴파일 후 파일 복사는 불필요합니다.
- /"wɪt/많이"라고 말할 수 있습니다.(이것은 Google IO 2009, IIRC의 프레젠테이션 중 하나에서 인용한 것입니다.)
- 더 많은..Google IO 2009의 비디오를 보고 GWT Wiki에서 GWT를 사용하여 RIA를 쉽고 오류 발생을 줄일 수 있는 정보를 확인하십시오.
중간중간
경험 및/또는 선호도에 따라 다음과 같은 이점이 있을 수 있습니다(저에게는 장점이지만 때로는 PITA일 수도 있습니다).
- 위젯의 기본 제공 컬렉션은 작고 단순하게 유지됩니다.완전한 GUI 프레임워크(웹이든 데스크톱이든)를 사용하는 경우 위젯 GWT의 수가 상대적으로 적은 것에 놀랄 수 있습니다.그러나 GWT의 개발에 따르면, 이는 의도적으로 유지되고 있습니다.기본 위젯은 사용자의 요구에 맞게 맞춤형으로 자체 구축에 필요한 모든 도구/"블록"입니다.다른 방법은 다양한 사용 사례를 지원해야 하는 다양한 범용 위젯을 제공하는 것입니다.그 결과 UI가 다소 느려졌습니다(최소한 IMHO는 SmartGWT나 Ext GWT와 같은 프로젝트를 직접 확인해 보십시오).이에 따라 GWT 위젯은 상당히 잘 쓰여 있는 제안박스(예:선택사항)을 지정할 수 있습니다.제안 표시, 사용자가 제안을 선택할 때 사용자 지정 동작을 선택합니다.제안 콜백) 또는 사용자 지정 제안 또는 사용자 지정 제안
SuggestBoxs...
결론은 - GWT를 사용해 보세요.아마 당신은 그것을 좋아하게 될 것이고 다시는 순수 자바스크립트로 쓰고 싶지 않을 것입니다.
버전 1.3이 출시된 이후 GWT를 사용하여 소규모(~2K Java 클래스)에서 중규모(~6K)의 엔터프라이즈 시스템을 정기적으로 구축하고 있습니다.초당 수천 번의 클릭이 발생하는 공공 사이트에서는 해결해야 할 여러 가지 문제가 있다는 것은 이해하지만, GWT 1.x의 가장 큰 문제와 GWT 2.0의 접근 방식에 대해 설명하겠습니다.
브라우저 메모리 리크 GWT에 의한 IE6의 누수는 매우 크고, IE7의 누수는 정기적인 페이지 갱신으로 보충할 수 있습니다.IE8은 이 영역에서 어느 정도의 안정성을 보증하지만, 기업에서는 아직 널리 받아들여지지 않습니다.또한 네이티브 JS 콜이 없는 유효한 GWT 코드에서도 경우에 따라서는 메모리가 누출됩니다.특히 UI가 복잡하고 Panel.clear() 콜을 많이 실행하는 경우.현재 누출의 진짜 원인을 파악할 수 있는 유용한 도구가 없습니다.브라우저 자체를 해킹하는 방법을 모르면요
렌더링 성능 특히 일반적으로 사용되는 사용자 지정 위젯을 작성할 때 UI 코드를 매우 신중하게 작성해야 합니다.JavaScript, CSS 및 DOM에 대한 자세한 지식은 여전히 필요합니다.인터넷에는 이 주제에 관한 많은 자료가 있다.GWT 위젯 수준에서 DOM 조작을 지시하는 방법과 시기를 알아야 합니다.
다운로드 가능한 콘텐츠의 크기는 2.0 이전 버전에서는 애플리케이션에 "하드" 네비게이션이 내장되어 있지 않으면 모듈을 다른 다운로드 가능한 조각으로 분할할 수 없었습니다.그러나 이 경우 JavaScript 컨텍스트가 지워지고 창을 새로고침해야 합니다.
UI Developers Mind Shift 경험 많은 UI 개발자들은 Java와 OOP를 모릅니다.경험이 많은 Java 개발자는 CSS, JS, HTML을 모르며 UI를 구축하는 것을 좋아하지 않습니다.UI 바인더는 올바른 방향으로 이동합니다.
이행 1.3 -> 1.5 -> 1.7은 항상 재컴파일 및 몇 가지 CSS 수정에 불과했습니다.GWT 2.0에서는 사용되지 않는 코드와 초기 접근법(프로젝트 구조, GWTShell)이 많이 삭제되어 신속한 이행이 어려울 수 있습니다.그러나 모든 기능은 유망해 보이며 구글이 어느 시점에 레거시 코드를 삭제한 것은 좋은 일이다.2.0의 안정성은 아직 실제 프로젝트에서 사용한 적이 없기 때문에 잘 모르겠습니다.
이게 도움이 됐으면 좋겠다.
셀레늄 승인 테스트를 포함한 GWT 앱이 있습니다.(당신처럼) GWT를 1.7에서 2.0으로 업그레이드하는 것이 안전하다고 생각했습니다.그리고 그것은 - 대부분이었다.이 앱은 "인간" 사용자들에게도 동일하게 작동했지만 셀레늄 테스트는 모두 중단되었다.새로운 버전의 Selenium이 준비 중이지만(Alpha 릴리즈, Unsupported Operations가 다수 포함), GWT 2를 계속 사용하려면 테스트 가능성을 포기해야 할 것 같습니다.따라서 "미래에 대비할 수 있는" 가정에 주의해야 합니다.
GWT를 사용하기로 한 것은 몇 달 전에 YUI와 ZK를 비교한 결과입니다.그래도 GWT를 선택해서 다행이에요.GWT 웹사이트의 지원 수준과 문서의 전반적인 품질은 매우 높은 것으로 보입니다.
GWT는 모듈 분할을 실시하여 충분히 가볍지 않다는 주장에 대응하는 퍼포먼스프로파일을 제공합니다.
언급URL : https://stackoverflow.com/questions/2097964/why-gwt-advantages-and-trade-offs-of-using-this-ria-framework
'programing' 카테고리의 다른 글
| 사용자 이름과 비밀번호를 사용하여 MongoDB를 보호하는 방법 (0) | 2023.02.15 |
|---|---|
| 현재 페이지가 wordpress에서 플러그인 관리 패널인지 확인하는 방법 (0) | 2023.02.15 |
| create-react-app을 사용하여 빌드 버전을 실행하는 방법 (0) | 2023.02.15 |
| React 16에서의 class vs className (0) | 2023.02.15 |
| 스프링 코드 생성 시 OpenAPI "one Of" 속성을 OpenAPI-generator-maven-plugin과 함께 사용하는 방법 (0) | 2023.02.11 |