<div dir="ltr">2008/10/9 xu zhou &lt;<a href="mailto:redicaps@gmail.com">redicaps@gmail.com</a>&gt;:<br>&gt; cgi<br><br>原生 CGI/FastCGI 的 web app 对于极小的应用非常合适,但稍复杂一些就有些痛苦,但运行效率是最高的 ;) 如果是自己用 Perl 开发高性能的站,多推荐之。<br><br>&gt; mason<br>
<br>Mason 只是一种模板机制。。。多作为框架中的 view 引擎。当然,也可以利用其 handler 构建完整的 site.<br><br>&gt; Catalyst<br><br>Catalyst, CGI::Application, 和 Jifty 是最流行的三大框架。CGI::Application 是 CGI 之上很薄的一层,非常 popular,呵呵,这里的许多哥们使用之。Catalyst 也见过许多网站应用,包括比较大的网站。从技术和想法上讲,Jifty 的创新点非常多,有许多非常酷的设计,甚至有些独创之处。唐凤,Jesse Vincent, clkao 都是 Jifty 的开发者,我也为 Jifty 贡献过一些补丁和文档。<br>
<br>从架构上讲,这些框架与 Ruby 的 RoR 和 Python 的 Django 没有本质区别,甚至可以说是大同小异,只是许多细节和设计理念若有区别。比如 Catalyst 是典型的 N 种方式完成同一件事情,使用起来感觉更像是自组装的自行车;而 Jifty 则是 full-stack 那种,哲学是 One Best Way. 这些框架都存在一个同题,网站所在的服务器布署成本很高,框架多是"解释型"的,server 上都要跑一个很大的 runtime,都有 N 多 CPAN 依赖项,布署的成本都非常高(不是一般的免费租用空间能胜任的)。于是我发现,虽然我很喜欢 Jifty,但我却不愿在自己的 web 服务器上布署之,即使我有 root 权限。<br>
<br>这让我陷入了很深的思考。。。我和 Jifty 的老大 Jesse 也交流过。。。我们的 web 应用框架是否应该学习一下 C/C++ 这些编程语言的编译器?是否应该做成"编译型"的框架,而非解释型的?这样,即使我们开发时使用很多库,很多 Perl,很多工具,但经过框架的处理,最终我们可以得到一个高性能的依赖项极少的高度自治的网络应用?而且这种应用还可以在多机集群的环境中很容易地 scale?<br><br>这个最终得到的"二进制"的网站是什么样子,就依赖我们的想象力和需求了。它可以是一个非常轻便的 CGI/FastCGI 的 perl 脚本,或者根本不含 Perl,只有布署成本极易的 JavaScript 代码或者 PHP 代码。<br>
<br>在过去的一年内我做了许多有趣的尝试。XUL::App 就是这种思考的实践,我们在开发过程中可以使用许多 Perl,包括 Template::Declare 和 Locale::Maketext::Lexical 这样的模块,但最终得到的 Firefox 插件产品中却不含一行 Perl 代码,可以安装在任何机器上。当然了,XUL::App 并非建站框架了,但有许多类似之处。<br><br>随后,因为工作需要,开始开发 OpenResty。在这里,我们的"最终的二进制网站"是一种极端,即完全由 .html, .js, .css 等静态文件组成,但却是高度交互性的。所以这种网站的布署成本严格为 0,毕竟它是纯客户端的网站,完全运行于用户的浏览器中,因此即使没有 lighttpd 和 apache 这样的服务器,直接从桌面双击打开也能正确运行。<br>
<br>然而,我们同时必须解决中央数据源的问题,所以我们走了通用目的但同时又是用户可定制的 web service 平台和跨域 AJAX 的道路。我们已经成功地得到了纯 JS 的博客、小BBS以及公司主页性质的网站。我们下面还要尝试纯 JS 的全功能论坛,纯 JS 的 Gmail 和 RSS Reader,以及原生 PHP 站的生成(不能否认 PHP 的布署在许多最一般的情况下比 Perl web app 要容易要经济,所以我们是朋友,不是敌人 ;) )关于这个主题,我可以一直说下去,呵呵,不过这次 Perl Workshop 上的 OpenResty talk 我还可以慢慢道来,呵呵。<br>
<br>巧的是,clkao 也在我之前做过类似的尝试。他试图从使用了 Template::Declare 的 Perl 代码生成原生的客户端 JavaScript 代码,利用了一些 B:: 模块的高级技巧。与 XUL::App 类似,他也把 perl 的 Maketext 的 I18N love 带给了客户端的 JavaScript 代码。必须承认,这一点也值得 XUL::App 学习,目前 XUL::App 的 I18N love 只限于 XUL 代码(虽然 JS 代码可以利用隐藏的 DOM 节点技巧而享受到 I18N,但无疑有些 hacky 了)。<br>
<br>无论如何,Jifty (以及最近的 Prophet)都是非常值得一看的好东东。我参加工作以来的大部分 $project 的灵活都来源于 Jifty. 所以我曾和 Jesse 说过:&quot;I&#39;ve found myself stealing good ideas or even code from Jifty in $work but avoiding using Jifty directly.&quot;<br><br>
&gt; 学那个好呢<br>&gt; 那个更流行点?<br><br>IMHO, 博采众家之所长方是"万全之策" ;)<br><br>Cheers,<br>-agentzh<br><br>P.S. 一不小心,就把邮件写长了。。。或许我应该把这些文字整理一下贴到我自己的 blog 上去 :P<br><br></div>