TreeFrog Web Framework -- An C++ Web Framework

[skywinger]

http://www.treefrogframework.org/

最近看到一个新的fullstack的C++ Web Framework TreeFrog
和ROR非常的相似，也是可以用C++来快速开发Web应用，不过是鬼子的。

[reorx]

哈哈，楼主最后一句我喜欢。

[skywinger]

呵呵，看来大家对用C、C++来做web都不感冒。

[limu]

@skywinger web开发=字符串拼接. 就C/C++的的字符串功能, web开发就是找虐.

[ljbha007]

@limu c++不是支持字符串拼接么

[limu]

@ljbha007 要说支持自然是支持，就连c也可以concat。 但是好用吗，易用吗，有正则表达式吗，要手动管理内存吗，有split函数吗，unicode好搞吗，这都是问题

[zealot]

@limu 有一两年技术积累的C++团队，如果没有类似动态语言一样的正则表达式/split函数/编码处理 封装，那就该反思了。
最大缺陷还在手动内存管理，不过简单业务逻辑(点击统计等中转页面、简单吐出一个iframe页面等)&追求高性能的场景下，这个缺陷就是优势了（自定义内存管理带来的性能提升）。

不过如果需要用到模版引擎、ORM，那么这个复杂性估计已经不适合用C++了。
个人认为，C++应用到web前段引擎开发还是比较适合处理简单的业务逻辑，框架可以是基于Nginx模块机制，或libevent的http库，封装出来一个易于使用的东西，提供uri参数、header、cookie、postdata的获取与Response生成的便利接口。简化开发逻辑。

[yetone]

@reorx 喜欢日本的产品

[limu]

@zealot 赞同。
用nginx或boost.asio写异步的代码，由于没有closure，资源的所有权问题很棘手，就算java，也有gc，这个问题还不是那么突出，经过多次异步回调，业务逻辑分散在各处时，c++的资源（内存）谁来分配，谁来释放，都很考量设计能力（智能指针也不能完全解决）。
时间花在这里头就一大半，就不能专注于业务逻辑了，开发效率低，而且门槛太高了。

[skywinger]

@limu @zealot 不过就执行效率及大并发量访问而言，c++ web framework 还是优势明显的。
字符串拼接 c++不成问题，也很简单，stl库中有多种常用的数据结构（泛型的）和算法;
也能够使使用者快速应用。

[fangzhzh]

@limu
@skywinger
@zealot
我们公司在boost::asio和muduo的基础上开发了一套蛮强悍的网络库，前几天我封了一下uri的处理，也是一个web framework了。执行效率和并发都很强悍。

我本来想自己做点东西出来，玩一玩。
但是发现他最大的问题，而你们说的都不在点子上。

字符串拼接，资源释放，正则表达都不是什么问题，closure没什么，有了boost，c＋＋0X就可以玩一玩。

最大的问题是投入。
1 服务器的投入，php，python，ruby的空间，便宜的一抓一大把，程序移植也没什么大问题。
但是C＋＋程序开发环境和运行环境的一致性就很头痛。 linux内核版本，glibc版本，boost版本，一个不同，他就运行不起来。 方案就是买vps，直接自己装。vps对于想要玩一玩的就相对很奢侈了。对一些前期比较拮据的小团队也很奢侈。
2 员工。 不是为了引起口水战。相同段位的C＋＋程序员要比python，php，ruby的程序员贵。相对投入要大。
3 开发周期。 相对来说，C＋＋相对python，ruby，php来说开发的低效才是最重要的。相同的业务逻辑用python这种动态语言开发很快，库很多，语法优雅；C＋＋各种变量，各种类型，各种引用，指针，变量，库。头文件包含问题，编译时间时间爆长。开发起来很麻烦，产出不高。

[zealot]

@fangzhzh
“1. 服务器的投入，php，python，ruby的空间，便宜的一抓一大把。”
看来我们讨论的不是一个阶段的问题。
起步阶段：需要不断试错，探索，要点就一个字：快！产品快速迭代，不该用C++来写web前端，php/python/ruby更合适。就算是后端也应当Python/Ruby+开源软件来搭建。
成熟阶段：这时候产品成熟了，也开始赚钱了，线上堆上成千上万台服务器，性能优化1%都能带来巨额的经费节省，那么没有人会介意投入点人和时间进去搞搞C++的。而实际上，前期快速的产品迭代必然给后期留下巨大的优化空间，发展没压力时该考虑从性能上榨出利润了。

[fangzhzh]

@zealot 请参考我说的第三点:)

[skywinger]

@zealot @fangzhzh
如果假设有个c++ web framework 具有runtime binding 及动态编译的功能呢？

[zealot]

@fangzhzh
我说的第二点可以对你的第三点，但业务规模发展到每天千万、甚至过亿的PV时，人力成本占比就没那么大了，当然，依旧不建议复杂的web逻辑用C++实现，可以针对api之类的简单逻辑且调用次数庞大的业务采用C++，这样的话过于复杂且笨重的C++框架也未必合适：
成熟阶段：这时候产品成熟了，也开始赚钱了，线上堆上成千上万台服务器，性能优化1%都能带来巨额的经费节省，那么没有人会介意投入点人和时间进去搞搞C++的。而实际上，前期快速的产品迭代必然给后期留下巨大的优化空间，发展没压力时该考虑从性能上榨出利润了。

[forest520]

@fangzhzh 说的好。对于第三点，不知道你怎么看java的开发效率？因为对java更熟悉些，play框架看起来还比较易用。

[zealot]

@skywinger 重点还是在开发效率，小公司刚起步时迭代速度很重要，C++ web framework有runtime binding 及动态编译的功能也无济于事。

使用动态语言，可以马上拥有庞大且成熟的开发库，包括模版引擎、ORM、Auth集成、权限管理、甚至是开源的SNS/电子商务网站等等，这些是C++真正缺乏也没必要拥有的特性。当然如果真在C++里面把这些功能全集成进去时，性能也会大打折扣，选择C++意义就不大。

小公司起步时就一个字：快！

至于性能问题不应该优先考虑C++，而是考虑找些资深的Python/Ruby/PHP工程师。
产品都没定型，业务模式还没想清楚时，就不应该想C++还是Python，而应当考虑下个A/B Testing有什么办法能快点发布，尽早验证想法和方向。

[skywinger]

@zealot 如果产品是搞通用搜索引擎呢？而非普通的web应用呢？

[zealot]

@skywinger 我不知道怎么建议，如果是我的话，会优先选择开源的，比如Sphinx等，毕竟用户需要的是产品，而不是C++/Python之类的东西。
产品演化过程中，有必要的话，可以改进开源工具，既节省了自己从头开始研发的时间成本，也能给社区做出回馈。比如Twitter之前采用Lucene，后来因为实时性的特殊需求而在Lucene之上做改进。
等到有一天开源工具彻底不能满足需求时，也应该有钱、有时间去自行研发定制化的搜索引擎了。

[skywinger]

@zealot 明白了，不过google当初搭建搜索引擎时，未必是用的开源产品吧。

[shiweifu]

c++ 都忍了，为啥不上openresty？