我正在考慮在一個主要的內部Web應用程序開發項目中使用GWT,即在我眼中主要的優勢是交叉編譯爲Javascript,這將(至少在理論上)幫助我的團隊縮小技術堆棧的大小一個。何時不使用Google Web Toolkit?
但是,在被燒燬之前(像大多數開發者一樣),我希望聽到程序員確實在GWT中使用它,這會妨礙或限制它在某個問題域中的使用。
您何時不推薦使用GWT,爲什麼?
我正在考慮在一個主要的內部Web應用程序開發項目中使用GWT,即在我眼中主要的優勢是交叉編譯爲Javascript,這將(至少在理論上)幫助我的團隊縮小技術堆棧的大小一個。何時不使用Google Web Toolkit?
但是,在被燒燬之前(像大多數開發者一樣),我希望聽到程序員確實在GWT中使用它,這會妨礙或限制它在某個問題域中的使用。
您何時不推薦使用GWT,爲什麼?
我沒看過在Jamshid提供的鏈接所有的評論,所以這可能是有解決...
如果你想建立的東西更接近傳統的Web應用程序(即Web 1.0的)以提交的頁面和表單的概念爲中心,那麼GWT將成爲一個障礙。但是,如果你想建立一個更豐富的界面,更像是一個桌面應用程序的東西(即Web 2.0的),然後我發現GWT是漂亮的一對夫婦的原因:
這就是說,GWT並不完美。試圖與第三方JavaScript庫集成幾乎沒有任何痛苦,並且通過maven和eclipse實現它的工作方式給我帶來了一些麻煩。如果你真的走了GWT,我強烈建議你看這個演示文稿 - Google Web Toolkit Architecture: Best Practices For Architecting Your GWT App。
自2011年以來,我一直使用GWT。任何技術都有其優點和缺點。到目前爲止,主要的好處是,如果你有一個擁有強大的Java技能的團隊(甚至可能是與Swing合作的開發人員),那麼GWT是一個平滑的步驟。它會更加熟悉,並且可能與其他技術相比,您可以更快地完成工作(起初)。 現在,你說它是一個「主要的內部web應用程序」,所以要考慮到編譯時間是GWT中的一個大問題。請參閱Vaadin的GWT報告https://vaadin.com/gwt-report-2012-portlet/download/1150559483/Future-of-GWT-Report-2012.pdf 所以,我相信只有在使用GWT描述的場景纔有意義。
對於那些想要關閉它的人來說,這真的是主觀的和議論性的嗎?要問GWT是否比其他人更適合某些問題,這不是一個公平的問題? – 2011-01-20 18:09:30