致想用 Node.js 的你
Node.js，09 年这个集成了 Google V8 JavaScript 引擎和一个底层 I/O API 的项目，如今项目无数，大企业也纷纷尝试。
Node.js，09 年这个集成了 Google V8 JavaScript 引擎和一个底层 I/O API 的项目，如今项目无数，大企业也纷纷尝试。
从Node.js进入人们的视野时，我们所知道的它就由这些关键字组成 事件驱动、非阻塞I/O、高效、轻量，它在官网中也是这么描述自己的。
前段时间 Node.js 发布了新版本 4.0，其中涉及到一个更新比较多的模块，那就是下面要介绍的 timer 模块。
Node.js 诞生之初就遭到不少这样的吐槽，当然这些都早已不是问题了。1、可靠性低。 2、单进程，单线程，只支持单核 CPU，不能充分的利用多核 CPU 服务器。一旦这个进程崩掉，那么整个 web 服务就崩掉了。
熟悉 Node.js 的同学一定见过 ETIMEDOUT、EADDRINUSE 等错误提示，那么这些错误信息到底是什么呢？答案其实很简单，因为 Node.js 底层使用的是 glibc 库，这些错误信息都是 glibc 库在 socket 连接时使用的 connect 函数中定义的错误类型，当然，v8在使用glibc库时也会加入一些自定义的错误类型，但许多错误情况还是和glibc中的定义一致的。
上篇文章讲解了 Node.js 中多进程部署时遇到的各种问题，那么实际的线上项目中到底是如何利用多进程，如何保障各个 worker 进程稳定性的呢，又是如何利用 cluster 模块 fork 子进程，父子进程间又是如何实现通信的呢？本篇就来一一揭晓。
笔者最近在研究如何实现页面 HTML 及内联 JS/CSS 的实时压缩功能。首先笔者尝试了在前端模块中扫描内联的 JS/CSS 并压缩，这样还可以集成至前端模块的上传工具中。观察了一段时间发现这样无法处理模板中的 JS/CSS，造成很多遗漏的 JS/CSS 不能压缩。
很多同学在选择 node 的版本管理工具时，可能第一时间就直接使用了 nvm，一般不会再去调研另一个工具 n，更没有闲情去了解这两者的特性和差异。毕竟工具能用就行，没必要搞清其运作机制。
最近在看 koa 的中间件实现时，总是看到 yield* next 这种用法，觉得很困惑。下面是学习成果。
众所周知，PHP 占据了服务端编程语言的半壁江山，正如汪峰在音乐圈的地位一般。随着 Node.js 逐渐走上服务端编程的舞台，关于 PHP 和 Node.js 孰优孰劣的争论也不曾间断。
为了解决传统 Web 开发模式带来的各种问题，我们进行了许多尝试，但由于前/后端的物理鸿沟，尝试的方案都大同小异。痛定思痛，今天我们重新思考了“前后端”的定义，引入前端同学都熟悉的 Node.js，试图探索一条全新的前后端分离模式。
在做前后端分离时，第一个关注到的问题就是渲染，也就是 View 这个层面的工作。
使用 Node.js 做前后端分离的开发模式带来了一些性能及开发流程上的优势（见《前后端分离的思考与实践 一》）, 但同时也面临不少挑战。在淘宝复杂的业务及技术架构下，后端必须依赖Java搭建基础架构，同时提供相关业务接口供前端使用。Node.js 在整个环境中最重要的工作之一就是代理这些业务接口，以方便前端（Node.js 端和浏览器端）整合数据做页面渲染。如何做好代理工作，使得前后端开发分离之后，仍然可以在流程上无缝衔接，是我们需要考虑的问题。本文将就该问题做相关探讨，并提出解决方案。
在前后端分离的开发模式中，从开发的角色和职能上来讲，一个最明显的变化就是：以往传统中，只负责浏览器环境中开发的前端同学，需要涉猎到服务端层面，编写服务端代码。而摆在面前的一个基础性问题就是如何保障 Web 安全？
近年来各站点基于 Web 的多终端适配进行得如火如荼，行业间也发展出依赖各种技术的解决方案。有如基于浏览器原生 CSS3 Media Query 的响应式设计、基于云端智能重排的「云适配」方案等。本文则主要探讨在前后端分离基础下的多终端适配方案。
关于前后端分享的思考，我们已经有五篇文章阐述思路与设计。本文介绍淘宝网收藏夹将 Node.js 引入传统技术栈的具体实践。