Node.js 的出现，让 JavaScript 脱离了浏览器的束缚，进入了广阔的服务端开发领域。而 Node.js 对 CommonJS 模块化规范的引入，则更是让 JavaScript成为了一门真正能够适应大型工程的语言。
在 Node.js 中使用模块非常简单，我们日常开发中几乎都有过这样的经历：写一段 JavaScript 代码，require 一些想要的包，然后将代码产物 exports 导出。但是，对于 Node.js 模块化背后的加载与运行原理，我们是否清楚呢。首先抛出以下几个问题：
本篇文章，就会结合 Node.js 源码，探究一下以上这些问题背后的答案。
阅读全部作为一个前端，不可避免同时与三个语言打交道：JS、CSS 和 HTML。而 HTML，超文本标记语言，是其中可编程性最弱的，一直以来得到的关注都较少。加上浏览器对 HTML 逆天的容错支持，即使是错误百出的文档也可以在浏览器里边表现得中规中矩。这样的背景下，绝大部分被产出的 HTML 代码都存在着各种各样的小问题，比如缺少必要的元信息（meta），比如混乱的 class、id 或属性的取值格式；这些问题或影响页面在不同浏览器下的表现，或增大了页面的开发、维护成本。
因此，选用一个合适的工具对 HTML 代码进行质量控制会是一件很有意义的事情。本文选择了 Bootlint、AriaLinter、htmllint、HTMLHint 及 htmlcs 这五个目前最活跃的相关项目进行对比。除此之外还存在如 tidy、W3C/Mozilla HTML validator 等工具，但它们专注于 HTML 规范，几乎不涉及代码风格上的检查，这里就不做比较。
对比角度将主要包括以下几个方面：
为了后续说明的便利，这里先对语法风格的规则进行简单的分类，第一类包括 attr-value-double-quotes（使用双引号包围属性值）， max-length（限制单行最大长度）， tag-pair（要求需要显式闭合的标签显式闭合）等；第二类包括 script-in-tail（JavaScript 内容要求在页面最后嵌入）, title-required（要求 title 标签）, id-class-ad-disabled（不允许在 id 或 class 的值中出现 ad_，ad-，_ad，-ad 等）等。这两类规则有很明显的区别，第一类偏重于代码格式（遵循与否都不影响最终语义），这里叫它格式规则；对应地，第二类偏重语义，即最终 document 的表现，这里叫它语义规则。一般情况下，前者更适合在语法分析阶段做，而后者更适合在分析完后基于分析结果（AST / document）进行。
原文：http://blog.nodejitsu.com/scaling-isomorphic-javascript-code/
译者注：这是一篇2011年的老文了，最近苦恼于单页面应用的首屏速度与SEO问题，期望本文能给有同样烦恼的同学们带来些启示。
先花点时间想想你是有多么频繁地听到“Model-View-Controller”（MVC）这词儿，但你真正明白它的意义吗？在较高层次上而言，它是指在一个基于图像系统（非光栅化图像，比如游戏）以展示为主的应用中对功能的关注点分离（separation of concerns）。进一步看，它就是一堆表示不同事物的专有名词。过去，许多开发者社区都创造了各自的MVC解决方案，它们都能很好地应对流行的案例，并且在一步一步地发展。最好的例子就是Ruby和Python社区以及它们基于MVC架构的Rails与Django框架。
MVC模式已经被其它语言所接受，比如Java，Ruby和Python。但是对于Node.js而言还不够好，其中的一个原因就是：Javascript现在是一个同构的语言了。同构的意义就在于任何一段代码（当然有些特殊代码例外）都能同时跑在客户端与服务器端。从表面上讲，这个看似无害的特性带来了一系列当前的MVC模式无法解决的挑战。在这篇文章中我们会探寻目前存在一些的模式，看看它们都是怎样实现的，同时关注不同的语言及环境。另外也谈谈它们为什么对于真正同构的Javascript而言还不够好。在最后，我们会了解一种全新的模式：Resource-View-Presenter。
阅读全部