在 MacBookPro 上安装 ArchLinux 后最大的问题就是那一排功能键和触摸板还能不能用。 功能键比较复杂涉及你的桌面系统或窗口管理器的选择， 本文解释 MacBook 触摸板如何在 ArchLinux 下进行配置。 依赖的软件只有触摸板驱动 xf86-input-mtrack 和 X11，本文应该对绝大多数 Linux 发行版都适用。（不过 Ubuntu 貌似是 Wayland 窗口服务？）

我们重点解释如何恢复 OSX 下独有的触摸板手感和功能： 自然（反向）滚动、三指选择和拖动、四指横向滑动、滚动惯性、鼠标加速（Pointer Acceleration）。 触摸板的通用配置比如敲键时禁用触摸板、手掌识别等，可以参考 Harttle 的另一篇文章： Linux 下的触摸板设置

TL;DR

文中主要介绍一些技巧和原理。心急的同学可以直接按以下步骤操作：

1. 安装 AUR 包 xf86-input-mtrack
2. 把 50-mtrack.conf 下载到 /etc/X11/xorg.conf.d
3. pkill x 或者 sudo reboot

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 方案（这里说是方案，其实更是一种技术方向的选择）的价值和私有平台的最佳演化方式。

从 ECMA 2015（ES6）JavaScript 开始标准化 ES Modules， 从 JavaScript 语言层面给出了模块的概念和 import, export 等关键字。 ES Modules 用来取代 AMD、Webpack Require，CommonJS 这些社区规范。 那么 ES Modules 和 CommonJS 有啥区别，以及新的 ES Module 和旧的 CommonJS 之间怎么相互引用呢？ 毕竟 npm 上还有成千上万的 CommonJS 模块，本文就来谈 ES Modules 和 CommonJS 之间的互操作问题。

TL; DR

1. ESM 需要不同的解析方式，因此 Node.js 中需要用新的 .mjs 后缀名。
2. CommonJS 可以通过 import API 引用 ESM，ESM 则可以直接 import CommonJS。
3. import = 语法受到 Babel 和 TypeScript 支持，但不符合 ES Modules 标准。
4. TypeScript 中通过 import * as 引用 CommonJS 的方式不符合 ES Modules 标准。
5. 使用 default-import + esModuleInterop 来让你的 TS 代码符合 ES Modules 标准。
6. 开启 esModuleInterop 之后，allowSyntheticDefaultImports 也会自动开启。

这是 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 的问题来源以及对应的几种解决方式。