每天联系； 介意你的想法不接触其他异性。 这算哪门子分手啊，赶紧去追回来，男人要不怕失败。 如果都讲什么“上进心”，条件，那很多人不用谈恋爱结婚了。 边追边上进

@marc 哈哈, 一定~ @hysios 谢谢胡总支持, 一起加油

@agilejzl @pishilong @marc 谢谢各位啊, 湖南老乡还不少, 欢迎有空来坐坐~

@forecho 谢谢提醒, 现在还没有开始大规模推广, 所以没有想太多, 确实放个二维码比较好. 已更新. :plus1:

可读性是针对人而言的, api 需不需要人去读? api 是给机器去消费的吧? 问题域中的座位编号用模型域中的id去表示, 我觉得很直观啊.

#59楼 @ericguo 误会误会啊, 其实我的意思和你一样, ember 是个好东西, 鼓励有能力有精力的人捣鼓, 个人觉得比 rails 门槛高. 其实我用 ember, 从 ruby 圈子进入了 nodejs 圈子, 这本身就让我受益匪浅.

@nightire 我说的 session保持 的问题可能太泛泛, 举个例子: current_user.

你前端想要一个 current_user, 用了 simpleAuth, 在 initializer 里面注入到 session, 得到一个 promise. 然后我在 application route 里面还有一部分逻辑, 是处理购物车的, 跟 current_user 相关, session(cookieStore) 只能放很少的东西, 你要依次初始化这些对象(去后台去取, 都要发请求, 如果服务器端生成页面的话就直接取了), 难度体现在:

1. 处理 promise. 我为了每次都有一个可用的 ember model 对象, 把 resolve 好的对象塞到 applicationController 里面, 其它 controller 里面定义一个别名引用它(这样很傻..).
2. 考虑到 购物车 列表, 商品列表等, 即使用了 side load, 请求次数和数据量也挺大的. 且每次用户刷新, 上述逻辑都要跑一遍, 数据都要跑一遍.

现在看来, 有些问题是我 ember 没用好造成的, 比如为了烦躁的 promise 问题, 我后来将所有的模型全部定义为同步的了.. 还有的是 ember 本身还在快速演进, 比如 ember service, 至少在我使用的 1.X 版本里面没有.

作为一个全职写了一年 ember 的人, 我后来总结是使用 ember 拖了项目进度的后腿, 当然这不是 ember 的问题, 一是可能场景不适用, 二是学习成本(以及没学好用好..)

我也认可你的观点, 前后端分离及 ember 是前端的方向, 仅一个 双向绑定 可能就会让你爱不释手. 有厉害一点的前端, 或者团队允许一定的试错, ember 可以上的.

在你的大力普及下, 我对 ember 的关注度和信心又上升了

ps: 作为一个厉害的前端, 怎能没用合适的后端, 看看这个? https://github.com/artificialio/sane

前后端还分离烦躁的事情还是有不少的, 部分代码要写两遍, 比如前后端的 model 呀, 一些验证逻辑等, seo, session保持 等, 单个看是小问题, 堆积起来多了也郁闷.

前端的世界变化太快... ember 还没掌握好, react , webpack 什么的又火起来了..

囧, 回复错了, 回复到一个老帖子去了..