今年 2 月，微信團隊針對小程序登錄和用戶信息獲取進行了一次接口調整，這一舉動史無前例地撼動了幾乎所有小程序開發者，在小程序社區產生了不小的反響。

作為接入方，本文將從產品和技術兩個角度，討論微信新授權登錄機制的設計目的、適配方案以及對產品帶來的影響。

最近看的代碼 yield 比較多，上次看到這么多 function* 還是在 koa1 時代，腦子中滿是 yield 和 next，而我自己用這個用的較少，就水個文章學習一下。

原文地址: https://github.com/vorshen/blog/blob/master/yield/index.md

原文地址：https://github.com/vorshen/blog/blob/master/callable-object/index.md
今天我們來聊一聊可調用對象，從底層來說，調用是指新建了棧幀，寄存器指向發生了變化。
從直觀上看可以加 () 執行的就是可調用對象！比如我們熟悉的 javascript 中函數。

或許在生活中大家都討厭定時器，比如周一早上的鬧鐘、承諾老板第二天一早給報告的 deadline；但是在代碼的世界里，定時器扮演著不可或缺的角色：定時任務、超時判斷、幀同步等等。
那定時器的本質是什么？我們使用的定時能力背后又暗藏著什么玄機，請繼續往下看。

原文地址

在 《前端資源加載失敗優化》文章中，我們聊到了前端資源加載失敗的監控方式，以及資源加載失敗時的優化方案。通過對加載失敗的資源更換域名動態重新加載、同時確保最終代碼正常的執行順序，從而有效地減少了因為資源加載失敗導致的網頁異常。到此，資源文件成功加載了！但加載到的是否就是正確的資源呢？是否會在加載過程中被半路劫持？此時又該如何監控？是否還能做更多的防護措施呢？本文將逐步進行分析。

原文地址

Web 項目上線后，開始開門迎客，等待著來自大江南北、有著各式各樣網絡狀態的用戶蒞臨。在千差萬別的網絡狀態中，訪問頁面難免會遇到前端資源加載失敗的情況，占比或許不高，但一遇到，輕則頁面樣式錯亂，重則白屏打不開，影響用戶體驗感受，緊急情況下甚至影響了用戶的工作，屬于非常嚴重的問題。本文將從如何監控加載失敗、加載失敗如何優化、始終加載失敗又該如何處理等問題逐一分析。

重學 HashTable

HashTable，又稱散列表，一說到這個，可能很多人第一反應就是時間復雜度 O(1)！那是不是時間復雜度永遠都是 O(1) 呢？別人說所得 hash 碰撞又是什么呢？
其實 HashTable 還是有很多細節的，這片文章就帶大家梳理一下 HashTable 的細節，最后一起拜讀一下 v8 和 redis 的 HashTable 相關源碼。

0. 背景

之前在這篇文章里說過做了個 SSR 《論如何像素級直出具有 14W 行代碼量的前端頁面》，本以為今天順順利利，高高興興。

沒想到項目放到線上后，隨著請求量的增多，卻感覺到首屏速度越來越慢，并且是在持續性地變慢。而且在發布完后（也就是容器重建了），耗時又陡然降下來了。

0. 前言

騰訊文檔列表頁在不久前經歷了一次完全重構后，首屏速度其實已經是不錯。但是我們仍然可以引入 SSR 來進一步加快速度。這篇文章就是用來記錄和整理我最近實現 SSR 遇到的一些問題和思考。雖然其中有一些基礎設施可能和騰訊或文檔強相關，但是作為一篇涉及 Node、React 組件、性能、網絡、docker 鏡像 、云上部署、灰度和發布等內容的文章，仍然可以小小地作為參考或者相似需求的 Checklist。

編譯的速度與激情：從 10mins 到 1s

導語：對于大型前端項目而言，構建的穩定性和易用性至關重要，騰訊文檔在迭代過程中，復雜的項目結構和編譯帶來的問題日益增多，極大的增加了新人上手與日常搬磚的開銷。恰逢 Webpack5 上線，不如來一次徹底的魔改～