前后端分离的话，View 层确实没什么存在感了。
Model 层不应该有太多处理数据的逻辑，组装、处理数据应该放在 Controller 中的。如果你觉得重复性的东西比较多，可以抽象出一个 Service 层，然后 Controller 去调用各种 Service。
Node 的 Egg.js 框架就是这么做的。

点进去看到 Last commit log 是，删除授权码……

建议 rebase 或者回滚重新提交吧

更新了最新版，测试后退没有问题。
一个猜想：你可能是碰上了单页应用，且没有调用 history api 把历史记录写进去。可以看看是不是同一个网站，只是跳转时候 url 带了 # 之类的

如果是一个网站或者 ip 这么短的文本，打开 iPhone 上面的 handoff，直接在 mac 上复制，在手机剪贴板上就有了

楼上说的稍微有点严格了吧。
即使是音乐网站也要看完成度的，这个也不是那种网上到处能抄的仿网易云音乐前端+后端，而且他不过是找个实习，水平已经很可以了，很多在校的学生连个博客网站都不一定搭的起来呢。
另外还是在校生，写个公开课也没什么吧，何况 github 上还有相关实践项目。

祝能找到个大厂的 offer。

目前团队约定在用的就是类似第一种，不过很多问题的处理不像上面的某些说法理解的那样。

1. 对 Object，不是直接序列化成为一个字符串，而是继续保留嵌套层级结构，只是处理 数字、bool 类型；
2. 对于 null 值，必传字段加默认值，非必传字段不传；
3. 对于 bool 值，很多时候很多字段你是并不能那么确定他一定是非真既假的，举例如你要做一个是否收货的列表，最开始需求不明确快糙猛写成了 `已收货 / 待收货`，你用 bool 值 `isDelivered` 来表示。后来要你加 `全部 / 待付款 / 待评价` 这些状态岂不是要懵逼，所以用 0, 1, 表示是比较保险的；
4. 对于数字型，就是前面有人提到的，假设后端是动态语言，谁也不能保证代码多了以后，返给前端的接口一定是 int / float / double 区分开的。返回一个 1.0, 客户端写的是 equals(int 1), 就会闪退

这是我和我们客户端沟通的一些结果，一切都是为了降低客户端的闪退率，毕竟他们的代码发布出去了就没法调整了，而有时候你很难去避免一些错误。

有什么不对或者说的不好的地方，欢迎继续讨论

试试 `npm list -g --depth=0` 看看还在不在

Node.js 后台，也在 Webstorm。VSCode 是挺好的，但是要配一堆插件，最后效果还不一定有 ws 好，就懒得去了解了……
而且不知道是不是我用的 vscode 版本低了，打开几千行左右的文件的时候，打字偶尔还是会卡，还是在 16G 的 mbp 上…

个人认为 indexOf 之类的不算什么很严重的问题吧。只不过没有用最新的 includes 之类的语法而已，很多市面上成熟的库因为推出时间早也有这样的代码存在呀，又不影响性能，可以以后再慢慢改。
没有文档才是比较关键的问题，不利于后来的人接手。这个在框架或组件库搭建的时候就应该着重考虑到的。

@tao1991123 听起来好厉害，期待

借问一下，有蛙泳基础，学自由泳，在南山，大概是个什么价位？
蛙泳游了一两年了，自觉游得不是很差。但是自由泳比较难学，要打腿嘛，不太会，想找人教一下……
谢啦~

同楼上。今天提了离职，突然要准备面试了，才发现压力还挺大的。之前工作太安逸，什么东西都不会钻的太深。不过也是因为这个想要跳出来的，想换个环境也是想改变学习习惯。

顶一下，pure render 那个专栏真的很不错

@mentalidade 貌似不读通讯录无法登陆。不知道这种 app 怎么过审核的。

这个 app 交互和设计真的很烂。
而且有个不能忍的，他读我通讯录，然后直接未经我允许给我通讯录的人发短信，还实名告诉他，[我的名字] 在脉脉，给你分享了 xx 个人脉。
我当时就上去改信息（流程巨麻烦），然后把这个 sb app 卸了。

江西移动。
该渠道没有权限。

服务端渲染和模板引擎并不是一个东西。

首先不用模板引擎改用前端单页应用原因，就是为了体验上的优化（不用频繁的页面跳转）。
在这个过程中，由于首次加载前端框架耗时较长以及 SEO 方面的原因，才会引入 Server Side Render 这个东西，一般来说也只是首屏直出，和传统的模板引擎并不一样。

另外引入这个 node 中间层还可以解决一些路由、数据定义上面的问题，并不是全无好处，只是在架构上会复杂一点。当然，也不是所有项目都需要这样搞，应该事先沟通确定

没有卡过诶，是啥格式的视频？大小多少呀？