GWT vs. ScriptSharp優點和缺點

我們已經確定，要維持大量JavaScript，我們需要編寫全面的「單頁」JavaScript應用程序，這對我們來說太困難了。依靠編程公約仍然讓我們想要......特別是在重構領域。對於剛接觸這些項目的開發人員來說，他們發現改變任何東西非常困難，因爲他們不相信他們知道還有哪些人真正依賴於組件（易於處理「找到所有參考文獻...」，並強烈地編碼訪問級別鍵入語言）。GWT vs. ScriptSharp優點和缺點

我們一直在玩GWT，但我們的開發人員之一想要使用Script＃。我們已經是一家基於微軟的商店，並且使用C＃完成我們所有的服務器端工作。

我不認爲java是GWT的顯示屏，因爲它與C＃非常相似。

我最初關注的Script＃主要圍繞支持和文檔。

一方面我們有谷歌，另一方面......「一些老兄」。腳本＃也是封閉源代碼......所以如果開發人員停止工作，我們是S.O.L.嗎？我也覺得GWT有更多的文檔和社區支持。

不管怎樣，你有沒有使用過？思考？優點缺點？

（將在通頭這一關：問題不在於是否有一個編譯器去不去......問題是哪個編譯）

類似，但不同的問題：

What advantages can ScriptSharp bring to my tool kit?
Should I use ScriptSharp

來源

2010-07-21 Steve

我已經使用GWT好幾年了。我從來沒有聽說過Script＃，所以我只會告訴你爲什麼你應該堅持Google解決方案。

積極開發。谷歌有一個付費團隊的工程師，既積極修復缺陷，又致力於新功能。我目前正在與其他開發人員討論如何實現GWT的新功能。
大型機構。谷歌已經投資這個項目並用它來實施大規模的解決方案。換句話說，他們正在吃自己的狗糧。他們有既得利益，不讓它停滯不前或過時。
社區。有很多人在加入插件/第三方/ etc等庫和API上工作，與香草發行版一起使用。這些人也在測試，歸檔和修復缺陷。
兼容性。 GWT可以使用瀏覽器可以執行的任何操作。還有針對jQuery和其他主要JavaScript庫的插件，這使得在使用JavaScript時管理項目的複雜性變得更容易。
打開。你自己觸及了這一點。

請注意，我沒有涉及到語言選擇問題。我認爲這與你所描述的水平無關。請記住，第一次遇到Script＃的限制或路障時，由於您和我描述的事情，您將很快陷入停滯狀態。

當然，我建議GWT只是因爲記錄。

來源

2010-07-21 21:19:07

有趣的沒有人發佈反駁。 – Steve 2010-07-22 18:09:41

我給你的答案信用，因爲它看起來不像其他人會回覆，我想感謝你的時間。再次感謝。 – Steve 2010-07-22 23:44:45

我使用腳本＃和以前使用過的GWT。他們真的是兩回事。 GWT旨在提供客戶端和服務器解決方案，RPC和其他一切。它肯定更成熟，你可以更快地開始複雜的應用程序。簡而言之，在野外有更多的代碼和例子。

但是，我認爲，如果你是開發者都是服務器端和客戶端，使用兩種不同的語言和兩個不同的平臺可以是非常，非常麻煩。這就是爲什麼我轉移到Script＃的原因。我所做的一切都是在C＃和Visual Studio中，它使我的工作效率更高。如果你沒有利用GWT的後端功能，那真是太過分了。

我喜歡把腳本＃如JavaScript寫在C＃2.0規範（它是）。它完全是客戶端，任何映射都必須手工完成（儘管自動映射可以廣泛使用）。它支持Javascript和jQuery非常完整，實際上它非常完整，這讓我感到驚訝。它似乎是在做的比現在少。

angryundead的點是有效的，特別是關於社會和開放性。雖然這對我來說有點刺，但我真的很喜歡使用Script＃。我不必更改IDE，也不必查看如何在Java中進行操作等。jQuery有一個巨大的插件庫，將它們綁定到Script＃中非常容易。您只需拋出幾個對象來表示屬性，將它們標註爲「已導入」並讓它返回null。在您的代碼中，您將一個對象作爲插件投入使用，並且您的輸出完全與在Javascript中顯示的一樣。腳本＃不關心/知道插件的工作方式。

不要讓Script＃缺乏社區支持來欺騙你。雖然這是一個問題，但該產品非常成熟並且功能豐富。如果您的開發人員使用C＃/ VS，爲什麼要讓他們爲客戶使用單獨的程序？我發現這是一個巨大的生產力衝擊。

另外，自從使用C＃以來，我在Javascript中變得更好。 Javascript的許多問題都是缺乏您不需要的語言功能，但在大型項目中，這是使其易於管理的唯一方法。

來源

2010-07-27 20:48:12

嘿！感謝您花時間回覆！爲了記錄，我確實在腳本＃中給出了確定，但我確實（並且仍然有）有關注和保留。但是在一天結束的時候，我覺得像木匠這樣的開發者需要喜歡使用他們的工具......而且我不會強迫GWT壓倒任何人的喉嚨。知道其他人使用腳本＃來取得良好效果令人欣慰。 – Steve 2010-07-28 01:09:52

腳本＃*擁有大量（？）用戶社區，我相信：微軟內部的開發人員創建了使用MVC分發的控件。當然，這個社區還是比GWT小，我不能等到它開源。 – 2010-10-02 18:35:47

我很好奇Script＃automapping。它是如何完成的？由於這條線索是古老的，我並不真正期望得到答覆，但希望是永恆的。 ;） – 2010-10-02 18:39:26

如果你想用C＃爲你的JavaScript代碼，我建議SharpKit。它與其他C＃解決方案有一個feature comparison。同樣作爲其應用的一個例子，您可能想要查看使用SharpKit創建的CodeRun。

來源

2011-01-13 15:24:47 orad

有趣！感謝您的鏈接！ – Steve 2011-01-14 01:19:19

除非你正在構建一個完全在瀏覽器應用程序，我的偏好是腳本＃，因爲它堅持自己最擅長的 - 編譯C＃來的JavaScript - 而不是試圖成爲一個全面的客戶端/服務器工具包。網絡範例很快發生變化，並且將項目投資到GWT中可能會讓您產生希望沒有的開銷或技術承諾。但我想補充一點，它確實取決於您正在嘗試構建的Web應用程序或Web體驗的類型。

就個人而言，我已經非常熟悉的jQuery，WCF和現在開始直接使用新的HTML5功能。 Script＃是完美的缺失peice，因爲我可以很容易地繼續使用jQuery和WCF，並且我不需要經歷轉換或整合GWT的範例或需求的麻煩。另外，在UI的構建方面，你可能會考慮我最近開源的Sharp UI，這使得在jQuery + Script＃設置中構建可重用控件變得更加容易。

來源

2011-03-26 06:21:52 DuckMaestro

GWT vs. ScriptSharp優點和缺點

回答

相關問題