lyris

想起上古时代，我用过网海拾贝 netcollect 很多年，每次系统要重装都备份好

@TypeNANA 多谢，这个可以！

忽略，自己的问题，错怪 wall 了

但是大多数网站并不是单页面应用，却非得搞成单页面，或半单页面(肯定也有蹩脚的页面路由),我觉得就是走上邪路了

@janrykk 这也是我一直非常喜欢 bootstrap ， ace 这种前端库的原因，既能适配手机，又能满足功能，界面还快，现在每次看到新框架做的花里胡哨的页面，花了非常多的时间做出来，居然连手机也不能自适应，各种浏览器兼容问题，页面源码全是 js 就觉得这绝逼要玩玩啊，如果是微博网页版和微博聊天，纯 js 渲染我觉得是正道

最为一个后端狗，恰好在前后两个公司经历过两种模式的开发：

第一种就是 前后端不分离， 前端用 freemarker 辅以 js, 页面的主体框架部分是 freemarker,数据提交验证，侧边栏之类的都是 ajax post 来验证或渲染。每个开发周期，前端负责和美工要图，切图，静态页面的 css+静态 js （ js 用的也是 jquery ）交互效果，后端负责后台实现接口，套 freemarker 页面， js 动态数据交互，后端一个人完成一个功能，由于 js 请求有各自的 namespace ，也不会出现各个模块 js 冲突之类。页面简洁干脆。各种前端技术稳定，浏览器兼容性好，周边工具（ js/css 合并,压缩，版本控制）基本不出问题

第二种就是现在前后端分离，后端提供 api ，前端用 mvc 前端框架 knockout js ，由于时间短+任务紧，开发的系统功能点繁多，使用对象复杂， api 数量暴增，尼玛一个鼻屎大的功能就得提供分页列表，增删改查各种接口啊，各种全局定义的枚举也需要提供接口给前端啊，由于 knockout js 有自己的 MVC, 所以后台接口增加一个字段，或者重构一个字段，推动前段去改比推动牛还慢啊，各种格式化库新来的前端不熟悉，要引入各种 js plugin (传统的各种控件要适应 knockout js 框架你不可能一行代码不改动就去适配吧)啊，时间来不及就强迫让后端做各种格式化好的数据喂到前段面前啊。

感受：

1.前后端未分离时代，本人还可以自称全栈，团队开发效果奇高，页面上的数据权限控制非常简单。 在前后端分离后，出现问题本人已经改不动那些 js 了，后端已经实现了一遍 MVC ，现在前端又来一遍业务上的 MVC ，心累，除了偶尔写过几个 knockout js 的 plugin ，但是前端这种 MVC 框架层出不穷，熟悉各种东西需要花时间吧，技能还停留在 Mongo + express + angularJS + NodeJS 阶段，对 bower, gulp ， yeoman 之类的非常有好感，但对新花样的前端 MVC 代码非常厌倦了。数据接口往往会把一些前端用不到的数据也吐给 json api 上来，个人觉得是一个安全隐患，但是不这样，前端的日子也不好过，真要做好权限控制，个人觉得前端的 MVC 中的 V 也要多做几套，否则那些页面元素只是隐藏啊，丑陋不堪。各种周边脚本一会是 grunt,一会儿是 gulp ，一会儿又是 webpack ，喜欢前后端分离的前端往往喜欢作死用最新的技术最新的版本，而自己又 hold 不住，线上各种问题。

2.前后端分离带来的好处。如果接口提供给多个终端用，比如手机，后端提供的接口标准化还是非常有用的。一套接口可以应付所有终端，以前前后端分离的时候接口的质量也没有太高。还有一个重大好处是部署的时候前后端分离部署，后端部署和前端部署各自部署各自的，没有耦合，但在前端用 MVC 框架下，本程序狗已经改不动一个完整的功能模块了，前端部分还要看到一遍业务 MVC 就感觉恶心，改不动。对于个人而言，工作量反倒变少了，只用自己写好测试格式好接口就行了，不依赖页面。

总之，痛点还是以前的 freemarker/velocity 和 jquery 太好用而新出的前端 MVC 框架喜欢挖坑；而我时不时喜欢做点东西，喜欢一个人做完整个功能，沟通太费事了，又目睹了前端 MVC 及其周边发布工具的挫样，哀其苦逼但又无可奈何。

zsh启动太慢不能忍，用一段时间后卸载了

非常不错