2015年12月19日在杭州阿里巴巴举办 第10届D2前端技术论坛
我没有像民工叔那样现场速记的能力，不过乘着记忆还热乎，写一下。本次D2共0x10场分享。
其中移动hybrid/native解决方案相关的分享有4场，分别来自百度、淘宝、手淘团队的工程师和GeekZooStudio的老郭。
组件和应用框架相关的分享（不包括react native）有3场，分别来自腾讯、蚂蚁金服、碉堡了（strikingly）的工程师。
node.js架构相关分享有4场，分别来自天猫、360、阿里云、腾讯的工程师。
特定平台主题分享有2场，分别来自阿里数娱、阿里智能云的工程师。
其他API管理、可视化、国际化各1场。
主题的分布还是很有代表性的。当然因为主题如此丰富，所以又是同时有三个会场，我想很多人都会有选择困难。后来跟圆心聊了下，主要是现在前端议题多，又不想分两天（增加参会者出行负担），又不想每年两次或者收费（主办方控制成本），所以还是选择了现在的方式。至于说为什么分会场不是按主题（比如node.js主题、hybrid/native主题等）分，圆心说是故意的，但没有细说原因。
因为我本人的工作并不侧重hybrid/native方向，所以优先选择了其他主题，包括死马、朴灵的两场node.js的相关分享，杨文坚的组件化设计的分享，听鸿的TV平台的分享，黄高岚的react的分享。
先说死马的。
天猫从php切换到node的架构层面改造我以前就听过一些分享，这次只是增加了一些运维层面的细节。还有关键的一点，就是通过天猫的真实数据说明新架构相对于老的php架构的巨大优势。（死马虽然在QA环节说部分提升来自于重构而不是php=>nodejs，但我认为那只是说说而已，继续使用php却要抛弃php的传统模型是非常困难的。）
不过我对于死马讲的koa的一些优点并不完全认同。我个人认为koa是比express在api设计和middleware开发上更方便一些，但大部分benifit是相对次要和只惠及框架developers而不是框架使用者的。因此其他框架比如thinkjs也还是有机会跟koa去竞争的，呵呵。BTW，@李成银[3] 作为thinkjs的主要作者在D2上也有一场分享，其实主办方应该让成银跟死马pk一下。
当然这个部分不是重点。重点是nodejs大法好。
然后说一下朴灵的。
简单说就是alinode的广告。然而我狠happy能看到这广告。因为虽然我从2010年开始就是node.js的坚定支持者，但在实际生产环境中一直只将node.js用于工具链，而很少将node.js用于主要的服务。最大的原因就是缺乏node.js运维的信心。而朴灵的广告可以说给我提升了狠大的信心。希望朴灵团队早日进入node.js的core contributor和node基金会！
下面说下腾讯杨文坚的组件相关的分享。这是又一个借鉴WebComponents规范的尝试。作为一个对React体系持保留态度的人，我个人其实一直期待这个方向能看到更多的可能。不过遗憾的是文坚的尝试并没有能让我惊喜的部分，简单说，就是把容易做的事情都做了（做得可能还是不错的——特别是已经用于生产环境），但是困难的部分都没有做。
当然这有一个难题。用于生产环境固然好，但也因此，特定工程上的需求就获得了更高的优先级。我不是说来自于实践的工程需求不重要，可是，组件化是非常复杂的架构问题，要优先考虑特定的工程需求，最简单的办法就是牺牲掉一些在特定工程中相对不重要的特性。然而要判断某种特性裁剪是临时性的措施还是永久性的架构约束，是非常困难的。
延伸开来说，在这一点上，各种hybrid/native方案也是如此。虽然我没有听这次所有的hybrid/native解决方案的相关分享，但是总体上我对所有目前类RN的方案有一个判断。它们其实本质上是重造浏览器渲染引擎。js是不动的，html/dom被裁剪，css被裁剪。其中尤以CSS为改造重点。像表单交互、动画、无障碍性等也是被牺牲的，但是这些部分是临时性的，像react生态里，这些问题已经得到解决或缓解。唯有对CSS的改造是本质性的改变。
CSS大体可分为三个方面：
1. selector和cascade机制
2. 布局模型
3. 其他特性（比如css单位、transition/animation、透明通道、渐变、filter、svg等）
如React官方的CSS in JS方案，是完全干掉了1。React Native进一步裁剪了2和3。
说到底，现今浏览器的复杂性，80%来自于CSS。像html parser、dom接口、各种device api这类，麻烦管麻烦，但是都是可以模块化，可以做到解耦和正交，因而实现和维护并不算特别难。但CSS部分就不是。尽管CSS规范也是模块化的，互相之间是正交的，但是那是从使用者（web开发者）的角度正交，而不是从实现者的角度。对于实现者来说，CSS特性错综复杂，互相影响。渲染引擎的许多优化，实际上很多是很dirty的。这导致渲染引擎（相对于native来说）又慢bug又多。
可是简化CSS就是solution吗？我对此其实一直有所保留。所有强调工程实践需求的，可以试想，回到CSS1的时代，我们也可以解决80%的页面样式需求的嘛，但是我们难道会满足于CSS1吗？所以问题是，各种类RN的方案如果一直停留在今天的样式相关特性集，我们是否真的能满足于此？如果它们也不断扩充特性集，我们怎么有信心说CSS发展中踩过的坑它们就会避免？
我个人倾向于，样式相关的复杂度是所谓本质复杂度，也就是长远看无法完全避免的。这是为什么我对RN或类似方案给出的评价一律都是：（目前来看）工程上是可行的。但是长远来说，它们是不是答案，我存疑。
回到文坚在组件化方面的尝试，虽然说借鉴了WebComponents规范，但实际上的实现却如React一样是牺牲了CSS的selector和cascade机制（当然如果在现有技术上很容易做到，那也不需要新标准了）。而保持原有DOM/CSS架构正是WebComponents相对于其他组件化方案的核心优势（至少对喜欢WebComponents的人来说是这样）。所以这大概也只能评价为一种尝试。
另一方面，文坚可能花了不少精力在打包优化上面。从工程实践的角度来说，这一点是非常重要的。然而从未来组件方案的角度来说，现在条件下所做的优化都是不重要的。原因我在晚场的分享和交流里讲了，我认为整个前端构建/部署即将发生重大的变革。组件的构建、打包自然不会例外。
整个下午我一直在白马山庄听分享，前面提过的朴灵的分享是第一场，第二场是阿里数娱的听鸿的「TV前端开发解决方案」。这一场听的人比较少，这也可以理解，这毕竟不是热点。不过对我个人来说，这场我是很有共鸣的。因为他讲的正是我2006年期间在盛大工作时参与盛大盒子项目时研究过的领域。作为一个TV Web框架的先驱（烈），我很高兴看到后继有人。当然也有一点伤心，因为当年盛大盒子推出的时候，Apple TV第一代还没有推出；今天Apple TV已经是行业标杆，而我以及当年近百人的工程师团队所有的努力却早已灰飞烟灭，没有留下一点痕迹……如果那时盛大更牛逼一点，并且没有广电总局这样恶心的机构，说不定今天听鸿参考的就不是Apple TV的文档而是我写的文档了，呜呜……最后补充一点，问答环节hehe123建议结合无障碍领域是非常到位的，当年我在写交互Guideline的时候其实也参考了许多W3C WAI的文档。
白马山庄的最后一场是碉堡了的黄高岚的分享。整个presentation准备充分、条理清楚，代码演示很顺畅，还有彩蛋。在听了一整天之后，以这样一场轻松但又扎实的分享结尾，让人一点也不会有疲倦之感。其实之前碉堡了的CTO郭达峰就给我提起过他们有位员工技术出色，但因行动不便所以很少出来参加技术活动。没想到那么快就能看到本人。希望以后能看到黄老师的更多分享。
流水帐报告完毕。至于晚场我在台上即兴讲的内容，以后再整理成文，这里就不赘述了。
