kancloud看云 | 专注技术文档的创作、阅读和托管 V2EX 第 135471 号会员,加入于 2015-08-27 11:06:50 +08:002 |
| 基于 PHP5.6+的 ORM 框架 think-orm PHP kancloud 2017 年 10 月 31 日 最后回复来自 kancloud | 2 |
| ThinkPHP V5.1RC2 版本发布大量细节完善 PHP kancloud 2017 年 10 月 17 日 |
| ThinkPHPV5.0.11 版本发布包含安全更新和近期修正 PHP kancloud 2017 年 9 月 8 日 |
| 关于近期阿里云推送的 ThinkPHP 缓存设计缺陷问题的公告 程序员 kancloud 2017 年 8 月 29 日 |
| 看云阅读客户端测试啦 分享发现 kancloud 2017 年 8 月 18 日 最后回复来自 kancloud | 3 |
| ThinkPHPV5.0.9 版本发布520 爱心放送 PHP kancloud 2017 年 5 月 24 日 最后回复来自 kancloud | 4 |
| ThinkPHP 发布 V5.0.8 正式版暨 V5.1 测试版喜迎五一 PHP kancloud 2017 年 4 月 28 日 |
| ThinkPHPV5.0.7 版本发布小版本修正和改进 PHP kancloud 2017 年 2 月 24 日 |
| ThinkPHP 发布 5.0.6 版本主要为修正和优化,并完善了对 MongoDb 的支持 PHP kancloud 2017 年 2 月 8 日 |
| 看云祝您 2017 新年快乐,新春满额送红包啦! 推广 kancloud 2017 年 1 月 26 日 最后回复来自 Livid | 11 |
kancloud 最近回复了
2017 年 10 月 31 日 回复了 kancloud 创建的主题 PHP 基于 PHP5.6+的 ORM 框架 think-orm |
@Junjunya 感谢支持 我们还会不断努力做出更多的独立库
2017 年 10 月 12 日 回复了 onanying 创建的主题 PHP 我为什么要开发一个 MixPHP 框架 |
没有细看,为手册放看云点个赞
2017 年 9 月 29 日 回复了 dubuqingfeng 创建的主题 PHP 腾讯开源了一款高性能的超轻量级 PHP 框架, Biny |
今时今日 这种框架优势并不大 看看腾讯官方的各种接口 SDK 就知道 内部规范啥样了
2017 年 9 月 4 日 回复了 welefen 创建的主题 Node.js ThinkJS 3 正式版发布! |
赞一个^_^
2017 年 8 月 18 日 回复了 xuezher 创建的主题 程序员 午后的天空很蓝,一个崭新的背锅侠诞生 |
楼主 写小说来看云吧^_^
2017 年 8 月 18 日 回复了 kancloud 创建的主题 分享发现 看云阅读客户端测试啦 |
@frozenthrone 抱歉 https 没有加自动跳转 加上 www 访问就行了
2017 年 7 月 17 日 回复了 gavinczhang 创建的主题 PHP 对主流框架不感冒,想开发属于自己的框架,寻求不同见解或同好朋友 |
@gavinczhang 你可能没明白我的意思,不同的框架默认加载或者启动的类以及请求生命周期各有不同 例如 CI 我记得是默认不开启 Session 的 而其它框架默认会启动,这个对于你这种 helloworld 测试来说的话 数据差异是非常大的。我的建议你的压力测试最好是使用数据库操作,这是最起码的使用场景,谁用框架来写 helloworld ?而且框架不太可能存在一键开启全部优化的情况,你觉得 apache mysql 有开启一键优化的配置么? 框架的使用场景和环境太复杂了,调试模式的关闭不代表你的框架就已经进行调优了;
框架的重点不是类库,类库的问题无论目前的 Composer 还是以前的类库包都能解决,框架的处理机制和请求生命周期可以做什么以及怎么做,决定了你的功能是否强大,是否方便扩展。数据验证就算是前后端分离,后端依然要验证;
模板引擎的存在并不一定是为了给开发人员写的,否则 MVC 还有啥意义;
DI 和 IoC 的优势,如果你了解 Laravel 就明白了;
那些自诩性能很高的框架我见过很多,代价就是缺少功能以及不够完善(一旦你的用户群越来越大,你会不断增加功能满足这些需求,然后。。。),主流框架在完成相同的功能和机制的情况下,其实性能已经优化的不错了,无论 thinkphp/yii/laravel,所以应该去说你的框架如何好用,而不要用不负责任的测试数据去误导用户(讲真,现在主流框架都不在乎运行性能)
框架的重点不是类库,类库的问题无论目前的 Composer 还是以前的类库包都能解决,框架的处理机制和请求生命周期可以做什么以及怎么做,决定了你的功能是否强大,是否方便扩展。数据验证就算是前后端分离,后端依然要验证;
模板引擎的存在并不一定是为了给开发人员写的,否则 MVC 还有啥意义;
DI 和 IoC 的优势,如果你了解 Laravel 就明白了;
那些自诩性能很高的框架我见过很多,代价就是缺少功能以及不够完善(一旦你的用户群越来越大,你会不断增加功能满足这些需求,然后。。。),主流框架在完成相同的功能和机制的情况下,其实性能已经优化的不错了,无论 thinkphp/yii/laravel,所以应该去说你的框架如何好用,而不要用不负责任的测试数据去误导用户(讲真,现在主流框架都不在乎运行性能)
2017 年 7 月 17 日 回复了 gavinczhang 创建的主题 PHP 对主流框架不感冒,想开发属于自己的框架,寻求不同见解或同好朋友 |
文中提到的评测数据毫无意义 在你不了解每个框架的内部机制的情况下 数据差异是很正常的,而且还涉及到优化的层面,作为一个部署项目,不优化就上线的情况较为少见;
其次,所有的性能问题随着你的自定义框架的功能完善以及业务场景需求都会不可避免的下降,框架如果仅仅是为了解决部分需求 那根本不需要框架,当你的框架慢慢完善成为主流框架的时候再来做一次数据比较就非常明显了;
DI 或者 IoC 等设计带来的开发优势 相对于学习成本和性能损耗 是值得的;
说模板引擎毫无意义的 主要是不想重复造轮子,如果你的应用还是传统的 MVC 模式 模板引擎仍然有意义 ;
总而言之,性能不是重复造轮子的理由,学习和提升才是重点,但一个框架的实用是否有太多的细节和体验;
其次,所有的性能问题随着你的自定义框架的功能完善以及业务场景需求都会不可避免的下降,框架如果仅仅是为了解决部分需求 那根本不需要框架,当你的框架慢慢完善成为主流框架的时候再来做一次数据比较就非常明显了;
DI 或者 IoC 等设计带来的开发优势 相对于学习成本和性能损耗 是值得的;
说模板引擎毫无意义的 主要是不想重复造轮子,如果你的应用还是传统的 MVC 模式 模板引擎仍然有意义 ;
总而言之,性能不是重复造轮子的理由,学习和提升才是重点,但一个框架的实用是否有太多的细节和体验;
2017 年 6 月 27 日 回复了 tamlok 创建的主题 Markdown VNote:一个更懂程序员和 Markdown 的笔记 |
@tamlok 预览确实是为了阅读的效果,但编辑的时候也要知道实际的阅读效果是什么的吧(事实上很多 md 编辑器都支持预览 不过也可以关闭 其实 vscode 的 md 预览效果挺不错的) 至于分心的问题 只要能关闭预览 就没问题。
2017 年 6 月 27 日 回复了 tamlok 创建的主题 Markdown VNote:一个更懂程序员和 Markdown 的笔记 |
根据我们的经验,语法高亮仍然不能替代实时预览,看云也曾经在这个问题上纠结过,当然还有一个关键的问题是 使用扩展标签的时候 必须要预览才能有效查看。
