GWT는 Java 코드 및 Java Runtime 클래스 라이브러리의 서브 세트를 JavaScript 코드로 변환하는 소프트웨어 스택입니다.
JavaScript 툴킷과 비교할 때 GWT는 본질적으로 그리고 용도에 따라 소외되어 보일 수 있으며, 간단한 작업조차하기에는 지나치게 복잡 할 수 있습니다.
왜 웹 개발자가 순수한 JavaScript 및 JavaScript 프레임 워크 및 툴킷을 사용하는 대신 원래 웹용이 아닌 언어를 사용하는 GWT와 같은 도구를 사용하려고합니까?
측정 기준이 더 좋으며 어떤 기준을 기준으로합니까?
답변:
정말 대단합니다.
일찍 버그를 잡습니다. (Google Closure는 개발자가 원하는 경우 개발자를 JavaScript 세계에 유지하면서 조금 해결합니다).
GWT는 (대규모 애플리케이션의 경우) 사용자보다 더 빠르고 더 작은 JavaScript를 작성 하며 , 동등한 풀 JS 솔루션보다 클라이언트로 전송 될 내용을보다 쉽게 결정할 수 있습니다.
또한 MVC 또는 MVP 아키텍처가 미리 준비되어있어 대규모 응용 프로그램에 대한 우려를 적절히 분리 할 수 있습니다.
GWT는 흥미로운 라이브러리를 제공하며 동적 번들 로딩을 사용하여 I18N 지원 애플리케이션을 쉽게 (잘, 더 쉽게) 구축 할 수 있습니다.
Eclipse IDE 및 명령 행에서 JUnit 사용 이것은 나의 첫 번째 요점과 관련이 있습니다. GWT 프로젝트에서 Java 코드 품질 도구 중 일부를 사용할 수도 있습니다 (바이트 코드 검사가 아닌 소스 검사의 경우).
GWT가 모든 사람을위한 것은 아닙니다. 일부 사람들의 생산성을 높이고 JS가 아닌 개발자가 JavaScript를 건드리지 않고 동적 프런트 엔드로 전문적인 웹 응용 프로그램을 만들 수있는 좋은 도구를 제공합니다. 그러나 그것이 효과가 없다면 다른 것을 사용하십시오.
위의 대부분을 원하지만 Java를 원하지 않는 경우 Google Closure 또는 Dojo Toolkit을 참조하십시오 .
오늘날 JavaScript 세계 (및 웹 프론트 엔드 기술)는 활발히 활동하고 있기 때문에 많은 것들이 찾고 있습니다. 그러나 몇 년 전만해도 상황이 그렇게 밝지 않았습니다. LESS / SASS는 그다지 인기가 없었으며 jQuery는 아직 공장 JS 라이브러리가 아니었고 JavaScript 라이브러리는 격주로 생성되지 않았으며 툴링은 일반적으로 그리 좋지 않았습니다.
그러나 동적 프런트 엔드를 갖춘 전문적이고 대규모의 웹 응용 프로그램에 대한 수요가 이미 증가하고 있으므로 개발자의 생산성을 높이려면 빈틈이있었습니다. JavaScript에는 알아야 할 많은 함정과 이상한 점이 있으며, 신경 쓰지 않아도되는 것이 더 좋습니다. 따라서 GWT와 같은 도구의 틈새 시장입니다.
그 이후로 다른 사람들이 등장했습니다 (커피 스크립트가 떠오를 때 다트가 떠오를 것입니다. 그러나 큰 자바 스크립트 프레임 워크, Node.JS와 다른 서버 측 JS의 혁명, 그리고 "충분히 좋은"것으로 자바 스크립트에 대한 강력한 복귀 -클라이언트 측뿐만 아니라 비즈니스 스택의 다른 부분에서도 사용되는 언어.
물론 Firebug로 GWT 코드를 디버깅 할 수 있지만 이상적으로는 Eclipse IDE의 디버거에서 직접 디버깅하여 라이브 코드 디버깅 지원을 제공합니다.
그러나 Firebug는 여전히 사용 가능하지만 GWT는 최적화되고 압축 된 JavaScript를 생성하므로 디버깅하기가 쉽지 않을 수 있음을 명심해야합니다.
물론 CSS 코드를 직접 작성해야합니다. GWT 프로젝트를 SASS와 같은 다른 도구와 쉽게 결합 할 수 있습니다.
그렇지 않은 것을 GWT로 오인하지 마십시오. 자바 코드를 클라이언트 측에서 직접 자바 바이트 코드로 실행하도록 작성하지는 않습니다. Java 언어로 코드 를 작성 하면 효율성을 위해 JavaScript로 변환되어 더 높은 수준의 언어를 사용할 수있게됩니다 (또는 적어도 그렇게 표시되어야합니다).
아마도 Java와 JavaScript는 추상화 수준 측면에서 비교 가능한 것으로 간주 될 수 있습니다. 그러나 Java에는 몇 가지 장점이 있으며 (위에서 자세히 설명) 기존 도구를 다시 작성할 필요없이 기존 도구의 이점을 얻을 수 있다는 이점이 있습니다. Google 개발자는 기존 Java 지향 도구를 재사용 할 수 있지만 실제로는 JavaScript 응용 프로그램을 개발할 수 있다는 영리한 아이디어를 얻었습니다.
또한 JavaScript와 Java 코드가 별도로 처리되는 이중 언어 웹 응용 프로그램의 관리가 번거로운 또 다른 문제를 해결합니다. GWT를 사용하면 개발 프로세스의 양쪽에 일정한 수준의 수렴이 가능합니다.
GWT에서 웹 응용 프로그램을 개발하는 데 수년을 보낸 후 GWT는 너무 강하게 불리하여 강제하지 않으면 다시는 사용하지 않을 것이라고 생각합니다.
DOM 트리
JavaScript 성능은 향상 될 수 있지만 렌더링 된 DOM 트리는 종종 불필요하게 복잡합니다. 예를 들어, Tree 구현은 각 개별 항목에 대해 <table>을 포함하여 13 개 이상의 DOM 요소를 사용합니다. 큰 나무 (약 10000 개 항목)를 사용하면 브라우저가 정지됩니다. 순수한 JavaScript / HTML / CSS 트리는 같은 양의 항목을 쉽게 처리 할 수있었습니다.
개발
순수한 JavaScript / HTML / CSS 소스의 수정 시도주기는 이길 수 없습니다. 소스 파일을 저장하고 브라우저에서 페이지를 새로 고칩니다. 이는 생산성의 핵심 요소이며 GWT는 코드 서버를 사용해도 경쟁 할 수 없습니다.
Chrome 또는 Firebug의 디버거를 사용하면 JavaScript 디버깅이 매우 쉽고 즐겁습니다.
해머 전문가
모든 것에 Java를 사용한다는 아이디어는 "해머 전문가"인 개발자를위한 것입니다. 그들은 망치의 주인이므로 모든 것이 못입니다. 나는이 접근법이 매우 잘못되었다고 생각합니다. GWT를 사용하려면 CSS와 HTML에 대한 지식이 필요합니다. 이 GWT가 없으면 개발자는 종종 해결하기가 거의 불가능한 문제에 부딪히지 만 HTML / CSS 경험이있는 사람은 솔루션을 생각해 낼 수 있습니다. 개발자가이 역량을 필요로하면 HTML로 개발하는 것이 더 쉬워 질 수 있습니다.
내 의견은 GWT가 제공하는 대부분의 장점은 적어도 의문의 여지가 있지만 순수한 JavaScript / HTML / CSS에서 개발하는 것보다 단점이 훨씬 심각하다는 것입니다.
그것은 더 나아지지 않습니다.
일상적으로 사용하려면 jQuery , AmpleSDK 또는 일부 html5 polyfill을 고려하십시오 .
GWT는 실제 적이고 개념적인 오버 헤드가 많습니다 .
웹 애플리케이션으로 포팅 하기위한 Java 앱 또는 일부 서버 측 Java 코드가있는 경우 유용 할 수 있습니다 .
내가 생각하는 GWT 사용의 몇 가지 이점 (자세한 내용은 내 블로그 http://www.pandurangpatil.com/2012/09/benefits-of-using-gwt.html 참조 )
GWT 클라이언트 애플리케이션이 Java로 작성되었으므로 컴파일 타임에 구문 오류가 발생할 수 있습니다 (브라우저 자체에서 지원하지 않는 기능이므로 모든 JRE 클래스를 지원하지는 않지만). 내가 말하는 것을 이해하기 위해 예를 들어 봅시다. 순수한 JavaScript 라이브러리를 사용하여 JavaScript 변수 이름의 철자를 틀린 경우 이러한 실수를 잡을 수있는 유일한 방법은 응용 프로그램을 실행하고 원하는 결과를 테스트하는 것입니다. Generics 및 Annotations와 같은 Java 기능은 모두 사용되며 애플리케이션에서 사용할 수 있습니다.
생성 가능한 코드가 Java에 있어야하기 때문에 기존의 사용 가능한 라이브러리를 사용하거나 요구에 따라 코드를 생성하기 위해 하나를 작성할 수 있습니다. GWT 컴파일러는 컴파일하고 JavaScript로 변환합니다.
코드 관리가 더 쉬워집니다.
하나는 공통 비즈니스 로직을 GWT 클라이언트 측 코드와 서버 측 코드에서 Java와 같이 데이터와 같은 공통 유틸리티 기능과 같은 Java에서와 같이 사용할 수있는 방식으로 간단히 작성할 수 있습니다.
GWT 이클립스 플러그인을 사용하면 비즈니스 로직에 맞게 Java로 클라이언트 코드를 쉽게 디버깅 할 수 있습니다.
GWT 컴파일러는 클라이언트 Java 코드를 컴파일하고 JavaScript를 생성합니다. 서버에 배포해야하며 요청시 사용자 브라우저에서 제공되고 실행됩니다. 이 JavaScript를 생성하는 동안 일부 최적화가 수행됩니다.
JavaScript를 생성하는 동안 죽은 코드를 고려하지 않습니다. 죽은 코드를 말하면 "주 흐름에서 호출되지 않는 코드"를 말합니다. 결과적으로 최종 JavaScript 코드의 유효 크기가 줄어 듭니다.
생성 된 JavaScript 코드를 난독 처리합니다.
생성 된 JavaScript 코드를 최소화합니다.
그리고 더 중요한 것은 브라우저별로 최적화 된 코드를 별도로 생성한다는 것입니다. 별도로 말하면 주어진 브라우저에서 각 요청을 수신 할 때 제공되는 브라우저 별 별도 JavaScript가 생성됩니다. 결과적으로 하나의 단일 코드로 모든 브라우저 별 처리가 포함되어 있지 않으므로 특정 브라우저 용으로 다운로드되는 JavaScript 코드의 크기가 줄어 듭니다.
GWT의 국제화 기능을 사용하여 영어, 힌디어, 마라 티어 등 다른 언어로 응용 프로그램을 작성하는 경우. JavaScript 코드를 생성하는 동안 언어 및 브라우저 조합별로 사본을 작성합니다. 언어와 브라우저의 주어진 조합에 대해 생성 된 JavaScript 코드를 가장 최적의 작은 코드로 만듭니다.
Java GWT 코드에서 호출 할 수있는 직접 JavaScript를 사용해야하는 경우 JSNI (JavaScript Native Interface)를 사용하여 수행 할 수 있습니다. JavaSctipt에서 GWT Java 코드를 다시 호출 할 수도 있습니다.
북마크 가능 페이지를 만들려면 GWT의 히스토리 기능을 사용할 수 있습니다.
통신 및 조작을 위해 데이터 형식으로 JSON을 사용하려는 경우 JavaScript Overlay Types라는 매우 유용한 기능이 있습니다.
GWT의 Deferred Binding 기능은 Java 때문에 제공 할 수 있다고 생각하는 좋은 기능입니다.
Java Swing 스타일에서 사용 가능한 GWT 위젯을 사용하여 사용자 인터페이스를 빌드 할 수 있습니다. 당신은 매우 쉽게 사용자 정의 위젯을 만들 수 있습니다.
순수한 html 스타일로 사용자 인터페이스 (웹 페이지)를 빌드하려는 경우 GWT의 선언적 UI 기능을 사용할 수 있습니다. GWT의 주요 기능 중 하나라고 생각합니다. 개발자가 순수한 HTML 스타일로 페이지를 더 쉽게 만들 수 있습니다. 스윙 스타일 코딩보다 유지 관리가 더 쉽다고 생각합니다. 그리고 가장 중요한 것은 여전히 논리를 Java로 유지하고 순수한 HTML로만 프리젠 테이션 부분을 가질 수 있다는 것입니다. (참고 : 어떤 메소드 (Declarative UI 또는 Swing Style)를 사용하든 궁극적으로 HTML 만 가능하지만 차이점은 코딩 및 유지 관리 방식입니다).
GWT의 클라이언트 번들 기능을 사용하면 CSS, 이미지 및 기타 텍스트 컨텐츠와 같은 다른 웹 리소스를 매우 쉽게 관리 할 수 있습니다.
셀 위젯 : 페이지가 매겨진 데이터 콜렉션을 표시하기 위해 GWT에는 셀 위젯이 있습니다. CellTable, CellList, CellTree 및 CellBrowser와 같은 위젯이 있습니다.
GWT 클라이언트 코드에서 서버와 통신 클라이언트 서버 통신을 구현하는 여러 가지 방법을 지원합니다.
데이터 전송에 사용되는 프로토콜이 걱정되지 않으면 GWT RPC 메커니즘입니다. 데이터 전송을위한 클라이언트 측 코드를 서버와 매우 쉽게 통합 할 수 있습니다. 서버 측 코드에서도 사용할 수있는 클라이언트 코드에서 사용자 지정 DTO (데이터 전송 개체)를 정의 할 수 있습니다. 서버 측 구현은 매개 변수 또는 반환 값과 동일한 DTO를 허용합니다. 다른 모든 것은 GWT RPC 프레임 작업에 의해 처리됩니다. 서버 측 코드에서 클라이언트 측 코드로 호출자에게 발생한 예외를 전달하기도합니다 (클라이언트 측 코드 패키지 내에서 예외 클래스를 정의해야하는 경우 GWT RPC는 내부적으로 데이터 전송을 위해 자체 사용자 정의 프로토콜로 AJAX 호출을 사용합니다.
GWT RPC를 사용하지 않으려는 경우 요청 빌더를 사용하여 서버에서 데이터를 페치하기 위해 서버 AJAX 호출을 작성할 수 있습니다. 구현하기가 훨씬 쉽습니다. 또한 흥미로운 기능 Request Factory가 있습니다. 이 기능을 사용하면 DAO 또는 서비스 계층이 클라이언트 코드에서 호출되도록 노출시킬 수 있습니다. 그러기 위해서는 서비스 및 사용자 정의 데이터 유형에 대한 몇 가지 인터페이스 세트를 정의해야합니다. 이러한 인터페이스를 사용하면 클라이언트 코드에서 해당 서비스에 액세스 할 수 있습니다. 이 인터페이스를 생성하기 위해 maven 플러그인을 작성했습니다. 필요한 주석으로 DAO 레이어에 주석을 달면 ( https://github.com/pandurangpatil/gwt-mvn-helper 참조)) 사용법은 mvn-helper-test 모듈을 참조하십시오. Request Factory는 서버의 JDO 또는 JPA와 같은 ORM 계층과 통합하는 것을 목표로합니다. 그것은 클라이언트 코드로부터 주어진 엔티티에 대해 persist 호출을 지원합니다. 그리고 persist 메소드를 호출 할 때 가장 중요한 것은 계산하기 위해 변경 (델타) 만 서버에 보내 저장합니다.
교차 도메인 JSONP 호출을하려면 동일한 참조를 수행 할 수 있습니다.