自从这个博客立项开始我就在反复思考一个问题——是否需要将Vue引入到这个项目中从而替换掉Blade模板。

21年接近三分之二的时间我都在混战地1的圈子，期间和别人合作做了一些试手的项目，内卷榜便是其中之一[目前后端数据失效]。由于需求十分简单，仅仅需要展示百来条数据并予以显示即可。一开始只是帮忙Django相关的一些东西，负责将东西呈现出来即可，所以我也就套用了一个手头现成的Bootstrap模板就完事了。

随着项目的不断完善，单纯只是呈现数据显得有些笨拙且单调，于是这个项目进行了一次迭代升级，打算在呈现内容的基础上添加排序功能。对于页面元素(table)进行操作就开始涉及到JS相关的内容了，在考察了JS家族的众多语言中，我选择了Vue这个新秀进行页面的动态处理，同时将过于单调的Bootstrap框架更换为UIKit这个轻量的前端框架。朋友小铃[@SuzuBucket]让后端所有的数据以Json格式发送，我则让前端的Vue通过Fetch方法获取并进行处理后进行渲染。通过这一个方法就将数据的排序等操作下放到了用户本地，从而减轻服务器的负担，是一种理想的解决方案。在这基础上又进行了i18n和百度地图适配等其他功能，不过这些就和本文主题没什么关系了。

那么回到本文的标题，究竟Laravel是否必须替换Blade模板为Vue？

为什么说要替换Blade呢？

从一段时间的Laravel开发经验来看，Blade模板在一些情况下显得较为复杂。尽管接收到了数据，对其进行一定的处理还需要遵守Blade一些固有的语法，再复杂的操作就需要额外定义一块PHP块进行处理，而且一般的习惯是采用模板继承的方式，导致html元素和数据之间的联系看上去不是非常地直观。

那难道Vue就很好了？

回答这个问题稍微有些难度。从数据和页面元素之间的关系来说，Vue尽管也多用模板(template)继承，但是其语法风格和原有html有很高的融合度，从某些角度来看，这种方式更有助于理解数据和元素之间的关系。同时由于Vue的特性，结合文章开头的例子，可能就能明白我要说什么了——是的，使用Vue可以更好的实现数据的一些变化，这也正是其DOM特性带来的一大优势。

那么代价是什么？

凡事总归有得也有失，用Vue替换Blade总归是要付出什么的。最直接的冲突应该就是路由方式的改变。由于Laravel是个典型的MVC结构，所以页面的访问都需要通过路由来获取相应的控制器并返回对应的视图，这一切在Laravel设计之初都考虑到了，所以一套流程下来工作的很好。但是现在视图被我们人为的替换了，于是路由自然而然就需要进行相应的大改。同时数据之间的传递又成了一个问题，在使用Blade的时候，控制器可以直接将数据传递给模板，但是更换后Vue，似乎强制造成了一种前后端分离的味道，一切数据的获取需要依赖API进行传输。

所以得出的结论呢？

应该来说，对于较大数据以及页面内容数据呈现方式变动频繁的项目来说，采用Vue应该是更为推荐的，或者说可能被迫采用。同时，如果项目对大部分数据都有公开的API接口，也可以轻易的升级成Vue。而对于数据量较小，内容变动有限，比如这个博客站这样的项目，特地将Blade转变为Vue则显得有些小题大做。当然，这一切都是基于最直接的利害关系得出的结论，最终决定权依然是在个人。尝试学习一门新的语言去跳出自己的舒适区未尝不是一种进步，不是吗？

由于我已经离开了战地1的圈子，所以上述的内卷榜目前为何停止运作我并不知情，可以尝试询问小铃[@SuzuBucket]