相比算法，我認為數據結構和設計模式對前端更重要，原因有三:
1)JS原生能提供的數據類型確實有限。很多時候我們用對象和數組簡單粗暴的解決問題，寫壹堆復雜的業務代碼來支撐邏輯。
比如我們要做壹個輪播，自然會想到用數組來記錄輪播圖片的列表數據。我們這裏比較時髦，用vue數據驅動視圖的思路來實現。我們需要在每次輪播翻頁的時候改變數組中圖片的順序，看起來沒問題。但是當業務比較復雜的時候，比如我們需要支持循環回放和雙向回放，就需要對數組的邊界值進行特殊的判斷，降低了代碼的可維護性。
所以如果我們換個角度想，壹開始不使用數組定義圖片列表，而是使用鏈表？問題就簡單多了。但是鏈表的數據結構不是js原生實現的，需要我們自己完成。
因此，有必要掌握常用的數據結構及其相關方法。
2)設計模式是在特定情況下對問題的優雅解決方案。我在這裏大膽而優雅。是的，壹個問題往往有不止壹個答案。
例如，我想將click事件綁定到頁面上的壹系列按鈕，並要求按鈕的內容在被單擊時彈出。壹個簡單粗暴的方法是給每個按鈕添加壹個onclick事件。假設按鈕的數量非常大或者有其他點擊事件要在這個按鈕上執行，這個方案就不那麽可行了。壹些學生想到了使用事件委托，是的，這裏妳使用了壹個設計模式，代理模式。孰優孰劣壹目了然。
我認為每個業務場景都有壹個合適且優雅的解決方案，這就是設計模式。
3)壹般來說，前端要處理的數據量和計算復雜度都不高。比如我想求壹個數組中的最大值，壹般我會直接使用數組的排序方法，而不考慮自己寫壹個氣泡或者快速行。如果真的要處理大量的數據，這個處理過程是否應該放在前端恐怕是值得商榷的。
問題是需要不斷抽象的，抽象的程度與經驗和能力成正比。