虽然我们生活在一个异步的世界里，但对于多数编程初学者来说，异步还是很陌生。学习一门编程语言，通常都是从同步流程开始的，即顺序、分支和循环。而异步流程是什么呢——开始一个异步调用，然后……就没有然后了。异步程序跑哪去了？

随着 CPU 从单核变多核，软件从注重功能到注重体验，Web 从页面跳转方式到 Web2.0 的无刷新加载（AJAX），程序员越来越多的接触多线程和异步。而 Android 的主线程中不允许操作网络，更是将程序员们推向了异步的深渊。异步深渊产生的主要原因是回调，这在 nodejs 里尤其严重。

前面我们聊到了可能超时的异步操作，其中提到对 fetch() 异步操作的“中断”处理。这次我们就来聊一聊“中断”异步操作。由于 JavaScript 的单线程特性，能在 JavaScript 中进行的异步场景其实不多，大概有如下一些：setTimeout() / setInterval()事件Ajax部分对 Native 方法的调用……中断 Ajax 操作Ajax 处理基本上也可以归...

网页弹框是个很常见的功能，比如需要告知用户消息的时候 (Alert)，需要用户进行确认的时候 (Confirm)，需要用户补充一点信息的时候 (Prompt) …… 甚至可以弹框让用户填写表单 (Modal Dialog)。

自从 ECMAScript 的 Promise ES2015 和 async/await ES2017 特性发布以后，异步在前端界已经成为特别常见的操作。异步代码和同步代码在处理问题顺序上会存在一些差别，编写异步代码需要拥有跟编写同步代码不同的“意识”，为此我还专门写了一篇「异步编程需要“意识”」，不过看的人不多，可能确实“无趣”。

问题 原题来自 @若泽 的提问。 可修改下面的 aa() 函数，目的是在一秒后用 console.log() 输出 want-value {代码...} 但是，有额外要求： aa() 函数可以随意修改，但是不能有 console.log() 执行 console.log() 语句里不能有 setTimeout 包裹 解答 也许这是个面试题，管它呢。问题的主要目的是考察对异步调用执行结果的...

上回写到： 没看上回的同学，在这里：在微信小程序中使用 async/await {代码...} {代码...} 这不已经封装过了吗？ 这回写的是不一样的封装。因为，一个小程序里要写好多个 toAsync 调用，真的很烦呐！ 能不能一次封装，到处调用？能！把所有用到的方法都在初始化的时候封装起来。可是，难免会有遗漏。 能不能一次封装，...

首先，最直观的问题：缩进太深。缩进最深的地方是 24 个空格，也就是 6 层。一般我们认为 3 层以内的缩进比较容易阅读，超过 3 层应该考虑使用“Extract Method”方法进行重构。

微信小程序中有大量接口是异步调用，比如 wx.login()、wx.request()、wx.getUserInfo() 等，都是使用一个对象作为参数，并定义了 success()、fail() 和 complete() 作为异步调用不同情况下的回调。

又到了年末写总结的时候。我不断地提醒自己过去这一年是 2021，不是 2022 —— 是的，作为一个使用了 VS2022 好几个月的人来说，感觉已经在 2022 好久了。然而， 2022 只是即将来临。回往昔，我都干了啥？

接口，本身只是种约定，向来只是声明，没有实现……可是 Java 和 C# 相继推出了“接口默认方法”的概念，让接口从纯粹的抽象变得有血有肉。接口的默认方法是什么鬼，接口还是接口吗？—— 这是 2020 年“边城客栈”的第一篇文章，现实世界对新冠病毒全力以赴地围追堵截时，我们在开发的世界“抓鬼”。

调用 API 访问数据采用的 Ajax 方式，这是一个异步过程，异步过程最基本的处理方式是事件或回调，其实这两种处理方式实现原理差不多，都需要在调用异步过程的时候传入一个在异步过程结束的时候调用的接口。比如 jQuery Ajax 的 success 就是典型的回调参数。不过使用 jQuery 处理异步推荐使用 Promise 处理方式。

最近在 2021-11-13 更新记录（主要更新内容）：[2021-11-13] 补充返回 Promise 对象的情况下，加或不加 async 是有区别的[2021-09-28] await 等待的不是 Promise Like 对象时 ...[2020-06-04] 解释 Promise.resolve()

为了不切换开发环境，前后端都使用 JavaScript 开发。采用了前后端分离的模式，但没有引入构建过程，避免项目分离，这样在 VSCode 中可以把前后端的内容组织在同一个目录下，不用操心发布位置的问题。具体的技术选择如下：

parallel 英 [ˈpærəlel] 美 [ˈpærəˌlɛl]adj.平行的； 相同的，类似的； [电]并联的； [计]并行的adv.平行地，并列地n.平行线（面）； 相似物； 类比； 纬线vt.使平行； 与…媲美； 与…相比； 与…相似

Node7 通过 --harmony_async_await 参数开始支持 async/await，而 async/await 由于其可以以同步形式的代码书写异步程序，被喻为异步调用的天堂。然而 Node 的回调模式在已经根深蒂固，这个被喻为“回调地狱”的结构形式推动了 Promise 和 ES6 的迅速成型。然而，从地狱到天堂，并非一步之遥！

然而为了将列表项抽象出来，以及便于对列表项的细节调整和后期可能需要实现的操作，还是把它定义成一个组件的好，这个组件就叫 Pserson，只需要把原来 map() 中的代码拷贝到 render() 的 return 中，再把 map() 中的 return 稍稍改一下

前不久看到 Dima Grossman 写的 How to write async await without try-catch blocks in Javascript。看到标题的时候，我感到非常好奇。我知道虽然在异步程序中可以不使用 try-catch 配合 async/await 来处理错误，但是处理方式并不能与 async/await 配合得很好，所以很想知道到底有什么办法会比 try-catch 更好用。

你一定注意到博文的标题变了成了“TypeScript 版 ...”。在上一篇 JavaScript 版俄罗斯方块——转换为 TypeScript 中，它就变成了 TypeScript 实现。而在之前的 JavaScript 版俄罗斯方块——重构 中，只重构了数据结构部分，控制（业务逻辑）部分因为过于复杂，只是进行了表面的重构。所以现在来对控制部分进行更深入的重构。

已经不是第一次写这个主题了，最近有朋友拿 5 年前的《Web 应用中保证密码传输安全》来问我：“为什么按你说的一步步做下来，后端解不出来呢？”加解密这种事情，差之毫厘谬以千里，我认为多半就是什么参数没整对，仔细查查改对了就行。代码拿来一看，傻眼了……没毛病啊，为啥解不出来呢？

由于 JavaScript 的动态特性，其对象本身就是一个映射表，对象的「属性名⇒属性值」就是映射表中的「键⇒值」。为了便于把对象当作映射表来使用，JavaScript 甚至允许属性名不是标识符 —— 任意字符串都可以作为属性名。当然非标识符属性名只能使用 [] 来访问，不能使用 . 号访问。

原文：What's new in C# 7 2016-12-21 译者注：原文于 2016 年 12 月发表，当时 Visual Studio 2017 还是 15 Preview 5，不过直到 VS2017 它们仍然没什么变化。

通讯录做到这个程度，应该考虑增删改功能了。但是，增删改功能的前提是能进行相应的数据持久化操作。因为需要先研究在 Cordova 中使用 SQLite。

TypeScript 为 JavaScript 带来静态类型检查，让 JavaScript 编写中大型应用的时候可以应用工具来避免部分错误。

今天回答了 @j_bleach 的问题：JS生产嵌套数组（也就是对数组分组）更好的写法。回答的过程中对 lodash _.chunk() 产生了好奇，所以分析了一下它的源码，再加上我自己的解决方案，收集了如下一些方案，分享给大家按惯例，我还是使用 es6 语法，在 Node7 中实验通过

前后端分离并不是什么新鲜事，到处都是前后端分离的实践。然而一些历史项目在从一体化 Web 设计转向前后端分离的架构时，仍然不可避免的会遇到各种各样的问题。由于层出不穷的问题，甚至会有团队质疑，一体化好好的，为什么要前后端分离？

JavaScript 使用了基于原型模式的 OOP 实现，一直以来，其封装性都不太友好。为此，TypeScript 在对 JavaScript 类型进行增强的同时，特别关注了“类”定义。TS 的类定义起来更接近于 Java 和 C# 的语法，还允许使用 private、protected 和 public 访问修饰符声明成员访问限制，并在编译期进行检查。

[学习笔记] Cordova+AmazeUI+React 做个通讯录 系列文章 目录 准备 联系人列表(1) 联系人列表(2) 联系人详情 单页应用 (With Router) 使用 SQLite 传送门：全部章节 示例代码 了解 React 的工作方式 在阅读了大量 React 的资料（主要是官网）之后，发现有两个概念非常重要 React 的基本元素是组件，所有内容都由各种组件...

随着 JavaScript 本身的完善，越来越多的人开始喜欢使用原生 JavaScript 开发代替各种库，其中不少人发出了用原生 JavaScript 代替 jQuery 的声音。这并不是什么坏事，但也不见得就是好事。如果你真的想把 jQuery 从前端依赖库中移除掉，我建议你慎重考虑。