首页 > 想找一个坚定学习Laravel的决心和理由

想找一个坚定学习Laravel的决心和理由

声明:这个问题是我脑洞大开,展开的一些疑问,如有说得不对的地方请见谅。

Laravel到底颠覆了PHP的什么东西,难道只是为了推广Composer吗,到底Laravel的这些特性是否违背了PHP的初衷,PHP本来就是以轻量为特色,现在又加入了命名空间和包管理。还有Laravel的国内实际应用项目到底有哪些?难道只是为了开发一个像WordPress这样的极致博客吗?而且在GitOsChina上并没有找到很多的Laravel相关的应用项目,你不会给我说GitHub上面有很多吧,不能因为GitHub很出名而忽略了国内Git社区的发展和功劳吧,GitOsChina现在也是国内很有影响力的Git服务社区了,Composer的推广势必会造成项目各种依赖包的增加和烂用,这样PHP必然会变得越来越不经量级。我所理解的能被广泛流行使用的东西,肯定是像加JQuery一样的瑞士军刀,由于它的轻量级、快捷、灵活,同时可以利用它来扩展开发很多东西,完成我们自己的需求,还有BootStrap前端框架也是,像这样的框架可以广泛流行并得到充分发展和利用。Laravel的工匠精神,我想会造成了它很不灵活,学习曲线难等等问题,最后成为只有极少数部分极客和狂热者的宠物。

X补充20160621 00:36
X--------------------------------------------------------------+++>

首先感谢各位给了我真诚的回复,从大家回复的当中我也体会到了很多,我以下是我想补充说一下的:

我赞成了@飞龙的观点:

php早就不是那个简洁的php了,学了java太多东西,丢失了一些脚本语言应有的灵活。你对php的认识还停留在3x时代。

关于命名空间和包管理我是这样说的:

PHP本来就是以轻量为特色,现在又加入了命名空间和包管理

希望大家不要太咬文嚼字,偏离我大的观点,我也并没有把命名空间和包管理扣在Lavavel上,再说Lavavel还不至于可以让PHP做改动。Python,Node.Js和PHP感觉没有什么可比性,毕竟设计目的和初衷不一样,而且别人很早就有包管理的概念,在包管理方面PHP早已落后很多,在我看来国内的中文项目很多人拿Laravel只做出来博客的样子,做出的博客确实不能和WordPress比,也没法比,还有WordPress现在都还支持3x也没见别人一定要用Composer。还有一点Lavavel这个单词感觉取得不怎么样,国人都感觉不好记,至少对于我来说。

我可能像@飞龙说的还停留在3x的时代,就算是像@JellyBool说的一样是我不思进取的借口吧。
但我想在大家看来JQuery,BootStrap确实算是灵活的框架,不能因为我的这个问题连它们一起喷。

无意把GitOsChina带进来,大家也不要误导别人,让别人误认为GitOsChina不好,对于英文不好,或者不能科学上网的人来说,像GitOsChina,Coding.net等这样的平台至少提供了一个学习的渠道,至少我接触Git是从它开始的,总不能说让不擅长英语的就别学编程了吧。

综合大家的意见,我个人的想法是,看机缘先去了解和接触一下Laravel,如果开始的坑就很多,几天我都不能上手,摸不着门的话,那我就只有等它在国内真正的像JQuery一样的流行的时候我再慢慢去学习它。

以下仅代表个人现有理解水平的观点,不涉及任何其他团体组织和利益

适合自己的才是最好的 点赞

X补充20160621 08:30
X--------------------------------------------------------------+++>
以下仅代表个人现有理解水平的观点,本着不知道就是不知道,不懂就是不懂的基本观念出发,不涉及任何其他团体组织和利益

Lavavel的国内推崇者不要把Lavavel老端着,一副高高在上的样子,整天把工匠、艺术家精神、轻量级、简洁优雅、PHP最新特性什么的挂在嘴边,夸夸其谈,搞得像是说你一定要跟着我搞5x、7x什么的,你怎么不用Composer呢,我只用Composer的啦,你还在搞3x那一套吗!去打击像我这样的老菜鸟,搞得像是你不马上学PHP的新特性,你就不用它就不用在这个圈子里面混了的样子,看不起国内的框架、看不起织梦CMS,看不起WordPress,甚至于看不起GitOSchina,别人为了国内能有像样的Git服务做了多少努力和付出了多少汗水,改善了多少国内的编程环境,不要整天拿GitHub来说事,不是人人都有机会到国外去,不是人人者都懂Git,国内的编程环境什么样,国外的环境什么样大家应该都很清楚,国内大多数人都还在被迫为那点工资来码代码,国内服务平台有国内服务平台存在的道理,别人发展的好不好长不长不是你说了算。

在工匠精神方面Lavavel有Java的众多流行框架这么有工匠精神吗,简洁优雅又有Python的众多流行框架这样简洁优雅吗,不要滥用这些词夸大推崇,搞得神神秘秘的。包管理不好理解就多写资料让大家好理解,学习曲线难就简化优化入门方式方法,执行流程不好理解就多完善细化流程分析,中文支持不好就多写中文语言包,中文资料少就多写中文资料,这些后来的推崇者都可以共同去完成,也不排除以后会有我,但前提是要大家知道这东西怎么才能简单上手,Apache,Nginx,Mysql好用未必人人刚开始都要知道怎么配置,一键环境不也来得快,用一键环境也不代表就学不到配置的知识,它只是降低了我们入门的门槛。好比VIM编辑器用惯的人都说它牛它好,但是对于一般人来说入门起来很难,刚开始用得很不顺手,被拒之门外,SublimeText就很好地规避了入手的问题所以更广泛的流行和被推崇。


我都直接用php写,感觉更加方便。就一个路由


命名空间和加载器属于psr2规范,不要把锅甩给laravel。php的包含系统一直是反模式,caller访问不了callee,callee却能访问caller的东西。解决方案就是封装成类、名字空间,进一步模块化。

要想成为现代的编程语言,大量的三方库是必须的,没这些库还玩啥。有了composer就有人发布库,有了库就有人愿意用,就有社区,就能产生正反馈。官方的推广算个蛋,你告诉我apache如果不一个一个写那些组件,javaee能有现在这么火?要是光靠业界毒瘤oracle早就玩蛋去了。

php早就不是那个简洁的php了,学了java太多东西,丢失了一些脚本语言应有的灵活。你对php的认识还停留在3x时代。

然后再看laravel,我刚才说php很多默认实现都是反模式的。比如那个原生的模板系统,居然能跟业务逻辑穿插在一起。工程上看的永远不是轻量与否,而是解耦和抽象,抽象得越高明可维护性就越好。你把所有东西混一块,你倒是简单了,让别人怎么玩?

说实话laravel的sql查询器设计的非常优美,特别是链式调用,比tp直接塞一大坨sql语句高到不知道哪里去了。

反正好的代码有差不多是相同的模式,差的代码各有各的不足。mvc算是web开发的公认模式了吧,不爽就不要玩,反正你用其它框架也是这样。以上。


你根本就没有理解laravel以及团队开发,还停留在单兵作战的年代,建议先深入了解之后再来评判


用过tp,ci,再用laravel的时候,感觉它很棒,很简洁,不过性能差了点


一句话: 因为它像rails


其实也不能怪PHP现在变的这么复杂。

PHP出生的时候,也是WEB比较初级的时候,那时候的网站一个小型的CMS足已,逻辑简单,整体规模较小,不论代码你怎么编整体都不会太跑偏。这个时候的PHP脚本语言,解决了大部分问题,甚至使用HTML+PHP混合编码方式,也不会让人感觉有多少不适。我如果没记错的话,这种编码方式称为“意大利面条式编程”。

然后随着WEB越来越复杂,混排编码方式已经有点力不从心了,表现出来的结果就是,一个页面有n多的PHP和HTML的交替编码,导致后来的编码人员(包括自己)越来越头大,用上include把一些通用的代码提出去也不行,于是出现里模板的概念,比较有代表性的就是smarty,这个时候,你可以把逻辑写到一个PHP文件里,然后加载另一个模板文件作为展现层,这个文件里仅包含一些必要的PHP逻辑代码,这样使得逻辑代码与展现代码的分离。

然而WEB发展太快了,很快负责处理逻辑部分的代码又变的庞大起来,有处理request的,有连数据库的,还有些比较通用的逻辑都在里边,后端的工程师都崩溃了,越写BUG越多。于是有人就写了框架来把这些逻辑分开,于是一批像是Codeigniter等框架就出现了。这类框架大部分会使用单一入口确保逻辑部分都由它接管,然后分出MVC层,让其各司其职,代码顺畅了。但是这个时候PHP也开始不再是原来的PHP了,不再是24小时就能入门的PHP了,虽然还可以用意大利面条式编程,甚至到现在也可以,但是这么编程至少会被人鄙视的,于是众多PHPer被迫学习了新的编程方式,美其名曰:分层编程。不过说实话,分开层,确实编程舒爽多了。(楼主,既然你有点反对Laravel编程方式,那么我猜你应该在用这类MVC分层的框架形式编程,如果我说这也违背了PHP快速编程的理念,你能回归最原始的编程方式么?纯猜的哈,如果猜错了,别介意。)

后来,也就算是现在吧,WEB不在是简简单单的知识共享的需求,什么SNS社交,什么电子商城,什么B/S服务类软件,作为后端的工程师,想想头都大。于是就又有人跳出来解决各种问题了,怎么解决呢?有什么问题解决什么问题呗,呵呵。我随意举个例子说吧,比如用个大部分认为有些老的框架Codeigniter去写一个电子商城,问题不大,虽然逻辑端代码可能有点长,但是忍忍就能过去了,但是某天回过头来看代码的时候,你发现V端的代码还是可以的,逻辑比较清晰,就是一个展现嘛,也没什么可以优化的,M端也是可以的,无非就是写了些SQL语句,即使是SQL语句太复杂了,那也是数据库设计的事儿,然后你接着看了看C端,有些不忍,这里边有负责接收各种GET、POST值得代码,有处理各种逻辑计算的代码,有各种负责验证数据的代码,有各种加载数据M加载V端的代码,每个function里少说都是上百行,于是你打算把逻辑那部分代码抽出来,让C端只负责读取用户输入数据以及加载M和V,至于逻辑运算那部分,再拆一个Service层吧,这部分拆出去,不仅C端简洁了,有些service还能复用,一举两得。等着手拆的时候,你忽然发现,这个层没有地方放,放library里吧,觉得它只是一个放置独立库的地方,而不是分层的地方,放到M里吧,又觉得破坏了MVC本身的含义似的,不过也没办法,规矩不是死的,既然能用就用吧。然而如果你用比较新的框架,他们都遵循了PSR编码规范,你可以随意建个文件夹作为分层,然后到C端use一下即可,完全不破坏现有结构,最爽的是,如果你写的代码能有有效的解耦,那么配合composer,你可以把你写的东西共享给别人用,这也是众多新式框架让人比较爽的地方之一。

然后我就不多说了,如果PHP真的总是裹足不前,大家总是用很久以前的脚本式编程方式,迟早有一天会被淘汰的。

当然我确实想吐槽,各种新框架带来了很多新的特性,太难学了……

这里是重点:以上纯属个人吐槽,有些地方没有详细考证,可能不对,就当茶余小点吧。如果能指出错误之处甚好,不喜喷子。


因为像rails啊


因为用着顺手


可以先玩一玩Laravel,玩了就知道好不好玩了。。


Composer的推广势必会造成项目各种依赖包的增加和烂用。

写的水的写啥都是滥用

另外 gitoschina 不是当github 的 backup,就是放玩具的,影响力不知道你说的啥,如果你以这平台的项目丰富度当影响力的话真是没救了。


为了艺术:)
以上开玩笑,学习最好的动力永远是需求


没人要喷你

看了你的问题,自己也是有一些思考的过程,其中有部分的结论我是无法赞同。一个建立在错误假设上的结论是不可信的,所以我就仅仅对你的问题发表一下粗浅的看法,希望共同学习。

Laravel 无疑是个优秀的框架,但是作者从未说过自己“颠覆”或希望颠覆什么,作者就是那样一个普普通通的宅男,陪陪家人,谢谢代码,开发自己框架的同时,穿插着自己的创业项目,一系列从 Laravel 框架之上衍生的部署服务,SASS,顾问服务等等。 我接触 Laravel 大半年了,貌似也没有看到谁说这个框架颠覆了什么,估计这么对你讲的人,不是脑残粉就是惯用夸张词汇的针扎火燎型,对于程序方面的东西,遇到这类夸张词汇无视就好。 Laravel 构建于 PHP 社区前人细致又无私的贡献之上,使用了包括 Symfony 组件在内的很多其他开发者的开源项目作为底层依赖,无论是 Laravel 还是他所依赖的库,这些不是全新再造的东西,也不是 PHP 独有的写作方式,每一个依赖社区都有很多个类似的实现。

Composer 和 Laravel 直接关系并不大,前者是社区发展到一定程度自然而然产生的依赖管理工具,帮助开发者维护数量庞大的依赖库和其版本更新,举个例子,如果你自己写个 Web 应用,很可能需要完成诸如路由、ORM、请求和响应、验证、模版引擎等很多方面,现在突然有一方面你自己不想写了,那么这时候你就会想到引入其它维护活跃、文档良好的库为你所用,当你的程序功能点足够多时,可能发邮件、文件系统抽象、队列接口,方方面面你都要站在前人的肩膀上加速自己的开发,让擅长的人去做它们做的事。这个时候 Composer 是保证你维护好依赖更新、冲突、回滚的唯一工具。社区发展到一定阶段,就算没有 Composer,也会有 Overture, Singer。今天为止, Composer 已经成为 PHP 社区事实上的行业标准。你对他的不了解,只能说明你自己的懒惰无知,哪怕随便去 Github 搜个 PHP 项目看看也不会认为 Composer 是被某一个框架推广的。

你说“Laravel 的特性违背了 PHP 的初衷”,那么你最好能够讲明白, 你觉得他的特性是什么, PHP 的初衷又是什么。

PHP 们无私的维护者们,以及背后的商业公司,从未说过 PHP 是以轻量为特色,我也不知道你嘴里的轻量什么意思,如果加个特性,社区拥有依赖管理工具就是轻量,那么使用人数较多的语言中,大概没有轻量的。PHP 入门是简单,但这并不意味着你可以用傻逼方式写代码却一副理所当然。现在的开发者有种很病态的心理,管 Sublime 叫轻量,PHPStorm 叫重,管文件少叫轻量,文件多叫重。 但我可以告诉你的是一个功能的添加和被发明经历过复杂的讨论,无数人的谨慎思考,沉淀着很多开发实践中的迫切需求。你不能不学无术的坐在原地质疑别人的初衷。一个语言或工具,如果真令你感到心衰失去信心,以至于你认为那就是有违常理的,别担心,他肯定会被淘汰,因为绝大多数人并不傻,市场自然淘汰无用的产品。

国内项目不清楚,你现在所用的绝大多数编程工具都不是“国内”产生的,所以可以的话,眼光不要仅仅放在身边,英文结果中,还是有相当多很棒的资料,顺便插播一句,Laravel 是一个对人编程风格影响极大的框架,请谨慎使用,否则恐怕很难回到过去写面条代码的时代。

WordPress 是个插件丰富的内容系统,我了解并不深,但以我感觉他和 Laravel 完全不是一个领域的东西,各自追求的方向也不同。

GitOSChina 并没什么鬼影响力,包括国内所有的此类服务,以为加个论坛,加个外包市场就是微创新了,就本土化了,本质上,都是赚的国内开发者低能的钱,多么贴心的大中文呀,一点脑子都不用动哦。 一个总用 Github 的人,并不可能使用你说的这玩意。首先 Github 上开发者是全球最多的,以大公司组织身份开源他们产品最多的,上面聚拢的是这个星球上最聪明的几百万人,反观国内的这些整天想着怎么骗甲方钱的 coder 们,你指望他真正做技术?世界上只需要一个 Git 社区,也许两个,但另一个绝对不是你说的这种一个大社区临时凑几个人用 Gitlab 匆匆架设起来的东西。“不能因为 Github 很出名而忽视国内 Git 社区的功劳”,没人故意忽视他们,是压根看不到。

“Composer的推广势必会造成项目各种依赖包的增加和烂用,这样PHP必然会变得越来越不经量级。”, 以文件、依赖数量论断轻重有些草率了,一页代码,写的渣的,一样能比 10000 页更吃资源,更重。PHP 开启 Opcache 虽然算是半编译语言,不过在绝大多数系统上,多几十个文件,少几十个,应该没有显著区别。

“肯定是像加JQuery一样的瑞士军刀”。 jQuery 也不是瑞士军刀, 它只是浏览器发展早期、标准支撑不完善,以 IE 为首的不思进取的产品所衍生出来的一个兼容性解决方案,让你在不同环境下,统一 API 写法。 当然今天他的作用也是这个。而且未来很长时间会因为其接口统一而流行着。 但是你不能把一个大而全,恨不得什么都装进去的东西称作瑞士军刀。

工匠精神只是 Laravel 网站上这么宣称,优雅也是,作者总要吃饭,总要有一个词让你想起这个框架。以我用过额外两个比较复杂的框架的经验来看, Laravel 是个非常简单的框架,如果有 OOP 基础,熟读文档即可立刻开发,而且在查看源码的过程中会不时发现作者根本没写到文档中的惊喜,会感叹他在易用性的基础上还能兼顾各种复杂的使用场景。Laravel 也不是“少数极客”的宠物,最近 3 年 Laravel 稳居全球 PHP 框架流行度 No.1. 在大陆, 从 2015 年开始,用户人数和关注度也是徒增,详情可以自己去 index.baidu.com 看看它们的搜索指数,拖到全部时间看看增长曲线。 即使大陆这种生产代码猴子的培训机构满地(高等教育落实不到位、逐利), 某框架和培训机构深度合作,离开了某框架都不会写代码的水土上, Laravel 也在慢慢的被更多希望让自己成长到新的高度的程序员所接受。

写到一半就不太想写了,因为叫醒一个装睡的人是何其困难的事。一个每天都要创造内容的职业,却偏偏把新鲜事物看作最大的敌人。还用自己仅有的知识去做出自己都说不出前因后果的无端推论。 尽管每个人都有发表看法的权力, 但我觉得遇到自己都想不明白的事时,最先做的应该是学习和了解而不是提出一些难以说服别人的结论。


爱学不学
自己low就别找借口了


php一统天下


个人觉得你是误解了laravelcomposer 的关系,高兴的就是,你通过laravel 认识了 phpcomposer 类似的依赖管理工具
至于说因为 composer 的引入,造成项目各种依赖包的增加和烂用,我建议你看看 node 的 npm,python 的 pip,ruby 的 gem 等等,看看它们有没有造成滥用,

会有人说 laravel 抄袭了 rails ,的确他们有很大的相似,laravel 可以说是全栈的开发框架,快速的进行web开发,引入web中的最佳解决方案,引入最合理的技术,比如说引入了 composer 依赖管理
至于你说的不灵活是什么 ? 哪里看出来不灵活了 ?
至于你说的学习曲线,的确 laravel 的学习曲线相对其他框架来说较高,但这个也是相对的,较高的学习曲线意味着,你学好之后,更快的开发效率。

建议你 不要人云亦云,如果你觉得不好,可以不学,选择适合自己的框架,也不错。
如果你觉得不好,就不需要寻找什么学习laravel的理由了。


恩,前方已做好撕逼准备。以下仅代表个人观点,不涉及任何其他团体组织和利益

1.Laravel 并没有颠覆PHP的什么东西,只不过是用到了很多PHP的新特性而已。

2.不是为了推广composer,composer本来就是PHP社区的产物,只是你不去了解而已。

3.Laravel的特性跟PHP的初衷完全不是两回事,命名空间是PHP的产物,而且命名空间这也不是违背所谓的轻量的特色,每个技术产生的背后都是为了解决某个场景下的问题,简单而言,为了解决类和方法命名冲突,才引进的命名空间。我个人觉得,那些在github上维护PHP源码的人,做出对PHP加入命名空间的决策是比较正确的。维护所谓的轻量特色不是你不思进取的借口。如果一门语言不能随着时代的变化而变得更适合解决问题,这语言终究没啥生命力。

4.个人觉得WordPress跟Laravel根本没有可比性。

5.很抱歉,对于GitOsChina是国内很有影响力的Git服务社区这句话,在下实在不敢苟同。要说做开源,必然Github甩开其他所有git服务社区十万条街(修辞称之为夸张手法)。如果不是开源,是公司的商业项目,基本上的选择都是自建git服务,所有我完全没看好和感受到GitOsChina是国内很有影响力的Git服务社区。个人觉得GitOsChina活不了多久(欢迎打脸),因为GitOsChina的生态实在挫到不行。

6.Composer的推广势必会造成项目各种依赖包的增加和烂用,目前来看,不敢苟同,滥不滥用得看写项目的人。

7.这样PHP必然会变得越来越不经量级你说的轻量可以理解成一成不变么?那只是不思进取的接口罢了

8.肯定是像加JQuery一样的瑞士军刀,由于它的轻量级、快捷、灵活,要说轻量,Jquery真排不上。而且现在的Jquery很难在获取之前那样的生命力了,因为前端的发展目前更倾向于 Vuejs 这样的 MVVM了吧。

9.还有BootStrap前端框架也是,像这样的框架可以广泛流行并得到充分发展和利用。如果要说在PHP社区中找一个跟Bootstrap这样CSS偏重的框架,那非Laravel莫属了吧。

10.Laravel的工匠精神,我想会造成了它很不灵活,学习曲线难等等问题。恰恰相反,Laravel却是非常灵活的,如果你了解IOC的话。

11.最后成为只有极少数部分极客和狂热者的宠物。但凡关注PHP社区和看过外面世界的人,应该都不会有这种想法。

12.Laravel的国内实际应用项目到底有哪些。不才,自己写了一个 https://laravist.com

所以我的观点是:按照这种情况看来,你可以完全不用学习Laravel,毕竟适合自己的才是最好的。每个人都有不同的追求。


你觉得哪个顺手用哪个,就和手机一样。


Laravel到底颠覆了PHP的什么东西,难道只是为了推广Composer吗
PHP5.3就已经有Composer了,除了larevel之外用Composer的项目非常多。
到底Laravel的这些特性是否违背了PHP的初衷,PHP本来就是以轻量为特色,现在又加入了命名空间和包管理。

这正好是一个现代的成熟的语言的特点,而且PHP不算轻量级的语言

还有Laravel的国内实际应用项目到底有哪些?难道只是为了开发一个像WordPress这样的极致博客吗?

larevel推出几年了,国内有不少项目是用它开发的,你没听说过不等于没有。另外现在的WordPress不是博客了,是一个小型CMS。

而且在GitOsChina上并没有找到很多的Laravel相关的应用项目,你不会给我说GitHub上面有很多吧,不能因为GitHub很出名而忽略了国内Git社区的发展和功劳吧,GitOsChina现在也是国内很有影响力的Git服务社区了

是吗?我还没听说过“大名鼎鼎”的GitOsChina呢,但是Github在开发者圈子里面无人不知。而且国内外用larevel的项目只会越来越多。

Composer的推广势必会造成项目各种依赖包的增加和烂用,这样PHP必然会变得越来越不经量级。

nodejs、python等语言也有自己的包管理器,没见过有滥用的情况,而且PHP本身也不是轻量级的语言。

我所理解的能被广泛流行使用的东西,肯定是像加JQuery一样的瑞士军刀,由于它的轻量级、快捷、灵活,同时可以利用它来扩展开发很多东西,完成我们自己的需求,还有BootStrap前端框架也是,像这样的框架可以广泛流行并得到充分发展和利用。

你提到的这些东西,没有一个是轻量级的,在我看来都是很重或者臃肿的东西。

Laravel的工匠精神,我想会造成了它很不灵活,学习曲线难等等问题,最后成为只有极少数部分极客和狂热者的宠物。

这是你个人的观点,什么叫极少数?你去Github上面搜一下,用Larevel的项目有多少?


如果你认为larevel有这样那样的缺点和不足,可以换其他框架啊,没必要人云亦云,盲目跟风
还是那句话:适合自己的才是最好的。


刚开始用laravel发现这东西特别复杂,各种乱七八糟的扩展,不过坚持了一段时间还是能学到很多东西。

之前看到的一句话,在用了一段laravel后确实发现这句话还是很靠谱

大项目用小框架,小项目用大框架


Laravel比较复杂,一般人学不会?

【热门文章】
【热门文章】