我用 Three.js去写了一个新闻网页，不知道这东西好在哪里

link标签的 media 属性，配置成 print，然后专门写一份针对打印的 css 就好了

那就别发布了

看你对钱的灵活性要求了，如果半个月内可能会需要，就投余额宝或者招行的朝朝盈了，我是朝朝盈，比余额宝利息高； 如果1个月以上，可以试试懒投资，二个月的话，还有 it 福利可以拿，多赚个50快利息这样

何不入台 air。。。

以后就是扫脸登录，扫脸转账了

kinde voyage 挺不错，关键是保护眼睛，ipad air也有，体验肯定比 kv 好，但是伤眼。

浏览器端的用 bower，服务端的话用 npm

个人观点：

仅从计算资源成本角度来说，当然是客户端计算来的节约。

效率问题：

如果网站并发比较大，大到一个临界值 x 以上，前端计算比较能够保证稳定性，后端响应能力相对减弱；

如果网站并发一般，在临界值 x 以下，后端渲染，生成 html 字符串给前端较快。如果要兼容 ie7这种不带原生 JSON 对象的浏览器，靠前端渲染 html 估计界面会挂。

不过这个 x 很多时候都是一个经验值，而一般的网站选择前端渲染和后端渲染很大程度依赖于前后端的人力资源以及整体的架构。

如果架构是 spa，那么基本是由前端来渲染的；如果是传统的 web page，由后端生成还是前端来搞取决于上面提到的临界值以及开发资源（前端多么，那就前端来搞，后端多么后端搞）。

这个挺好的，基于 angualr 的

ionicframework.com

@soulteary 能解决我的疑问才是真的，逃避技术点疑问，没有重点的回答也没啥必要继续了。我目前对淘宝ued一点兴趣都没，不用啥简历简历的，要解决问题，和要不要去ued 那一点关系都没；我从那出来1年多，在现在这个地方无比爽，就这样，，

@thonatos seo这块，百度做的确实不够好，该黑的还是要黑，就事论事，解决方案文中提到过一个，针对 robot 使用 phantomjs 渲染页面丢过去，我没试过，但理论看着可行，所以我也希望有人尝试一下论证。 另外，也没啥打架不打架，我只是想明白中途岛方案和其他方案相比，到底优势在哪？仅仅是想探讨技术而已，请尽可能的，也尽情的在技术上扇我耳光。。。。所以如果有支持中途岛的同学，我仅仅是想和你们交流下技术方案而已，不要想太多了。

@soulteary 既然你们是中途岛的拥护者，不好好的推广，说说你们的方案对比其他方案的优势，掩着藏着是为何？ 既然你们提倡这种模式，又出来做分享，解决别人的困惑，说服别人用你们的东西应该是很乐意才对。

关于你说朴灵强不强，我先放着。。。。我也不是要从层级去论能力，但很多时候，层级确实是和能力挂钩。

你说的什么中间件用起来爽，完全没有去回答我提出的疑问，java 不能有中间件？相信阿里的 java 中间件用起来更爽。

再说你的约定数据格式的问题，前端写后端模板，后端一样可以做到只准备数据。难道其他前后端分离方案就不能愉快了？

说性能，你觉得双十一性能稳定是因为你们用了 node？。。。

最后你的接口变了的问题，其他方案的改动会比你的改动代价大？没记错的话，你们是 java 和 node 在同一台机器部署，如果 node 要重新部署了，java 会需要一起部署不？


你说到了苏千，我和你观点一致，他确实是大牛，但是，他确实是搞后端的啊，呵呵，当然现在转到支付宝做个挂个前端 title，做架构的事嘛。包括大部分好用的 node 中间件，你能给我说说这些作者有几个是前端出身？ 而阿里一开始就搞前端的，有几个写出了好用的中间件？


另外，我也是经历了写 html demo，到写前端 mvc，再到现在体验前端维护后端模板的方案，才会有了此次的回帖。我想要的方案很明显是ROI 最好的那个。。

@HaEx 我比较喜欢直接吐槽，这样我可以认识到我的问题，至于你说最后的三个问题，有一个不对，那么我猜你说的是第二个，这个我没有打听，因为这个是我在 velocity 上直接问的清羽，是他说的，至于他说的是不是事实，我只是转发。 数据平台部门在 node 牛逼，这句话我确信没啥问题，当然，可能现在没这个部门了就是，呵呵

好无聊，过来练习下写作和表达能力。

首先，我觉得不要扯性能方面的问题，性能对于绝大多数非首页场景都不会是瓶颈。真要追求极致性能，就像淘宝首页一样，写成静态 html好了。


解决前后端分离的问题，目前大概有以下几种方案：

1. 前端写后端模板

1）前端和后端的模板是不一致的，比如前端可能用 Hanldebars，后端 java 经常用velocity，php 用 smarty，都由前端一起维护。比较恶心的问题在于，公司大了，部门多了，业务线多起来了，可能技术选型都不一样，比如有的业务线用 php，有的用 java，还有的用 python，他们的模板引擎可能都不一致，一是碎片语言实在太多了，更严重的是阻碍组件的复用，比如淘宝的通用吊顶和吊尾以及登录框是可以全站复用的，但之前用 java 写的，如果有的业务线用 php 咋办？于是他们对这些组件进行前端组件的静态化处理，即这些组件变成了 html+css+js的片段给其他业务线去用，数据请求通过 ajax 去做；但这些组件的一个特点是，依赖后端的动态数据较少，比如吊顶只是简单的一个登录信息请求即可，不适合需要大规模的后端查询页面。

因为1）的问题，于是有了下面的 2）

2.1） 前后端统一模板，模板语言嘛，用不同的语言都写个引擎就好了嘛，比如后端 nodejs 用 jade，咱前端也用 jade，嫌慢，咱先编译好。这个我还没找到比较大型的案例，我自己做着玩玩的时候用过。

2.2）有人觉得每个语言都要为一个模板语法写一个引擎，维护成本也大，模板语法一更新，所有引擎都要更新，真是去你大爷的- -！ 于是呢，linkedin的做法是前后端统一模板为dust（你猜对了，js的模板引擎）, 后端在渲染模板的阶段，起个线程跑v8引擎，去做模板渲染。于是成功解决了web组件（前后端都有）复用的问题。


1方案的普及需要有好用的工具提供给前端做开发调试mock等，比如淘宝曾经出了个 vmarket，据说难用所以没然后了。然后，fis 也有针对这个专门做了工具，具体去 fis 主页看好了，最近我在试用他的 java 解决方案，感觉还是比较容易上手的。

2. 前端 mvc（webapp）

感觉不用太多介绍吧，这几年比较火的架构，模板在浏览器渲染（尼玛，你说后端返回渲染好的 html 字符串，艹，这还能叫前后端分离- -！！！！）。

很多人这个方案问题在于seo 和性能。就 seo 来说不是太大问题，比如我从组里同学那获知的用个 phantomjs 渲染出页面丢给 robot 就好了，以及 google 是有针对 ajax 页面做索引的。

再说说性能，linkein 不用前端 mvc 的一个很重要原因就是性能，不过人家是因为页面要兼容到 ie7，ie7没有原生的 JSON 提供，解析起来确实是巨慢无比，所以放弃了。我觉得吧，如果你的项目仅需要支持ie9+等现代浏览器，基本可以考虑采用这个方案试试，当然 seo 这块我也没涉及到，不好扯淡，有朋友去试了可以教教我~


2方案对前端的要求会比1更高些，大规模项目的路由设置，模块切分，mvc 的职责，代码规范，目录结构的组织，都需要有一定功底，否则会玩脱。

这个玩法比较多，框架也很多，angularjs，ext，然后是我们这的一系列组合： https://github.com/ecomfe/er
https://github.com/ecomfe/esui
https://github.com/ecomfe/oo
https://github.com/ecomfe/uioc

打广告就是爽，呵呵呵呵。


3. 加一层中间层

比较火的，淘宝中途岛，比较低调的， fis 的 yogurt。 线上案例，百度音乐移动版，淘宝的对外项目不是太清楚，麻烦知道的同学告知下，内部项目主要是之前的数据平台部门的一些产品:在云端等。

我曾经是这个方案的拥护者，在经历了北京velocity大会的 fis 和淘宝的前后端分离实践分享，前不久d2的支付宝前后端分离实践分享，以及最近自己在搞一个业务线前后端分离的实践后，我现在成为这个方案的反对者。至少我觉得这个方案不适合大多数场景。

我们看看这个方案想要解决的问题：

1) 前端依赖服务端开发环境
2）在服务端View层高度耦合
3）沟通成本高
4）职责不清晰

对于1），可以通过开发优秀的工具去解决，至少 fis 的 jello 还不错。
对于2），不明白这耦合在哪里？
对于3），阿里的场景是前端写html Demo，再丢给后端套，敢问有几个公司这样做？
对于4），我觉得和2）一样，说的太虚了。你要说职责清晰，学学腾讯把 html css 也分出去得了
- -。。


关于 ppt 中说前端 mvc的问题，限于篇幅和精力，我懒得吐槽- -！，@otakustay 可以来试试- -！

再看看这个方案会遇到的问题：

1）学习成本实质是最高的。

天真的以为仅仅是语言没有学习成本？ 后端的各种技术，安全，日志，监控，并发，事务，分布式 session，数据库读写分离，确定一般的前端能搞定？阿里经历了多少年，java 发展了多少年才成就了现有这么成熟的体系。 bat 或许能用 nodejs 去玩玩，因为技术的服务化和平台化比较成熟，都会提供服务化的api来用， 比如分布式的 session 访问，你只需要去调接口，不用自己去用 nodejs 实现一套了，再说用户信息，订单信息也是提供接口给你，至于他们怎么做性能调优，安全处理，数据库设计你都不用管。 但是一般的公司能做到这么高度的服务化么？

2）现阶段绝大多数前端水平还跟不上

即便很多前端号称自己会 node，也只是停留在写工具层面。

在 velocity 上，淘宝的分享者（p7）说，他们请了后端的同学帮他们实现 nodejs 的 session 读取框架，我就跪了好嘛，整个淘宝 ued 都找不出一个前端能写这个，你确定有几个前端有这个技术能力去 hold 这种技术？
在阿里也就那些数据平台部的人在这方面比较牛逼了，但是别人一直都是以后端为主，前端为顺手写，起点和一般前端完全不同，现在最多就是挂个前端的 title 在上面。

3）想要解决的问题都可以有更快捷简单的方式去解决

对大多数场景来说，我更推荐1的解决方案，简单快捷，没有太多成本。比较成熟的公司想要做组件化的复用可以参考 linkedin 的方案。 中间层可能只是一个舍近求远的方案。


最后，中间层这个方案给我感觉最多会成为一个，由 nodejs 渲染的模板引擎方案。

当然，我个人倒是蛮希望这个方案能够将前端的总体水平提高一个档次，能够将前端工程师变为工程师。

有钱没？ 有的话就 pd10，没的话 vb

明天我去买一副试试看就知道了。。

1. 代码规范，这个比较简单，随便看了
2. 目录规范，这个感觉才是比较有意思的地方，不同的目录结构划分代表了对项目不同维度的切分
1) 一种是按照职能组织，即html，css，js 放在独立的文件夹，业务逻辑模块分为分散在三个文件夹，这是比较常用的一种组织方式，适合中小网站，以及对复用性要求不高的场景。

2） 按照业务功能组织，将业务按照功能切分为模块，一个模块一个文件夹，模块包含了 html/css/js，模块可以递归的继续包含子模块。 这种划分非常利于模块复用，以及网站的功能扩展。webapp 经常用这种方式组织。

目录规范个人推荐：
这个是我所在团队的那群人搞的： https://github.com/ecomfe/spec/blob/master/directory.md

另一个是 google 的 angular app 的规范，要翻墙，我保存到了自己的笔记中：

https://www.evernote.com/l/ANE8oCpzLrFO858xTDqQqvKVkJJs87rHhYw

两者的思维基本是一致的。

xlsx.js