Google은 Google 웹 툴킷 (GWT)을 만들었 으며 자체 웹 애플리케이션을 빌드 할 때이를 사용하지 않습니다.

이것이 GWT가 동적 애플리케이션을 구축하기에 적합하지 않다는 것을 의미합니까? 아니면 캐싱 문제가 있습니까? 아니면 RPC 문제가 있습니까? 아니면 Google이이 기술을 사용하지 못하게하는 다른 문제가 있습니까?

EDIT: 나는 구글이 어떤 앱에서도 GWT를 사용한 적이 없다고 말하지는 않지만, 왜 광범위하게 사용하지 않는가?

먼저, 대부분의 Google 제품은 GWT보다 오래되었습니다. 새 라이브러리가 출시 될 때마다 완벽하게 좋은 제품을 다시 작성하지는 않습니다.

둘째로-이것은 실제로 제 개인적인 견해입니다-GWT는 HTML에 대한 ASP.NET (클래식)이 Javascript에 있다는 것입니다. 간단한 인터페이스에는 좋지만 복잡한 작업이 필요한 경우 약간의 고통이 될 수 있습니다.

Google의 많은 프로젝트는 Closure Javascript 라이브러리를 사용하여 작성되었습니다 . 클로저는 브라우저의 "금속"에 가깝게 유지하면서 복잡한 웹 응용 프로그램에 필요한 강력한 템플릿 및 기타 여러 기능을 계속 제공합니다.

그런 말을하는 데, 거기에 있는 GWT를 사용하는 구글 내에서 프로젝트. 애드워즈 프론트 엔드는 마음에 드는 것입니다.

당신이 말하는 것은 일반적으로 알려진 개념입니다 :

너만의 개밥을 먹어라

그러나 모든 회사가 실제로 자신의 고객이 될 수있는 것은 아닙니다. 예를 들어, Microsoft를 고려하십시오. 이전 버전의 SQL Server는 엔터프라이즈 용도로는 지금처럼 강력하지 않았습니다. 따라서 Microsoft는이를 사용할 수 없었으며 엔터프라이즈 레벨 개발을 위해 Oracle 또는 DB2와 같은 것을 사용해야했습니다.

첫 번째 요점은 모든 사람이 자신의 개밥을 먹지 않아야한다는 것 입니다.

두 번째 요점은 Google이 GWT를 사용하지 않는지 어떻게 알 수 있습니까? 결국, 그것이 생산하는 것은 JavaScript이며 JavaScript를 사용자 정의 할 수 있으므로 GWT의 사용법을 나타내는 어떤 종류의 서명도 포함하지 않습니다. 즉, 웹에서 거의 모든 플랫폼을 구성하여 언어, OS, 웹 서버 등을 사용하여 만든 언어를 아무도 이해할 수 없도록 구성 할 수 있습니다.

예를 들어 ASP.NET으로 구축되고 IIS에서 실행되는 사이트에는 HTTP Response 헤더 필드 X-Powered-By: ASP.NET또는 이와 유사한 것이 있습니다. 그러나 IIS에서 이러한 헤더를 쉽게 삭제할 수 있습니다. 또한 ASP.NET으로 만든 웹 사이트에는 일반적으로 .aspx파일로 끝나는 경로가 있습니다. 그러나 URL 재 작성 개념을 사용하여 확장없는 URL로 쉽게 변경할 수도 있습니다.

따라서 강조하고 싶은 두 번째 요점은 Google이 GWT를 사용하지 않는다고 확신 할 수 없다는 것입니다 . 아마 그렇습니다.