2007년 05월 06일
Google Web Toolkit(GWT) 장단점들
http://blog.blessedsoft.com/entry/Google-Web-ToolkitGWT-%EC%B2%AB-%EC%9D%B8%EC%83%81
-------------------------------------
-------------------------------
요약하면
- 전통적인 페이지 중심적인 애플리케이션에 맞지 않다. 한 페이지에 모든 기능이 들어가는 경우에 더 적합하다.
- J2EE와의 통합은 쉽다.
- 너무 급격한 솔루션이다. 자바 스크립트가 아니라면 UI를 다룰 수 없다.
- 국제화의 문제가 있다(런타임시에 자원을 로딩하는 문제).
- 자바 코드에서 자바 스크립트를 생성하는 것은 장점이 있지만 모두 동의하는 것은 아니다.
- 좀 더 안전한 코드를 작성할 수 있다는 장점에도 이견이 있을 수 있다. 하지만 클라이언트 코드의 오프라인 검증은 확실히 이점이 있을 것이다.
- 전례가 없는 것은 아니지만 RPC 메커니즘과 내장된 Serialization은 Ajax 프로그래밍의 가장 어려운 부분을 해소한다.
- GWT는 Ajax 애플리케이션 개발의 저수준의 면모를 잘 추상화한다. 크로스 브라우징 문제, Dom 이벤트 모델, Ajax 콜 등등. 하지만 코드 생성 방식 자체를 바꾸지 않고도 Yahoo UI Library나 Dojo, MochiKit과 같은 라이브러리도 비슷한 레벨의 추상화를 제공한다.
이쯤하고, 여기에 아주 짧은 나의 경험을 추가하자면 다음과 같다.
* 장점
- 자바스크립트를 잘 몰라도 된다. 클라어언트 환경을 잊어도 좋다. 자바 개발하듯이 이클립스에서 개발하면 끝이다.
- 디버깅이 수월하다.
* 단점
- 코드 크기가 상당하다.(가장 기본적인 예제 20k, KitchenSink는 100K 정도)
- 한글이 정확히 출력되지 않았다. Properties 파일에서 처럼 유니코드를 사용해야 한다. 위에서 언급했듯이 다른 국제화 문제도 있을 수 있을 것 같다.
- Ajax는 어디 있는 것일까.
전체적으로 봐서 높은 안정성이 요구되는 복잡한 기업용 애플리케이션에 어울리는 툴킷이지만 처음 Ajax를 배우는데는 그다지 권장하고 싶지 않다. 위에서 지적된 것처럼 추상화의 수준에 비해서 방식이 너무 과격(?)하기에 왠지 꺼려지는 점도 있다.
-------------------------------------
Why use GWT?
Contrary to what you might expect, GWT applications are remarkably un-Weblike. GWT essentially exploits the browser as a run-time environment for lightweight GUI applications, and the result is much closer to what you might develop with Morfik, OpenLaszlo, or even Flash, than to normal Web applications. Accordingly, GWT is best suited to Web applications that can exist as a rich Ajax GUI on a single page. It's probably no coincidence that this characterizes some of Google's recent beta releases, such as its Calendar and Spreadsheets applications. These are great applications, but you can't solve all business scenarios using this approach. The majority of Web applications fit quite comfortably into the page-centric model, and Ajax lets richer interaction paradigms be employed where needed. GWT does not play nicely with traditional page-centric applications. Although it's possible to combine GWT widgets with normal HTML form inputs, the state of a GWT widget is fenced off from the rest of the page. For example, there's no straightforward way to submit the selected value from a GWT Tree widget as part of a regular form.
If you do decide to use GWT into a J2EE application environment, GWT's design should make integration relatively straightforward. In this scenario, GWT services should be thought of as similar to Actions in Struts -- a thin middle layer that simply proxies Web requests into business-logic invocations on the back end. Because GWT services are just HTTP servlets, they can be integrated easily into Struts or SpringMVC, for example, and placed behind authentication filters.
GWT does have a couple of fairly significant flaws. First among them is its lack of provision for graceful degradation. Best practice in modern Web application development is to create pages that work without JavaScript, and then use it where available to embellish and add extra behavior. In GWT, if JavaScript isn't available, you won't get any UI at all. For certain classes of Web application, this is an immediate deal-breaker. Internationalization is also a major problem for GWT. Because GWT client Java classes run in the browser, they have no access to properties or resource bundles to grab localized strings at run time. A complex workaround is available that requires a subclass of each client-side class to be created for each locale (see Resources), but GWT's engineers are working on a more viable solution.
The case for code generation
Probably the most contentious issue in GWT's architecture is the switch to the Java language for client-side code. Some GWT proponents suggest that writing client-side code in the Java language is intrinsically preferable to writing JavaScript. This is not a view shared by all, and many JavaScript coders would be extremely reluctant to sacrifice their language's flexibility and expressiveness for the sometimes onerous grind of Java development. One situation where the substitution of Java code for JavaScript might be appealing is in a team that lacks experienced Web developers. However, if that team is moving into Ajax development, it might be better served by hiring skilled JavaScript programmers rather than relying on Java coders to produce obfuscated JavaScript at arm's length through a proprietary tool. Bugs are inevitably caused by leaks in the abstraction that GWT stretches over JavaScript, HTTP, and HTML, and inexperienced Web programmers have a hard time tracking them down. As developer and blogger Dimitri Glazkov puts it, "If you can't handle JavaScript, you shouldn't be writing code for Web applications. HTML, CSS, and JavaScript are the three prerequisites for this ride." (see Resources).
Some people argue that Java coding is inherently less error-prone than JavaScript programming, thanks to static typing and compile-time checks. This is a fairly fallacious argument. It's possible to write bad code in any language, and plenty of buggy Java applications are around to prove it. You're also dependent on GWT's code-generation being bug-free. However, offline syntax-checking and validation of client-side code can certainly be beneficial. It's available for JavaScript in the form of Douglas Crockford's JSLint (see Resources). GWT has the upper hand in terms of unit testing, though, providing JUnit integration for client-side code. Unit-testing support is an area where JavaScript is still sorely lacking.
In developing the Weather Reporter application, the most compelling case I found for client-side Java code was the ability to share the same validation class between both tiers. This obviously saves development effort. The same goes for any classes transferred over RPC; you only need to code them once and you can use them both client and server code. Unfortunately, the abstraction is leaky: in my ZIP code validator, for example, I would have liked to use regular expressions to perform the check. However, GWT doesn't implement the String.match() method. Even if it did, regular expressions in GWT have syntactical differences when deployed as client and server code. This is because of GWT's reliance on the host environment's underlying regexp mechanism and is an example of the trouble that imperfect abstractions can land you in.
One big win that GWT scores is its RPC mechanism and built-in serialization of objects between Java code and JavaScript. This removes a lot of the heavy lifting you see in the average Ajax application. It's not without precedent, though. If you want this functionality without the rest of GWT, then Direct Web Remoting (DWR), which offers RPC with object marshalling to and from Java code to JavaScript, is well worth considering (see Resources).
GWT also does a good job of abstracting away some of the low-level aspects of Ajax application development, such as cross-browser incompatibilities, the DOM event model, and making Ajax calls. But modern JavaScript toolkits such as the Yahoo! UI Library, Dojo, and MochiKit all provide a similar level of abstraction without needing to resort to code generation. Moreover, all of these toolkits are open source, so you can customize them to suit your needs or fix bugs that arise. This isn't possible with the black box of GWT (see the Licensing sidebar).
-------------------------------
요약하면
- 전통적인 페이지 중심적인 애플리케이션에 맞지 않다. 한 페이지에 모든 기능이 들어가는 경우에 더 적합하다.
- J2EE와의 통합은 쉽다.
- 너무 급격한 솔루션이다. 자바 스크립트가 아니라면 UI를 다룰 수 없다.
- 국제화의 문제가 있다(런타임시에 자원을 로딩하는 문제).
- 자바 코드에서 자바 스크립트를 생성하는 것은 장점이 있지만 모두 동의하는 것은 아니다.
- 좀 더 안전한 코드를 작성할 수 있다는 장점에도 이견이 있을 수 있다. 하지만 클라이언트 코드의 오프라인 검증은 확실히 이점이 있을 것이다.
- 전례가 없는 것은 아니지만 RPC 메커니즘과 내장된 Serialization은 Ajax 프로그래밍의 가장 어려운 부분을 해소한다.
- GWT는 Ajax 애플리케이션 개발의 저수준의 면모를 잘 추상화한다. 크로스 브라우징 문제, Dom 이벤트 모델, Ajax 콜 등등. 하지만 코드 생성 방식 자체를 바꾸지 않고도 Yahoo UI Library나 Dojo, MochiKit과 같은 라이브러리도 비슷한 레벨의 추상화를 제공한다.
이쯤하고, 여기에 아주 짧은 나의 경험을 추가하자면 다음과 같다.
* 장점
- 자바스크립트를 잘 몰라도 된다. 클라어언트 환경을 잊어도 좋다. 자바 개발하듯이 이클립스에서 개발하면 끝이다.
- 디버깅이 수월하다.
* 단점
- 코드 크기가 상당하다.(가장 기본적인 예제 20k, KitchenSink는 100K 정도)
- 한글이 정확히 출력되지 않았다. Properties 파일에서 처럼 유니코드를 사용해야 한다. 위에서 언급했듯이 다른 국제화 문제도 있을 수 있을 것 같다.
- Ajax는 어디 있는 것일까.
전체적으로 봐서 높은 안정성이 요구되는 복잡한 기업용 애플리케이션에 어울리는 툴킷이지만 처음 Ajax를 배우는데는 그다지 권장하고 싶지 않다. 위에서 지적된 것처럼 추상화의 수준에 비해서 방식이 너무 과격(?)하기에 왠지 꺼려지는 점도 있다.
# by | 2007/05/06 13:49 | 트랙백(1) | 덧글(0)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
제목 : GWT의 장단점
xissy 님 의 글을 보다, 몇가지 의견을 적습니다. ... 중략 이쯤하고, 여기에 아주 짧은 나의 경험을 추가하자면 다음과 같다. * 장점 - 자바스크립트를 잘 몰라도 된다. 클라어언트 환경을 잊어도 좋다. 자바 개발하듯이 이클립스에서 개발하면 끝이다. 여전히 스크립트를 알아야 하고, 그것도 세부적으로 알아야 합니다. 컴파일 된 결과물이라 하더라도, 그 원리를 알지 못하면 GWT를 제대로 사용할 수 없습니다. - 디버깅이 수월하다. 기존 방......more