哪個Web應用程序框架？

從下面的框架列表中，您將使用哪一個開發一個豐富的Web應用程序，以及爲什麼您會選擇其他應用程序？哪個Web應用程序框架？

SproutCore的 GWT ExtJS的 GXT SmartGWT的道場/ Dijit的的Flex 卡普琴糯 Grails的

來源

2010-03-18 Fergal

什麼？沒有電梯？電梯和GWT一起美味。添加一些谷歌應用程序引擎的麪食基地的混合和重擊，你有自己的營養晚餐。 – 2010-03-18 05:15:15

Downvoting this question？這不是一個*壞問題*它只是不太可能會有任何明確的答案... – 2010-03-18 05:30:59

我同意不可能有一個明確的答案，但讓人們對這些框架的意見在一定程度上肯定是有用的。我會接受所提供的最翔實和客觀的答案。 – Fergal 2010-03-18 05:55:21

這些都是基於使用你所提到的框架，我個人的經驗。所以，是的，這是一個有點偏。因此，正如其他人說了一遍又一遍，確定您的要求和其根據人們在此提出的建議，您認爲一個符合您的要求：

GWT是太冗長eventhough我發現許多Java開發人員喜歡GWT，因爲你可以單元測試，這一切都在Java中。但我個人不喜歡它，因爲它遠非簡單。有些時候，我覺得我可以用Javascript稍微調整一下，但是對於GWT，我強制要用幾行Java代碼來完成它。
GXT現在離GWT太遠了，你會發現很難做事情，因爲GXT有自己的做法，這與GWT有很大的不同。當複雜的需求出現時，最終你會回去做簡單的GWT。噢，他們的技術支持不是很好，或者我向他們提出幾個問題時遇到了一些不好的經歷。
EXT-JS是好簡單的東西以及外觀和感覺真的很光滑。但是當事情變得越來越複雜時，你就會打起仗來。儘管我已經處理了GXT技術支持，但我還沒有處理ExtJS技術支持，因爲他們有不同的人，儘管它在一家公司，所以我不能說太多。
Flex很好，真的很好。但是對於簡單的東西來說，這又是好事。一旦事情變得更復雜，你會寫很多動作，這是不太愉快的。有很多東西可用於開箱，如果您必須使用Javascript進行編碼（如多媒體支持），則可能會遇到困難。哦，如果你正在寫一個公共網站，你必須考慮到不是太多的用戶在他們的瀏覽器上有Flash插件。
Grails，我不確定你將如何使用Grails實現RIA應用程序，因爲Grails只是另一個MVC框架，您需要在其上添加自己的RIA框架，比如您提到的框架。

來源

2010-03-18 05:05:04

你確定你已經看過GWT足以評論它的簡單性嗎？我剛剛開始使用它，實際上我很驚訝它的清潔和簡單。 – 2010-03-18 16:09:40

這些天來人們使用GWT和MVP模式，這個模式太冗長而複雜。 – 2010-03-18 21:16:22

這是嚴格見仁見智。你不會得到任何人的明確答案，因爲任何人的答案都會有他們個人喜歡的。

嘗試每一個足夠長的時間來決定哪一個最適合您（或您的團隊）的目的。

這就是說，我更喜歡GWT。其他人總是不同意我的看法。

的原因，我喜歡GWT：

你可以分享（一些）客戶端和服務器端的代碼（只要你的服務器是用Java編寫的）
GWT使得很多先進的性能功能非常簡單（如遞延JS加載，圖片組合，CSS混淆）
一家專注於單頁的應用程序，與第三方支持的地方（使用gwt-presenter庫）
這只是爲方便地添加GWT到現有的網頁，因爲它是創建一個完整的一年ge GWT應用程序
UiBinder允許您使用聲明式HTML語法編寫您的UI;如果你不想要
瀏覽器不兼容性（大部分）由GWT處理 - 你只需編寫Java代碼，並且GWT編譯它在每個瀏覽器上工作

的事情，可能使GWT不適合你：

如果您的服務器已經被寫入的東西，除了Java中，你仍然可以寫在GWT你的用戶界面，但你會失去了一些不錯的功能
使用GWT編譯時間是一個不平凡的成本 - 開發模式減輕SA很多，但它仍然是有時
正如其他人所說，GWT可以被認爲是「冗長」的問題比較簡單的JavaScript庫，如jQuery或ExtJS的

來源

2010-03-18 04:19:53

我目前工作的一個聖盃/柔性混合應用程序這比我預期的要好得多。我曾看過GWT，但當時沒有太多關於它的書，它似乎強調了我從來不喜歡的類似Swing的編程技術的利用。我同意關於全部嘗試的評論。運行他們都有的應用程序，並測量它的修改難度或容易程度。此外，工具（IDE，Maven，CI ...等）的支持也可以成爲立即生產力的重要因素。

來源

2010-03-18 04:50:58 Vinny

不幸的是，答案將是自以爲是的，GWT的最純粹的形式不是一個眼睛的糖果。這就是說，ExtJs GXT超級豪爽。我面對不斷變化的框架所面臨的一個主要問題是它們不是絕對沒有缺陷的，如果我沒有記錯的話，那麼GWT 2.0就會出現一些新的佈局缺失的CSS樣式。我試圖從最近5天開始在ExtJs/GXT中遇到問題:(框架混淆了很多東西，我將使用任何絕對健壯的框架，並給出相應的錯誤消息，儘管我沒有與其他人一起工作

來源

2010-03-18 04:54:54 questzen

我個人對瀏覽器的不一致感到厭倦，如果別人已經解決了問題，我寧願不要再這樣做，這就是爲什麼我對前端如卡布奇諾和qooxdoo更感興趣。零HTML零CSS的解決方案。

來源

2010-03-18 05:02:00 z5h

我們使用Grails這裏+ ExtJS的。由於我們試圖製作一個慣用的ExtJS應用程序，所以Grails沒有得到充分的利用，儘管在服務器端部分使用Grails而不是JSP可能是有意義的。

爲什麼選擇ExtJS：因爲它是一個非常豐富的類似GUI的Web應用程序工具包。我們的工作是替換舊的Motif GUI，所以這正是我們需要的。

爲什麼選擇Grails：因爲它可以輕鬆快速地完成工作。對於ExtJS的部分通信，就需要大量的JSON，並在Grails的是這樣的：

import foo.bar.FooBar 
class FooBarController { 
    def viewFooBars = { 
     def list = FooBar.getList(session.userId, params.foo, params.bar) 

     def result = [resultset: list] as JSON 

     response.setHeader('Content-disposition', 'filename="json"') 
     response.contentType = "text/json"; 
     render result 
    } 
}

而這甚至二，三線超過必要的...

來源

2010-03-18 13:06:41

分機GWT已經工作以及我的項目。高級支持一直很好。

但是該項目是內部使用的，它允許在一個操作系統上將部署限制在一個瀏覽器上，並且沒有努力改變Ext GWT的默認外觀或行爲。

完全在Java內部開發是一項關鍵的好處，因爲它有助於在添加功能時保持項目的可管理性。

來源

2010-03-18 15:17:21

ExtJs非常適合創建複雜的Web應用程序。這個API提供了任何你可以在webapp中想象的東西，並且在一段時間之後很容易擴展任何組件。

您可以將它插入任何後端（我們使用django或php），並在幾個不同的應用程序中重用或擴展任何組件。

您需要幾個月才能感覺舒適。恕我直言。

這就是說，lib有時對於像網站這樣的簡單用戶來說太慢了（那麼你可以使用ExtCore）。但是，當涉及到web應用程序，這不是一個問題。

我不是一個java的傢伙，所以GWT是不是一種選擇對我來說：/

希望這有助於

來源

2010-11-01 15:14:02 jujule

我建議道場。

除了提供的大量基礎架構外，Dojo 1.6也是第一個（也是唯一）流行的JavaScript庫，可以成功地用於Closure Compiler的高級模式，並且所有的大小，性能和混淆優勢都附加在它上面 - 除了Google自己的Closure Library之外，就是。

http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t

換句話說，使用道場的程序可以是100％的混淆 - 即使庫本身。

編譯後的代碼與純文本代碼具有完全相同的行爲，除了它比規模更小（平均值比平均值高25％），運行速度更快（特別是在移動設備上），並且幾乎不可能進行反向工程，甚至在通過美化器之後，因爲整個代碼庫（包括庫）都被混淆了。

只有「縮小」的代碼（例如YUI壓縮器，Uglify）可以在穿過美化器後輕鬆地進行反向設計。

來源

2011-03-10 10:32:21

哪個Web應用程序框架？

回答

相關問題