PHP 和 Go 作為技術堆疊。

首先，讓我先談談為什麼我比其他著名的 JAVASCRIPT 技術堆疊更喜歡它的所有原因。

• 我討厭「Javascript 無所不能」的趨勢.. 是的.. Javascript 在這一點上幾乎可以做任何事情.. BUTT，這樣做有效嗎？

• 讓我們舉一個非常密集的 CPU 密集型任務的範例。這是模擬 CPU 密集型任務的程式碼範例。讓我們看看 Javascript 是如何執行的。

原因 1：Javascript 在處理 CPU 密集型任務時表現不佳！

setTimeout(function() {
    console.log("Hello world")
}, 1000)

const startTime = Date.now();
while (Date.now() - startTime < 3000) {} //Simulating a long CPU intensive main thread task..

console.log("End")

• 那麼，我們這裡有什麼？我，作為 JAVASCRIPT 的用戶，希望在 1 秒後看到“hello world”打印出來......你猜怎麼著。事實並非如此。 3秒後它會吐出「hello world」..

• 為什麼會發生這種情況？為了理解這一點，我們需要了解瀏覽器和 Node js 中的事件循環是如何運作的。簡單來說，事件循環同時檢查呼叫堆疊和回調佇列。一旦計時器完成 1000ms，我們傳入 setTimeout() 的回呼函數就會進入回呼佇列。

• 但是你猜怎麼著...當計時器完成工作時，調用堆疊不為空..它仍然忙於執行我們編寫的3 秒CPU 密集型任務（是的..它是一個模擬. .不是一個現實世界中的愚蠢程序，需要3 秒才能完成其打算做的任何事情）。

• 所以，回呼佇列和微任務佇列中的回呼函數將會挨餓。 . 糟糕的回呼函數。他們只有在 3 秒後才有機會進入呼叫堆疊。這就是為什麼我們看到“hello world”在 3 秒後被列印出來，即使我指定了 1000 毫秒。

是的。這是我從網路上下載的事件循環的隨機圖像。很酷的圖像。

讓我們使用一個執行相同操作的 Go 程式碼..

package main

import (
    "fmt"
    "time"
)

func main() {
    time.AfterFunc(1*time.Second, func() {
        fmt.Println("Hello world")
    })

    // Simulating a long CPU-intensive main thread task
    startTime := time.Now()
    for time.Since(startTime) < 3*time.Second {
    }

    print("End")
}

這裡，「hello world」在 1 秒後被印出來..如何？因為 AfterFunc() 運行在它自己的 GoRoutine 上，它與主 GoRoutine 沒有任何關係..

原因2：我個人討厭客戶端渲染。

• 我們來談談reactJS。它將 javascript 元件推送到客戶端，並用很多東西塞住客戶端的喉嚨，以至於客戶端開始節流..

• 想像一下，一台低階 PC 要求一些靜態 HTML 文件，然後你會得到一堆 React 元件的垃圾。客戶端會有什麼感覺？它變得很慢..瀏覽器必須解析 javascript，執行虛擬 DOM，從中產生 HTML..還有什麼..

• 瀏覽器正在完成伺服器必須做的所有工作..

• 還記得網路的自然流動嗎？

• 先載入 HTML，然後才載入 javascript？為什麼？為了讓初始繪製盡可能快..還記得我們在 HTML 文件頁腳中載入 javascript 的日子嗎？

• React 只是讓整個流程顛倒了。

• 結果，客戶必須長時間盯著空白螢幕..

原因都說了..

• 我正在選擇兩種在自己的世界中閃耀的語言..

去

• 最讓我印象深刻的是，Go 是一種編譯語言，而且是靜態類型的.. 你可以盲目地說，Go 超級快，比 javascript 快很多..

• 它有內建的輕量級線程，稱為“GoRoutines”，它比實際作業系統線程快得多，因為 Go 線程是輕量級的。

• Go 可用於建立 RESTful 端點或可用於任何後端服務..

• 但是，我不能用 Go 來進行 SSR。 PHP 的亮點就在於此。在我的堆疊中，Go 將大量用於 CPU 密集型 API 或任何後端服務。

PHP

• PHP 是我用過的最好的 SSR 工具。簡單且非常直接。為每個客戶端建立一個流程..使得速度有點慢。但這些進程仍然是彼此獨立的，不像線程共享相同的進程內存空間，並且不利於競爭條件和許多其他線程相關的問題..

• 在我看來，PHP 也與 Web 緊密耦合。直接開箱即用的超級全域變量，如 $_GET、$_SERVER 等...這使得一般情況下使用 Web 變得更容易。

• PHP 中的會話管理太好了.. 語言本身自帶.. 並且管理會話太容易了..

結論：

• PHP 可以純粹用於 SSR。和會話管理。我不能相信 PHP 可以完成 CPU 密集型任務，因為它很糟糕。為什麼？它是一種解釋性語言，而且也不是多線程的..

• 因此，我將所有 CPU 密集型呼叫卸載給 Go。

• 兩個世界中最好的.. PHP 用於SSR，這樣客戶端就不會受苦，並且可以執行CPU 密集型任務，因為它可以很好地實現並發...

以上是PHP 和 Go 作為技術堆疊。的詳細內容。更多資訊請關注PHP中文網其他相關文章！