應該避免使用GWT/WebSharper還是其他抽象來編寫Javascript？

我很好奇什麼是「編譯成JavaScript的東西」的觀點，例如GWT，Script＃和WebSharper等。這些似乎是相當利基的組件，旨在讓人們在不寫javascript的情況下編寫javascript。我個人很喜歡編寫javascript（使用JQuery/Prototype/ExtJS或其他類似的庫），並將諸如GWT這些東西視爲不必要的抽象，這可能最終會限制開發人員需要完成的任務或提供最佳案例非常冗長的解決方法。在某些情況下，您最終還是會編寫javascript JSNI。應該避免使用GWT/WebSharper還是其他抽象來編寫Javascript？

更糟糕的是，如果您不知道封面下面發生了什麼事情，那麼您將面臨意外後果的風險。例如。你怎麼知道GWT正在創建閉包和管理命名空間？

我很好奇聽到別人的意見。這是網絡編程的目標嗎？

來源

2010-07-10 Francis Shanahan

雖然我個人不喜歡一種風格而不喜歡另一種風格，但我不認爲從Javascript抽象出來的這些框架帶來的唯一好處就是它。當然，在抽象整個語言的過程中，會有以前可能變得不可能的事情，反之亦然。決定使用諸如GWT之類的框架來編寫vanilla JavaScript取決於很多因素。

使JavaScript與X語言的討論毫無結果，因爲每種語言都有其優點和缺點。相反，通過採用這樣一個框架來對將要獲得或失去的東西進行客觀的成本效益分析，而這隻能由你而不是不幸的SO社區來完成。

不知道底層的問題適用於JavaScript，就像它對任何翻譯過的源代碼一樣。你認爲有多少人知道jQuery究竟發生了什麼，因爲他們試圖做一個比較，比如$("p") == $("p")，並且因此返回false。這不是假設情況，關於同樣的問題也有幾個問題。學習語言或框架需要時間，如果有充足的時間，開發人員可以理解這些框架的編譯源。

上述問題的另一個相關方面是信任。我們不斷在較低層次的抽象層次上構建更高層次的抽象，並依靠低層次的東西應該按預期工作的事實。你最後一次深入到C++或Java程序的編譯二進制文件中以確保其正確工作？我們不是因爲我們相信編譯器。例如，當使用這樣的框架時，使用JSNI回落到JavaScript並不丟臉。這一切都是用手頭的工具以最好的方式解決問題。 JavaScript，Java或C＃或Ruby等沒有什麼神聖之處，它們都是解決問題的工具，雖然它可能成爲你的障礙，但它可能是一個真正省時又有利於其他人的工具。

至於我認爲網絡編程的發展方向，我認爲有很多有趣的趨勢，或者希望能夠成功，例如服務器端的JavaScript。它至少爲我解決了非常實際的問題，因爲我們可以在Web應用程序中輕鬆避免代碼複製。客戶端和服務器端可以共享相同的驗證，邏輯等。它還允許編寫一個簡單的（de）序列化機制，以便RPC或RMI通信變得非常容易。我的意思是這將是非常好的能夠寫：

account.debit(200);

在客戶端，而不是：

$.ajax({ 
    url: "/account", 
    data: { amount: 200 }, 
    success: function(data) { 
     .. 
    } 
    error: function() { 
     .. 
    } 
});

最後，它是偉大的，我們擁有所有這些多樣性在框架和解決方案構建Web應用程序，因爲下一代解決方案可以從每個解決方案的失敗中學習，並專注於他們的成功構建更好，更快，更棒的工具。

來源

2010-07-11 02:03:22 Anurag

我的看法是，每個框架都有其優點和缺點，項目團隊在評估其使用案例之前應該對其進行評估。對我來說，任何框架都只是一個用來解決問題的工具，你應該選擇最適合的工作。

我寧願自己堅持純JavaScript解決方案，但據說我可以想到GWT會有所幫助的一些情況。 GWT將允許團隊在服務器/客戶端之間共享代碼，從而減少兩次編寫相同代碼（JS和Java）的需求。或者，如果有人將Java客戶端移植到Web UI中，他們可能會發現堅持使用GWT會更容易（當然，這可能會讓它變得更難:-)）。

來源

2010-07-10 18:52:35 eSniff

我知道這是一個粗略的過度簡化，因爲像GWT提供的框架還有很多其他的東西，但這裏是我如何看待它：如果你喜歡JavaScript，寫JavaScript;如果你不這樣做，使用GWT或卡布奇諾或其他。

人們使用像GWT這樣的框架的原因不一定就是它們提供的抽象 - 你可以使用像ExtJS這樣的JavaScript框架 - 但它允許你用JavaScript以外的東西編寫Web應用程序。如果我是一個想要編寫Web應用程序的Java程序員，我會使用GWT，因爲我不需要學習新的語言。

這是所有的偏好，真的。我更喜歡寫JavaScript，但很多人不喜歡。

來源

2010-07-10 19:04:38

JavaScript應該避免使用X嗎？無論如何！

我將從一個免責聲明開始：由於我在WebSharper開發團隊中，所以我的回答非常有偏見。我在這個團隊中的原因首先是我發現自己在編寫純JavaScript時完全失敗，然後向我的公司建議我們嘗試使用我們最喜歡的語言F＃編寫一個編譯器到JavaScript。

對我來說，JavaScript是web的便攜式組件，履行與C在世界其他地方一樣的作用。它是便攜式的，廣泛使用的，它會留下來。但我不想寫JavaScript，不過我想編寫程序集。我不想使用JavaScript作爲一門語言的原因包括：

沒有靜態分析，它甚至不檢查函數調用的參數的權數。錯字咬人！
圖書館，命名空間，模塊，類沒有或非常有限的概念，因此每個框架都發明瞭自己的（與R5RS計劃類似的情況）。（1）和（2）：JavaScript不適用於靜態分析。工具（代碼編輯器，調試器，分析器）相當差，大部分是因爲（1）和（2）：JavaScript不適合靜態分析。
沒有或非常有限的標準庫。
有許多粗糙的邊緣和使用突變的偏見。即使在無類型的家庭中JavaScript也是設計不佳的語言（我更喜歡Scheme）。

我們正試圖解決WebSharper中的所有這些問題。例如，Visual Studio中的WebSharper具有代碼完成功能，即使它公開第三方JavaScript API（如Ext Js）。但是，我們是否有成功或失敗並非真正的重點。關鍵在於，我希望能夠解決這些問題，這是非常可取的。

更糟的是，如果你不知道什麼是被窩裏怎麼回事
運行的意想不到的後果風險。例如。您如何知道GWT正在創建關閉和正確管理名稱空間？

這只是編寫正確的編譯方式。例如，WebSharper以1：1的方式將F＃lambda映射到JavaScript lambda（實際上，它從不引入lambda）。如果您提到這一點，我可能會接受您的觀點，比如說，WebSharper還不夠成熟並且測試不足，因此您不願相信它。但是，GWT已經有一段時間了，應該生成正確的代碼。

底線是強類型語言嚴格優於非類型語言 - 如果需要，您可以輕鬆地在其中編寫無類型的代碼，但是您可以選擇使用類型檢查器，這是程序員的拼寫檢查器，檢查。你爲什麼不呢？拒絕這樣做聽起來有點像我。

來源

2010-07-13 06:55:44 t0yv0

我有三個大的實際問題，我與websharper和其他編譯器，聲稱避免JavaScript的痛苦。

如果您不會很好地瞭解Javascript，那麼您無法理解使用DOM/ExtJs等Web上的大多數示例，因此您必須學習Javascript。（由於某些原因，所有F＃程序員必須至少能讀取C＃或VB.NET，否則他們無法訪問大多數關於.net框架的信息）
在任何Web項目上，您都需要一些知道DOM的Web專家， CSS裏面出來了;這樣的人願意使用F＃而不是Javascript嗎？
被捆綁到編譯器的提供者中，他們將在5年左右的時間內;我想要完整的開源代碼或者微軟支持的工具。

的4個大陽性我與這些框架看到的是：

共享型碼
擁有更少的語言程序員需要知道（JavaScript是一種真正的痛苦，因爲它看起來像Jave/C＃，但不是像他們那樣）
F＃程序員的平均質量比jscript程序員要好很多。

來源

2011-04-13 10:41:09

+1如果提到'綁定到編譯器的提供者'的問題 – 2011-04-19 14:00:35

WebSharper現在是開源的，但考慮到你寫這個時，這是一個非常好的答案。 – 2012-07-04 15:52:22

「出於某種原因，所有F＃程序員都必須至少能讀取C＃或VB.NET，否則他們無法訪問大多數關於.net框架的信息」。 FWIW，這當然不是真的。 – 2012-11-11 12:45:37

應該避免使用GWT/WebSharper還是其他抽象來編寫Javascript？

回答

相關問題