帶有Socket.io的異步模塊加載（AMD）

Question

我正在開發一個Web應用程序並使用Socketio測試WebSocket等一些事情。目前我正在考慮像Socketio這樣的解決方案。它工作正常，我可以加載JavaScript文件，並用「新功能（）」（安全性？）解析它們。如果我用「普通」（使用腳本元素）加載文件，性能會更好嗎？

system.create.script(['rg.observable', 'rg.route', 'rg.bindings.*', 'rg.utils.*'], function() { 

    var bind = function(node) {} 
    return bind; 

}); 

感謝

Answer 1

TD;博士，我真的不認爲這將值得在上面花時間。

問關於性能，我真的說你必須在你的生產環境中嘗試它。

移動部件太多，因此在一種情況下每個移動部件可能會更快。首先有不同的瀏覽器，在不同的地方每個瀏覽器可能會更快或更慢。然後，根據瀏覽器和網絡支持，socket.io具有不同的傳輸方式（到處都不支持網絡套接字）。然後是可能具有高或低帶寬或等待時間的客戶端網絡。此外，服務器上的負載和服務器的數量可能會影響哪個更快。

但是從我的經驗（未盡管有很多），這是它的外觀：

如果你的應用是足夠小，我給你的建議是，僅僅編譯和壓縮你的requirejs模塊集成到一個或兩個文件，只是只需通過普通的http服務即可。在大多數情況下，它應該比動態加載socket.io更快，因爲您必須等待socket.io腳本下載並執行，等待socket.io傳輸設置（握手和東西），然後動態解析依賴關係並在那裏發生瀑布效應。

但是，如果你有一個包含很多模塊的巨大應用程序，並且你不想在開始時加載所有的應用程序（假設用戶不會在每次加載時都使用它的所有功能）可能認爲這可能值得研究。但差異只會是有一個websocket連接（讓我們忽略其他socket.io傳輸，因爲他們也使用http）vs 2或3（比這更多，這意味着你做錯了！）http請求。

從技術上講，如果你使用http保持活動，那麼他們都應該採取相同的時間，假設你有正確的設置，因爲瀏覽器保持http連接存活一分鐘或更長時間，所以你不會創建新的所以它會類似於websocket連接。現在，如果你使用SPDY，那麼使用socket.io的速度可能會更慢，因爲它只是額外的開銷。

現在談論的是一個很好的和高性能的動態加載模塊，你應該看這個談話：Malte Ubl & John Hjelmstad: A novel, efficient approach to JavaScript loading