不就一個下拉選單,是能有多難?
一顆下拉選單,我手刻了八個版本才勉強能用,後面還排著十一版沒動。這篇講每一版壞在哪——Portal、鍵盤、ARIA、輸入法、手機、螢幕閱讀器,以及為什麼一個人重構跟一群人重構,難的完全不是同一件事。
共 156 篇
一顆下拉選單,我手刻了八個版本才勉強能用,後面還排著十一版沒動。這篇講每一版壞在哪——Portal、鍵盤、ARIA、輸入法、手機、螢幕閱讀器,以及為什麼一個人重構跟一群人重構,難的完全不是同一件事。
一個人用 Vibe Coding 做出金流、SEO、三個自製瀏覽器引擎都齊全的字幕產品,完成度高到不像 side project。但 1024px 的硬地板、寫死的多語系、沒清理的暫存檔,缺的剛好都是不好玩的那些。
多語系的痛不在裝哪一套套件,而在 key 誰命名、字誰擁有、翻譯跟不上 sprint 怎麼辦。這篇把 i18n 治理拆成命名、擁有權、流程、在地化、政治五層,越往下工程越管不到,也越決定它會不會爛掉。
從全域 CSS、預處理器、BEM 到 CSS Modules、CSS-in-JS、Atomic CSS 與 Zero Runtime,每一代方案都在解作用域、複用性、可維護性這三題。這篇講每一代解掉什麼、留下什麼代價,以及不同專案型態該怎麼選。
被邀請到 Vue Taiwan 小聚分享「來造一個下拉選單的輪子」。四十分鐘我把程式碼整個拿掉,只留觀念,因為真正想講的那件事根本不適合當演講標題。這篇記錄當天的取捨、埋的橋段,還有另外兩位講者。
Refresh Token 難的不是流程,是流程跑起來之後的那些鬼故事:token 放哪會被 XSS 端走、跨分頁併發怎麼把使用者踢出去、長連線與登出的時序怎麼排,還有為什麼一用 SSR 就得全部重做一次。
前端打包完成後,環境變數就寫死在產出檔案裡,不像後端可以重啟切換。這篇講為什麼「動態介接環境變數」在前端不成立,以及 runtime config 這個解法的代價。
登入系統是使用者對產品的第一印象。Auth0、Cognito、Firebase 這些工具省時省力,但要細緻化 UI Flow 時就會被 API 和架構綁住。
工程師背景的我想找開源的 UI 設計資源來加速,結果發現設計圈的開源遠不如工程圈蓬勃。這大概也解釋了為什麼「造輪子」在設計端這麼普遍。
陳述型的技術文章沒有「精華感」,也沒有演算法喜歡的關鍵字,不容易飄出去。但這系列會是踩過無數坑的紮實經驗談。
開一個前端基礎建設的篇章。每篇長度不均,還會加一點幹話,不會到部落格的複雜度,但盡量交代前後文。
Monorepo 有很多流派:主框架放 root、共用放 root、或是 root 乾乾淨淨。我偏好切分清楚的那種,每個 package 都有獨立的存在價值,代價是比較麻煩。
webpack 怎樣都不肯把 require 轉成 __webpack_require__,我丟給 Claude Code 查,燒到 token limit 還沒解決。自己查半小時就找到答案:package.json 的 type 設成 module。
CommonJS 與 ESModule 是天生不對等的兩種實作,轉換工具解決不了。這篇講 Node.js 生態的歷史包袱,以及為什麼這塊連 LLM 也幫不上忙。
AI 切版切得好不好,取決於設計師 Figma 的品質。說 AI 切得很棒只有兩種可能:你的設計師功力高超,或是你根本沒有設計稿。
tailwind 幾乎成了 Atomic CSS 的標準,但它跟 UI Library 其實不太合:無法動態拆 CSS Chunk、掃描原始碼需要曝露、變數架構更隱晦。
UI Library 卡了兩週都在調架構,Primitive UI 的 API 設計常常撞到底層盲點。測試案例動不動比原始碼大兩三倍,維護難度又更高。
設計師開始主動要求導入 Storybook 了。導入失敗多半敗在不重視元件庫迭代;而 .stories 檔案其實也是給 AI 很好的 Context。
除了 React 之外的框架都在走 signal 的心智模型。但事實證明,成功的產品不需要優秀的工程實作,它需要的是市場聲量和穩定。
Primitive UI、Atomic UI、Headless UI 講的都是同一件事。原子化把樣式控制權還給你,但版本管理、依賴共用、權重管理這些問題也一併曝露出來。
越熟悉 Chakra UI 的底層,越覺得它的抽象化是門藝術。真正驚奇的不是 Chakra 本身,而是 Zag、Ark、Park 這三套底層的抽象技巧。
React 更新了,React 19.2 ! 其中我最在意的功能莫屬 useEffectEvent 。 一直以來 react 在下傳 function 時要去掛勾 useEffect 常常造成不必要的更新,這不是用 useCallback
Select、Dropdown、Tooltip、Modal 都建立在 Portal 上。點背景要不要關、撞到邊界要不要換邊、內容過多怎麼滾,每個邊際問題都得處理。
前端打包是最難學又最不容易被看到的技能。大部分人只是把插件爽快加上去,卻沒想過 pipeline 裡發生了什麼,這其實是在疊技術債。
PM 在驗證需求寫「禁止特殊符號」時我最害怕。到底什麼算特殊符號?白名單還黑名單?鍵盤上看得到的才算?emoji 算不算?
中文怪物的答題 App 在啟動前一刻卡在系統更新。這正是網頁應用程式和原生應用最大的差別:版本的兼容能力。
各種 Icon 方案我最喜歡 SVG。這篇講怎麼把 SVG 文字直接 mount 到 HTML、用 currentColor 控制顏色、用 em 讓尺寸繼承 font-size。
做 Dialog 一定要實作 Portal,因為 overflow 這個天坑連 fixed 都躲不掉。這篇也講定位為什麼一定要用絕對位置,以及鎖捲軸時的抖動怎麼處理。
以為 Button 是最簡單的元件,做下去才知道超級困難。Variant 與 Theme 該不該混用、icon 讓 Size 的 padding 難以分類、Loading 要不要保留原寬度。
CSS 的色彩系統進步飛快,color-mix 讓半透明疊色和 CSS 變數混搭終於可行。但致命缺點是不能 transition,算出來的顏色也不好預期。
老客戶要重啟四年沒維護的專案,clone 下來 install 就紅得慘烈。最後是靠 git 裡的 lock 檔紀錄,把沒問題的版本組合一個個挑出來。
新專案的架構規劃:monorepo 分 apps 與 packages,先把 eslint 和 builder 的 config 抽出來共用,打包從純 rollup 改成 vite。
數據說前端職缺數和起薪都上升了,但數據沒告訴你:求職者上升得更快,而起薪上升的意思其實是低階職位消失了。
包 useMemo 比較好讀,還是用 IIFE 比較好讀?這個萬年話題在 React Compiler 還沒普及之前,依然逃不過要花心思優化 memo。
「太懂技術會限制創意」是常見說法。我幹過前端也幹過設計,我的做法是設計時不想怎麼實現、實作時不回頭改設計——換個位置換腦袋。
Shadcn UI 現在幾乎成了前端的優先選型,老實說有點疲乏。Headless 帶來極強的可修改性,但也帶來閱讀負擔——工程師永遠在彈性和效率之間取捨。
上一頁、重新整理、右鍵、閱讀器,這些都是 Web 才有的操作。權限模型、外框空間、版本兼容期限也都不同——不要把 Web 當 App 去設計。
兩個實際踩到的瀏覽器差異:Firefox 裡 absolute + inset 對 input、img 這類無結尾標籤會失效;webkit 裡 flex-shrink 的壓縮效果也會失效。
「打開 devtool 畫面就卡死」,查下去發現跟 devtool 無關,是 resize。用 performance recording 一步步縮小範圍,元兇竟然是 Textarea。
手機版把文字壓到 12px、間距縮到最小,只為了塞更多東西,對使用者本身就是負擔。業主要「一個畫面看到全部」,但你的 TA 到底是誰?
網頁字體是個大坑。這篇從「字體檔到底是什麼」講起:它像一組組向量的 image sprites,粗體斜體的排列組合是指數增長,中文字又特別肥大。
現在的 SSR 已經不是你想的那個 SSR 了。除了 CSR、SSR、SSG,查資料時還會撞見 ISR 和 PPR,光要搞清楚差異就一顆頭兩顆大。
Next.js 帶起 Serverless 的 Rendering Service,但 Edge runtime 是閹割版的 Node.js。想串外部服務才發現沒有 net module,也就是沒有 Socket 能力。
成本高可以寫 any、編譯慢可以部分預編譯、老專案可以用 JSDoc 漸進導入。這些反對理由我都認同,但沒有 TypeScript 的大專案真的很痛苦。
前後端在處理資料這件事上的思路差別,這是一段還沒寫完就擱著的隨手筆記,先留個開頭。
Auto Layout 某種程度模擬了 CSS Flexbox,打破了設計與前端之間的溝通橫溝。從「太花時間了不可能都用」到現在出現歧視鏈,這個變遷很有趣。
拆元件的目的不是因為大而拆,而是為了更好理解、更好的渲染效益、更好的共用。急著抽共用的結果,就是一堆只有一個地方用到的「共用元件」。
Service Worker 就像一台開在瀏覽器裡的伺服器:長期快取、Web Push、攔截請求、背景長連接,還能不卡主線程做運算。PWA 就是基於它。
Refresh Token 是我做過所有前端需求中最通用、也最困難的機制。非同步處理、閉包、重試限制只是基礎,業界幾乎沒有統一做法或標準化套件。
Design Token 讓 CSS 的共用被規範化,也讓設計師參與了開發流程,代價是知識門檻。這篇講 System、Seed、Alias 三層 Token,以及實務上的普及率。
暫停了一群人的 UI Library 專案,改成自己一個人做。從最基礎的 Button 開始,光是 Variants、Theme、Size、Shape 加上 Token 關聯性就複雜到不行。
最好用的狀態管理機是哪一款?Redux、Zustand、Vuex、Pinia 都不錯,但我更喜歡 Proxy base 的。我的答案是:vue。
事件要清除、外部狀態要恢復,大家都知道。但 Promise 的 callback 嚴格說也是一種 event callback,那是不是也該 cleanup?
大家寫的 ESModule 上了瀏覽器多半不是真的用 ESModule 在跑。這篇講遷移時最麻煩的兩個東西:export default 與 require,以及兩種模組化為什麼不等價。
styled components 終止更新,進入長期維護階段,這件事社群沸沸揚揚。 有人說,這件事代表的是一代技術的興衰,隨著 Atomic CSS 的興起,逐漸大家捨棄了原本 cssinjs 的方案。也有人說,與其使用 runtime
很多人把 Tanstack Query 當成打 API 的工具,那太狹隘了。useQuery 是「Resource 的非同步狀態同步機」,useMutation 是「非同步方法的狀態管理機」。
在現在 極端 內捲的 前端 生態裡面 , 每個 都計較 怎麼 打包 , 要多小, 要 多 快 。 B un dl e Siz e 可以說是 非常 有價值 的 優化 項目 , 但 你 真的 有 驗證過 , 你 自己的 專案 T re e S
沒什麼人敢說自己精通 CSS,但 CSS 很強也不等於商業價值高。這篇講為什麼 CSS 的問題多半是「知不知道」而非熟練度,並列出六個有鑑別度的題目。
Tanstack Query 大概是我近年用過最超乎預期的套件了。(這篇是當時隨手記下的一句話,完整的心得寫在工程實務分類那篇。)
前端架構不只是資料夾結構和 Builder Tool。這篇列出七個真正該關注的點:可測試性、各種狀態的顯示、多語系破版、跨 feature 解耦、命名規範。
前端拿到 Design System 就像拿到加速工作的標準,但這只可能發生在產品開發,接案公司初期根本定義不出來。這篇講設計師那側的難點。
平常我多半護航 Vue,因為很多人噴的都不在點上。這次換我自己來講 Vue 相較 React 真正不好用的地方,從模板與腳本語意不一致開始。
三次比較大的重構:80 多組 Resources 的 Vue2 系統、要用微前端 migrate 到 React 的高耦合專案,以及 31 組語系、品質極差的 Nuxt3 重構案。
四五年前 SASS 是處理 CSS 的主流手段,現在趨勢往 Atomic 靠攏,Global CSS 因為反查太難而逐漸被淘汰。這篇聊 SASS 使用率一路下降的原因。
在 Vue 裡處理 CSS 的幾種解決方案速記:HOC、Sass Mixin、Global Sass 與 Component Wrap。
接手一個看起來功能不多的專案,直到看見它的 i18n——宏偉的 28 種語系,需求還要再加三種。每多一個詞彙,要改的 json 就是一場惡夢。
前端沒有微服務,那資深前端架構師到底要設計什麼?這篇先定義前端獨有的五個問題:bundle size、難以拆分、Context 太多、體感細節、瀏覽器管控。
JavaScript 本來就是 Event Drive 的語言,Event 對解耦有無比強大的特性。但很多前端不喜歡甚至反感這個設計,覺得多餘、複雜、難維護。
用過 vue-router 之後,其他路由系統我都覺得難用。這篇列出 react-router-dom v6 讓我卡住的地方:不建議操作 Router 實體、沒有導航攔截、無法針對 route id 導向。
全端工程師對我來說是個貶義詞。我把自己實際會的後端項目一條條列出來,然後講為什麼「前端學那麼久該學後端了」這種說教是雙標。
Restful API 不只是分 GET、POST、PUT、DELETE,你還得懂 http 規範和瀏覽器規範。這篇列出三種一看就會踩雷的 API 設計。
Vue 容錯率超高,所以特別容易寫出一堆有問題的程式碼。所謂的黑魔法本質就是 JavaScript,魔法來自於不了解,而業務元件用到的 API 越少越好。
元件掛載時打 API 很常見,但元件被卸載後 callback 並不會中止,還是會把非同步跑完,執行「不需要的行為」。趕快檢查你的元件有沒有好好清理。
class 其實只是 function 的進階應用。想寫的話要注意:解構後 this 會消失、用 this 改狀態不會響應。OOP 和 FP 從來不是對立的。
以主流前端框架當對照組,把 Vue 的優點、缺點,以及那些「特性造成的雙面刃」分開來講清楚。工具就是工具,不必吹捧哪個框架最好用。
有人開課教設計師「RWD 要靠工程師腦補」。工程師願意通靈是為了把事情做好,不是應該的,這篇講為什麼這種說法真的讓人生氣。
就算前端有實力也有意願,還原設計稿依然做不到完美。這篇講三個原因:RWD 不可能每個 pixel 都出到、沒有 Guidelines 的獨特元件,以及那些不可執行的需求。
SSR 架構下 Token 該放哪?伺服器拿不到 Client 的 LocalStorage。這篇講怎麼用 http only cookie 解決,也講為什麼我更推崇 PreRender。
「寫寫 HTML 加點 CSS 和 JavaScript 就出來了」——這是很多主管對前端的認知。這篇列出前端一樣要學的 Web Service、微服務、部署、資料庫。
技術長希望用 AI 提高測試覆蓋率,我的答案是「可以」也「不行」。輸入輸出明確的沒問題,但前端元件的參數量與渲染時間差,離 AI 能寫還有一段路。
後端還沒好、外部資源掛掉都會卡住前端開發,Mock Server 可以用 Node.js 或 Service Worker 模擬一個伺服器環境。但也有人認為這只是拉高成本。
從零打造一套 UI Library,不基於任何現有框架,從 bundle script 到每個元件細節都自己做。目標是能同時跑在 SSR 與微前端架構下。
今年大部分心力都投在這個 Side Project:從零造一套像 antd、mui、vuetify 的 UI Library。UI 設計師相對好找,前端反而少之又少。
微前端選 CSS 方案要格外小心,因為 CSS 不分作用域。這篇比較 CSS Module、Component Selector、CSS in JS、Atomic CSS,也分出全域、Hash、Document 三種作用域模式。
經驗不足的優先用套件,有經驗的要知道套件做了什麼,資深的則是「有條件的造輪子」——先讀完知名套件的原始碼,再來造自己的。
SEO 用 SSG 排程預渲染就夠了、渲染效率未必更快、CLS 本來就不該是問題。這篇把 SSR 的好處一條條拆開檢查,再看它帶來的四個副作用。
browser history 在整個應用中是唯一的,多個微應用各開路由器就會打架。解法還是單向資料流:微前端應用不要直接操作路由器。
前端工程師,社群的朋友都叫我竹子。 React, Vue 雙棲 專注在 Micro Frontend, Frontend Infrastructure 社群活躍者,喜歡參加與舉辦社群活動 發起 UI Library 相關 Side Proj
History Router、Locale、Browser Storage 都是單例狀態,在微前端裡最容易發生循環修改與資料流混亂。同步的狀態修改我最推薦用 Flux 單向資料流管理。
網路上都說 React 是款自由的框架,但我在寫的時候並不這麼認為。 hook 不允許改變順序與判斷,看似提供多樣的封裝,其實有有嚴格的規則。 React 只允許 JSX 和 jsx render function 兩種寫法,不會讓你看到太
設計系統最關鍵的是一致性,但前期該關注的不是 component,而是更包容的 Design Language。這篇講為什麼一開始需要更多發散。
前端有流量成本,所以「共用」比微服務更需要煩惱。Module Federation 目前幾乎沒有更完善的替代方案,代價是模組化會被綁在特定的 chunk system。
微前端的跨應用溝通沒有 import 可以用。但所有微應用都跑在同一個 global 底下,這篇講三種做法:套件共享、瀏覽器事件機制、後端 WebSocket。
很多人把微前端和 Module Federation 劃上等號,但 MF 不是必要的,也不是 Framework,它只是一種 bundle 的概念,用來解決版本管理與模組共享。
接著就是以 Component 化的角度來看看微前端的實作方法。 iframe WebComponent Frontend Framework Component (react, vue, angular) iframe 這是最古老最穩定的
三種服務端解決方案的優劣:xhr/fetch 插 script 上下限最大、module-federation 完整但綁打包工具、微前端框架最省力卻失去微調能力。
我為什麼開始玩微前端?公司有多個前端框架並行、產品要架在 Local 且組態多變、還希望能給第三方動態掛載功能——這三個原因把我推上這條路。
微前端要面對的五個核心問題:應用間溝通、模組共用、全域單例狀態、樣式管理、CI/CD。這篇逐一說明每個問題到底出在哪。
Wix、Shopify 這類版型網站確實讓官網不需要前端。但繪圖編輯器呢?極端優化的體驗、複雜的商業邏輯呢?被淘汰的會是底層的工程師。
實施微前端的主流方案:Application 層級有 xhr/fetch 插 script、module-federation、微前端框架;Component 層級有 iframe、WebComponent、框架元件。
前端圈不流行寫 class,那還需要學 Design Pattern 嗎?後來我才體會到設計模式是一種「精神」,不限於物件導向——Curry 就是物件不需要的模式。
微前端的好處是解耦、拆分職責、CI/CD 更快、沒有超大專案的維護壓力。壞處也很實在,這篇把優劣一起攤開來分析。
微前端、微應用、前端微服務講的是同一件事。這篇是系列開場,也澄清一個常見誤會:把服務切成 npm package 並不算微前端。
微前端就是把微服務的概念套進前端。這篇講什麼時候該考慮導入:專案大到影響編譯時間、跨部門共同維護、需要多框架共存,以及第一個麻煩點——溝通。
模組循環在前端多半不會爆,因為打包後模組早就載入完成。但完全不經過打包執行時就會出事,而且它本身就是架構層次不清楚的徵兆。
問「公司使用哪些技術線」是我的最終篩選。MVC 跟 jQuery 是危險訊號,手刻 UI 要追問管理方式,這篇列出從打包到 Code Review 該追問的細節。
「你們的開發流程是什麼」這一題可以問出超級多東西。這篇分成 PM、UI、後端、QA 與一般溝通五塊,講各自該追問哪些細節、聽到什麼答案要警覺。
前端最甜蜜的區間是年薪 80 到 120,機會多、競爭相對少,不需要很強的演算法或架構力。但過了 120 到 200 之前,幾乎是一片求職荒漠。
我們前端每天都在寫 ESModule,但你真的懂它是怎麼運行的嗎?這篇談它的載入特性。
做多站點登入和 SSO 踩了滿坑滿谷。這篇講 cookie、sessionStorage、localStorage 各自的保存範圍與風險,以及為什麼快取機制會深深影響系統設計。
路由器看似簡單其實很複雜。popstate 只監聽得到 forward、back、go,pushState 和 replaceState 是聽不到的。解法還是回到單向資料流。
光是用 div 刻一個 Custom Select,就有八個坑等著你。這篇講手刻元件的隱形成本:測試、Storybook、元件文件、打包成 package,全都是長期技術債。
正式接到 CTO 的需求,要從零著手開發一套自己的微前端框架,這篇是動工前留下的紀錄。
Frontend Infrastructure 涵蓋 CI/CD、打包、套件管理、SSR、監控、容器管理、AST、Module Federation。這些多半不是業務開發會碰到的技術,卻是團隊規模長大後的關鍵。
新手最常犯的錯是「貪圖一個案例測到太多東西」。觸發和渲染該拆成兩個 Test Case,外部依賴該 mock 掉——那是 end to end 才要做的事。
JavaScript 早期沒有命名空間也沒有模組概念,所有東西從頭寫到尾。這篇從那個時代講起,看模組化是怎麼一步步長出來的。
為什麼只有前端要又轉譯又打包?從一支破萬行的 HTML、破萬行的 CSS、上百張圖片講起,也講為什麼後端能拆微服務而前端拆不了。
微前端目前炫技成分居多,生態系極不成熟。後端拆微服務有伺服器壓力分配的必要性,微前端沒有這種優勢,反而大幅提高溝通與程式碼複雜度。
前端套 DDD 的水土不服:Domain layer 得靠 class、CQRS 讓定義一個行為的成本暴增。但用 Domain 劃分後重構成本大降,微前端也有了溝通橋樑。
動畫的本質是處理每一個影格該長什麼樣子。這篇講 Reflow 與 Repaint 的差別(連「取得」尺寸都會觸發),以及為什麼實作動畫最好脫離框架直接操作 DOM。
「為什麼不乾脆用 TypeScript 就好?」因為不是每份工作都能讓你任意導入技術。JSDoc 不只是閹割版型別檢查器,它在編輯器輔助上的價值也很高。
為什麼前端的 circular dependency 多半不會爆?因為 ESModule 打包後模組早已載入完成。但這不是「會不會動」的問題,是架構層次不清楚的徵兆。
「有新專案就該用 Composition API」我持否定態度。它在大專案的優勢很明顯,但給 junior 用會有超多誤操作,Optional API 的價值不該被忘記。
「套件幫我解決了,不用管細節」這種態度我不太認同。我的實力是靠大量閱讀原始碼建立的,知道它的實作原理,就能預先知道坑在哪。
研究狀態管理器是怎麼做到監聽與響應的。背後的效能節約與運算其實藏了很多技巧,這篇是 Observable pattern 的筆記。
學生許願想聽 FP,結果我一頭栽了好幾個月。從陳述式換到表達式、習慣 immutability、熟悉 curry,這篇也講為什麼 FP 很少在工作場域看到人真的用。
現場聽尤雨溪講 Vue 一路走來的心酸血淚。這篇整理八個重點:聽社群的聲音、破壞性改版該慢慢來、TypeScript 已成事實規範、避免使用私有 API。
mobx 用 OOP 的核心理念建構,跨應用驅動的特性在微前端有優勢。但物件導向邏輯跟 React 那套非常 FP 的設計,衝突與不便也很明顯。
前些陣子在社群上討論了一個話題,「哪一個 UI 框架好用?」這件事。 基本上在 React 的生態系中,毫無疑問的是對應 Material Design 的 mui,和對應 Ant Design 的 antd。有 Google 和螞蟻金服兩
useMemo 到底該不該用,吵了這麼久卻沒人拿出數字。我直接用 console.time 壓測十萬量級的迴圈、useMemo、Virtual Node 與 DOM 掛載,把真正的效能大戶找出來。
Module Federation 讓微前端的各應用有效共用函式庫,但它是「同版本共享」而非多版本共存。這篇講共享機制的維護、權重規則與它帶來的打包代價。
做微前端半年,大部分時間都花在架構和打包上。這篇談踩坑最深的 vite、微前端為什麼比微服務普及得慢,以及它需要的那片知識海。
FreeGo 和 CNN 檢測都過了,不代表真的能用。這篇分享做無障礙電子書時注意到的八個細節,以及為什麼無障礙做得最好的其實是 Bootstrap。
從輪播、下拉選單到彈窗,手刻元件累積的都是經年累月的智慧。這篇講顏色系統、多國語言排版、無障礙互動與 API 接口設計各自的難處。
Vue 是一間自助餐:九種以上的寫法組合、全自動依賴樹、模板把難的地方封裝掉。但這些好處的另一面就是它的壞處,這篇把兩面一起講。
我經歷過兩次框架轉換:Mithril 到 Vue,Vue 到 React。這篇講 Mithril 是什麼樣的框架,以及跳進 React 之後適應不良的五件事和它實在的好處。
網路上一面倒說新手該學 React,我還是推薦先學 Vue。這篇把七個理由攤開講:模板的黑魔法、寫不好也不會太差、公司教育成本,以及 junior 的工作機會。
很多工程師無條件相信套件,但套件不一定寫得好。挑套件前我一定會把原始碼大致讀一次,重點是快速掌握它的關鍵在哪,而不是「不懂,用就對了」。
從 Vue 轉到 React,把功能寫出來不難,難的是元件設計與效能優化。這篇講兩種框架背後截然不同的思維:一個讓你極盡追求,一個讓你不用太煩惱。
「我 postman 都會通,為什麼你打不到?」這就是 CORS。這篇講瀏覽器為什麼要擋、該從伺服器解決,以及前端自己起 proxy 這個解法的代價。
頁面不可複用,元件要考慮通用性,到了微服務層級則是任何改動都會牽扯全部產品。這三種設計是完全不同的層級。
Monorepo 最難搞的是依賴問題。打包套件內部自動 require 時無法分辨 workspace 還是 root,會去讀它自己所在的 node_modules,坑就從這裡開始。
要關閉 Vue cli 的 TS,方法就是去修改 ts loader 的設定,從頭到尾不是 ESLint 做的祟。到這裡總算是可以把專案暫時動起來了,但接著還要各種問題⋯⋯最要命的是 typescript 的各種運行規則,不要去挑戰非常冷門
把一個龐大的 Vue-cli 專案從 webpack 4 升到 5。這篇記下升級介面的選擇、Node 版本與 polyfill 的坑,以及 TS 錯誤噴到崩潰時關不掉檢查的怪事。
面試官只用 10 秒決定要不要認真看你的履歷。這篇從幫大量朋友健檢履歷的經驗,講六件能讓履歷被看完的事,以及 GitHub 該怎麼呈現才加分。
App 與 Web 的分辨點在「預設行為」與「預設介面」。要求兩者統一,得先建立在了解與充足的開發資源上,否則只是因為無知而做的任性。
設計師要發散,工程師要收束,爭執的本質是不了解對方的工作。這篇分別講兩邊的職責與立場,以及「做不到」其實通常是「時程內做不到」。
前端和 UI/UX 是新興職務,上下限差距巨大,會切版就能當前端、會畫圖就能當設計師。這篇講入行門檻低下的副作用,以及這兩個角色真正的價值在哪。
被主管用「畫面不漂亮」評估前端能力是什麼感受?這篇講前端的工程價值為什麼外人看不到,以及抽離工程師角色、站到產品設計師位置後看到的東西。
為了做一個高度客製化的 Event Time Line Chart,只好跳下去跟 Canvas 搏鬥。到了 Canvas 沒有 CSS,碰撞、渲染、組件化全部要用數學算出來。
從海軍退伍、做保全、玩傳直銷,一路撞到 Wordpress 才開始學 HTML 和 CSS。自學一年半、破釜沈舟海投,最後拿到 32k 的第一份前端 offer。
Junior 繼上一篇 我是如何變成前端工程師? 之後,接著又發生什麼事呢? 第一份工作拿了 32k 薪水的 offer ,我開始了前端工程師的道路。實際上了工,依照我的能力工作內容是設計做圖和前端切版,慢慢從我能做到的工作去執行工作。後來
設計的知識領域已經一大塊了,還要懂前端嗎?我的答案是看公司:老闆願意為畫面付出成本就去要求前端,老闆只要求快,那你真的得懂前端。
前端工程師的前身是網頁工程設計師,隨著使用者端需求提升才細分出來。這篇用最白話的方式講前端負責什麼:凡是瀏覽器發生的大小事都算。
很多人覺得工程師每天都在看天書。但久了其實跟學外文、看原文書差不多,你沒辦法解釋,但就是看得懂。
SEO 免費、高曝光、客戶自己找上門,卻也人人喊難搞。這篇從 1995 年的起源講到爬蟲演算法越來越細緻,以及排名到底怎麼搶。