Nboat3 Q&As

关于这个新网站上线，可能大家会有一些想知道的东西。Neboer整理出了一些常见问题的回答供大家参考。

终于。

根据GitHub上的记录，Nboat3历经了接近两个月的开发2020.4.7-2020.5.26，才算是正式和大家见面了。

我当然知道大家都觉得我有很多想说的，所以我整理了这篇“ Nboat3 Q&As”供大家参考。

Nboat3和Nboat1/Nboat2比起来，变化大不大？

何止是大不大，这是完全不同的两个网站，只是碰巧看起来长得一样而已（那不能说是碰巧，就算是“我故意让这两个网站看起来长得差不多”吧！）。

Nboat2使用的是pug+express，这是很标准的模板渲染建站的方法。“模板渲染”大概是各位入坑Web开发所做的第一个“网站”就接触到的东西吧？其实模板渲染一点也不基础，相反，模板语言很好的把HTML和代码语言结合在了一起，虽然有缝合怪的嫌疑，但是很稳定，写起来所见即所得，非常的直观。当我们提到“个人博客”的时候，可能很多经验比较丰富的开发者脑海中第一个闪过的，大概就是“模板渲染”。

所以，Nboat1采用了golang的HTML template作为后端渲染方法，我至今仍然认为做出那个决定的我非常愚蠢，因为golang和mongodb联动完全就是自讨苦吃——明明可以不用找这份罪受，便于开发的语言这么多，我非要选择一个强schema的golang——简直就是好日子过久了，想给自己找点不痛快。开发得十分痛苦，做到一般甚至觉得“没法做了”。

所以应该是去年五一假期？我用了大约一周的时间写出了Nboat2——很舒服，模板渲染真开心啊——其实我自己都知道，这七天我大概有五天是在解决各种编辑器“editor”的问题。我最终做出了一个违背祖宗的决定（？？）——把编辑器的关键JavaScript文件拆开，然后在模板中根据需要引入各种函数。事实证明这个做法是可以用的，但是代码基本不能维护，因为一拆就散，想要修改点啥感觉都要先重写。引起这个问题的主要原因是因为这个设计不直观，也不贴近逻辑实际——编辑器是一个独立的、带有“预览”功能的整体，而拆成各种“文章编辑器”、“meta编辑器”之后，也应该把整个“带有预览功能的”编辑器的“外壳”保留下来，只更改里面的需要编辑的东西和生成预览的方法。这个设计其实也是在像Vue这种设计框架中里可以通过slot非常完美的描述，其实还是一个“组件化”的问题。所以组件化——这才是现代网站开发的目标，当然这篇文章在若干月之后可能就过时了，现在所说的”现代网站开发技术“说不定就是将来的“古代网站开发技术”了，可能到时候有比“组件化”更贴近于人类思维方法的描述网站结构的框架设计模式，但谁知道呢？

所以说，Nboat3使用了基于vue的Nuxt框架，用Neboer自己的话来说——就是“跟上了时代的步伐”，这样在未来相当长一段时间之内，都没有换框架之虞了，也算是“一次开发，解决几年的问题”了。在这个高科技领域发展进步非常迅速的今天，防止自己开发软件的技术落后于时代的方法，除了不断学习不断尝试用新方法开发程序，不断用新框架重写之前写好的东西之外，还有一点，就是尽可能使用“超前于时代”的开发方法来开发。这样说不定过了相当长一段时间，过去“超前于时代”的开发方法已经变得稀松平常了？

所以Nboat3和Nboat2比起来，真的一点也不一样，依赖的样式库确实还是bootstrap，但是此bs非彼bs，这是bootstrap-vue啊！其实像bootstrap这么优秀的组件库，应该再继续支持各种Web框架。

不管是之前所用的pug，还是现在所用的Nuxt，neboer.site一直坚持用JavaScript开发，尽可能采用各种开源的框架来解决问题，实际上，现在neboer.site完全是基于开源技术搭建起来的一个站点，自认为是开源爱好者的Neboer表示一本满足。服务器的Ubuntu是开源的，Nginx是开源的，Docker-CE是开源的，nodejs是开源的，（js层）pm2是开源的，vue/Nuxt、以及Nboat3所用的每一个js库都是开源的，真是开源到家了（ JavaScript社区有一个很棒的好处，就是npm社区是真的开放，开源万岁！我在这里再说一遍，开源万岁！

为什么直到现在才想到用Nuxt开发网站？

其实我有的时候总觉得我一开始的路线走错了，Nboat1、Nboat2都是因为自己不够技术自信才会有的产物。如果我一上来就开发Nboat3，会不会一步到位，一下子就成功呢？

这个问题已经无从回答了，因为开发Nboat1的时候还不知道Nuxt这个好用的框架，我只知道Vue可以prerender或者SSR，而且那个时候还是Vue2时代，Vue3还没有稳定版放出来。而且那个时候我还没有接下那个不小的项目，代码量和现在完全不能比（其实现在代码量也少得可怜，加油啊Neboer），所以只能说Nboat2是“那个时代的产物”，和Neboer本身没有什么关系。代码本身就是存在于那里的，我只是负责把正确的字符的排列组合找出来。（？）

Nboat3使用了Nuxt框架，相当于在框架层面直接支持Vue的服务端渲染方法，这一点带来的开发体验提升是革命性的——因为你可以在编写代码的时候就考虑到SSR的问题。你的网站不再是简单的单页应用，你的Router不再是JavaScript的文字游戏（哈哈，确实是文字游戏。Vue-router里的URL更像是一种“匹配”而不是一种“地址”，因为所有的事情基本都是在前端完成的，你请求了不同的地址，竟然给你返回了同一个页面，更令你惊讶的是，这个页面竟然可以做到和之前的页面不一样，这个过程竟然是前端完成的！在你请求第一个页面的时候，如果不是懒加载的话，这个页面的所有内容已经全部发给你了），你不用再担心SEO的问题，你只需要专心的做好网站，Nuxt自动会把该渲染的部分都渲染好，等着搜索引擎来抓取，这一点对于个人博客来讲还是非常重要的。

所以Nboat3和之前的两个版本完全不同——之前的版本是服务端根据模板填内容，组装HTML发给前端；而现在服务端通过复杂的服务端渲染机制，以更高级的方法实现了更基本的东西，前后端之间的数据交互还是像Vue一样通过HTTP请求传递，但是从原来的客户端请求服务器接口变成了前端“服务器”请求后端接口，然后用vue的逻辑渲染到页面上。最棒的是，这个所谓的前后端还运行在一个nodejs应用之中，对于这种较小的应用来讲，这种开发方法真的又快又好，唯一的缺点就是调试的时候比较头疼，因为后端不能独立于前端而单独调试，每次调试的时候最好的方法就变成了console.log（很麻烦。

现代前端设计方法的优势

方便。

现代前端设计之所以“现代”，肯定表示了这是一种“趋势”。就比如现在一提到做游戏不会有人想到用Visual C++编程一样，现代游戏开发基本都是面向引擎编程（，为什么呢？因为方便。方便是最大的优势，因为人们总是希望专注于一件事情本身，而不被其他的问题所打扰。因为方便，所以开发的标准化很高，文档里有详尽的阐述，或者社区中已经有很好的库来供你使用。古老的东西终究没有现代化的东西好，这也是为什么要用Arch Linux——尽早地体验到社区做出的软件的新功能——和新bug（

方便，就意味着少bug，就意味着规范，就意味着能够获得更好的开发体验。当然，现代软件/网站开发肯定是比较繁琐的，因为现代化很多时候还是复杂化，更新的框架就意味着要支持更多的环境，需要更详细的配置。不过熟悉了这个过程，就可以让你的代码的适应性变得很好，变得更招搜索引擎喜欢……而且现在很多复杂的东西都是模块化的，你可以根据自己的需要自由的选择要用“复杂到何种程度的”配置，实际开发起来也没有那么困难。

Nuxt是一个高度规范化的前端框架——高度规范化，指的就是它对你的编程范式要求严格，同时集成了大量的vue常用库的功能。比如最常用的vue-router，在Nuxt里直接以“页面结构”作为默认的route，同时这个结构还适用于动态路由。也就是说Nuxt在支持传统router config的基础上，还支持根据规范的目录结构自动生成这种config，这简直太方便了，我在之前的vue开发过程中就曾经想过如果要是不用写内容繁多而且高度复杂的vue-config该有多好。

Nuxt不但原生继承了vue-router，还继承了很多其他的基本库。Nboat3用到的库还有nuxt store。这个就是Nuxt中的Vuex。考虑到ssr在处理用户登录等方法上会比较麻烦，Nuxt还有原生的Auth模块。使用这种模块可以方便的“免安装”使用类似的vue库。本来是为了移植到Nuxt上才有的库，用起来体验竟然比Vue原生还要好，这叫什么，后来者居上？

Nuxt的template、page和component把vue文件管理的井井有条。这还是体现了“方便”。想一想我在平时所写的vue项目，各种vue文件乱七八糟的堆放在一起，页面和组件基本没有特别明确的分界，即使有也是通过自己定义目录结构来实现的。但是即使这样，所有vue文件之间的依赖关系还是依赖于各个文件之间互相import，非常不直观，而且很多时候我们并不需要这个import，我只是想做一个组件让所有的父组件都可以调用而已，所以说Nuxt在各种意义上都非常方便。

怎么想到用Nuxt写Nboat3的？

其实你们都看过我之前发过的文章，我很早就有“用Nuxt框架重新写一遍neboer.site”的想法了。然后就是一直鸽子，迟迟没有动手。

Nboat3是什么时候开始“立项”的呢？大概应该是从我想更新一下博客内容开始的。我也是发现了一直用的bootcdn速度不快，想要把js文件直接用我的阿里云cdn serve出去，这就需要上线改一下我的模板文件。当我看到我几个月之前写的代码的时候，瞬间一种很特别的恶心的感觉涌上心头，当场关闭了终端窗口，直接打开了IDE，立刻新建工程——然后打开Nuxt官网，当场开始研究如何创建一个Nuxt项目起来。

为什么会感到恶心呢？这些话之前我是断然不能说的，因为直接批评自己刚刚写过的代码——有点无力了——你觉得之前自己写的代码垃圾，那你为什么不重写一个？你为什么不改一改？其实我自己是想改一改的，但是你知道，“shit mountain”再怎么优化也是建立在一堆shit上的——当然我不是说模板渲染不行！！！我的意思是，模板渲染虽然简单直观，但是可能不是很适合我这种“编辑”功能比较多的网站。Nboat3中有大量的编辑器，如果完全采用模板渲染的话，就需要把每一种编辑器都写一遍，或者把编辑器的js代码拆开——这显然都是很不能接受的。虽然说优秀的设计可以避免这个问题（可能存在一种设计，还是用模板渲染的方法，但是可以用最少的代码实现最多的功能，比如一套代码又可以编辑博文内容，又可以编辑博文meta，在实际使用的时候只需要在代码中做出一个小调用就可以。）

所以不是说模板渲染不行！而是说，模板渲染可能在解决“博客渲染”的问题上是确实很优秀的，而且非常直观；但是在解决网站的其他功能上可能就有些力不从心了。所以在一定程度上，PHP是不是世界上最好的语言？别问我，我不知道！

组件化是Nboat3的必然趋势。组件化、现代化的网页开发方法，那是什么？那不就是Vuejs嘛（react也可以），但是Vue做seo优化还是比较费力，需要额外花时间去配置，就像上面所说的那样。而且不得不承认Vue js加载速度还是比较慢的，以及很多其他问题。其实Vue也一直在进步，Vue3就是致力于解决这些问题而诞生的一个新版本的前端框架，但是作为一个个人博客而言，Vue的缺点看起来有点刺眼，所以我认为Vue并不适合用在做Nboat3上。

其实如果说这些都不算是使用Nuxt的直接原因的话，那直接原因一定是因为Bootstrap-Vue对Nuxt的“显式支持”了。Bootstrap支持Nuxt也不是一天两天了，很早的时候也用bootstrap-vue做网站，BS-vue的网站上很多组件都写明了它在Nuxt环境下的表现形式和用法，从这一点上看，Bootstrap和Nuxt真的走得很近。这一点也让我很放心，因为这就说明这个组件库在开发的时候是考虑到了支持Nuxt框架的，不至于出现不兼容的问题。剩下的部分，Nboat3过程中开发的过程中所用到的其他的库也基本都是Vue原生然后搬运到Nuxt环境中去的，就比如这个nuxt-moment库。我一开始用Nuxt开发的时候，也曾经非常担心兼容性的问题。因为Nuxt原生服务端渲染，在内部渲染的过程中要求服务端的DOM结构必须和浏览器中的DOM树中的内容保持一致，这就导致了很多直接运行在浏览器JavaScript环境中的客户端组件可能就无法正常在服务端上运行，从而产生类似于“document对象不存在”之类的迷惑错误，不过最后证明：这种问题暂时不存在，正如上面所说，很多vue库都有对应的nuxt对应的版本，如果不用什么奇怪的库的话，开发者是不需要有这个顾虑的。不过这也不意味着Nuxt就完全不能用只支持Vue框架的各种组件。如果要是用了什么Nuxt不支持的库的话，是可以通过配置文件做出合适的调整的。

Nboat3新在何处？

除了彻底解决了“内部问题”，Nboat3还增加了自定义主页、主页多语言和留言板三个功能。虽然都是不太起眼的功能，但想要很好的实现还是颇费一番功夫的。除此之外大概就是Nboat3依然依赖于mongodb数据库，mongo真的非常适合做个人博客的数据库。留言板是一个很有意思的功能，在编程的时候确实考虑到了其他用户提交评论的需求，不过因为各种原因我决定还是不开放留言板，暂时不允许用户与网站互动。不过过一段时间可能会有开放评论阶段，到时候经过认证的人类用户可能可以在留言板里直接发表受限制的评论，这还是取决于我的心情（叉腰）

Nboat3时代，我还想重做一下nerchat!。所说的“重做”也就是把最新的版本部署在服务器上。由于之前使用的docker部署方法有点麻烦，这次采用直接部署的方法。这样一来nerchat的网站也可以“动态”了。让nerchat的网站随时和官网保持同步，让希望加入的用户随时可以下载到最新的客户端，这也是很好的。

接下来的开发任务？

nbtp server，编译chromium。我决定抛弃繁琐的libcurl了，咱们用点现代C++的方法解决问题吧（