源代碼的大小，實際，理論和荒謬

我一直在寫JavaScript的很多年後，當它完全不酷。源代碼的大小從來沒有超過1萬行，這是瀏覽器兼容性的極端和惡夢。源代碼的大小，實際，理論和荒謬

然而在過去的五年中，JavaScript已經被證明是開發許多內部工具，概念驗證項目和複雜的Web應用程序的有效語言。隨着源代碼的大小也擴大了，一個持續2年的內部應用程序剛剛跨越了12萬行代碼，刪除了空白行，並{在同一行上。作爲一個.js文件，它是5.5MB。在過去的一個月中，我們注意到Chrome中的開發工具的響應速度突然下降，有時甚至無法使用，有時候開發工具對焦點離開標籤時彈出「無響應」警報的小型服務器沒有任何作用。我們把它放到代碼大小。

我想知道的是什麼是在 ECMAScript代碼大小的限制？
在跨瀏覽器的合理客戶體驗方面是否存在實際限制？
單個瀏覽器對源代碼大小有上限嗎？

內部應用程序並沒有處於我們想象的最佳實踐的想象範圍之內，如果它的工作是重要的話，如果錯誤可以通過前端解決，他們可以被忽略。用這種方法，一個應用程序有一個主要的對象，有不計其數（猜測1000+以上）的原型。

在對象原型方面有多少太多？
當性能開始顯着降低時，有沒有一點可以降低？
如果可能的話，那些有大量代碼庫經驗的人，請回答你自己的做和不做？
最後，通過大型項目，可以做些什麼來提高Chrome中的調試性能（而不是重寫）？或者是否有更好的調試器（FireFox，IE或？）適用於大型項目？

在此先感謝，我不確定這裏是否允許這樣一個複雜的問題，如果太多，我會削減它。

來源

2015-09-13 Blindman67

你可以在不同的瀏覽器上運行基準嗎？可能相關：http://www.pixeldonor.com/2014/mar/30/performance-ecmascript-6/（儘管提到的速度差異是幾％％）。 – usr2564301

代碼大小沒有正式的限制。是的，在實際情況下它取決於特定的瀏覽器（或者它的JS引擎是準確的）。

在我們的項目中，我們有非正式協議不超過1Mb的JS。此外，我注意到，如果JS在一個標籤中使用的內存超過30Mb，則性能會顯着下降。有時我碰到了字符串數組中的損壞值。所以最好的解決方案是根據請求加載需要的對象並在使用後放下它們。

你有沒有試過把5,5Mb這樣龐大的文件分成幾個獨立的文件？維護它會更容易。

來源

2015-09-13 09:39:05

是否有理由選擇1Mb限制，還是任意的？ – Blindman67

這只是我們項目的實際觀察。如果代碼超過這個大小，我們需要分析原因並優化它。也許這是項目的特點 - 我們在客戶端沒有沉重的邏輯。 –

大型項目從未打算成爲一種快速的內部工具來幫助創建內容，這非常有用，隨後隨着單個項目需求的增長而增長。有一個主要的削減和斜線，證明是一個噩夢的惡夢，所以我們現在只補充。爲了緩解錯誤，我們添加了一個自定義腳本工具來使用功能，這在減少代碼增長方面起了很大作用。 5.5Mb從不加載，該應用程序分散在50個.js文件，一些第三方。所有加載在同一時間，除web工作人員3文件。 – Blindman67

源代碼的大小，實際，理論和荒謬

回答

相關問題