後端入門可以了解的資料庫概念
資料庫就是一個儲存資料的軟體，根據儲存資料性質不同，合適的資料庫種類也會不同。了解 Transaction、ACID、Normalization……等核心概念非常重要。還有更多可以深掘的細節，先單純把學到的知識紀錄一下，未來個別用更多文章詳細描述 :)
資料庫就是一個儲存資料的軟體，根據儲存資料性質不同，合適的資料庫種類也會不同。了解 Transaction、ACID、Normalization……等核心概念非常重要。還有更多可以深掘的細節，先單純把學到的知識紀錄一下，未來個別用更多文章詳細描述 :)
依照先前的教學我們已經可以創建基本的 CRUD 程式，但基於 HTTP 是無狀態的協議，如果單純實作會員系統用戶將會需要在每次操作登入會員相關的行為時重複驗證，明顯是糟糕的使用體驗。一種解決方案是在請求時伺服器將會建立 Session。
隨著前端演進，我們時常需要依靠現成的框架輪子協助，而其中 Vue 又是繼 React 外第二熱門且成熟的選項，但很少有教學提到一個完整的專案該如何建構，以及有哪些模式可以遵循。這次來介紹一下如果從頭開始我會怎麼建構一個 Vue 專案，在 2025 年！
先前系列提到使用 Express.js 簡單的創造一個 CRUD App 並用 MVC 分層，這次流程差不多，目標是把後端接上本地的 MySQL 伺服器並使用 MySQL2，一個專為 Node.js 應用設計的 MySQL 資料庫連接工具。
使用套件時總是會好奇一般管理套件開發的流程是如何？我透過 Matt Pocock 的 Blazing Fast Tips: Publishing to NPM 教學影片順手實作了一次，並且把自己之前遇過的需求寫成一個獨立的 TS 套件公開發布：edit-element。
Express 提供便捷優雅的 API 讓我們接收請求經過處理後回應，但會發現隨著規模龐大起來路徑、商業邏輯、資料……等代碼都塞在一個 app.js 實在不是一個好做法，於是這篇文章介紹使用 MVC 架構替代碼進行用途上的切割，以方便維護。
近期正在學習後端相關領域，與前端最貼近的框架絕對就是 Express.js 了，很適合目標為全端的工程師，因為可以使用單一語言最快接觸到兩種領域。這次實作並不會牽扯到資料庫相關的部分，侷限在使用 Express.js 打造一個簡單的 in-memory 代辦事項後端伺服器，熟悉一下開設增刪查改相關 API。
近期看到 Web Dev Simplified 推出的教學促使我趕緊打開這篇文章記錄其中提到的網頁無障礙需要留意的地方，並且補充上一些我自己實驗有幫助的資訊。無障礙一直是我想重視但實際開發時優先順序總是排在最後的要求，差勁的無障礙對某些使用者來說會嚴重影響到網頁互動的體驗，身為前端讓網頁保持良好的無障礙是基本責任。
TypeScript 存在一些不太直覺但背後卻有合理因素的問題要留意，像是無論傳入任何物件進 `Object.keys` 都仍會回傳 `string[]` 型別是其中之一，本文探討背後因素與提供不同方向的解套方法供不同情境使用。
「如何編寫 GitHub 個人檔案」這個問題其實就像是「開發者怎麼製作自己的名片」，畢竟對你感興趣的人來說 GitHub 個人檔案就是第一印象，所以可以斟酌放些「你熱愛參與的專案或展示專業」基本不會錯。像我有熱情持續經營展現技術部落格那就放上最大篇幅去介紹，把作品、部落格或履歷放上。
之前碰到一道有趣的前端 UI 題，發現需要對於前端有較為全面的認知才有辦法解出來，並且也可以針對感興趣的領域延伸提出更更多問題，於是特地紀錄一下我的思考解題過程。身為一名前端工程師，你會怎麼實作上圖的電影院座位選位系統？
近期製作到內容大綱（Table of Contents）相關的功能，發現是一個很適合使用 Intersection Observer 的案例，透過監聽特定元素來自動更新目錄的狀態。在早期可能會需要透過 getBoundingClientRect 之類的方法來計算元素有沒有離開視窗，現在這樣的需求就變得更加容易實現。
實際網頁很少遇到特殊的視覺會需要動用到 CSS Grid 的情況，而我近期在製作一些比較特殊視覺的網頁布局，事後感覺特別適合作為一個 CSS Grid 的啟發教材，於是寫下了本篇文章幫助透過真實世界案例更深刻了解 CSS Grid。
CORS (Cross-Origin Resource Sharing) 跨來源資源共享，是一個機制用來決定網頁是否能夠存取其他來源的資源，能有效防止不同來源之間的不正當資源存取。透過 CORS，可以在保護用戶資料的同時，允許合法的跨來源請求。
這次我透過一步一步拆解解題路徑來描述如何解題。從基本解到分離資料與邏輯、保持 immutable 以及邊緣案例還有文件編寫都有涵蓋。打印出 1 到 100 的數字、假如數字是 3 的倍數，則打印 Fizz、假如數字是 5 的倍數，則打印 Buzz、假如數字是 3 和 5 的公倍數，則打印 FizzBuzz。
無論如何都不輕易相信用戶請求即能最大程度防範 CSRF。最近在碰一些資安的東東，發現自己對於這一塊知識都比較薄弱，身為前端工程師資安通常並不是首要關注的職責，但一但有漏洞保證後果不堪設想，於是近期來補足一下這方面的知識。
總結是無論如何都不輕易相信用戶輸入即能最大程度防範 XSS。最近在碰一些資安的東東，發現自己對於這一塊知識都比較薄弱，身為前端工程師資安通常並不是首要關注的職責，但一但有漏洞保證後果不堪設想，於是近期來補足一下這方面的知識。現代齊全的工具與文件幫助下意外執行用戶提供的惡意腳本的機率已經大幅降低。
會想調查這個主題是因為目前所在的團隊大量地使用到這樣的模式，但 Vite 並不會在開發中進行 Tree Shake 就導致每一次開發環境都有大量的無用代碼被打包進去，嚴重影響到開發體驗。因此研究一下這種方法的理念與優缺點以架構更好的專案。
前面寫了一篇文章關於 ES6 JavaScript 當中的內建資料結構： Map，這次來談談 WeakMap，它又與 Map 有什麼不同呢？會發現 WeakMap 相較 `Map` 少了非常多可用的方法，這是因為它們的根本處理資料的方式不同，Map 是強引用，而 WeakMap 是弱引用。
從很早以前就大致知道瀏覽器開始推出 Web Components 相關 API 與標準，但一直沒有機會在實戰中使用這項技術。想撰寫這篇文章記錄是因為隨著時間推移發現 Web Components 的應用範疇越來越廣，因此趁著有空也來了解一下相關知識，並且分析它與現有的解決方案有什麼不同。
近期我對自己看待撰寫程式這件事有更高的期許，除了最基本的效能、閱讀性、擴充性……之外還有一個非常重要的領域就是：測試。不過程式好端端的能動就代表測試沒有必要了嗎？在我剛工作時實際上做了一段時間的自動化 QA 工程一段時間，不過那時候的我其實也並不明白寫測試的原因，就是有程式就拿來自動化測試，並沒有想太多。
JavaScript ES6 中有一個用法與物件近似的資料結構我一直不是很清楚用途。 —— Map，這篇文章會主要拿熟知常見的物件與 Map 來做比較以分辨出 Map 的特性與使用時機。總結來說可以把 Map 當作是用來頻繁讀寫的物件，它具備更好的性能、更明確的語法。
發現身為初階打工人其實通常只是看見問題並拼命解決它，但換個角度思考：「如果現在手上專案燒起來，主管定個超乎預期的時程但你也沒有自己一套說法，要如何交代？」，最貼近實作的人其實是最能開出真實預估的人。參考：The work is never just “the work” - Dave Stewart 文章。
近期執行的專案在進行翻新包含了整體的視覺設計，因此前端也面臨要如何同步管理產品視覺的問題。先說痛點，先前專案並沒有具體的規範應該如何定義 UI 當中的數值，導致魔法數字（沒有規範與描述的值）流竄於整個產品當中，造成了非常大的的困擾。我會解釋得盡量具體明白如果要重新設計一款數位產品會怎麼管理其中的數值。
為了確保頁面內容保持在合理的範圍內，很多時候會需要在外層使用固定的尺寸作為網頁內容的容器。而近期在翻新的頁面有一些獨特的布局樣式，透過 CSS Grid 來更靈活的讓容器內容也能跳脫安排在各處，主要參考 Kevin Powell 的做法。
先前提到「添加深色模式要考慮的代價」無可避免的會增加比預想中還要多的成本，但如果能在一開始用正確的方式製作網頁風格，那麼可以有效的避免掉許多問題。如果你希望製作不同風格的數位產品都可以參考本篇文章，用更省力的方式定義風格。
經營這個部落格時我逐漸養成了「不管再忙也要推新進度上來」的習慣，不管是寫文章、小短文、找題材、修復 BUG 推新功能……總之每天都要盡量以讓部落格更好這個方向努力進而強制自己去精煉思考。這種生產力非線性與專注在目標大方向的概念幫助我建立了不少習慣。
開發至今從來都沒有特別去了解如何好好的執行代碼審核，大家都默認會寫代碼就代表你也有能力去審核別人代碼，但我想這是一門額外的學問，因而促使我寫下這篇文章去了解如何進行代碼審核。審核代碼是最直接可以發掘並改善問題的環節，主持得當的代碼審核能夠補足團隊成員間的知識盲區進而提升整體代碼水平。
身處開發領域會發現很多時候都是在做架構資訊的工作，所以我會覺得稱呼自己的日常工作像是「🌵 軟體園丁」是十分貼切的，如果你也同意寫作是為了思考更多，並期望透過輸出寫作來精煉自己的思考，那麼「數位花園」這個概念你應該也會有興趣。
瀏覽器引擎前綴是為了讓開發者在瀏覽器尚未正式支援的情況下先使用這些前綴來實現一些新的 CSS 特性，甚至當時還時常會使用 PostCSS 這類預處理器的 autoprefixer 插件來預處理 CSS 添加上這些前綴。近期發現需要前綴的屬性越來越少，未來也大機率不會再有新的前綴被加入了。
Git 允許我們紀錄任何檔案的變更，並且可以輕鬆地回溯到任何一個版本，但是當需要儲存大型檔案時 Git 就會顯得力不從心，因為 Git 並不是為了儲存大型檔案（圖片、影片、音樂……等二進制檔案）而設計的。而這次介紹的 Git Large File Storage 是 Git 的擴充，專門用於解決以上問題。
如今 Git 與 GitHub 已經成為業界主流，有很大機率你的專案也會使用到它們來進行版本控制，但由於 GitHub 是一款基於 Git 附加的服務，所以我們時常會輕視它的功能，其實 GitHub 有許多不錯的功能卻不是那麼明顯，因此主要分享一些我認為有用但日常使用沒有查覺到的功能。
一開始聽到 CSS Container Queries 這個名詞還是在一兩年前，隨著時間演進建構網頁的模式也變動了許多次，我也越來越確信這項技術會是未來建構 RWD 網頁的一塊重要拼圖，文章將介紹現有的 Media Queries 有哪些缺陷，新解方則具備哪些優勢？
近期將公司的新 Nx Monorepo 架構專案透過 GitHub Action 添加了自動更新套件的功能，會想實踐該功能是因為舊專案疏於更新導致吃了非常多的苦頭，希望在新架構下可以有更輕鬆且自動化的方式去執行更新。其中 Nx 有專屬的 nx migrate 指令幫助我們達成這件事，並且背後有些非常有趣的機制與理念。
近期維護的專案希望導入深色模式 （Darkmode），但分析下來我認為實踐這個需求並不是一項划算的選擇，這篇文章將會討論為什麼我會這樣認為。如今許多網站和應用程式預設都提供了深色模式，這是一種將背景色轉為深色，前景色轉為淺色的設計手段，具備各種功能性和情感上的特點，例如：節省裝置電力、降低眼睛疲勞……
近期在替專案做大型重構，其中就有將技術轉換為 TypeScript 與 Monorepo，途中一些還沒有頭緒如何解決的型別問題，就會使用 `@ts-ignore` 或 `@ts-expect-error` 來先行忽略，但這兩者的使用時機有所不同，這篇文章就來談談這兩者的差異。
近期在維護不同規模的專案，想說可以了解一下不同 Git 分支策略的優缺點來替專案選擇適合的開發策略。現階段我最常接觸的是 Gitflow 的方式來進行開發，但發現這樣的策略在小型規模的專案（5 人以下）並沒有這麼靈活好用，恰巧可以在全新的專案上嘗試其他策略。
撰寫這篇文章是因為接手過非常反人類的 Tailwind 專案，一些不應該出現的反模式其實都可以在早期被輕鬆避免，當專案規模變大時，這些反模式就會變成一個巨大的問題難以修正。這篇文章將會介紹一些我在專案中看到的反模式，並且提醒你千萬不要這麼做！
我是一個物慾非常低的人，日常東西就是用到壞才換新，直到某天常用的薄膜鍵盤壞了才開始尋找新的鍵盤。在挑選新鍵盤的過程中讓我想到選擇鍵盤的一些故事促使寫下這篇文章。作為軟體工程師不外乎每天接觸到的硬體生產力工具大概就是：鍵盤、滑鼠、電腦、螢幕、椅子、筆電、大水杯（喝水非常重要），其中鍵盤絕對是情感最深厚的一個。
近期重寫的專案中有許多狀態需要管理，會需要統一管理資料於專案中，為了避免寫死代碼（Hard Coded）並且讓接手的人都能輕易地瞭解資料型態，這裡記錄一些過程中的發現。結論是應該使用 as const 來達成列舉資料管理，因為它更加直覺沒有什麼認知負擔，並且更加靈活。
為什麼如今網站大多數都長得差不多，就連體驗也差不多？我們時常會聯想設計網頁是一門富含創意創新的工作，但對使用者來說創新並不全然是一件好事。本篇文章希望引導讀者了解網頁發展的經歷並推導出為什麼「無聊的使用者介面是好的使用者體驗」這個結論。
身為前端工程近期工作的感悟是很多時候開發問題還是陷於介面的外觀、行為或互動層面上，並不是說花時間製作這些層面的事情就很遜，它們實際需要依靠經驗豐富的開發者透過多方面的研究與考量才能打造合理的架構，例如有許多要留意的事：效能、適用性、可維護性、可測試性、搜尋引擎最佳化、跨平台相容性、多語系……
AI 並不會離開我們的生活，並且只會越來越普及，這也意味著我們的生活將受到影響。什麼事情是人類能 AI 不能的？未來的工作會是怎麼樣？人們能做什麼來保證未來？什麼事情是人類能 AI 不能的？未來的工作會是怎麼樣？人們能做什麼來保證未來？思考以上問題。
Lighthouse 是一款開源的自動化網頁效能檢測工具，通常都是遇上網頁效能問題才一個一個開網頁開來測試效能，手動測試總是會有：單次的測驗結果不穩、耗時費力、不利於團隊開發的問題，今天來嘗試使用 Lighthouse CI 自動化的在每次代碼更動時檢測網頁的效能問題吧！
不到 3 步驟讓你的網站擁有以 WebAssembly 高效驅動的客製化搜尋功能。靜態網站像是部落格、文件、個人網站、公司網站……等這類閱讀體驗為主的網站通常都有搜尋內容的需求，恰逢 Pagefind 1.0 的推出我把原先自製的 fuse.js 搜尋功能換成 Pagefind，分享如何在任何靜態網站上加入搜尋功能。
近期工作接觸使用 Shadcn for Vue 來打造網頁 UI，這是一款基於 Tailwind 可彈性客製化的元件組合，讓我們可以快速建立出符合需求的網頁介面。這篇文章將會介紹現有樣式庫的問題以及 Shadcn UI 的特色，以及為什麼在前端圈這麼火爆。
表單是是網站中最常見的功能性元素也是與用戶溝通的橋樑，像是購買商品、註冊會員、問卷填寫……等各項行動都離不開它，然而這麼重要的體驗卻時常被忽略，於是我決定整理一個良好的表單應該具備的體驗以及為什麼應該這樣設計，供所有人了解常見的表單設計問題。
JavaScript 有 try...catch 語法用於捕捉程式中的錯誤情境，在需要時使用 throw 語法來拋出「任何錯誤」，通常建議會丟出 JS 預設的錯誤物件，但在 TypeScript 要怎麼做才能確保拋出的錯誤的型別？
Zod 是以 TypeScript 為首的 Schema 聲明和驗證庫，為什麼有了 TypeScript 還需要 Zod？輕易的撰寫 Runtime 資料驗證就是 Zod 的目的，像是驗證三方 API 傳遞的資料、用戶輸入在 URL 中或表單中的資料使用 Zod 來驗證都很方便。
最近閱讀 Stay SasSy 提到的 Goals, Problem, Solutions 猛然察覺這不是我日常工作拆分問題的方式嗎！簡直是不謀而合，正好也想寫一篇文章來分享這個達成共識的方法，同時這也是一個很好向上溝通的方式，不管是對團隊還是對上級溝通都有幫助。
網頁原先是靜態文件，但隨著需求增加，動態的改動網頁的狀態已變得普遍，隨意使用 `disabled` 屬性就像是在用戶路上堵上一顆巨石，這樣的設計不僅無法幫助用戶解決問題，還會讓用戶感到困惑。我們應該盡全力讓用戶知道問題原因，而不是只做到「阻止用戶的錯誤行為」。
在 Astro 中使用 MDX 撰寫文章給我非常多的彈性，但絕大多數文章我還是希望使用 Markdown 現有的語法來撰寫，像是：圖片、程式碼區塊、列表……等，有沒有辦法將自定義的元件對應於 Markdown 語法呢？這樣就不用每次都要再 MDX 中特地引入元件並使用，單純的撰寫 Markdown 即可。
Continuous Delivery 在 The Biggest Problem With UI 影片中點出了我多年來對於產品 UI 開發流程最大的疑惑：為什麼 UI 設計與開發的流程總是如此不順暢不協調？「有沒有辦法讓團隊穩定高效的產出真實滿足用戶需求的產品？」是本篇文章探討的核心問題。
TDD 測試驅動開發是一種開發方法論，先寫測試再實踐代碼，應該如何撰寫測試？或許聽過 TDD 但不清楚與單純寫測試差別在哪？這篇文章詳細描述 TDD 的優勢與實際操作範例快速了解 TDD 為什麼這麼讚。TDD 目的便是打造一個工作流程能夠驗證程式碼的行為，讓開發者能夠更有信心的重構、更動程式碼。
觀察並釐清什麼樣的「品格」是一位工程師可以具備的，以及普遍工作環境和社群帶給我的感受，總結出幾點可以解決問題的模式，在日常也作為我自己參考與努力的依據。有耐心、能溝通、跳脫框架是我理想中軟體工程師可以具備的美德，不知道你是不是也認同這樣的想法？
JSON-LD 是一種夾帶更多資料以描述網頁網頁內容的方式之一。通常不會多留意它，直到真正實作下來也不知道有沒有任何用處？該如何檢驗搜尋引擎有正確抓到這筆資料？這篇文章分享我的經驗以及讓你實際驗證 JSON-LD 是否和規且有被正確解讀。
近期面對許多陳舊代碼維護的問題，碰巧我翻找到這個部落格：Understand Legacy Code，紀錄一下「重寫」陳舊系統可能會遇到的困境與解套方案。以我自己手上的專案為例，在進行專案升級評估時發現事情比原先想像還要複雜！
開發者在記錄或轉移知識方面的「失敗」並不是因為懶惰或缺乏關心。 相反，[環境壓力]促使他們在績效和學習目標之間的複雜緊張關係中找到平衡。當讓學習變得顯見並不安全時，績效文化就會獲勝。透過每日小會的方式，每天花費短小的時間讓學習在團隊中被提倡鼓勵。
UI 介面當中文字佔據了絕大多數的內容，文字充斥在設計的每個角落，它們是最有威力的設計元素之一，以極為精簡的形式傳遞深刻的意涵。這篇文章想分享設計與內容可以是相輔相成的概念，並且討論設計者在沒有內容的情況下設計可能造成什麼樣的問題。
隨著前端的複雜程度增加，Monorepo 這個詞彙也時常出現在眼前，可惜的是相關介紹資源非常不足，趁著近期較為閒暇的時間來統整紀錄一下我對 Monorepo 的理解。受到不同好文章與影片的的啟發，我想寫一篇最直白的 Monorepo 解釋，希望能夠幫助更多人理解 Monorepo 的概念。
近期在大改造現有產品的設計系統，預期會與來自不同領域的人合作，因此這篇文章是寫給對網頁無任何前置知識的人的，主要介紹「介面元件化」這個概念。元件是一塊拼圖、一個積木、一個齒輪……，就是一個可以被重複使用並且可被組合成更大物件的概念。
設計令牌（Design Tokens）或令牌是一種管理設計屬性與數值的方式，用於建構 UI 最細小的元素，適當的使用設計令牌可以讓設計系統更加彈性與可擴展，不論是任何職位，只要與設計系統相關的人士都應當了解設計令牌的概念。
開會是一門學問，也是身為團隊領袖必備的軟技能之一，架構差勁的會議會不只影響個人更甚至會整體團隊的生產力，特別是在遠端工作盛行的時代溝通技巧更尤為重要，架構差勁的會議會不只影響個人更甚至會整體團隊的生產力，本篇文章探討開會前中後有哪些細節是可以注意的。
近期公司購買了設計相關的課程，期望透過研究改良目前的設計來提升與開發合作的效率，恰好我之前的工作領域也與設計相關，而且我很早就想跨領域多寫與網頁相關的文章！因此打算特地開一系列文章記錄課程筆記以及我自己補充的想法與資源。
在加入新工作的數個月內我撰寫了接近百支大大小小功能的 E2E 測試，打算透過邊撰寫這篇文章邊閱讀文件穩固自己的知識，同時也方便團隊成員能夠快速上手我從零開始建立的 E2E Cypress 測試專案，並且最終期望能夠嘗試實驗導入 BDD 流程到團隊開發流程當中。
開發者們對 CSS 有不同的意見，有的人說它很簡單、有的人說它難以駕馭，這些都是事實。我時常聽到苦惱的後端或是與其打交道多年的自己脫口而出：「CSS 真的好詭異阿！」，這篇文章來總結為什麼 CSS 是一個讓人又愛又恨的存在，它為什麼這麼難學這麼詭異？
開發者的工作性質造就我們注定要站在最前線與 AI 並肩作戰，而 GitHub Copilot 這些年的陪伴顯著的提升了我的開發生產力與更有效率的學習開發技巧，是少數我覺得真正值得付費的服務之一，不管你是新手還是老鳥 Copilot 都有對應的定位幫助你加速開發。
近期工作剛好接觸很多介面開發的部分，其中一個需求實作「無限滾動加載功能」，當使用者滾動到頁面底部時會自動加載更多的資料，不用點擊按鈕就能瀏覽更多的資料，就像是自動版的加載按鈕。近期工作剛好接觸很多相關的介面功能開發，讓我們用 Vue Composition API 來實作。
不要让使用者等待！越多的等待时间，就越容易让使用者流失，因此让应用程式的回馈即时，是很基础重要的原则。 Optimistic UI 强调即时、乐观的使用者介面回馈。在用户触发操作后，系统即时假定成功，迅速更新介面，提升使用者体验。这种方法有效缩短用户等待时间，创造更流畅、令人满意的互动体验。
我既設計網頁也開發網頁，並且在過去幾年經驗中總結發現設計與開發配合上容易遇到的問題像是：我需要繪製多少種尺寸的網頁？我需要替網頁設置多少個斷點？這篇文章我分享自己身為設計者與開發者的經歷以及你為何應該使用越少的斷點來製作響應式網頁越好。
賦予網頁元素相對的關係而非絕對的數值，讓我們強烈聯繫元素之間的差異，而非取決於某個魔法數字可以避免很多折騰。最近看到一篇文章，作者提到用 CSS Variable 來賦予相對而非絕對數值的 `z-index` 值，真是優雅簡潔的方法！完美的發揮了 CSS 變數的優勢，促使我寫下這篇文章。
索取並顯示資料對前端工程師來說是家常便飯的事，但隨著背後延伸的狀態越來越多，就會讓整個專案極度混亂，因此想要藉由這篇文章點出現有問題並提出一些可行的方案，紀錄尋找更高效解法的過程。在索取資料時連帶的有許多狀態需要被管理和調整，文章透過 Vue 來探討如何更優雅的處理這些狀態。
本文描述近期在維護既有代碼時的故事，目前的專案中有各式各樣前人尚未統一的驗證方式，例如：有些是使用 HTML 原生客戶端驗證、伺服器端驗證、第三方套件、自造的驗證方法，如何統一規範驗證方式是一大問題，同時也要思考：「要如何避免創造更多的陳舊代碼？」
本系列 Astro 文章終於完結了，必須說連續 30 天到了後段有點寫不太出來任何東西，秉持著有寫任何東西無論如何都比沒寫強的精神完成了這次的挑戰！本系列文章是當完兵出來沒多久馬上開始寫的，因此是在最後一天開賽而且還只有不到 10 篇的屯稿的狀態下進行的，加上日後工作也忙碌起來，能夠完賽算是很幸運。
終於到第 29 天了……前面寫太多沒有規劃好反而到後面也不知道要多寫什麼。其實在撰寫這 30 天文章之前我有先試寫紀錄一下我用 Astro 製作個人網站的過程，可以參考看看：製作個人前端作品集 - 準備篇以及實作篇，裡面有記錄從發想草稿到實作的過程，如果想要製作個小網站試試水溫可以參考看看。
感覺 30 天真的要寫不下去了 😅，感覺要寫的前面都寫過了，今天這一篇來介紹 Astro 有那些資源可以入門以及近期的新聞。就在昨天 Astro 發布了 3.3 版本，來了嶄新的實驗性圖片組件 <Picture />，改進了語法突出顯示的相容性，引入了套件的可信性證明，以及其他一些提升使用體驗的改進。
本章節來談談 Astro 3.0 版本最吸睛的一項功能：View Transitions ，讓你的靜態網頁也能達成 App 應用一樣的絲滑感受。由於這項技術還在實驗階段，因此放在後面的章節補充。View Transitions API 是瀏覽器正推出的一項 API，提供簡易的方法對任何 DOM 狀態更換提供轉場特效。
很多時候建構網站都太著重在技術層面該如何應對，但要怎麼經營自己的網站或產品好像卻沒什麼概念，因此這裡添加一下我建構網站的歷程與收穫。我從幾年前剛學習網頁到現在一直在為寫部落格做準備，期間嘗試用很多不同技術與挑戰，但一直以來都沒有特別滿意的成果，直到近期才比較有「寫部落格」這件事究竟是什麼的體會。
在 Astro 中串接 CMS 是一件非常容易的事情。內容管理系統 （Content Management System）是一種用於編寫和管理網站內容的工具，可以讓幫助撰寫內容與管理網站資產，不同的 CMS 廠商有各式各樣的特色像是：排程發布、編輯器、合作編輯、資產管理……等特色。
我喜歡使用自動化的工具來為專案的代碼提供錯誤檢查與整理，因此使用 ESLint 與 Prettier 讓撰寫的代碼更一致無錯，還有額外添加 TypeScript 的檢查與 VSCode 提示。本篇文章將帶你認識我如何替自己的 Astro 部落格添加 ESLint 與 Prettier。
當網站規模愈複雜，使用相對關係路徑就會需要花費很多心力去解讀與撰寫，在撰寫引入路徑時會發現撰寫相對位置的路徑既又繁瑣又難維護，可以透過額外設置路徑別名來解決這個問題。本篇文章介紹如何透過設定 Astro 中的 TS 設定檔來達成路徑別名。
環境變數提供在不同開發階段切換伺服器地址的靈活性，避免硬編碼，同時安全存儲敏感信息，如 API 金鑰或數據庫密碼，使程式更具適應性和安全性。如果你熟悉 Vite 的話應該會非常熟悉，因為 Astro 即是使用 Vite 作為底層。
到這個章節介紹了絕大多數會使用到的 Astro 功能，後續的章節會著重在講解一些額外的環境設置。讓我們把製作好的網站放到伺服器上可以被其他人造訪吧。到目前為止教學都是以靜態生產的方式的使用 Astro，也就是預先渲染的網頁文件可以被靜態的放置在伺服器上被索取。
前面透過建立靜態端點實作了自己的 RSS Feed 算是一個簡單的練習起步，這次更進一步透過建立整個集合的資料來完成「集合文章搜尋功能」。隨著文章愈來愈多會需要一個查詢文章的功能，透過用戶輸入文章相關的訊息，比對文章資訊（標題、文章短描述）並顯示出最相關的文章。
前面章節我們學會了如何使用 Markdown 或 MDX 、在內容集合中定義資料格式與索取資料。本章節將解釋如何在 Astro 中創造端點提供不同種類的資料，並實作生成一個 RSS 檔案作為練習，RSS 是一種標準化的方式，一種特定格式的 XML 檔案，設計來推播最新資訊給網站用戶。
前面學習了內容集合與頁籤的製作，今天的主題練習透過整理集合抓取到的資料更進一步製作分類功能頁面。隨著內容集合發布的文章越來越多，裡面可能會有許多相同性質的文章你會想要集合起來並替他們分類，並且自動根據類別自動創建頁面方便查閱。
透過內容集合動態的生成 Route 是件方便美好的事情，但一旦數量一多就必須要想辦法分批次顯示這些資料，恰好 Astro 內建頁籤可以幫助我們打造這方面功能，會建議等到網站真的有這麼大量的內容再來考慮製作頁籤，嘗試添加分頁功能並創建分頁元件吧。
除了定義資料在元件中、在 `src` 中 `import` 進來或者是 `fetch` 遠端資料之外有其他撰寫內容的方式嗎？有的！內容集合於 2.0 版本推出，用於替網站的本地內容提供易於使用管理、自動化型別驗證的功能。如果你有大量文件需要注入網頁中便可以使用該項功能。
先前了解了如何使用 Markdown 與 MDX 來撰寫網頁，接著這個章節將會學習到如何替這些檔案設置畫面布局 (Layout)。布局可以想像成是常見的頁面的模板用於管理頁面常見的模式，定義布局頁面可以解省重複並統一管理頁面。
通常文件會伴隨著圖片，而圖片可以佔據一個頁面絕大多數的運算資源與流量！你會希望圖片能夠被好好處理避免它們壓垮整個網站的體驗，Astro 預設自帶相關的元件與方法幫助你處理這些事務。了解儲存圖片位址 src/ 和 public/ 的差異與如何最佳化圖片。
撰寫網站最終還是要回歸到易於維護，能不能不需要接觸程式，只需透過編寫文件就能更改頁面內容呢？也就是將內容與版面、邏輯做分離。本章節我們將會學習 Markdown 與 MDX 來達成這件事，它們主要用途是作為傳達與標記內容。
在上一章節介紹了基礎元件的使用，並且你也大概猜到了，只要元件放置在 src/pages/ 之內就會自動的成為 Astro 的頁面，在本章節會更細緻的介紹關於 Astro 的路由設置。Astro 採用的路由策略被稱為「基於檔案的路由 File-based Routing」。
前面章節了解到在 Astro 中引用不同框架的元件是極其容易的事情，但這些元件中的狀態要怎麼去管理呢？在一些 UI 框架中會提供創建 `context` 的方式來管理狀態，但由於 Astro 採用「局部 Hydration」的方式來渲染頁面，因此無法辦到，但我們可以額外使用 Nano Stores 來達成這點。
前面提到如何在 `.astro` 格式中添加客戶端 JavaScript 使元件具備互動性。Astro 最吸引人的一項特點就是可以整合各大 UI 框架到元件之中，享受不同技術與其生態域帶來的便利與好處。在本章節將會從安裝整合到製作一個 React 元件。
當你希望 Astro 處理腳本時可以直接撰寫 <script> 標籤到元件模板之中，當需要直接插入行內腳本可以使用 is:inline 模板指令。通常操縱 DOM 的行為都會放在客戶端腳本中，像是事件監聽、動畫、Ajax……一切與瀏覽器貼近的行為都會放在這裡。
這個章節更偏向我在 Astro 中使用 Tailwind 的歷程心得，如果你沒有打算導入 Tailwind 可以直接前往下一章節即可。透過兩個章節都在練習寫按鈕，現在推薦你嘗試撰寫各式各樣的元件熟悉使用 Astro，對你來說都不會是問題了。
網站中要用到許多種類的按鈕，在本章節綜合了先前「基礎元件」與「樣式」兩章節的內容，打造出一個通用的網頁按鈕元件，一起來實作看看吧。按鈕是網頁極具代表性的元件之一，下一章節講解整合 Tailwind 也會以這個例子出發，敬請期待！
綜合來說 Astro 讓你用自己習慣的方式撰寫 CSS，不管是 import 還是 <link> 還是 Scoped CSS 或是各式各樣的預處理語言或框架皆有支援。stro 中撰寫樣式是一件非常容易的事，並且有多樣選項可供挑選。
藉由本系列文章將持續 30 日不間斷的更新帶領你上手它！今日介紹構成 Astro 最核心的概念 —— 元件。前面除了創建新專案之外也了解了 Astro CLI 與設定檔的大致樣貌，本章節會從創建基本 Astro 元件開始。
藉由本系列文章將持續 30 日不間斷的更新帶領你上手它！今日介紹 Astro 的 CLI 指令與設置 `astro.config` 檔案。你可以使用自己喜愛的套件管理器來執行 Astro ，不管是 npm、pnpm、yarn 甚至是 bun。
藉由本系列文章將持續 30 日不間斷的更新帶領你上手它！今日介紹如何從頭建構一個專案並且了解資料夾結構。前面提到 Astro 是如何建構頁面的，像是將網頁拆分成「元件」以及透過 Astro Island 的方式來建構網頁，接著本章節就要來實際創建一個 Astro 專案囉！
藉由本系列文章將持續 30 日不間斷的更新帶領你上手它！今天理解到了動態網站與靜態網站的區別，關係到了網頁「渲染模式」的抉擇，而 Astro 就及是一個瞄準生成靜態頁面為主的框架。要了解 Astro 的優勢就需要了解現有的問題，需要進一步了解什麼是所謂的「靜態網站」什麼是「動態網站」。
藉由本系列文章將持續 30 日不間斷的更新帶領你上手它！學習 Astro 將會成為前端開發的一股新氣象，事實上也被前端社群評價為：「最喜愛的」、「最期待的」新技術之一，憑藉著它極為平緩的學習曲線、活耀的社群、踩到痛點的定位和極高的擴充性，它可以輕易上手成為前端的主力生產力工具之一。
近兩個月來在軍隊中學到的三點重要能力，時隔兩年重溫的兩個月軍旅生活說不上會對人生有什麼大改變，但讓我重新體會到自由的可貴。距離上次當兵已是 2 年前的事，在大學畢業後提早申請入伍進入了桃園楊梅再服役兩個月，這篇文章主要想在沒文章產出期間分享一下這兩個月來的感想與活動。
很多時候都會忽略掉 HTML 本身就有很好的支援輸入控制與提交，輸入選項的功能與介面都可以輕易的透過原生 HTML 標籤來完成，只要想要在網頁中提交資料，都是使用 HTML 表單的好時機，讓我們來了解怎麼使用 HTML 表單製作一個無障礙且語意化的輸入表單。
程式中出現錯誤是必不可少的，有千萬個原因可能造成程式出現錯誤無法運行，這時候在 JavaScript 中就可以使用 try...catch 語法來處理錯誤情境，除了攔截錯誤也可以自行定義與拋出錯誤，讓程式中的錯誤更容易被理解與管理。
NPM 是 JavaScript 開發環境中一定會使用到的一款套件管理器，本篇文章將比喻導演一部電影來解釋 NPM 如何運作。寫程式就像在拍攝一部電影，可以親自上陣設計並打理演員，也可以聘請別人設計好的，NPM 就像一個平台可以在上面找到很多現成的演員，這些演員就是套件（Package）。
null 與 undefined 兩者的意涵非常相近，意思都是「沒有東西」，但在根本上它們是截然不同的東西，雖然都代表「沒東西」，但一個是「存在沒東西」一個是「不存在沒東西」，藉由這篇文章我來釐清解釋他們兩者之間的關係。
通常寫多個 h1 都會被教育這是錯誤的做法，但實際上真的是如此嗎？我深入的研究各方面說法。整理 Google 與 MDN 文件的說法，一個頁面有很多個「重磅級標題」的情況非常少見的，如果這麼寫在閱讀架構上是合理的話，使用多個 <h1> 在單個頁面之中是完全沒問題的，此外有許多更值得探討的細節。
useEffect 是 react 中一個相當基礎常見的 Hook，要真正學會它就必須要對 React 如何運作有基礎的認識才行，它是 React 提供的一個 Hook 用於操作副作用，舉例來說：送出請求、操縱 DOM、設定監聽器……等都是副作用。
流程控制是程式語言中基礎不可少的概念之一，除了使用 if、else 之外，JavaScript 還提供一個簡潔的寫法，就是條件（三元）運算子，顧名思義，由三個片段所組成，分別是：「條件、成功流程與失敗流程」。用更精簡的語法來撰寫流程控制，條件運算子是常見且必學的語法之一
在 JavaScript 中函式可以使用任意數量的參數與引數，如果參數沒有對應的引數將導致該變數成為未定義，參數（佔位符）代表一個值你期望函式所接收；引數（實際值）則是函式呼叫時所傳遞的值，讓我們用預設參數來解決這個問題吧！
在 JavaScript 中活用 ES6 帶來的加強版物件實字可以精簡程式片段，甚至還可以動態的計算創造物件內的項目！實字(Literal) 指的是代表它自己的數值，舉例來說數字 `25` 或 `你好世界` 而進階物件實字就是在物件中使用的值。
我喜歡使用自動化的工具來為專案的代碼提供錯誤檢查與整理，因此使用 ESLint 與 Prettier 讓撰寫的代碼更一致無錯，還有額外添加 TypeScript 的檢查與 VSCode 提示，本篇文章有詳細的教學範例引導你在 Astro 中安裝 ESLint 與 Prettier 套件。
記錄一下我是如何製作自己的前端作品集的，隨著從大學畢業，很快也要步入社會尋找正職工作，因此急需一個可以展示自己作品的平台，既然身為前端開發者，何不動手製作一個作品集網站呢？製作自己的作品集是必經歷的體驗，也是一趟很有趣的體驗。
Astro 作為一個靜態內容為主的生產器非常適合用於打造靜態網頁，這次我將用自己的作品集為案例教你打造一個實際的靜態網站，透過以自己的作品集網站為範例，借助這個機會來展示這個框架好用與強大的地方。只需要有基礎的 HTML 與 CSS 知識就能跟著這篇文章創造一個屬於自己的作品集。
有時候為了裝飾用途會需要用圖片來顯示標題，於是我開始思考「把圖片放在標題裡面」是不是和規的 HTML？是不是一個好的作法？主要查閱了 Google Search Central 的回應以及 MDN 文件，結論是和規的，以及有更多可以留意的細節。
目前本部落格就是使用 Astro 所建構，在從正式版還沒推出之前就使用著它來創建網頁到目前算是小有心得，加上也有許多人詢問過，於是就寫這篇文章來分享一下。在這之前我使用過很多不同的框架，像是 Next、Gatsby、Jekyll、HUGO，它們都是很好的框架，但一直沒有戳中我的需求……
當建構一個網頁的時候，最首要面對的問題就是「網頁內容要怎麼生成並提交給用戶？」，而為了解決這個問題所產生的解決方法就是「網頁渲染模式 （Rendering Pattern）」。建構網站有許多種方式，藉由了解它們之間的取捨可以更好的幫助你建構下一個網頁專案。
總結在六角學院擔任線上助教一年來總結的三大心得以及給同學助教老師們的話。從去年七月至今已在六角學院擔任近一整年遠端助教，準備在下個月畢業、服兵役並開始下段旅程，打算藉由這篇文章談談這段時間的心路歷程與未來的規劃。期待六角學院未來的發展，培養更多新一代的工程師。
圖片是豐富網頁內容避不可少的元素之一，大家都會在網頁中添加圖片，並且大多數網站中圖片與影片是傳輸資料中最繁重的存在，了解如何改善它們是最划算的選擇，如果網站效能或加載速度出現問題，第一步可以從圖片或影片開始改善。讓我們先從簡單的例子一步一步找出潛在的問題以及如何解決，了解圖片實際上有很多有趣的細節可以調整。
「什麼是 Ajax 以及為什麼不是 Ajaj？」，這個問題一直在腦海中停留許久，有人和我一樣思考 Ajaj 之類的稱呼的可能性嗎？經過一些調查了解背後的原因並寫成文章，關於 Ajax 的歷史以及名稱的由來可以參考看看我的發現。
響應式網頁內的內容像水一樣，順應著瀏覽器的尺寸(容器)自動填裝，只要內容擠破容器就會產生 x 軸，因此解決方法無疑就是「找出網頁中超出瀏覽器寬度的元素」。這是大多數人困惑的地方「知道問題點，但是不知道怎麼下手 🥺」。實際上這個問題的解決方法很簡單，本篇文章提供提供兩種解決方案。
指标就是为了能够客观的测量网站体验而生的统计数值，本篇文章挑战用自己的方式去理解并解释所有Google 提出网页体验相关的指标，我发现没有必要一次性的记忆所有种类的指标，因此制作了一个懒人包与该文章，方便你我查询与学习。
唯有了解盒模型才能開始學習更多網頁切版布局的技巧，本文由內至外拆解盒模型，並且解說相關的特性與屬性。如果你對於網頁有這麼多間距可以被調整所困惑，或是初入門 CSS 我都非常推薦要先理解 CSS 的盒模型概念，網頁其實就是一堆箱子組成的概念。
瀏覽器已經不再是簡單的文件閱讀器，而是一個完整的平台，用戶期望網頁變得像應用程式一樣使用起來絲滑流暢，你可能在近期會很常聽到 Jamstack 這個詞彙，簡單來說它是一種現代建構網頁應用的方式。藉由這篇入門文章你可以了解：為什麼需要它？以及如何實踐這項技術。
「為什麼想經營網站？」在製作之前要好好想清楚這件事，製作網站與經營網站是完全不同的技能。舉我自己的部落格「網頁東東」為例，直到近期才比較有「寫部落格」這件事究竟是什麼的體會，透過探討分析我自己經營網站內外動力，希望能幫助你重新思考自己經營網站的真正的目標與動機。
Hoppscotch 是一個線上工具，可以讓你在瀏覽器上迅捷的測試後端提供的 API。很常遇到到後端的文件就直接上手寫程式，導致在寫程式的時候常常疏漏許多問題，像是請求方式錯誤、少夾帶參數、網址錯誤、資料不存在……等，因此我都會建議先熟悉怎麼用現成的工具來測試 API，使用圖形化的介面可以更直觀的管理 API 們。
React Hook 是 React 16.8 版本新增的功能，可以讓你在不寫 class 的情況下使用 React 的功能。「要如何區分 Hook 與方法的差別？什麼情況下在 React 裡稱為 Hook？什麼時候才只能稱為方法？」於是寫這篇文章來解釋清楚。
來寫寫對 AI 的看法，以及我如何對面對恐懼的方法與心得，如何保持一致步調學習前進。寫這篇文章主要是想傳達如何面對生活態度，正好社會上最新的恐懼「AI 取代人類」這樣的聲音正在增長，這樣的想法不只在前端，也在許多領域都有類似的聲音，像是：「繪師要被淘汰了！」、「作家要被淘汰了！」、「某某行業要被淘汰了！」屬不勝數……
柯里化就是將使用多個參數的函式轉換成一系列使用一個參數的函式，用不同的思考方式來撰寫函式，藉由將一個大函式分解成很多僅使用一個參數的函式，打造可被重複利用與輕鬆除錯的函式，透過實際製作三明治函式案例簡白的說明柯里化的概念。
閉包是一個聽起來非常難懂而且枯燥的題材，實際上概念很簡單，在了解閉包之前你必須熟悉作用域與事件佇列的概念。簡單來說閉包可以讓你在函式內獲得函式外作用域的變數，透過實際案例來觀察閉包的存在並且了解在什麼場合下會需要閉包，以及相關的取捨。
講解中「表達式」與「陳述式」的區別。表達式會產生一個值，而陳述式則是執行動作。表達式必須存在於某個陳述式中才能被使用。我回過頭來才發現表達式與陳述式的重要性，了解 JavaScript 底層的邏輯對我們使用像是 React 這類框架也有幫助。
意思是說「如果你熟悉撰寫原生 CSS 的話，那麼學 Tailwind 對你來說是易如反掌」。在 2022 CSS 調查中 Tailwind 都是最受歡迎、最多人使用的 CSS 框架，它開創性的設計理念打破了傳統語意化架構 CSS 的方式，值得嘗試看用不同的方式架構網站架構！
藉由解構語法可以快速取出目前陣列或物件的資料，是個常見且必學的語法糖。透過解構可以快速取出目前陣列或物件的資料，並且可以將取出的資料重新命名，讓程式碼更簡潔，是個簡單方便的語法，舉幾個實際例子就會發現它的用處很多且很好懂。
藉由學習 ES6 推出的展開與其餘運算子，在許多場合可以更直覺易讀的撰寫相同的程式碼，藉由動圖與實際案例來了解它們的用途吧。語法一模一樣都是三個點，但在不同的位置會有不同的效果，這篇文章也會介紹展開運算子 (Spread Operator) 與其餘運算子 (Rest Operator)之間的差異。
OBS 是 Open Broadcaster Software 的縮寫，是一個在開源社群非常熱門的錄影軟體，由於時常有錄製影片的需求，於決定把設定 OBS 的過程記錄下來，讓有需要的人可以依照簡單的圖示快速上手，從安裝到實際錄影。
總結作為六角學院助教一直以來審核作業上最容易碰上的問題，以及可以怎麼應對。本篇文章集合了各大要點與提醒幫助你寫出更好的 HTML 結構。，了解整篇文章將可以迴避掉很多同學最常踩的坑！推薦身為網頁開發新手的你看看這篇文章。
CodePen 是一個線上的模擬開發環境，功能很簡單，就是一個網頁可以在上面寫 HTML、CSS、JavaScript，並且可以直接在網頁上看到結果，而且還直接分享連結給別人看，對初學者來說介面友好基本沒有上手難度，我是非常推薦的。
總結作為六角學院助教一直以來審核作業上最容易碰上的問題，以及可以怎麼應對。了解整篇文章將可以迴避掉很多同學最常踩的坑！撰寫程式並沒有絕對的準則，留意文章可權衡的地方自行判斷即可。本篇文章記錄我撰寫程式以來的經驗與原則以及當六角學院助教審核同學時最常發現的問題。
在程式語言中最基本的問題就是問題就是如何紀錄與操縱資料，牽扯到傳值與傳址的問題，這篇教學使用 JavaScript 搭配圖表幫助你了解它們的差異。了解如何儲存變數有助於更好的操控資料，避免出現改 A 卻動到 B 的狀況。
寫程式久了會發現撰寫乾淨可被維護的程式是一件相當困難的事情，其中一個造成難維護的原因是因為「函式除了運算並回傳結果之外過程中產生變化影響到其餘的程式」，換句話說問題就是「不必要的副作用，讓程式變得捉摸不定難以理解」，因此應該了解純粹函式的定義以及如何使用，為了更進一步撰寫撰寫乾淨的代碼。
本篇文章將透過簡單易懂的辭彙介紹 JavaScript 中的 this，讓讀者能夠更深入理解 JavaScript 中 this 的使用方式與特性。`this` 會如此讓人混亂是因為它需要基於前後文來判斷，最簡單的原則就是：誰呼叫 `this`，`this` 就代表誰。
特別記錄下來，這是 React Hook Form 中非常相近的方法：watch 與 useWatch 的差異比較與說明，就連我在第一次理解他們的時候也被搞混了，這裡製作了一些可以互動的實際範例讓你馬上體會到它們之間的差異。
JavaScript 箭頭函式是 ES6 版本中新增的語法，能夠簡潔明瞭地定義函式，並且已經被廣泛的使用當中。於本篇文章中我們將會學習如何使用箭頭函式來簡化程式碼，並且了解這個語法的特性以及要注意的地方，以及它可以被使用在那些場合當中。
React useRef 與一般定義變數差在哪？我決定把他們詳細的比較寫在這篇文章中。簡單來說 useRef 是一個 React Hook 可以讓你參考一個值並不會受到 React 的重新渲染影響，透過實際代碼操作範例來理解它與類似的 useState 還有一般變數的差異。
我相信撰寫程式並沒有絕對的準則，但絕對有些常見可以權衡留意的地方。這篇文章記錄著作為助教在檢閱不同人寫的代碼的時候，留意到的一些潛在的問題……本篇文章主要是經驗的濃縮，如果要詳細的撰寫建議可以參考看看無瑕的程式碼，會有更全面的說明與案例。
絕大多數時候你不會想要使用「鬆散比對」，嘗試使用「嚴謹的比對」將程式撰寫得嚴謹精確一些。在絕大多數的情況下，你不會想要使用鬆散比對，但是在某些情況下，可能會使用它會更為便利，本篇文章將介紹相關取捨，以及你可以在什麼時候使用不同的比較方式。
如果你需要大於 3 層的嵌套，代表你已經搞砸了，應當考慮重構程式碼，應當透過反轉與封裝程式來重構邏輯。這篇文章將詳細的介紹現有問題以及使用 Guard Clauses 技巧撰寫更好閱讀的代碼，也就是透過反轉邏輯的技巧來撰寫更少嵌套邏輯的程式。
為了達成最佳化網頁加載的順序，本篇文章以實際案例說明為什麼應該使用 HTML 內建的 `defer` 和 `async` 屬性，先從問題點出發再來到三種解決方案與比對，透過原生的 HTML Script 標籤屬性及能規劃腳本的加載順序。
搜尋列是普遍輸入資料於 HTML 中最常用的方式之一，讓我們學會如何使用它。本篇文章將會練習從無到有包含介面製作一個搜尋框，可以輸入結果並比對現有資料顯示關聯的內容，是一個非常適合 JavaScript 新手的一道實用練習題目。
計數器是入門各大框架基本會見到的習題，可以說是任何 App 最低限度的功能展示。這次使用原生的 JavaScript 來重現該題目，並且一步一步的思考並改善結果，本篇文章將會練習製作一個具備加、減、重製功能的 JavaScript 計數器。
上一章節從動圖理解了非同步的概念，這一章節將會介紹如何撰寫非同步程式。從簡單的回呼函式到 Promise 再到使用 Async/Await 語法。目前知道非同步的程式實際上是透過執行環境(瀏覽器、Node.js) 所提供的 API 來達成同時間處理多件事情的。
防抖與節流是前端效能主題中必定會出現的模式，對用戶的輸入進行適當的防抖與節流處理，除了有助於提升使用者體驗之外，對開發者來說也節省掉許多潛在的資源浪費，透過實際案例還有動畫圖片一起來了解防抖與節流如何幫助我們提升程式效率。
了解單線程的 JavaScript 背後如何運作、併發處理事件背後的奧妙、拆解晦澀難懂的專有名詞。瀏覽器執行環境中的 JavaScript 是單線程的，也就是一次只能執行一件事，如此一來其他事情就都會被擱置在後，讓使用者等待。這是非常大的問題，但解決方法也非常的簡單：「不要呆呆站在那裏等！」。
代辦事項是非常常見的習題，其中需求含括了增、刪、讀、改資料，充分的模擬到未來在操縱資料時會碰上的各種情境與問題。可以說各式各樣的軟體都是一種客製化的代辦事項，透過製作代辦事項足以熟悉編寫應用的方方面面，跟著步驟寫一次來練習基本的應用撰寫。
在介紹到同步與非同步代碼時，常常會以 setTimeout 或 setInterval 來模擬程式被非同步執行的狀況，這兩種「方法」都不算是 JavaScript 的一部分，不過大多主流執行環境都有提供 (瀏覽器、Node.js)，是很好練習非同步處理 JavaScript 的起點，本文將會詳細講解其背後的故事與原理。
HTML 元素可以擁有自己的屬性，用於表達各種類的資訊，像是從外觀樣式到無障礙資訊到各式各樣的預設屬性，而 data 屬性是一個正式存儲資料於 HTML 元素的屬性，將資訊儲存在 HTML 標籤屬性上，使 JavaScript 與 CSS 都能讀取得到元素的資料。
身為前端必學如何操控網頁就需要學習 DOM，用一篇文章快速教你如何程序化的更動網頁，一起來學會如何存取、編輯與監聽 DOM，還有綜合懶人包！如果對 Javascript 物件有一定的了解，代表你已經差不多會操縱 DOM 了，如果還不熟悉，建議可以先了解後再學習 DOM API。
學習可選串聯語法可以讓我們安全的存取某個嵌套的物件屬性，就算其屬性並不存在也不會導致錯誤。存取物件屬性對開發者來說是一件非常直覺且每天都在做的事，但當資料的來源不穩定，像是使用第三方來源的資料或用戶輸入，應該如何迴避因使用不存在的值而出現的錯誤呢？來試試看可選串聯語法。
行動裝置占了現代網際網路流量的一半以上，並且這樣的趨勢只會越來越高，隨著行動裝置的普及，像手錶、手機、平板……等裝置，連結上網頁的裝置只會越來越多元零碎，而每個裝置又有不同的解析度與尺寸，因此市場對「能夠適應各種裝置」的網頁需求是大大的增加，因此出現了 Responsive Web Design (RWD) 的做法。
CSS 預處理器已經深深地改變了前端開發的方式，成為一項必備的工具。但隨著時間的轉變，新的標準持續地推出，我們仍然還需要它們嗎？在前端開發領域，常常會聽見的一些預處理器 (Pre-processor)，像是 Sass、less、stylus，是什麼？為什麼存在？這篇文章主要會探討以下幾個重點 (附帶範例)。
BEM 是一種管理 CSS 撰寫方式的一種規範。撰寫小型的網站時通常不需要特別考慮到未來樣式的命名與權級的規劃，但隨著網站的複雜度增長就必須需要一套可預測與可擴充的方式，BEM CSS 由於概念簡潔好懂，成效顯著，並且有著相對長遠的歷史被測試與應用過，很適合作為初學者第一套管理 CSS 的辦法。
前端開發者在開發過程中一些沒有想到過可能存在的小工具與網站，都打包好放在這裡，強化網站開發體驗！網頁總是有太多需要留意的技術細節，需要一個更快速簡便的方式來測試網站是某可靠？某項功能是否到位？可以參考底下的工具協助開發。
好的文檔應更容易的被撰寫，更簡單去維護，好的文檔可以幫助人們更快、更有自信的去上手某一項技術。本篇統整幫助你理解文檔可以被拆分為的 4 個種類，並且如何更好的整理、傳遞你的知識和想法，擷取自 Daniele Procida 發表的演說所總結的觀點筆記。
我們每天都會囤積大量的文件、筆記、素材、累積下來就像亂糟糟的房間一樣需要整理，如果你也同樣在困擾這樣的問題，這篇文章是為你準備的。本次文章想分享我們團隊是如何建立一個系統應對基本的檔案分工與備份的流程。好的檔案管理是可以被追溯、被規範的，這樣才好合作，好在未來被回顧。
字體是版面的靈魂，好的字體能夠更好的表達文詞間的情緒與情境！本篇文章蒐集了實用且來源可靠、授權清楚的字體網站並且是我平時設計時會考慮參考的網素材網站，像是：Google Fonts、FontShare……在使用時請務必要注意授權範圍限制。