大家好！今天，我想就大家熱議的 JS0 和 JSSugar 主題分享我的想法。我認為，這其中存在一定的危險，為數十億網站使用者潛在隱藏著危險。現在我將嘗試解釋我的意思。
你可能不喜歡我的觀點，拜託，dev.to 上有評論，我會盡力回答所有問題。
也許我誤解了什麼或在某個地方犯了錯誤，但我會盡力解釋。
簡而言之，今天的 javascript 不是用越來越多的功能來擴展功能，而是需要專注於使其更容易被使用者接受。就像，今天所有開發人員編寫的程式碼都會經過 typescript、webpack 和一堆其他層，那麼當開發人員編寫更少的程式碼時，為什麼不在 ecmascript 的未來版本中應用這種簡化邏輯呢？例如，設定這樣一個願景作為標準，我們需要像 lodash 或 jQuery 一樣創建函數（例如 forEach），而不是擴展，因為它已經很複雜了。
例如，有JS0，它會針對這個一切都編譯的環境，讓一般開發者有條件地使用forEach而不是for。
所以，現在這種方法出現了嚴重的問題。似乎寫的是“不是為了速度”，但事實上，每個曾經在基準測試中比較過 JavaScript 程式碼速度的人都明白我的意思。
是的，現在是時候繼續練習了：
代碼#1
const a = [1,2,3,4,5]
a.forEach((e)=>{
if(e === 4){
console.log(e)
}
})
代碼#2
const a = [1,2,3,4,5]
for (let index = 0; index < a.length; index++) {
const e = a[index];
if(e === 4){
console.log(e)
}
}
結果：
現在讓我們再舉一個例子：
代碼#1
const a = [1,2,3,4,5];
const b = a.map((e)=>{
return e + 1;
})
代碼#2
const a = [1,2,3,4,5]
const b = [];
for (let index = 0; index < a.length; index++) {
const e = a[index];
b.push(e + 1)
}
結果：
結果是基於網站 https://jsbenchmark.com 的資料。
所以，我的意思是，如果我們想像從TC39（技術委員會）和整個開發者社群來看，當我們創建lodash 和jQuery 函數時，建議想法的主要向量將朝這樣的方向發展，而這將成為ECMAScript 中的標準，然後就會出現像forEach 這樣的函數，它不會改變速度，但實際上會減慢應用程式的速度。這當然值得思考。
在這裡，即使在官方幻燈片中（鳥飛走了），它也顯示了向量應該移動的位置，這是事實，方便用戶。
而且方便使用者使用快速站點，而不是滯後拖沓，而是讓開發者「更有表現力」。
因此，我希望當這突然成為標準時，此類功能不再處於最前沿。 SOLID、DRY 和其他原則已經減慢了現代應用程式的速度，現在他們正在將其作為標準。
當然，本文的靈感來自於我使用 js-framework-benchmark 儲存庫的經驗，在我看來，這非常清楚地說明了為什麼速度在當今如此重要。事實上，人們希望網站載入速度更快——這是事實。如今，大多數現代流行的框架和函式庫實際上都很慢。甚至在某些人看來，速度是垃圾，但事實並非如此。如果你把所有東西放在一起，那麼經過這樣的“優化”，Web 應用程式的運作效果會差好幾倍。因此，我認為是這樣的。
今天出現這樣的想法真是太酷了。它們推動了 JavaScript 和所有 Web 程式設計的發展，但也有一些客觀的因素，例如速度，也不應該被忽視。
以上是JSSugar 和 JSre 的新概念如何減慢網站速度的詳細內容。更多資訊請關注PHP中文網其他相關文章！
