这么看其实多数人就用个双向绑定的功能

@zhuangtongfa 另外谁说 react 必须要全家桶才能用的？

@zhuangtongfa 全家桶当然都会用过，但如果 vue 想达到 react 全家桶的维护性，那必然比 react 全家桶还要复杂

@cxbig react 的整个概念就是一个 vue compontent 的概念而且还要简单很多，从这个角度讲 vue 一点都不简单

@Troevil 如果我想实现一个 dialog 能谈一谈用 Vue 实现的思路么，从被调用，用外部数据填充，标签指定填充布局，到弹出插入 dom ，外部数据和 dialog 渲染的先后此讯，到调用的方式
用他写个组件的时候其实并不是这么如愿的方便

说这些，所表达的意思是，技术在前进，而且在通往更好的时代

@FrankFang128 对于组件的通讯，来说目前看来，在复杂的项目上，没有 flux ， redux 的理念，事件维护性上非常差，特别是需要大量维护状态的时候，非常难于管理，维护时难于梳理，项目简单的时候到还好说

1. bable IE8 这个没的吐槽，前几年的 IE6 不是也就这么过去了么，现在 17%的占有率其实也就 1 年的时间了，和技术无关
2. JSX 相对于 angular 的 template 用字符串，这已经好太多了，我们还不讨论 angular 1 的 directive 设计的有多么糟糕， react 的组件只用了非常简单的理念就解决了 directive 解决不好的问题
3. 请找出一个比 webpack 更好的解决方案来
4. 现在前端工程的复杂度上讲过渡设计这件事情是要看项目的，简单项目 jq 自然几句话解决了，前端技术上的选择面很多，比比没有选择的时候
5. 模块化上， webpack sourcemap 调试要完爆各种其他调试

说这么多，很想看看楼主的代码，这么多东西都吐槽，
说白了前端这些工具很明显的不适合构建复杂的项目，这些语言上的改进，框架和库的兴起，都是有原因的，效率是一方面，更好的构建项目，应对更复杂的工程才是关键
来，发下代码吧，看看楼主是如何不采用上述技术，构建一个健壮的复杂项目的

想多了，就一个配置文件

没有 ruby 这帮魔法师，就没有现在 nodejs 社区的繁荣

commonjs 的 require 是加载时执行
而 es6 的 import 是调用时执行，加载时只产生引用
比如引入模块里的值异步的产生了变化， require 他的文件的值是不变的
而 import 的，则会根据模块值的变化而变化

4k 显示器写代码的最大优点在于字体的渲染，特别是 IDE 的等宽字的渲染上，
之前下个各种字体，结果用的时候发现和例子不一样，后来发现是操作系统对字体的渲染有个优化，因为 dpi 不够把细节都虚化掉了，所以看起来和原本的设计的非常好的字体差别巨大
retina 后 dpi 上来了，字体的细节比如衬线字，的细节就显示的非常完美，阅读代码心情也好

如上， 4k 显示器就会给你写代码更好的体验

react 把业务抽象成一个个组件，组件又即是标签
js 和 html 交叉融合这件事情本身不是前端逻辑维护上的问题
前端最大的问题其实就是 jquery 和 dom 直接操作，带来的操作 dom 的同时用又融入业务逻辑，这样 dom 的操作和业务逻辑无法分离，而产生维护性和复用性的问题
所以不管是 angular 还是 react 都更容易维护

关于 js 和 html 融合的维护性问题主要是早期，所有东西都写在 html 文档上，其实相当于， js ， css ， html 糅杂再一起然后再加上 dom 操作做和业务逻辑交错产生的更麻烦的问题
很显然 react 如果组件化抽象并并不会带来以上问题，当然如果你把整个页面和所有模块都丢在一个 render 里上述事情就会发生

必然要挂，这样的项目没法维护
本身访问这个对象就是没有封装，啥都一头雾水，更别说一个文件几万行了
如果所有状态的变化都牵扯到对这个对象的增删改查的话，可以想象有多少问题，你怎么知道这个字段的数据别人干啥了，改了以后牵扯到那些东西变化，这就是个死节。
拆分 store ，拆分 service ，独立功能模块

外包转正，一方面是看能力，一方面是有没名额，经验这种也就是说说，如果是对外招的话可能比外包转正还容易进，真不觉得是个坎

@nxn1987 。

@exoticknight 暂不招实习，应届可以