iframe异步加载技术及性能
这篇讲的是四种iframe加载技术的性能对比与最佳实践。作者从“如何不让iframe阻塞主页面onload事件”这一核心问题出发，详细剖析了普通加载、onload之后加载、setTimeout动态加载以及异步加载这四种方法的实现与表现。 对比的关键在于各方法对主页面加载进程的影响。普通方法简单直接，但iframe加载会阻塞主页面的onload，对用户体验和页面评分不利。将iframe加载推迟到主页面onload之后，或使用setTimeout，可以避免阻塞onload，但浏览器仍可能长时间显示忙碌状态，尤其在IE8下setTimeout方案存在兼容问题。 文章重点推荐了“异步加载iframe”技术。其巧妙之处在于先创建一个空的iframe，利用其body标签的onload事件立即触发的特性，再在回调中动态创建script标签来加载实际内容。这种方法能真正实现无阻塞加载，iframe加载时浏览器不再显示忙碌状态，综合性能表现最佳。作者也客观指出，该技术因某些原因未受足够关注，但仍值得开发者在需要无阻塞加载第三方内容（如插件、广告）时深入了解和采用。
探究 Node.js 中的 drain 事件
这篇讲的是 Node.js 中一个容易被忽视的事件——`drain`，作者从自己频繁看到却不知其所以然的使用场景出发，带着“什么时候触发”和“能用来干嘛”的疑问，进行了一番探究。 核心发现直指 `socket.write` 的返回值与底层“高水位线”（`highWaterMark`，默认 16KB）的关系：只有当写入的数据量累积超过这个阈值，`write` 才会返回 `false`，并在缓冲区被清空后触发 `drain` 事件。这解释了为什么简单的数据写入或高并发但数据处理极快的场景下，事件往往不会出现。 作者通过传输大文件的 HTTP 服务器实验，成功复现了事件触发，并揭示了它的核心作用——**用于实现流量控制，避免内存无限增长**。最佳实践是：当 `write` 返回 `false` 时暂停读取或生产数据的流，在 `drain` 事件触发后恢复，从而根据消费速度反向调节生产速度。 文章最后通过内存监控数据的对比，直观地验证了这种流控制策略在防止内存泄漏方面的必要性和有效性。
JavaScript 封装问题
这篇讲的是一个在 JavaScript 面向对象编程中，开发者容易踩到的具体“坑”。作者从百度知道的一个提问出发，发现不少开发者在使用构造函数和原型（prototype）封装类时，会习惯性地在函数内部给 prototype 赋值，从而导致实例化后调用原型方法时报错“XX is not a function”。 文章通过代码重现了这个问题，并深入分析了根因：JavaScript 引擎在执行 `new` 操作符时，会先基于构造函数内部的 `this` 创建一个新对象，然后才执行构造函数体内的代码。这意味着，当我们在函数内部书写 `Dialog.prototype = {...}` 这行代码时，其实是在函数执行期间动态替换了原型对象。然而，当前这个实例在创建时，其内部的 `[[Prototype]]` 指向的还是旧的、空的原型对象。因此，实例无法访问到新定义的原型方法。 正确的封装做法，是将原型的定义放在构造函数的外部、紧随其后的代码中。这样可以确保在创建任何实例之前，原型方法就已经稳定地定义好了。这个案例提醒我们，理解 JavaScript 原型链的绑定时机至关重要，一个简单的代码顺序差异，就会导致截然不同的运行结果。
前后端分离的思考与实践（二）
这篇讲的是前后端分离中“模板”这个模糊地带的梳理与实践。作者从传统开发模式切入，指出当模板逻辑堆积在服务端或浏览器端时，都会导致前后端职责不清、维护困难。文章的核心方案是，在 Java 服务与浏览器之间，引入一个前端可掌控的 NodeJS 中间层，将前后端的分割线从“硬件环境”重新定义为“工作职责”。 通过这个中间层，团队得以实现模板与路由的共享。前端使用一致的模板语言（如 XTemplate）和渲染引擎（JavaScript），决定是在 NodeJS 服务端渲染，还是交给浏览器端渲染，从而针对不同场景选择最优解。例如，对于复杂交互应用，首次进入时由 NodeJS 做全页渲染以避免白屏，后续交互则在浏览器端局部刷新，始终使用同一份模板，保证了体验一致性。 文章进一步通过多个案例（如单页面应用的 SEO 解决方案、跨终端页面的统一管理），展示了这一架构如何具体解决白屏等待、路由不匹配、SEO 困难等现实痛点。其本质是利用 NodeJS 的灵活性，让前端开发更聚焦于 UI 与交互，并与后端通过服务化接口进行清晰协作，最终提升整体项目可维护性与用户体验。
前后端分离的思考与实践（一）
这篇讲的是如何通过引入NodeJS层来真正实现前后端职责分离，解决传统Web开发中前后端代码混杂、沟通成本高、性能优化受限等顽疾。 作者团队认为，仅靠浏览器端的SPA模式不够通用，真正的分离应该从职责划分：前端负责View和Controller，后端只负责Model与业务数据。为此，他们提出在后端服务和浏览器之间增加一层NodeJS应用。这层Node让前端能掌控Controller，自由决定服务端渲染、异步接口或BigPipe等输出方式，同时后端可以专注于业务逻辑。文章解答了常见的疑问，比如“为何多一层”：它并非多余，而是为了解锁前端的控制权，通过集中代理请求、优化通信来提升整体性能，尤其在移动端效果显著。 淘宝已在部分项目中实践该架构，初步验证了其在开发效率和性能上的收益。他们认为，技术实现并非难点，关键在于打通开发流程、积累最佳实践，使这种分离模式能稳定落地。
让我们写快速的JavaScript,JS性能优化小窍门
这篇讲的是如何写出更快的JavaScript代码。作者从JS性能尚未达到极限的现状出发，直指在混合应用等场景中，性能优化仍是必要的“伎俩”。 文章没有空谈理论，而是用一系列直观的对比测试来揭示优化窍门。它告诉你，动态类型虽灵活，但会拖慢速度，保持变量类型一致（尤其是数组）是关键；`delete`运算符比赋值为`null`慢得多，而动态添加对象属性也会带来巨大开销。对于字符串拼接，`+=`运算符在主流浏览器上都胜过`concat`和`join`。在正则表达式使用上，`RegExp.prototype.exec`通常也比`String.prototype.search`更快。 更重要的是，这些结论都附带了跨浏览器（如Firefox与Chrome）的性能测试数据，比如位运算在Firefox上极快但在Chrome上却更慢。这些基于具体测试的发现，能帮助开发者在编写或优化JS代码时做出更明智的选择，避免那些“昂贵”的操作，让代码真正跑得更快。
“NodeJS在大搜车” 之 应用部署篇
作者从团队实际需求出发，分享了NodeJS应用在大搜车的部署实践。文章的核心在于解决不同环境下Node进程的稳定管理与高效部署问题。 针对工具选型，作者解释了为何线上环境选用功能全面、进程管理更稳定的PM2，而在需要频繁变更端口的测试环境，则采用更轻量灵活的Forever。本地开发则配合nodemon实现代码热更新。这套组合策略平衡了稳定性与灵活性。 在环境划分上，文章详细介绍了测试、预发、生产三套环境各自的作用与配置。生产环境依托阿里云ECS、SLB、RDS等一整套云服务，基本免除了底层运维烦恼。部署流程则通过自定义Bash脚本实现：从代码拉取、打包上传，到服务器上的解压、备份、覆盖及PM2重启，整个过程在预发服务器上执行，并通过间隔部署配合负载均衡，确保线上服务零宕机。 文章最后坦诚，这套部署体系仍在不断进化，未来计划引入Docker优化测试环境，并着手应对多环境自动部署、性能优化等新挑战。
“NodeJS在大搜车” 之 MVC基础结构
这篇讲的是大搜车团队如何在实际项目中落地NodeJS的MVC架构。作者从前端是否适合直接转向NodeJS服务端开发这个话题切入，提出了一个颇具启发性的观点：服务端开发所需的架构、性能、运维等综合能力，可能让一名经验丰富的PHP工程师转型得更顺畅。这其实引出了本文的核心——扎实的服务端思维与架构设计至关重要。 文章随后详细拆解了他们项目中的MVC实践。除了Controller、Model、View这些基本要素，重点阐述了几个关键扩展层。例如，Service层被定义为整个架构中最重的一环，它封装了跨数据库、跨缓存的复杂数据操作，为Controller提供简洁的“服务”。Route层则通过自研的rainbow库，实现了基于文件目录的自动化路由管理与API文档生成，便于维护成百上千个接口。此外，团队还在ORM之上封装了SuperModel，旨在统一MySQL和MongoDB的操作接口，并提供类似Mongoose的链式调用体验。 这些细节不仅展示了一套清晰、可维护的NodeJS项目结构，也体现了团队在工程化方面的深度思考。对于正探索NodeJS服务端开发的前端工程师，或是寻求不同技术视角的后端开发者，文中关于架构分层与工具封装的具体实践，提供了扎实的参考案例。
JavaScript中的继承方式
这篇文章讲透了JavaScript中实现继承的两种经典方式：原型链继承与类式继承。作者首先厘清了JS中基于对象的核心特性——它不像Java那样拥有严格的“类”概念，而是更多依靠原型（prototype）机制。文章系统梳理了原型链继承如何通过对象间的原型链接实现属性与方法的共享，以及类式继承如何借助构造函数和apply/call方法来复用代码。 为了帮助读者建立扎实的理解，文章特别定义了一套清晰的代码约定，区分了私有属性、实例属性与原型属性（包括基本类型与引用类型），为后续的深入分析奠定了明确的基础。作者指出，理解这些基本属性的归属与区别，是掌握不同继承方式适用场景与潜在陷阱的关键。无论是想搞懂JS对象模型的底层逻辑，还是为后续学习ES6 class语法打好基础，这篇文章都提供了扎实且细致的技术剖析。
前端编码风格规范（3）—— JavaScript 规范
这篇讲的是前端 JavaScript 编码中几个关键的最佳实践，核心目标是避免全局命名空间污染并提升代码健壮性。 文章首先强调，总是应该使用立即执行的函数表达式（IIFE）来包裹代码。这样做的好处是能创建独立的作用域，防止变量泄露到全局，也避免了代码被其他脚本意外修改。作者对比了 IIFE 的两种括号写法，并推荐将执行括号放在外层括号内部，以使表达式看起来更像一个整体。 严格模式的启用时机也很有讲究。文章建议在 IIFE 内部激活严格模式，而不是在整个脚本的开头。这样既能获得更严格的错误检查和性能优化，又能避免因全局启用严格模式而影响到第三方库的正常运行。 在变量声明方面，文章重申了必须始终使用 `var` 关键字。省略 `var` 会意外创建全局变量，使得作用域难以控制，而严格模式能帮助捕捉因变量名拼写错误导致的问题。 总的来说，文章通过清晰的对比和示例，梳理了这些容易出错的细节，旨在引导开发者写出更隔离、更安全的 JavaScript 代码。
前端编码规范（2）—— HTML 规范
这篇讲的是前端HTML编码中的几个关键规范。文章从HTML5文档类型出发，推荐使用``，并建议避免XHTML，因为后者在现代浏览器中的兼容与优化空间有限。对于无内容元素标签，开发时建议不闭合以保持可读性，但在生产环节可以通过压缩省略部分可选标签来优化文件体积。 文章强调了HTML验证的重要性，建议使用标准工具检测，除非为性能做出必要让步。一个容易被忽视的细节是：虽然规范允许省略可选标签，但在源码中显式写出能避免潜在问题，提升可维护性。 性能方面，文章重点分析了脚本加载策略。同步脚本会阻塞DOM解析，影响页面渲染。现代浏览器可使用`async`属性实现异步加载，甚至可以将脚本放在`
`中。对于需要兼容IE9等老旧浏览器的场景，最佳实践是将带`async`属性的脚本标签放在``之前，这样既限制了阻塞范围，又利用了现代浏览器的异步特性。 这些看似基础的规范，实则直接影响页面的可维护性、兼容性与性能。文章给出了清晰的对比与具体操作建议，对实际开发很有指导意义。前端编码规范（1）—— 一般规范
这篇讲的是前端开发中那些容易被忽视但至关重要的基础规范。作者从团队协作与代码质量的角度切入，清晰地梳理了制定一般性编码规范的核心意义。 文章聚焦于HTML、JavaScript以及CSS/SCSS这几个前端基石，阐述了一套旨在统一风格、明确对错的准则。它强调，规范的价值不仅在于代码的整洁，更在于它能让潜在的问题——无论是风格不一致还是逻辑Bug——在早期就变得显而易见。当团队成员都严格遵守这些约定时，后续的代码审核便能更精准地定位错误，而各种压缩、编译工具也能更顺畅地工作。 说到底，这篇指南提供的是一套可执行的“开发基石”，帮助团队在协作中减少无意义的摩擦，把精力更集中地投入到解决实际问题上。
如何在Angular中使用动画
这篇讲的是如何在AngularJS中为常见指令添加交互动画效果。作者开宗明义，指出Angular本身并不内置动画，需要通过引入ngAnimate模块来赋予动画能力，并且它的高度可定制性是其特点。 文章的核心是梳理了ngAnimate支持动画的具体指令列表，包括ngRepeat的进入、离开和移动动画，ngView、ngInclude、ngIf等的进入与离开动画，以及ngClass、ngShow/ngHide等的添加与移除类动画。这些细节清晰地展示了AngularJS动画机制的作用范围。 最后，文章以列表渲染指令ngRepeat为例，具体演示了如何配置和使用这些动画，帮助开发者理解动画元素进入DOM结构的过程。对于需要在旧项目中提升交互体验的开发者来说，这份针对ngAnimate模块的使用指南提供了直接的参考。
手机网页用Bootstrap还是jQuery Mobile
许多开发者在为手机网页选型时纠结过这个问题：Bootstrap和jQuery Mobile，到底该用哪个？这篇讲的就是这两者的深度对比。 文章的核心观点很清晰：Bootstrap本质上是一个CSS框架，它解决的核心问题是跨设备的响应式布局和前端开发规范，通过Media Query让一套代码适应不同屏幕，并提供通用的UI组件如按钮、导航栏等。而jQuery Mobile则是一个更偏向移动端的WebAPP框架，它提供的是类似原生APP的组件（如手机导航栏、底部菜单）和丰富的页面转场效果，目标是让移动网页体验接近原生应用。 两者的适用场景也因此截然不同。如果你需要做一个同时在电脑和手机上都能良好展示的网站，或者构建后台管理系统，Bootstrap是更合适的选择。但如果你的项目是一个纯移动端的应用，并且希望给用户带来接近原生APP的交互体验，jQuery Mobile会更贴合需求。 文章也给出了一个务实的结论：对于追求产品级质量的WebAPP，这两个框架可能都力有不逮，自建响应式框架和组件库往往是最终的路径。
SVG精简压缩工具svgo简介和初体验
这篇从实际协作场景切入，探讨SVG文件精简的必要性。作者指出，设计师用Adobe Illustrator等工具导出的SVG常包含编辑器源信息、注释、默认值等冗余内容，使得文件过大且影响性能。前端开发者需要一种本地解决方案，而非依赖在线平台。 为此，文章介绍了svgo——一个基于Node.js的SVG优化工具，在GitHub上收获4000+星。它基于插件架构，提供一系列优化操作，比如移除文档声明、删除空属性、转换路径数据为更简洁形式、合并多个变换等。这些插件覆盖了从清理无用代码到智能压缩的全流程。 作者通过初体验展示了svgo的实用效果：能快速精简SVG文件，保留渲染结果的同时大幅减小体积。这不仅提升了项目加载效率，也促进了前端与设计师的协作分工，让前端专注于Web化处理。对于处理SVG的开发者来说，svgo是一个值得集成的工具。
NodeJS的代码调试和性能调优
这篇讲的是NodeJS调试方法的演进与核心实践。作者从NodeJS版本合并的背景切入，指出许多开发者仍停留在`console.log`或`asserts`模块的基础调试阶段，这些方式需要将调试逻辑硬编码进业务代码。为此，文章详细介绍了NodeJS内建的命令行调试器作为更专业的解决方案。 核心方法是通过`node debug`命令启动文件，进入一个提供丰富调试指令的环境。文章清晰地区分了“debug模式”（用于单步执行、设置断点）和“repl模式”（用于实时检查变量状态），并列举了`cont`、`next`、`step`等关键命令。这种调试方式通过TCP与内建模块通信，摆脱了在代码中“埋点”的束缚，让调试过程更干净、高效。 文章最后也点出了调试器的工作原理，并提及IDE集成的图形化调试工具是其更友好的封装。其价值在于，它将调试从一种“破坏性”的辅助操作，转变为一种与代码分离的、系统化的质量保障流程。
近几年前端技术盘点以及 2016 年技术发展方向
这篇讲的是，作者从自身2012年入行经历出发，对2009至2015年间前端技术的演进逻辑做了一次系统梳理与展望。 文章并未停留在简单罗列，而是清晰勾勒出一条演进脉络：从早期jQuery等基础类库对浏览器差异的抹平与功能完善，到HTML5标准确立后对富应用与性能的关注，再到2013年后以Node.js、模块化、工程化工具链为标志的“大前端”生态构建。作者特别指出，技术革新的背后是Web从“网页”走向“应用”的根本诉求，以及浏览器标准化、移动端崛起、前后端分离等关键驱动力。 文中对关键转折点的分析很有见地，例如14年HTML5定稿与ES6落地共同推动了大型Web应用开发成为可能；15年React Native等框架的兴起，则标志着前端技术开始突破浏览器边界，向跨平台原生开发渗透。作者将2016年展望为“低版本IE消亡”和“前端工业化生产”深化的一年，并呼吁业界共同推动标准落地与生态进化。 这篇盘点将技术变迁置于具体的时间线与行业背景中，对理解前端技术的昨天、今天与明天提供了扎实的参考。
nodejs文件无刷新上传
这篇讲的是在Node.js环境下如何实现文件无刷新上传，改善传统表单提交带来的页面刷新问题。作者从ExpressJS和multiparty工具包出发，详细拆解了基于RFC1867协议的两种异步上传方案。 第一种方案利用隐藏的iframe接收服务器响应，避免页面跳转，并通过JavaScript跨窗口调用实现结果回传。这种思路兼容性极佳，适合需要覆盖老旧浏览器的场景。第二种方案则拥抱现代Web技术，使用XMLHttpRequest第二版和FormData对象实现真正的Ajax异步上传，但需要浏览器对相关标准有较好支持。 文章并未止步于方案罗列，而是进一步展示了如何通过路由参数合并两种方式的后端逻辑，体现了代码复用的工程思维。无论是对iframe这一“老技术”新用的剖析，还是对前端上传演进思路的梳理，对开发者在实际项目中选择合适方案都有清晰的参考价值。
JSON.parse()和JSON.stringify()方法总结
这篇讲的是JSON对象的两个核心方法：parse()与stringify()。作者从字符串与对象互相转换这一基本需求出发，清晰拆解了这对方法。 parse()负责“解析”，将符合JSON格式的字符串转换成可用的JavaScript对象，其translator参数允许自定义转换逻辑。而stringify()则执行反向的“序列化”，将对象转为字符串，并重点介绍了它强大的格式化能力：通过replacer参数可以选择性序列化指定属性，通过space参数则能控制输出字符串的缩进层级（数字指定空格数，字符串用作缩进符），大幅提升可读性。 文章通过对比示例与运行效果截图，直观展示了不同参数组合下的输出差异，比如如何只输出“name”字段，或如何用“###”作为缩进。最后，作者特别强调了一个实践原则：应避免使用eval()方法来解析JSON，指出了其潜在风险。 对于前端开发者而言，这篇文章将这两个高频使用的方法讲得细致透彻，不仅说明了“怎么用”，还阐释了“怎么用更好”，是扎实的技术参考。
DOM中Property与Attribute的区别
这篇讲的是前端开发中一个经典又容易踩坑的问题：DOM里Property和Attribute到底有什么不同。虽然中文都常被译作“属性”，但它们在JS和HTML中的角色、行为与生命周期有着本质区别。 文章从源头梳理了二者的核心定义：Property是JS对象的属性，可以是任意类型，主要用于JS操作；而Attribute是HTML的特性，值始终是字符串，并通过`getAttribute/setAttribute`方法操作，直接体现在DOM结构上。一个关键背景是，在IE<9时代，浏览器将二者强制映射，这给许多开发者留下了“它们是一回事”的误解。 作者重点剖析了它们之间复杂的同步关系。自定义的Property与Attribute互不干涉；而非自定义的属性（如`id`, `src`, `value`）则有条件同步——例如，用`setAttribute`修改`input`的`value`会同步到Property，但通过`.value`赋值却不会反向同步到Attribute。`href`/`src`等属性的取值方式也不同，`getAttribute`拿到的是原始值，而Property则是完整的URL。 对于开发者而言，理解这个区别至关重要，尤其是在使用jQuery等库的`.attr()`和`.prop()`方法时，混淆二者可能导致难以排查的UI状态同步bug。文章最后用一张关系图清晰总结了这些复杂情况。
