博客单页化实践

这个单页化的博客现在也没在用了,Ghost平台挺好的……如果需要看代码的话,请参考GitHub上的仓库 半年前,因为VPS未续费导致所有数据丢失,直至今日终于重新恢复了所有的文章数据(虽然丢失了全部的评论),并且借此机会对所有文章进行了一次重新审视,修改了部分问题,并将所有示例迁移到jsfiddle和jsperf上,总算造一段落。 新的博客完全独立建设,不使用任何第三方的CMS系统,后端使用ASP.NET MVC实现,数据库使用MySQL,通过Mono部署于Ubuntu Server之上,前端使用nginx作为静态服务器。 也正因为完全独立构建,不受任何系统出于安全、简便等奇怪理由而附加的限制,这个博客系统也成了自己练手的娱乐场。就比如本篇要介绍的OPOA化实践。 概念 OPOA,全称One Page One Application,中文可以称之为单页应用。 顾名思义,在OPOA下,一个页面组成一个应用,不再以传统的超链接跳转导航的方式,而是通过javascript以XMLHttpRequest加载数据,通过DOM操作展现数据。 作为一个单页应用,其优势主要有: 多个页面拥有相同的结构时,一些相同的内容(如侧边栏、LOGO等)不需要重复加载,节省流量(及一定的数据库查询)。 没有浏览器跳转地址导致的短暂空白页面状态,提升用户体验…

浅谈eval的影响

听闻最近由于老赵在其Wind.js关于eval这一函数使用上与BYVoid进行了一系列的争论,甚至为此写了一篇博客来证明eval对性能的影响可以忽略这一观点。 而不幸由于在这一次讨论中,起于Ericpoon智对eval性能影响的疑问,也不知不觉参与了一些讨论,随后Franky提出要有数据上的事实来说明这一问题,于是在好久没有新的博客出产的时候,决定对这一问题进行一下非常浅薄的挖掘,提供一些客观的数据。 首先在此文中,需要声明的是: 个人倾向于不要计较eval产生的影响。 此文会从eval有负面影响这一角度进行表述和举例,与老赵的博客属于完全相反的观点,但并不是一种对其的驳斥或者反对,仅仅是希望可以提供一些客观的理论依据。 本文只谈V8引擎,由于这一问题是不同引擎的表现会大不相同,不可能完全覆盖,因此数据不可作为权威参考。 本人不懂C或C++,看不懂V8,因此完全是黑盒的推断,各结论也不具权威意义,完全可能是臆测,当然数据保证真实。 以下是本次测试使用的Chrome版本详细信息: Google Chrome: 21.0.1180.79 (Official Build 151411) m OS: Windows WebKit: 537.1 (@124502) JavaScript: V8 3.11.10.18…

所谓闭包的PPT

这是近期一次内部分享的PPT,从函数的相关概念上,主要内容有: 变量的概念。 闭包的表象。 核心概念,包括可执行代码、执行环境、词法环境、变量环境、环境数据、绑定对象等。 函数的相关过程,包括创建函数、进入函数、定义绑定初始化、变量查找等。 闭包对垃圾回收的影响的探究。 PPT权当对新事物的一种普及性展示,不会有深入的内容,也不会有详细的例子,如果有任何疑问,欢迎随时交流。 如需观看或下载,请点击此处。 …

关于闭包及变量回收问题

本文的诞生,源自近期打算做的一个关于javascript中的闭包的专题,由于需要解析闭包对垃圾回收的影响,特此针对不同的javascript引擎,做了相关的测试。 为了能从本文中得到需要的知识,看本文前,请明确自己知道闭包的概念,并对垃圾回收的常用算法有一定的了解。 问题的提出 假设有如下的代码: function outer() { var largeObject = LargeObject.fromSize('100MB'); return function() { console.log('inner'); }; } var inner = outer(); 在这一段代码中,outer函数和inner函数间会形成一个闭包,致使inner函数能够访问到largeObject,但是显然inner并没有访问largeObject,那么在闭包中的largeObject对象是否能被回收呢? 如果引入更复杂的情况: function outer() { var largeObject = LargeObject.fromSize('100MB'); var anotherLargeObject = LargeObject.fromSize('100MB'); return function() { largeObject.work(); console.log…

另类MVC模式 - 优势及实现

继续大逆不道系列…… 在上一篇中,提出了一个另类的MVC模型,与经典MVC模型有一些不同,那么自然需要描述这样的另类模型有什么优势,又能在怎么样的场景中使用。 逻辑划分 正如上一篇所说,这种模式下,最大的优势莫过于逻辑的清晰划分。在该模式的作用下,每一个Action都只要处理真正与自己有关的逻辑及数据,而不需要关心一些“通用”的内容,因为这些通用内容也成了独立的Action。 例如,继续引用上一篇中的页面设计,根据经典的MVC模式,我们不得不在一个Action中准备所有数据: public ActionResult ViewPost(int id) { ViewBag.Friends = FriendsRepository.ByUser(CurrentUser); ViewBag.RecentVisitors = VisitorsRepository.ByPost(id, TimeSpan.FromMinutes(30)); Post post = PostRepository.ById(id); return View(post); } 即便你按上一篇提到的方案使用Action Filter,依旧没有办法彻底地将这些数据从当前Action产生的数据模型中消除,当模块越来越多时…