언제 Google Web Toolkit을 사용하지 않습니까? [닫은]

주요 사내 웹 앱 개발 프로젝트에서 GWT 사용을 고려하고 있습니다. 즉, 적어도 적어도 이론적으로는 팀이 기술 스택의 크기를 1 줄 이도록 도와주는 Javascript에 대한 크로스 컴파일입니다. .

그러나 (대부분의 개발자와 마찬가지로) 이전에 화상을 입었으므로 특정 문제 영역 내에서 사용을 방해하거나 제한하는 GWT 문제에 실제로 사용 한 프로그래머의 의견을 듣고 싶습니다.

GWT 사용에 대한 논쟁은 무엇이며 왜 그런가?

— 재스
소스

나는 GWT가 죽었다고 생각했다.

— Aaron McIver

@ 아론, 정말로 요?

— Jas

개인적으로 GWT를 권장하지 않습니다. 이 사고 방식은 데스크탑 응용 프로그램에서 작동하도록 강요하지만 HTML 함수에서 그렇게 생각하는 데 문제가 발생합니다. 나는 코딩 패러다임을 당면한 문제에 맞추는 팬이며 추상화가 방해가된다. 그렇기 때문에 평가를 시작할 때마다 사용하지 않기로 결정했습니다.

— Berin Loritsch

@Jas Experience는 몇 년 전이었습니다. 초기 단계에 있었고 당시에는 매우 생생한 느낌이었습니다. 바뀌 었습니까? 아마도 ...하지만 프레임 워크 자체에 의존하는 대신 프레임 워크의 토대를 천천히 배우려고합니다. 하루가 끝나면 JS를 휘젓는 고기 분쇄기입니다. 그것은 나쁜 것이 아니라 어딘가에 노력하고 싶습니다. 이러한 프레임 워크 중 많은 부분은 기술 X 지식 또는 그와 관련된 정보 부족으로 인해 선택되지만 ... 어느 시점에서 기술 X에 대한 지식이 있어야합니다.

— Aaron McIver

나는 JS에 대해 매우 잘 알고 있으며 꽤 심각한 것들을 썼지 만 지금은 매우 중요한 프로젝트를 실행 중이며 Java에서 JS로 컨텍스트 전환으로 인한 오류로 인해 주니어 직원이 시간을 낭비 할 여유가 없습니다. 따라서 GWT가 효과가없는 이유에 대한 실제 사례가 있다면 설명해주십시오. 그렇지 않으면 가상적이고 주관적인 색의 토론으로 서로의 시간을 낭비하지 마십시오.

— Jas

답변:

나는이 질문에 대답하는 것이 좋고 나쁘다. 실제로 그것을 사용했기 때문에 좋고 나쁘다 .GWT로 작업하기 전에 HTML / CSS / JavaScript에 상당히 경험이 있다는 점에서 나쁘다. 이것은 실제로 DHTML을 모르는 다른 Java 개발자가하지 않은 방식으로 GWT를 사용하여 화를 냈습니다.

GWT는 JavaScript를 추상화하고 어느 정도 HTML을 Java로 추상화합니다. 많은 개발자에게 이것은 훌륭하게 들립니다. 그러나 Jeff Atwood가 말했듯이 모든 추상화가 추상화에 실패했습니다 (GWT를 고려하면 읽음). GWT를 사용하면 다음과 같은 문제가 발생합니다.

GWT에서 HTML을 사용하면 짜증납니다.

내가 말했듯이 어느 정도까지는 HTML을 추상화합니다. Java 개발자에게는 좋은 소리입니다. 그러나 그렇지 않습니다. HTML은 문서 마크 업 형식입니다. 문서를 정의하기 위해 Java 오브젝트를 작성하려는 경우 문서 마크 업 요소를 사용하지 않습니다. 엄청나게 장황하다. 또한 충분히 제어되지 않습니다. HTML에는 본질적으로 작성하는 한 가지 방법이 <p>Hello how are <b>you</b>?</p>있습니다. GWT에는 노드에 3 개의 자식 노드 (text B,, text)가 연결되어 P있습니다. P를 먼저 생성하거나 하위 노드를 먼저 생성 할 수 있습니다. 자식 노드 중 하나가 함수의 반환 결과 일 수 있습니다. 많은 개발자들과 함께 몇 달 동안 개발 한 후 GWT 코드를 추적하여 HTML 문서의 모양을 해독하는 것은 골치 아픈 과정입니다.

결국 팀은 모든 HTML에 HTMLPanel을 사용하는 것이 올바른 방법이라고 결정했습니다. 이제 데이터에 쉽게 바인딩하기 위해 Java 코드에서 요소를 쉽게 사용할 수 있다는 GWT의 많은 이점을 잃어 버렸습니다.

GWT에서 CSS를 사용하면 짜증납니다.

HTML 추상화에 첨부함으로써 CSS를 사용해야하는 방식도 다르다는 것을 의미합니다. GWT를 마지막으로 사용한 이후 (약 9 개월 전) 개선되었을 수도 있지만, 당시 CSS 지원은 혼란 스러웠습니다. GWT가 HTML을 작성하는 방식으로 인해, 주입 된 줄 모르는 수준의 노드가있는 경우가 많습니다 (CSS 개발자는 이것이 렌더링에 크게 영향을 줄 수있는 방법을 알고 있습니다). CSS를 포함하거나 연결하는 방법이 너무 많아 네임 스페이스가 혼란스러워졌습니다. 그 외에도 스프라이트 지원이 있었지만 다시는 멋지게 들리지만 실제로 CSS를 변경했으며 나중에 명시 적으로 덮어 써야하거나 속성을 작성 해야하는 속성을 작성하는 데 문제가있었습니다. 코딩 된 CSS와 GWT가 망쳐 놓지 않은 방식으로 CSS를 다시 디자인해야했습니다.

문제의 연합, 혜택의 교차

모든 언어에는 고유 한 문제와 이점이 있습니다. 사용 여부는이를 기반으로하는 가중 수식입니다. 추상화가있을 때 얻는 문제는 모든 문제와 혜택의 교차점입니다. JavaScript에는 문제가 있으며 일반적으로 서버 측 엔지니어들 사이에서 파생되지만 빠른 웹 개발에 도움이되는 몇 가지 기능도 있습니다. 클로저, 구문 속기, 임시 객체, Jquery가 수행 한 모든 작업 (CSS 선택기에 의한 DOM 쿼리 등)을 생각하십시오. 이제 GWT에서 사용하는 것을 잊지 마십시오!

우려의 분리

우리는 프로젝트의 규모가 커질수록 우려를 잘 구분하는 것이 중요하다는 것을 알고 있습니다. 가장 중요한 것 중 하나는 디스플레이와 처리의 분리입니다. GWT는 이것을 정말로 어렵게 만들었습니다. 아마도 불가능하지는 않았지만 내가 근무했던 팀은 결코 좋은 해결책을 찾지 못했으며 우리가 생각했다고해도 항상 다른 사람에게 누출이 발생했습니다.

데스크탑! = 웹

@Berin Loritsch가 의견에 게시 한 것처럼 GWT 용으로 개발 된 모델 또는 사고 방식은 프로그램이 처리 엔진과 긴밀하게 연결된 라이브 디스플레이를 갖는 리빙 애플리케이션입니다. 많은 사람들이 웹이 부족하다고 느끼기 때문에 이것은 좋은 소리입니다. 그러나 두 가지 문제가 있습니다. A) 웹은 HTTP를 기반으로하며 본질적으로 다릅니다. 위에서 언급했듯이 HTTP-HTML, CSS, 심지어 리소스로드 및 캐싱 (이미지 등)을 기반 으로 하는 기술이 해당 플랫폼을 위해 구축되었습니다 . B) 웹에서 작업 한 Java 개발자는이 데스크탑 애플리케이션 사고 방식으로 쉽게 전환 할 수 없습니다. 이 세상의 건축은 완전히 다른 학문입니다. Flex 개발자는 Java 웹 개발자보다 GWT에 더 적합 할 것입니다.

결론적으로...

GWT는 Java 만 사용하여 빠르고 더러운 AJAX 애플리케이션을 매우 쉽게 생성 할 수 있습니다. 빠르고 더러운 소리가 마음에 들지 않으면 사용하지 마십시오. 내가 일했던 회사는 최종 제품에 대해 많은 관심을 기울인 회사였으며 시각적이고 대화 형인 사용자에게 세련된 느낌을줍니다. 프론트 엔드 개발자에게는 권투 글러브를 착용 한 상태에서 피아노를 연주하는 것과 같이 GWT를 사용하는 방식으로 HTML, CSS 및 JavaScript를 제어해야했습니다.

— 니콜
소스

나는 우리가 GWT 대신 Wicket을 선택한 이유 중 일부를 발표했다.

— biziclop

FUD의 경우 -1, 소규모 및 대규모 응용 프로그램에 사용 된 GWT에 대한 나의 경험은 부정적인 것보다 훨씬 긍정적이었습니다. 그리고 나는 이러한 "문제들"중 하나에 직면하지 않았으므로 FUD 의견입니다. 우리는 적은 노력으로 GWT 생성 위젯을 매우 복잡한 HTML 페이지에 성공적으로 포함시킵니다. 당신이하고있는 일이 훌륭하다는 것을 알고 있다면, 더 좋은 방법으로 일을하고 싶지 않다면이 "답변"을 따르고이 설명을 무시하십시오.

@Jarrod 이것들은 "문제"가 아니라 GWT의 본질에 대한 명확한 설명입니다. 관련이있는 경우, 특히 프로젝트 목표의 관점에서 부정적인 것으로 인정했습니다. 다른 경험이 있다면 자유롭게 작성하십시오. 그때까지, 입증되지 않은 유일한 정보는 GWT가 "새롭고 더 낫다"는 귀하의 주장입니다. 그건 그렇고-이 답변을 썼기 때문에 회사 (더 이상 일하지 않음)는 1 년 동안 여러 엔지니어의 작업을 포기하고 GWT없이 프로젝트를 다시 작성했습니다. 짧은 시간에.

— 니콜

@JarrodRoberson 나는 NickC에 동의하며, 당신의 경험에 대해 똑같이 자세한 글을 읽는 것이 좋습니다.

— funkybro

@NickC 프로젝트 재 작성을위한 "적은 시간 내에"GWT IMO에 큰 타격을주지는 않습니다. 기본적으로 다른 프레임 워크 나 언어로 수행 한 작업을 반복하는 프로젝트는 "시간이 덜 걸립니다".

— funkybro

사용량이 많은 대규모 전자 정부 웹 애플리케이션 (백엔드의 SOA)에 GWT를 사용합니다. 이전 UI는 DHTML에 있었지만 브라우저 호환성, 성능 최적화 및 개발 프로세스에 문제가 있었으므로 대안을 찾았습니다.

우리의 요구 사항은 다음과 같습니다

서버 부하를 최소화하는 클라이언트 측 UI 계층
브라우저 호환성
웹 기반 RIA
쉬운 성능 최적화
클라이언트 플러그인 설치가 필요하지 않으며 일반 Windows 설치에서 작동해야합니다.

우리는 GWT를 선택했으며 결코 후회하지 않습니다. 새로운 팀은 DHMTL 경험이 적었으므로 GWT의 Java 개발 프로세스가 매우 도움이되었습니다. 당신이 상자에서 얻는 것은 :

브라우저 호환성
자바 기반 개발 프로세스 및 코드 재사용
손쉬운 요청 최소화 (이미지 번들, ...)
손쉬운 공격적 캐싱 (클라이언트 측에서 새로운 앱이 완전히 캐시 됨)
모든 리소스의 손쉬운 압축 (이전 버기 IE의 js에서도 가능)
그리고 훨씬 더, 여기에 언급 할 많은

우리의 응용 프로그램은 시작할 때 하나의 요청을 서버에 발행합니다. 단점은 GWT (및 Android)가 기본적으로 디자인이 좋지 않다는 것입니다.하지만 어쨌든 자신의 모양과 느낌을 적용하면 CSS를 조정해야합니다. 또는 적절한 스타일과 테마를 쉽게 적용 할 수 있도록 다양한 컴포넌트 라이브러리를 GWT에 사용할 수 있습니다.

나에게 HTML DOM이 손수 만든 것만 큼 좋지 않다는 점은 없습니다. 이것은 결코 문제가되지 않았습니다. C ++로 개발할 때 생성 된 어셈블러 코드를 보지 않습니다. GWT에서 개발할 때 JS 코드를 살펴볼 이유가 없었으며 DOM을보고 리팩토링을 수행 해야하는 이유는 한 번뿐이었습니다.

저에게는 GWT가 RIA 개발에있어 유일한 선택이며 GWT가 밝은 미래를 갖기를 바랍니다. 다음 사명을 참조하십시오.

[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction

그러나 Google은 많은 내부 프로젝트에서 GWT를 사용하지 않으며 현재 GWT의 미래에 대한 소문이 있다고 언급해서는 안됩니다.

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC

— ChrLipp
소스