不是的，后端通常使用多線程來解決耗時操作，一個耗時操作只能阻塞一個線程，其他線程還可以處理其他的請求。這樣后端可以采用同步編程的方式，前面的代碼肯定在后面代碼之前執(zhí)行，后面代碼可以用前面代碼的結(jié)果，邏輯上比較清晰。
但前端一個頁面只有一個ui線程，沒法多線程，耗時操作會阻塞整個瀏覽器頁面。所以對于耗時操作，前端不能用同步的編程方式，只能用異步編程方式，用回調(diào)函數(shù)，層層嵌套的回調(diào)函數(shù)造成回調(diào)地獄，非常難以閱讀和維護(hù)。所以前端逐步發(fā)展出對付異步編程的方法，最早的是Promise和Observable，后來的async/await，讓異步代碼看起來像是同步，但只是偽同步，代碼還是比后端的真同步難寫。
雖然前端沒有多線程的同步互斥問題，但總的來說，異步代碼總是比同步代碼難寫。
前端js異步編程也有一個好處，只用很少的線程，并發(fā)量大的時候效率更高，引起線程切換也很耗資源。所以后端也引進(jìn)了異步編程，比如nodejs，還有playframework2也是異步的，利用了promise或者java8中類似promise的機(jī)制。
                            

前端的JS解釋引擎只有一個線程，相當(dāng)于后端的主線程，其余線程均由瀏覽器進(jìn)行實現(xiàn)，并暴露相應(yīng)的API給JS執(zhí)行引擎，這些API通常要求JS綁定一個函數(shù)，以便回傳結(jié)果。事實上，JS代碼通常不會全程運(yùn)行，而是函數(shù)綁定的事件發(fā)生之后，將函數(shù)語句放到調(diào)用棧里逐條執(zhí)行。至于孰難孰易，聽說后端比較難咯。