32-bits 与 64-bits 系统差异
还记得小时候的电脑都是 32-bits 的系统，大约在 win7 的时代已经逐步的替换成 64-bits 系统了，但我还是不了解具体来说有什么差异，只记得有段时间有两种软体规格可以选择，或是某些软体需要用「兼容模式」来执行。
还记得小时候的电脑都是 32-bits 的系统，大约在 win7 的时代已经逐步的替换成 64-bits 系统了，但我还是不了解具体来说有什么差异，只记得有段时间有两种软体规格可以选择，或是某些软体需要用「兼容模式」来执行。
当处理多个加解密应用时我纳闷：「多一份金钥需要管理，意味着多一个需要防守的东西」、「如何避免用户使用一串非常简单的金钥让破解变得非常容易」。而正好有个专门的算法：金钥衍生函式 Key Derivation Function 正是为此类问题而生。
在学习 Go 时会了解到 `struct` 其实就是一串自订的资料结构，而其中栏位的「顺序」将直接影响到在内存中所占用的实际大小甚至程式的速度。了解内存对齐的概念除了「节省空间」外也能为打造「更佳的缓存局部性（Cache locality）」。
近期在开发 Go 专案时发现到提交代码流程总是有些摩擦，像是开发时习惯用 Tab 到 GitLab 上宽度就会变得很奇怪，或是一些简单的对齐问题都在无形消耗专注力。所以透过把一些原生的 Go 静态检查工具搬到 CI 上执行，确保统一的开发体验。
Redis 是十分常见的 In-Memory 资料库，工作上时不时会碰到它但很少仔细从头了解它，所以透过撰写重现一些案例达成更深刻的理解。缓存就是把常存取的资料放在能够快速获取的地方，缺点是记忆体不像硬碟适合长久保存资料，但不管是提高速度、降低延迟、降低负担或减轻成本⋯⋯缓存都是很棒的选择。
相较于 C 读取未定义数值的变数会造成安全漏洞或崩溃，或是动态语言如 JavaScript 没有数值型别初始化的问题，Go 的设计上就自动赋予了确定意义的数值避免出错与创建即可使用。具体来说在例如使用 json 反射的标签中 `omitempty` 也正是运用了 Zero Value 的概念来判断。
虽然在 AI 出现之前很难想像，但 2026 年工作上我已经很少「手写程式」而是透过 AI 更有效率的辅助开发，我相信在 AI 百家争鸣的时代不用特别执着用哪个模型或工具，挑个最新顺手的免费方案就够了，未来模型只会更便宜更有效率。
前端测试主要重点在与浏览器打交道（Jsdom、Headless Browser）且通常只与单一后端进行沟通，而后端测试则是面临截然不同的难题：分散服务与状态。这篇文章介绍实战上我如何透过 Testcontainers 创建 Docker 测试环境来达成完整的后端整合测试流程。
AES（Advanced Encryption Standard）是最广泛使用的对称加密，HTTPS/TLS、Wi-Fi（WPA2/3）、全硬盘加密（BitLocker、FileVault）……通过理解 AES 如何运作有助于了解现代安全加密如何实践。
不同网站的密码需要管理，不仅容易忘记，也存在被窃取或重复使用的风险。如果只需要扫描指纹或使用面部识别，就能立即完成注册与登录——这正是 FIDO（Fast IDentity Online）所推动的“无密码身份验证”愿景。
最近在写 Go 测试时发现官方与社群中有一种大力推崇的惯例：TableDrivenTest，我一直以为测试应该要保持简单愚蠢，但这种做法让我想到程式人的三大美德之一：「懒惰」。可能是因为这种模式通常只是测试框架包装下的方便手段，而 Go 社群文化下人人对于追求简单程式有一种莫名的执着。
纪录近期从 JavaScript 迁移到 Go 的过程中实践 Set 资料结构的方式。先前代码使用 JavaScript Set 来实现不重复资料定义，但在 Go 语言当中并没有实践 Set 资料结构，但我们可以透过改造 map 来实践。
纪录使用到其中一项 Go 1.16 的 embed 功能，可以把任何档案在编译时就包进去，进而不用烦恼路径与环境问题。如果资料需要在 runtime 被修改，那就不适合使用 embed，但如果它是「版本的一部分」，那 embed 是更安全的选择。
P 与 NP 用来描述解决问题的难度所需的时间为：polynomial time 或 non-deterministic polynomial time。将问题分类为 P 或 NP，有助于理解一个问题是否有可能在合理的时间内被解决——即执行时间不会随着输入规模的增长而爆炸性膨胀。
先前探讨到：什么是 Feature Flag 以及它解决什么问题？了解 Feature Flag 存在的价值后，今天了解更多关于 4 种类型的 Feature Flag 以及实战上的用途。不同目的的 Flag，在设计方式、生命周期、动态程度与管理策略上都有明显差异。
我一直觉得事情可以保持简单就好，有问题改程式码或环境变数切换就好，何必导入更复杂的套件管理与第三方服务呢？但真实情境当问题发生时不会有空闲慢慢部署与除错，就有必要透过更完善的 Feature Flag 规划来降低推送功能的风险，也能减少心脏病发作的机率。
通常有些规模的专案会透过架构分层的方式来管理，而近期在研究如何更好的透过「依赖注入」替换模块并实现更干净的测试。架构分层的概念可以参考之前写过的：Express.js 入门建构 MVC 范例。我上传了 go-gin-testing-todos 范例透过 DI 实践测试架构。
从 JavaScript 转写 Go 我其实还是不太熟悉 Go 如何模组化处理代码，虽然它们有大致相似的地方，但使用体验感觉非常简单甚至到简陋的程度，当然简单并不意味着「容易」或「没用」，Go 简单且固执己见的哲学在各方面都感受得到。
很早以前接触资料库就有听说过「N+1 问题」，不过一直没有写下笔记认真思考过一次，这次撰写问题成因与详细解方与图表。透过：资料结构设计（去正规化）、在 DB 层完成关联资料查询、批次查询并在应用层组装、ORM ODM Eager Loading 来解决。
处理传递资料时都快忘了有「序列化与反序列化资料」这个步骤，因为都被套件像是：Axios 抽象掉了，近期在写后端也重新温习相关知识，也延续先前文章：Go Struct Tag 是什么？如何透过 reflect 动态处理栏位？探讨 Go 如何处理序列化资料。
学习高阶程序语言通常都会接受一个观念是：「没用到的变量会自动被垃圾回收掉」。不过越接近底层或开始探讨性能问题，发现自己对于程序语言核心的记忆体概念 Heap 与 Stack 并没有那么清楚。程序语言究竟是如何分配与管理记忆体的？所谓的垃圾回收（Garbage Collection, GC）具体来说又做了哪些事情？
Context 是 Go 1.7 添加于标准函式库的功能。常在存取资料库或其他服务时会遇到，初步看起来是用于「传递取消信号」用途的语法，用于处理 goroutine：背负期限（deadline）、取消信号（cancellation signal）、传递请求相关的值（request-scoped values）。
随着越来越多的软体推广与强制双重因子验证 2FA，我的手机也装上了 Google Authenticator，但老实说，很长一段时间我只知道「打开 App → 输入六位数字」，对于这组数字为什么会一直变、伺服器又是怎么验证的，其实没有真正了解过。直到最近在测试一些相关登入逻辑才回来补齐这块知识。
我一直对程式中日期存在个模糊不可靠的概念，通常依靠方便的库像是：dayjs 去处理日期转换，但底层的原理至今仍不是很清楚，只知道时间是相对的，且存储方式可能是某种标准格式，这篇文章将尽可能补全程式处理时间所需要的知识。关于时区的规则与电脑运算存储时间的概念。
虽然之前制作过一个笔记网站有建构用户注册的部份：my-note，但没有笔记下来发现忘了很多概念，碰巧看到我看过最简单好懂的解说影片：You're Storing Passwords Wrong. Here's The Fix - LearnThatStack，把密码保存相关的知识都纪录一下。
近期在 Go 处理字串时发现对于电脑处理文字的原理不是很透彻，所以翻了更多教学文件了解电脑是如何处理文字的。历史上电脑如何处理文字？以及后续 ASCII、Unicode、UTF-8、UTF-16 相关演进特点与背后取舍，了解为什么现代文字编码都使用 UTF-8。
当在 Go 字串中索引位置 `n` 时，为什么没有得到第 `n` 个字元？相较于其他程式语言一串文字在遍历时会预期拿到单一个字符，在 Go 会拿到「Rune」；如果直接透过索引取得 string 内容会拿到 byte。透过实际解 Codewars 题目了解处理字串要留意的东西
最近在与 MongoDB 互动时发现 Struct 栏位结尾有一段语法不是很熟悉，这篇文章探讨 Struct Tag 存在的原因以及解决什么问题。与其命令式的操纵资料，透过宣告式的方式来描述资料格式是 Struct Tag 的主要用途。
「对称加密」就是通讯双方进行加密与解密使用相同的金耀，但除了双方都要保守金钥外，怎么让双方都持有相同的金钥本身就是个问题，存在被劫持的风险（中间人攻击）。 「非对称加密」透过一对金钥（Key Pair），也就是公钥与私钥来解决对称加密会遇到的问题。
在 Go 语言中，有两种常见的资料结构可用于表示「序列资料」：Array 与 Slice。这两者在语法上相似，但背后行为与使用情境差异非常关键。简单来说，Array 是固定长度（Static Array），而 Slice 是动态长度（Dynamic Array）。
近期工作上计划将 GitLab 迁移到 GitHub，但光是腾出时间进行专案迁移就感觉很麻烦，也因此很多计画被耽搁着，像是建构 CI 自动化测试环境、导入 AI 代码审核。幸好 GitLab 很早就有一项功能叫做 Mirroring。
对于 TypeScript 的泛型我一直有种恐惧，什么满满的 `<T>`、`<U>`、`extends`、多层嵌套，看起来就很可怕。毕竟在日常开发里，好像也不太需要……对吧？的确解决小问题如此，但在特定问题下泛型将会非常必要。
前端 UI 一直是多变且复杂的题材，经历各种工具迭代与起伏，有很长一段时间其实并没有什么特别统一良好的方式进行测试。在经历过太多次的跌宕变化过后，纪录我认为现阶段怎么打造可被验证的前端与未来趋势与过程中实际遇到的各种困难。
之前提到 JavaScript 的 Iterator Protocol：什么让 JavaScript 数据结构能够被迭代？ 了解 Iterator Protocol 与 Generator，数组自然受惠于最近推出的 iterator helper 进行惰性求值。
你有想过为什么阵列可以被迭代处理（for...of）但物件不行吗？ Iterables 背后仰赖 Iterator Protocol 来实践可被迭代的资料结构。基于 Iterator Protocol 的概念更是伸展到 Generator Function 相关的知识点，可以创造更多特殊的资料结构。
Functor 的好处是：它让我们能用同样的方式操作不同的「容器型别」，想像成一个「装值的盒子」，它允许我们对盒子里的值进行运算，但同时又保留了盒子的结构。 Functor 「提供了方式在容器里操作值」，遵循同一性（Identity）与合成性（Composition）。
从先前 Functor 的概念出发，Functor 的 `map` 只能作用在数值上，而不能是「存在于容器中的数值」上，所以才需要 Applicative Functor，一种比 Functor 更多功能的结构，除了满足 Functor 的功能外还能「让盒子里的函数作用（apply）到另一盒子的值」。
一种代码风格，着重于函式的组合关系而非具体资料，定义函式时不显式提其参数（points），而是透过函式组合与高阶函式来表达资料流动。可以减少不必要的命名保持代码简洁与达成更好的通用组合性，但是额外的抽象须被理解与熟悉。透过两个实际案例熟悉 Pointfree 开发风格。
我不是数学家也对于范畴论没有太大兴趣，但它深刻的与 Functional Programming 进阶理念挂勾，透过实战了解开发层面这些理论可以如何撰写更好维护的程式。 Functor 是一种具有 map 方法的结构，允许对其中的值进行转换同时保持结构不变、让函数可以基于容器进行组合，意味着可以被用于封装副作用或情境。
最好的用户体验是即时的，因此追求更短的等待时间和更快的反馈非常重要，然而匆忙的将任何信息显示给用户未必是最佳体验，举例来说：1.进入网页 2.反馈“加载数据中……”3.显示加载完成的数据，以上流程简洁实在，会有什么问题呢？问题出在时机和时间。
对于「多型 Polymorphism」的概念理解像是「要做一件事，但这件事对不同对象来说实践的方式不同」。具体来说像是各种「形状」都可以「算面积」，但背后实践的方法却不同，而在 Go 当中 interface 就是方法的集合。
第一次看到 Go 的 Receiver 函数会觉得这是啥怪语法，函数名前面还能接收参数？Go 语言提倡「Composition over inheritance」，并极力追求代码的简洁性，以此规避 class-based OOP 所带来的复杂性。
Go 设计上一切数值都是直白的「Passing by value」，会有「Passing by value」的效果原因是因为 Reference Types 带有指标，复制时是复制指标值。要让 Value Types 有 Passing by Reference 的效果要显式的使用 Pointer。
前端生涯中遇到无数攸关资料呈现的需求需要解决，而 TanStack Table 是一款第一眼看起来很多余复杂但实际上能省下无数时间的一个优质套件，如果有任何「大量表单、中大型表单应用」我会强烈推荐。在实际工作中我透过导入 TanStack Table 在几天时间内就能把现有表单大多复杂功能重现。
使用 TypeScript 确保程式型别安全以维持大型前端专案的品质和维护性已经是很成熟且常见的做法，但有一项最常见的破口会让程式变得脆弱且混乱：「程式间 API 沟通」。 TypeScript 本身虽然能静态检查程式内部的型别正确性，但只能在程式执行阶段验证资料格式才能真正确保型别安全。
UI 通常仰赖设计者与前端耗费大量时间精力进行组织与维护，近期工作上进行前端翻新也遇到大量陈旧代码需要翻皮的作业，问题是谁有时间一个一个重新替换？尝试串上 Figma MCP 与 Shadcn MCP Server 让我们透过与 AI 聊天就能精准打造前端介面。
渲染永远是网页运算中极度耗费效能的一块瓶颈之一，而在像是仪表板应用或是大量资料清单如社群媒体版面很容易会遇到前端渲染效率上的问题，透过「只渲染看得到的东西」来减少效能负担。这种模式通常称作 List Virtualization（虚拟化看不到的东西）或 Windowing（只渲染视窗内的东西）。
AI 解决一些上下文清晰的小题目如 LeetCode 会发现它通常有惊人的效率与准确率，然而在真实情境下 AI 通常没有这么厉害，因为环境上下文和需求是模糊的，如何更好的让 AI 看清与外部世界互动能够达成更有效率的产出，而 MCP 是一种大型语言模型的统一协定帮助达成该目标。
先前文章提到：如何优雅的于 Vue 正确的处理资料载入点出了一些获取外部资料延伸带来的问题与实际解方，这次我想透过 TanStack Query 的视角挖掘怎么建构更好的前端资料获取体验。本篇教学继续延续使用 Vue 框架，不过概念对主流框架基本相通。
TypeScript 型别定义档案通常就是在全局创个 type.ts 档案并把所有型别丢里头，随处都能引用很方便，但很多专案初期沿用的习惯到了一定规模就会开始混乱，近期也遇到相关的问题因此研究一下一般有哪些方式管理型别档案。
还记得之前参与某个专案使用 Git Flow 的方式管理产品发布，但随着时间过去它与持续进行中的主支线差距越来越大，也是在那次问题之后我更认可 Trunk Based Development 流程的概念，其中提到 Feature Flag 是一种很好的技巧用来降低推送功能的风险与控制程度。
当只有 10 行代码改动还可能会细心检查留言，当有 1000 行改动一切都 LGTM（Looks Good to Me）！要让人好好集中精神盯着几千行的代码改动本身就是很难得的事，身为提交的一方，有没有可以改善审核效率的方式？或许能试试看 Stacked PR。
如果你在考虑建立基于 Tailwind 的元件库这篇文章值得一看，探讨当下前端环境背景与 UI 扩充难题与问题是如何保持元件弹性点出 Shadcn 如何成为 2025 最热门的 Tailwind 元件解决方案，正巧最近又在导入 Vue Shadcn 就来更齐全的回顾这项工具。
在网页提到 E2E 测试通常有 Cypress 与 Playwright 两种选项，而两种测试工具我都尝试过。单论整体开发体验来说我更喜欢 Playwright，不过还有更多可以考虑的要素在选择合适的测试工具，纪录我会在意的细节与选择原因。
近期在回顾一些测试的概念，其中有个测试金字塔的概念来自于 Mike Cohn 的书 《Succeeding with Agile: Software Development Using Scrum》。还没有看过这本书，但这个词汇只要有研究过测试多少都会接触到，这次来重新了解一下并输出自己对这个议题的理解。
近期不管是用 AI Vibe Coding 还是工作上切换不同功能感觉使用 git stash 不是很方便，虽然大致知道有 git worktree 但都还懒得学直接先跳过。这次有空来学如何使用 Git Worktree 快速切换复杂的专案情境。
近期要重写很多的 Vue 发现多得是我需要多补充的知识。你可能了解 Vue 组件间通过 props down 与 event up 或是使用 Scoped Slots 来传递信息。还有一种做法是「显式地暴露某些变量或函数给父组件使用」。
JWT 也就是 JSON Web Token，一个基于 RFC 751 的标准，可用于在两个实体（如前端和后端）间进行 JSON 物件的传输。由 header、payload、signature 三种资料所构成，透过 . 来区隔并使用 Base64 编码以便传输。
验证（Authentication）与授权（Authorization）是存取控制中两个常被混淆的概念，背后分别代表两种问题：你是谁？你被允许做哪些事？同时也将介绍几种常见的授权模式，例如 RBAC 与 ABAC 管理授权。
要了解 Jamstack 架构解决什么问题，需要先回顾网页演变的历史，从静态档案到动态伺服器渲染再到客户端渲染，Jamstack 的核心概念是强调预先生成静态页面并解耦商业逻辑与内容，以提高网站效能、弹性与安全性。适合大多数动态资料不多的网站。
近期预览我的线上履历时发现阅读体验有点生硬，甚至最糟的情况下会裁到文字行间，导致没有任何提示指明可以继续往下滑动，这篇文章描述如何透过 CSS 伪元素达成卷动元素淡入的样式。这个样式我应用于自己的线上履历或 CodePen 范例可以参考看看。
最初是看到 Glitch 网站 图示像冰箱磁铁可以随意挪动的功能觉得充满趣味，背后是使用 react-draggable 套件制作。不过考虑到速度与维护性，部落格不打算因为一页特效就引入额外套件，所以从头用 DOM API 手刻了相关功能。
单纯透过 SQL 与关联式资料库直接沟通，可能会带来开发效率与安全性的问题，因此挑选一款合适的 ORM 多一层抽象是常见的选择，而 Drizzle ORM 是我最常使用也是接触 ORM 的起点。它在 TypeScript 生态中有出色支援，虽然相对新颖，但社群活跃，值得一试。
刚接触后端时我还不清楚如何有效重现服务供其他开发者使用，直到遇见 Docker 才大幅简化各种设施的维护与重现的工作，是一项非常高回报的实用技能，本篇从实做角度透过 Docker 建构 Postgres 服务，了解它的便捷快速。
开发网站无可避免的会和关联式资料库打交道，而互动的方式有三种：SQL、SQL Builder、ORM。这三者有着不同的使用方式、优缺点与适用场景，了解它们的差异能帮助我们做出更适合专案需求的技术选择。分享我在 Node.js 的学习经历。
近期很频繁使用到台湾最知名的求职平台：104 人力银行，其中个人资料选单的体验有潜在的问题值得挖掘。就目前 104 的体验对我来说没什么好抱怨的，就是最少这个 `0` 如果能改成 `-` 或 `载入中` 代表无资料都清楚得多阿！就和 `0` 与 `null` 一样，它们相近的意义是不同的。
在团队中冲突是不可避免的，发现遇到太多次需要解释对于团队冲突的看法：「不同意但致力（Disagree and Commit）」，所以特别重复习一次并写成文章推广。 1. 鼓励讨论 2. 设立决策停损点 3. 不要事成定局后，方才提出意见或办法。
为了厘清自己电子阳痿或对事情提不起兴趣的念头，一直回忆起某天偶然读到一本书的推荐《有限与无限的游戏》，里面提到世上有两种游戏的概念发现对于梳理看待「游戏观」是有帮助的。不幸的是，时间确实在流逝。时间飞快地流逝。过去在增加，未来在减少。可能性在减少，遗憾在增加。
在打造多语系网站时，许多人会关注翻译的准确度或切换体验，但往往忽略了一个对 SEO 非常关键的设定：`hreflang`。正好最近把部落格和个人网站模板的多语系都调整完成，它们都是需要重视 SEO 的静态内容网站类型，其中的经验我纪录于这篇文章当中。
在先前的文章提到如何使用 Lighthouse 这款工具监控前端大大小小的最佳实践，例如：效能、SEO、适用性……等能被客观测量比较的数值，虽然很方便但你可能会希望自架 Lighthouse 服务，以便实现：搜集与管理自己的隐私资料、持续性监控同个网站的检测资料、减少依赖第三方伺服器服务。
随着服务增多也出现了维护上的困难，要如何知道自己与第三方的伺服器有好好在运作？可以额外再开设一个伺服器再去专门监控其他伺服器的状态，而 Uptime Kuma 就是一款开源免费的监控工具。我用它来监控所有对外的服务确保在第一时间出问题或服务时好时坏时能得知并着手修理，算是一个简单但实用的好工具，展开监测服务的第一步。
身在前端有几个必须知道的浏览器存储方案，重点差异在于： 容量上限、有效期限设置、是否与服务器互动，各自有不同的特性适合运用在不同场景。之外也有许多延伸的问题如： Cookie 与法规、资安漏洞防范相关设置、除存字符串以外的数据结构。
近期在面试考一些常见逻辑测验题目而在与朋友对谈到这件事的过程中，发现一种观点是「时间到也宁愿留白也不要乱填」，以免被发现了仰赖运气不懂装懂又要解释。我很讶异自己当过多年的学生，却是第一次反思这项行为背后的动机与取舍。人的偏见不是那么轻松就能够改变的，但透过思考能更明白自己是否知行合一。
随着博客文章逐渐增多，静态生成压力也随之上升，例来说在日常开发会需要近 10 分钟的时间，大多是生成图片占据大多时间，建构预览图的数量是：`(语言 x 文章数量)`。延续最大程度的静态渲染是合理的选择，而针对 OG 图片渲染可以包成 Serverless Function 在需要时呼叫。
近期在尝试 n8n 时碰上了不少麻烦，但在问题解决后觉得其实也不是什么太大的问题但就是莫名的卡住流失了许多时间，我踩过的坑或许也是你踩过的坑。这篇文章适合像我一样没特别看文件直接跳进去玩的开发者，后续细读文件反省把问题都列出来。
网页东东至今仍完全以本地为主，所有代码、字体、图片影片与文章内容都记录于 Git 当中，并通过 Git LFS 来管理大文件。这样的决定有好有坏，其中一个问题便是内容与代码的耦合高，任何一个想维护的人要把我撰写的几百篇文章连带抓下来 😅，随着项目成熟我决定要将两者分离。
近期在琢磨刚玩上手的 n8n 的各式功能，其中在制作 AI 流程时发现如果其中一个环节不如预期整个流程重来十分的耗费时间与金钱，这时候我们就可以添加上人类的反馈，重复的修改提示词直到满意为止。在制作文章研究生成 AI 时我也运用了相关功能来达成与 AI 沟通动态调整需求的目的。
近期在熟悉 n8n 流程自动化的工具，发现值得推荐给任何人（特别是软件工程师）n8n 算是一种 low-code / no-code 解决方案可以帮助任何人通过现有的整合来快速实践流程自动化的目的。这次教学通过简单的串接 Google 服务来展现它的灵活性和强大功能。
近期工作顺代研究到使用 Mermaid 来快速生成图表，这是一个很方便的工具，可以快速生成各种图表，例如流程图、心智图、圆饼图……等，你能想到的图表基本都有支援。大致纪录一下选择这项技术的原因以及使用上的心得。 Mermaid 与 AI 结合完美的免去了复杂度，让我们能够更专注在内容上，而不是花太多时间在制作图表上。
近期工作研究到使用 Slidev 来呈现简报，一个基于 Vite + Vue3 的简报工具整合了大大小小的套件方便用网页创作简报，主要以 Markdown 来撰写内容，这样的方式让我们可以专注在内容上，而不用花太多时间在花俏的简报软体操作。
手风琴是一种常见的网页 UI 模式，通常是一系列垂直堆叠的标题可以用于展开收合显示不同资讯，在 HTML 当中有项新颖的语法 <details> 和 <summary> 可帮助快速实现类似的功能，并且配合上最新的 interpolate-size 和 transition-behavior 制作滑顺的展开闭合动画。
随着前端演进，我们时常需要依靠现成的框架轮子协助，而其中Vue 又是继React 外第二热门且成熟的选项，但很少有教学提到一个完整的专案该如何建构，以及有哪些模式可以遵循。这次来介绍一下如果从头开始我会怎么建构一个 Vue 专案，在 2025 年！
TypeScript 存在一些不太直觉但背后却有合理因素的问题要留意，像是无论传入任何对象进 `Object.keys` 都仍会返回 `string[]` 型别是其中之一，本文探讨背后因素与提供不同方向的解套方法供不同情境使用。
CORS (Cross-Origin Resource Sharing) 跨来源资源共享，是一个机制用来决定网页是否能够存取其他来源的资源，能有效防止不同来源之间的不正当资源存取。透过 CORS，可以在保护用户资料的同时，允许合法的跨来源请求。
无论如何都不轻易相信用户请求即能最大程度防范 CSRF。最近在碰一些资安的东东，发现自己对于这一块知识都比较薄弱，身为前端工程师资安通常并不是首要关注的职责，但一但有漏洞保证后果不堪设想，于是近期来补足一下这方面的知识。
总结是无论如何都不轻易相信用户输入即能最大程度防范 XSS。最近在碰一些资安的东东，发现自己对这一块知识都比较薄弱，身为前端工程师资安通常并不是首要关注的职责，但一旦有漏洞保证后果不堪设想，于是近期来补足一下这方面的知识。现代齐全的工具与文件帮助下意外执行用户提供的恶意脚本的概率已经大幅降低。
我之所以调查这个主题，是因为目前所在的团队大量使用这种模式，但 Vite 在开发中不进行 Tree Shake，导致每次开发环境都有大量无用代码被打包，严重影响开发体验。因此研究一下这种方法的理念与优缺点以架构更好的项目。
近期我对自己看待撰写程式这件事有更高的期许，除了最基本的效能、阅读性、扩充性……之外还有一个非常重要的领域就是：测试。不过程式好端端的能动就代表测试没有必要了吗？在我刚工作时实际上做了一段时间的自动化 QA 工程一段时间，不过那时候的我其实也并不明白写测试的原因，就是有程式就拿来自动化测试，并没有想太多。
发现身为初阶打工人其实通常只是看见问题并拼命解决它，但换个角度思考：“如果现在手上项目烧起来，主管定个超乎预期的时程但你也没有自己一套说法，要如何交代？”，最贴近实作的人其实是最能开出真实预估的人。参考：The work is never just “the work” - Dave Stewart 文章。
近期执行的专案在进行翻新包含了整体的视觉设计，因此前端也面临要如何同步管理产品视觉的问题。先说痛点，先前专案并没有具体的规范应该如何定义 UI 当中的数值，导致魔法数字（没有规范与描述的值）流窜于整个产品当中，造成了非常大的的困扰。我会解释得尽量具体明白如果要重新设计一款数字产品会怎么管理其中的数值。
先前提到「添加深色模式要考虑的代价」无可避免的会增加比预想中还要多的成本，但如果能在一开始用正确的方式制作网页风格，那么可以有效的避免掉许多问题。如果你希望制作不同风格的数字产品都可以参考本篇文章，用更省力的方式定义风格。
Git 允许我们纪录任何档案的变更，并且可以轻松地回溯到任何一个版本，但是当需要储存大型档案时Git 就会显得力不从心，因为Git 并不是为了储存大型档案（图片、影片、音乐……等二进制档案）而设计的。而这次介绍的 Git Large File Storage 是 Git 的扩充，专门用于解决以上问题。
如今 Git 与 GitHub 已经成为业界主流，有很大机率你的专案也会使用到它们来进行版本控制，但由于 GitHub 是一款基于 Git 附加的服务，所以我们时常会轻视它的功能，其实 GitHub 有许多不错的功能却不是那么明显，因此主要分享一些我认为有用但日常使用没有查觉到的功能。
近期将公司的新 Nx Monorepo 架构专案透过 GitHub Action 添加了自动更新套件的功能，会想实践该功能是因为旧专案疏于更新导致吃了非常多的苦头，希望在新架构下可以有更轻松且自动化的方式去执行更新。其中 Nx 有专属的 nx migrate 指令帮助我们达成这件事，并且背后有些非常有趣的机制与理念。
近期维护的项目希望引入深色模式，但分析后我认为实现这个需求并不是一个划算的选择，本文将讨论原因。如今许多网站和应用程序默认提供深色模式，这是一种将背景色转为深色，前景色转为浅色的设计手段，具备各种功能性和情感上的特点，例如：节省设备电力、降低眼睛疲劳……
近期在替项目做大型重构，其中就有将技术转换为 TypeScript 与 Monorepo，途中一些还没有头绪如何解决的类型问题，就会使用 `@ts-ignore` 或 `@ts-expect-error` 来先行忽略，但这两者的使用时机有所不同，这篇文章就来谈谈这两者的差异。
近期在维护不同规模的专案，想说可以了解一下不同 Git 分支策略的优缺点来替专案选择适合的开发策略。现阶段我最常接触的是 Gitflow 的方式来进行开发，但发现这样的策略在小型规模的专案（5 人以下）并没有这么灵活好用，恰巧可以在全新的专案上尝试其他策略。
我是一个物欲非常低的人，日常东西就是用到坏才换新，直到某天常用的薄膜键盘坏了才开始寻找新的键盘。在挑选新键盘的过程中让我想到选择键盘的一些故事促使写下这篇文章。作为软件工程师不外乎每天接触到的硬件生产力工具大概就是：键盘、鼠标、电脑、屏幕、椅子、笔电、大水杯（喝水非常重要），其中键盘绝对是情感最深厚的一一个。
近期重写的专案中有许多状态需要管理，会需要统一管理资料于专案中，为了避免写死代码（Hard Coded）并且让接手的人都能轻易地了解资料型态，这里记录一些过程中的发现。结论是应该使用 as const 来达成列举资料管理，因为它更加直觉没有什么认知负担，并且更加灵活。
为什么如今网站大多数都长得差不多，就连体验也差不多？我们时常会联想设计网页是一门富含创意创新的工作，但对使用者来说创新并不全然是一件好事。本篇文章希望引导读者了解网页发展的经历并推导出为什么「无聊的使用者介面是好的使用者体验」这个结论。
身为前端工程近期工作的感悟是很多时候开发问题还是陷于界面的外观、行为或互动层面上，并不是说花时间制作这些层面的事情就很逊，它们实际需要依靠经验丰富的开发者通过多方面的研究与考量才能打造合理的架构，例如有许多要留意的事：性能、适用性、可维护性、可测试性、搜索引擎优化、跨平台兼容性、多语言……
AI 并不会离开我们的生活，并且只会越来越普及，这也意味着我们的生活将受到影响。什么事情是人类能 AI 不能的？未来的工作会是怎么样？人们能做什么来保证未来？什么事情是人类能 AI 不能的？未来的工作会是怎么样？人们能做什么来保证未来？思考以上问题。
不到 3 步骤让你的网站拥有以 WebAssembly 高效驱动的客制化搜寻功能。静态网站像是部落格、文件、个人网站、公司网站……等这类阅读体验为主的网站通常都有搜寻内容的需求，恰逢 Pagefind 1.0 的推出我把原先自制的fuse.js 搜寻功能换成Pagefind，分享如何在任何静态网站上加入搜寻功能。
近期工作接触使用 Shadcn for Vue 来打造网页 UI，这是一款基于 Tailwind 可弹性客制化的组件组合，让我们可以快速建立出符合需求的网页界面。本文将介绍现有样式库的问题及 Shadcn UI 的特色，以及为什么在前端圈这么火爆。
表单是是网站中最常见的功能性元素也是与用户沟通的桥梁，像是购买商品、注册会员、问卷填写……等各项行动都离不开它，然而这么重要的体验却时常被忽略，于是我决定整理一个良好的表单应该具备的体验以及为什么应该这样设计，供所有人了解常见的表单设计问题。
JavaScript 有 try...catch 语法用于捕捉程序中的错误情境，在需要时使用 throw 语法来抛出「任何错误」，通常建议会抛出 JS 默认的错误对象，但在 TypeScript 要怎么做才能确保抛出的错误的类型？
网页原先是静态文件，但随着需求增加，动态的改动网页的状态已变得普遍，随意使用 `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 是否和规范且被正确解读。
设计令牌（Design Tokens）或令牌是一种管理设计属性与数值的方式，用于建构 UI 最细小的元素，适当的使用设计令牌可以让设计系统更加弹性与可扩展，不论是任何职位，只要与设计系统相关的人士都应当了解设计令牌的概念。
近期公司购买了设计相关的课程，期望透过研究改良目前的设计来提升与开发合作的效率，恰好我之前的工作领域也与设计相关，而且我很早就想跨领域多写与网页相关的文章！因此打算特地开一系列文章记录课程笔记以及我自己补充的想法与资源。
开发者的工作性质造就我们注定要站在最前线与 AI 并肩作战，而 GitHub Copilot 这些年的陪伴显著的提升了我的开发生产力与更有效率的学习开发技巧，是少数我觉得真正值得付费的服务之一，不管你是新手还是老鸟 Copilot 都有对应的定位帮助你加速开发。
索取并显示资料对前端工程师来说是家常便饭的事，但随着背后延伸的状态越来越多，就会让整个专案极度混乱，因此想要藉由这篇文章点出现有问题并提出一些可行的方案，纪录寻找更高效解法的过程。在索取资料时连带的有许多状态需要被管理和调整，文章透过 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 来达成这点。
藉由本系列文章将持续 30 日不间断的更新带领你上手它！今天理解到了动态网站与静态网站的区别，关系到了网页「渲染模式」的抉择，而 Astro 就及是一个瞄准生成静态页面为主的框架。要了解 Astro 的优势就需要了解现有的问题，需要进一步了解什么是所谓的「静态网站」什么是「动态网站」。
藉由本系列文章将持续 30 日不间断的更新带领你上手它！学习 Astro 将会成为前端开发的一股新气象，事实上也被前端社群评价为：「最喜爱的」、「最期待的」新技术之一，凭借着它极为平缓的学习曲线、活耀的社群、踩到痛点的定位和极高的扩充性，它可以轻易上手成为前端的主力生产力工具之一。
很多时候都会忽略掉 HTML 本身就有很好的支援输入控制与提交，输入选项的功能与介面都可以轻易的透过原生 HTML 标签来完成，只要想要在网页中提交资料，都是使用 HTML 表单的好时机，让我们来了解怎么使用 HTML 表单制作一个无障碍且语意化的输入表单。
NPM 是 JavaScript 开发环境中必不可少的软件包管理器。本文将以导演一部电影为比喻，解释 NPM 的运作方式。编程就像拍摄一部电影，可以亲自设计和管理演员，也可以雇佣他人设计好的演员。NPM 就像一个平台，可以在上面找到许多现成的演员，这些演员就是软件包（Package）。
avaScript null 与 undefined 两者的意涵非常相近，意思都是「没有东西」，但在根本上它们是截然不同的东西，虽然都代表「没东西」，但一个是「存在没东西」一个是「不存在没东西」，藉由这篇文章我来厘清解释他们两者之间的关系。
通常写多个 h1 都会被教育这是错误的做法，但实际上真的是如此吗？我深入的研究各方面说法。整理 Google 与 MDN 文件的说法，一个页面有很多个「重磅级标题」的情况非常少见的，如果这么写在阅读结构上是合理的话，使用多个 <h1> 在单个页面之中是完全没问题的，此外有许多更值得探讨的细节。
useEffect 是 react 中一个相当基础常见的 Hook，要真正学会它就必须要对 React 如何运作有基础的认识才行，它是 React 提供的一个 Hook 用于操作副作用，举例来说：送出请求、操纵 DOM、设定监听器……等都是副作用。
我喜欢使用自动化的工具来为专案的代码提供错误检查与整理，因此使用 ESLint 与 Prettier 让撰写的代码更一致无错，还有额外添加 TypeScript 的检查与 VSCode 提示，本篇文章有详细的教学范例引导你在 Astro 中安装 ESLint 与 Prettier 套件。
记录一下我是如何制作自己的前端作品集的，随着从大学毕业，很快也要步入社会寻找正职工作，因此急需一个可以展示自己作品的平台，既然身为前端开发者，何不动手制作一个作品集网站呢？制作自己的作品集是必经历的体验，也是一趟很有趣的体验。
Astro 作为一个静态内容为主的生产器非常适合用于打造静态网页，这次我将用自己的作品集为案例教你打造一个实际的静态网站，通过以自己的作品集网站为范例，借助这个机会来展示这个框架好用与强大的地方。只需要有基础的 HTML 与 CSS 知识就能跟着这篇文章创造一个属于自己的作品集。
总结在六角学院担任线上助教一年来总结的三大心得以及给同学助教老师们的话。从去年七月至今已在六角学院担任近一整年远端助教，准备在下个月毕业、服兵役并开始下段旅程，打算藉由这篇文章谈谈这段时间的心路历程与未来的规划。期待六角学院未来的发展，培养更多新一代的工程师。
「什么是 Ajax 以及为什么不是 Ajaj？」，这个问题一直在脑海中停留许久，有人和我一样思考 Ajaj 之类的称呼的可能性吗？经过一些调查了解背后的原因并写成文章，关于 Ajax 的历史以及名称的由来可以参考看看我的发现。
「为什么想经营网站？」在制作之前要好好想清楚这件事，制作网站与经营网站是完全不同的技能。举我自己的部落格「网页东东」为例，直到近期才比较有「写部落格」这件事究竟是什么的体会，透过探讨分析我自己经营网站内外动力，希望能帮助你重新思考自己经营网站的真正的目标与动机。
Hoppscotch 是一个线上工具，可以让你在浏览器上迅捷的测试后端提供的 API。很常遇到到后端的文件就直接上手写程式，导致在写程式的时候常常疏漏许多问题，像是请求方式错误、少夹带参数、网址错误、资料不存在……等，因此我都会建议先熟悉怎么用现成的工具来测试 API，使用图形化的介面可以更直观的管理API 们。
React Hook 是 React 16.8 版本新增的功能，可以让你在不写 class 的情况下使用 React 的功能。 「要如何区分 Hook 与方法的差别？什么情况下在 React 里称为 Hook？什么时候才只能称为方法？」于是写这篇文章来解释清楚。
柯里化就是将使用多个参数的函式转换成一系列使用一个参数的函式，用不同的思考方式来撰写函式，藉由将一个大函式分解成很多仅使用一个参数的函式，打造可被重复利用与轻松除错的函式，透过实际制作三明治函式案例简白的说明柯里化的概念。
OBS 是Open Broadcaster Software 的缩写，是一个在开源社群非常热门的录影软体，由于时常有录制影片的需求，于决定把设定OBS 的过程记录下来，让有需要的人可以依照简单的图示快速上手，从安装到实际录影。
总结作为六角学院助教一直以来审核作业上最容易碰上的问题，以及可以怎么应对。本篇文章集合了各大 4 个要点与提醒帮助你写出更好的 HTML 结构。了解整篇文章将可以回避掉很多同学最常踩的坑！推荐身为网页开发新手的你看看这篇文章。
CodePen 是一个线上的模拟开发环境，功能很简单，就是一个网页可以在上面写HTML、CSS、JavaScript，并且可以直接在网页上看到结果，而且还直接分享连结给别人看，对初学者来说介面友好基本没有上手难度，我是非常推荐的。
总结作为六角学院助教一直以来审核作业上最容易碰上的问题，以及可以怎么应对。了解整篇文章将可以回避掉很多同学最常踩的坑！撰写程式并没有绝对的准则，留意文章可权衡的地方自行判断即可。本篇文章记录我撰写程式以来的经验与原则以及当六角学院助教审核同学时最常发现的问题。
写程序久了会发现编写干净的可被维护的程序是一件相当困难的事情，其中一个造成维护困难的原因是因为「函数除外并返回结果除了过程中产生变化对其他的程序产生影响」，换句话说问题就是「不需要的结果，让程序变得捉摸不定理解难以」，应该纯粹了解函数的定义以及如何使用，以便更进一步编写干净的代码。
我相信撰写程式并没有绝对的准则，但绝对有些常见可以权衡留意的地方。这篇文章记录著作为助教在检阅不同人写的代码的时候，留意到的一些潜在的问题……本篇文章主要是经验的浓缩，如果要详细的撰写建议可以参考看看无瑕的程式码，会有更全面的说明与案例。
防抖与节流是前端效能主题中必定会出现的模式，对用户的输入进行适当的防抖与节流处理，除了有助于提升使用者体验之外，对开发者来说也节省掉许多潜在的资源浪费，透过实际案例还有动画图片一起来了解防抖与节流如何帮助我们提升程式效率。
了解单线程的 JavaScript 背后如何运作、并发处理事件背后的奥妙、拆解晦涩难懂的专有名词。浏览器执行环境中的 JavaScript 是单线程的，也就是一次只能执行一件事，如此一来其他事情就都会被搁置在后，让使用者等待。这是非常大的问题，但解决方法也非常的简单：「不要呆呆站在那里等！」。
在介绍到同步与非同步代码时，常常会以 setTimeout 或 setInterval 来模拟程式被非同步执行的状况，这两种「方法」都不算是 JavaScript 的一部分，不过大多主流执行环境都有提供 (浏览器、Node.js)，是很好练习非同步处理 JavaScript 的起点，本文将会详细讲解其背后的故事与原理。
作为前端必学如何操控网页就需要学习 DOM，用一篇文章快速教你如何程序化的更动网页，一起来学会如何存取、编辑与监听 DOM，还有综合懒人包！如果对 Javascript 对象有一定的了解，代表你已经差不多会操纵 DOM 了，如果还不熟悉，建议可以先了解后再学习 DOM API。
CSS 预处理器已经深刻地改变了前端开发的方式，成为一项必备工具。但随着时间推移，新标准不断推出，我们还需要它们吗？在前端开发领域，经常会听到一些预处理器 (Pre-processor)，比如 Sass、Less、Stylus，这些工具是什么？为什么会存在？本文将主要探讨以下几个重点（附带示例）。
BEM 是一种管理 CSS 撰写方式的一种规范。撰写小型的网站时通常不需要特别考虑到未来样式的命名与权级的规划，但随着网站的复杂度增长就必须需要一套可预测与可扩充的方式，BEM CSS 由于概念简洁好懂，成效显著，并且有着相对长远的历史被测试与应用过，很适合作为初学者第一套管理 CSS 的办法。
前端开发者在开发过程中一些没有想到过可能存在的小工具与网站，都打包好放在这里，强化网站开发体验！网页总是有太多需要留意的技术细节，需要一个更快速简便的方式来测试网站是某可靠？某项功能是否到位？可以参考底下的工具协助开发。
我们每天都会囤积大量的文件、笔记、素材、累积下来就像乱糟糟的房间一样需要整理，如果你也同样在困扰这样的问题，这篇文章是为你准备的。本次文章想分享我们团队是如何建立一个系统应对基本的档案分工与备份的流程。好的档案管理是可以被追溯、被规范的，这样才好合作，好在未来被回顾。
字体是版面的灵魂，好的字体能够更好地表达文词间的情绪与情境！本篇文章收集了实用且来源可靠、授权清楚的字体网站并且是我平时设计时会考虑参考的网素材网站，像是：Google Fonts、FontShare……在使用时请务必注意授权范围限制。