AUR（ArchLinux User Repository）是 ArchLinux 的社区驱动的软件仓库， 属于不受支持的软件仓库（unsupported）。 但它却是 Arch 社区最有活力的仓库，很多官方仓库（Official Repositories）中的包都来自于 AUR。 AUR 之于 ArchLinux 官方仓库，类似于 Boost 社区之于 STL，类似于 PPA 之于 Ubuntu 官方仓库。 Harttle 在 MacBookPro 上安装 ArchLinux 时就用到了非常多的 AUR 包。

由于 AUR 中的包不受支持，ArchLinux 的官方包管理工具 pacman 不支持从 AUR 安装。 这就需要额外的工具，几年前 yaourt 独大，在很多 ArchLinux 安装教程中都会介绍如何安装 yaourt。 时至今日 yaourt 已经停止开发（discontinued），官方更愿意推荐 AUR 工具而非安装器。 因为这些包属于 unsupported，你要为安装和维护它们负责，ArchLinux 认为你应当知道一个包是怎样编译和安装进入你的系统的。

本文先介绍 ArchLinux 提供的软件包构建/安装方式，以及如何手动从 PKGBUILD 构建/安装一个软件包。 最后再介绍一些 AUR 工具。

很久以前写过一篇 安装 Arch Linux 的文章，解释在普通 PC 上安装 ArchLinux。 如今需要把一台 MacBook Pro（2013 Late）用于工作，而且 ArchWiki 上介绍安装系统的 Beginners’ Guide 也已经没有了，就借机写一篇如何在 MacBook Pro 上安装 ArchLinux 的介绍。

注意：本文介绍的是在 MacBoot Pro 上安装 ArchLinux 单系统。其他方案请直接参考 https://wiki.archlinux.org/index.php/Mac。

从 AJAX（Asynchronous JavaScript + XML，异步JavaScript和XML）开始应用， 尤其是 AngularJS 推出之后 SPA（Single Page App，单页应用）已经成为前端 App 的必选方案。 SPA 可以在客户端提供完整的路由、页面渲染、甚至一部分数据处理； 这往往需要一个比 jQuery 时代更重的 JavaScript 框架，来实现这些原本发生在后端的逻辑。 多数框架如 React、Vue 还会内置组件化机制来帮助开发者组织代码， 它们甚至进化到专门负责视图组件的程度，路由和数据交由各种插件来处理， 比如 vuex、Redux、Vue Router 等等。 这些工具已经相当先进和完整，提供了路由方案、服务器端渲染方案、前端状态管理方案。

但 SPA 的本质还是浏览器端 App，底层技术仍然依赖 history API、defineProperty、AJAX。 这些 API 的能力和完备性，决定了 SPA 能达到的用户体验和上层架构设计。 也正是这些底层 API 的不足和缺陷使得 SPA 很难企及原始 Web 的架构优势。 比如在内容可访问性（Accessibility）、服务的独立部署和演化（Independent Deployment） 等方面远不及十年前搭建的同类站点。同时还在不同程度上破坏了 HTTP、URL、HTML 的语义， 这些缺陷使我们需要花费大量精力去修复日志统计、性能优化、首屏渲染、静态分析和测试等环节。 而陷阱在于决策使用 SPA 方案时不一定能有足够的远见看到这些问题对架构带来的深远影响。

与此同时 Web 标准也在持续迭代，诸如 Web Bluetooth、Push API、Web of Things、Service Worker 的标准已经在主流浏览器（尤其考虑国内 webkit 内核的普及程度）有不同程度的支持。 尤其是 PWA（Progressive Web App，渐进式 Web 应用）概念的提出， 给出了一种在不破坏 Web 架构的前提下实现流畅用户体验的方式。 本文就 SPA 架构的一些不足展开讨论， 并探讨 PWA 方案（这里说是方案，其实更是一种技术方向的选择）的价值和私有平台的最佳演化方式。

ES5 没有定义文件之间引用方式，在浏览器中文件之间引用需要通过类似 define, require, __webpack_require__ 这样的全局变量，它们由不同的模块化框架定义。 ES Modules 从标准上定义了 JS 文件间的引用方式，而且现在主流浏览器和 Node.js 都已经有了实现。 本文介绍 Node.js 中新写的 ES Modules 怎么和旧的 CommonJS 模块相互引用， 以及如何引用 npm 上成千上万的 CommonJS 模块。即 ES Modules 和 ES5 Script 间的互操作问题。 ES5 Script 有多种模块化实现，本文集中讨论 Node.js 中的 CommonJS。

这是 Harttle 在去年发布在 百度 Web 开发者中心 的译文。为便于传播也转载在这里。 原文：https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/。 作者：Alex Russell。翻译：Harttle

摘要：如果我们继续使用这么多的 JavaScript，Web 就不会走向繁荣。现在多数开发者仍然在不加限制地使用 JS。即使有很多无 JS 和 TTI 友好的工具，但是我们陷入 JS 的泥潭无法自拔。鉴于 JS 的不对称成本，我们需要重新讨论“开发者体验”。

在 JavaScript 中很多时候都需要自定义错误，尤其是开发 Node.js 应用的时候。 比如一个典型的网站服务器可能需要有 NetworkError, DatabaseError, UnauthorizedError 等。 我们希望这些类都拥有 Error 的特性：有错误消息、有调用栈、有方便打印的 toString 等。 最直观的实现方式便是 继承 Error 类。 但考虑 TypeScript 需要编译到 ES5 兼容性问题会较为复杂， 本文用来帮助理解 TypeScript 中继承 Error 的问题来源以及对应的几种解决方式。

URL Encoding 又叫百分号编码，定义在 URL 标准 中。 在前端通过 encodeURI 和 encodeURIComponent 来分别编码 URL 和 URL 参数。 那么在 Bash 中怎么编解码呢？这在写处理网页或链接的脚本时非常有用。 本文给出两个不依赖 Node、Python 等非内置软件的编解码命令，并稍作解释。