2016 年做前端开发是什么体验？混乱+开倒车，这是我的体验

有人说，你有什么资格发表这种高谈阔论，实际上是这样的，我在看 lol 比赛直播的时候，有个很有名的主播说过，打到 2400 以上的都去做职业玩家了， 1800-的还在挣扎，只有 2000 徘徊的才出来做主播，的却是这样，如果你是一个能力很强的程序员，你可以驾驭任何新技术、框架，那么你的牛逼可能掩盖一些真正的问题，但是有些人偏偏把问题说成 feature 。

很多前端开发以鄙视 jQuery 为荣，以 jq-free 作为吹资，这是没问题的，因为如果你的目标是 IE9+，或者移动端， MVVM 框架可以让你不用 jq 。但是，我们来考虑 2 点，为什么强迫用户升级 IE8 到 chrome ？ win7 是如此优秀的操作系统，网吧的电脑，甚至很多办公电脑都是 xp ，大量的网站兼容了 IE8 ，用户就是上帝，我们有资格要求上帝无缘无故升级浏览器么？很多程序员鄙视 360 ，但是你们真应该好好感谢 360 ， 360 用一种比较温和的方式让大量用户升级了有 chrome 内核的浏览器，相比之下 YY 简直是强奸用户一样，在后台做不可告人的勾当。

那么接下来说 JQ 优秀在何处， JQ 不是框架胜似框架，而且我希望每个产品经理都学习一下 JQ ， JQ 的使用量绝对不是偶然，首先 JQ 的 api 设计非常优秀(用$代替所有选择器是太牛逼的设计，当然这里也要提一下underscore的下划线)，这个比起开倒车的 fetch 不知道高到那里去，我也用过 axios ， axios 在 get 和 post 下用一个用 params 一个用 data ，这是语义要求还是标准要求的呢？我不想管语义，因为工具类的封装就是要屏蔽掉语义的差异和不方便，做到以人为本。很多人批判 JQ 一个选择器干太多事，但是如果 jq 把$换成 jqDOM 、 jqString 、 jqSelector ，那么还会有多少人用一个框架。

兼容性就不提了， jq2 完美兼容 jq1 ，只是舍弃了一些浏览器。值得产品经理学习的是， jq 专注解决程序员遇到的 dom 操作问题，顺便附送了几乎完美的 ajax 封装和一些工具类，该有的都有了，而且几乎没有任何多余的功能。所以，在移动端没发力之前，很多前端都是 jq+模板搞定一切。所以说，想把 jq 批判一番，搞个大新闻？

接下来，让我们说一下 react ，我最近也跳了这个坑，没办法， ng2 和 vue 在我需要的一个第三方核心组件上表现的太差，甚至 vue 的这个组件 demo 都无法打开， star 也被几十倍的碾压。但是这不代表 react 没有问题，有很多人说 react 牛就牛在 jsx 上，是的，我最近在写， jsx 的却很灵活，内嵌函数的写法可以让你做到几乎无所不能。但是，我想反过来问你，你这辈子用过的模板，无论 js 、 java 、 python ，谁家的模板不支持 if 和 for ，这个时候有人跳出来教育我 jsx 不是模板，模板的定义太简单了，一个字符串，支持${}这样的变量替换，这就是模板， jsx 完全满足这个条件。当然，群众的需求总有人满足， npm 上有大量的 if 和 for 实现可以用。

另外一点我想说的是 redux 或者 flux ，这种设计，为了弥补 react 本身单向传递数据的不足（你说是 feature 我也没办法），我认为单向实际上也是一种倒车，因为无论以前 ng1 ，现在 ng2 ，国产 vue 还有支持 ie6 的 avalon 都是双绑支持，偏偏到了 react 这里就是单向绑定。我第一眼看到 redux ，这不就是一个状态机么，再想想，回想起本科学过的编译原理和形式语言与自动机这些课程，是的，状态机不简单，尤其是把一个大系统的状态清晰的梳理起来，不是一件容易的事，对团队要求很高，因此我在项目选型时，果断拒绝了 redux 使用了以前大家熟悉的事件模型。

这里顺便有一个我遇到的问题，一个选项卡组件，要求很简单(1)实现基本的选项卡功能，即点击选项卡高亮标签并切换对应选项卡(2)标签的样式和 html 由用户自行输入，不限制是什么，只要高亮标签的 bg-color 就够了。(3)选项卡标签和内容不一定在 dom 上有相邻或者嵌套关系，这点可选，这个需求用 jq 甚至源生应该是手写级别吧，那么大家试试 reactive 的开发需要多少代码呢？

接下来说说混合开发，这个东西，明显看出是专门为了企业开发而设计，当然对于那种创业多久就倒闭或者拿到钱转 native 的就不说了。企业开发，实现就可以了，不要求多炫酷的界面和流畅性，内网对网速不敏感，内部应用没人闲的去看你代码或者找你漏洞，这完美的避开的混合开发的弱点。没办法， js 的特性，无论混淆成什么样都裸的跟不穿底裤一样，这绝对比不上 lua 这种除了传统混淆还可以魔改解析器的脚本语言。那么，现在的微信小应用，除了传统 H5 的问题之外，你的入口、用户，整条命都落在别人手里，你甘心么？也许，这样可以净化一下现在的 app 乱象，留下用户真正需要的功能，也就是大公司、大企业的那些“公益”应用，比如查快递、挂号、查化验单，这些无人竞争，抄了都没用的东西，才是完美试用小应用的东西。

最近出了 rn ，又出了阿里的 weex ，这个跟 cordova （前段时间搞cordova的项目升级，真的跟名字一样，写作cordova读做坑多挖）系的框架不一样， cordova 上层无论什么，底层都有大量的 native 插件够你适配源生功能，用 rn 的还好毕竟上了 react 的船的太多了，有人解决 native 层的问题，然而对于新的 native 框架，你确认自己搞的定么。

前端人喜欢造轮子，前几天找一个 url param 拼接的框架，安装完发其他应用居然也依赖了 2 个 url param ，长的还不一样。仔细一翻，还有大量的 isEmail ， isURL 这样的依赖，数一数一个项目刚开始做就 600 多个 node modules （当然包括了 dev 依存），如果放到 java 里，这简直是不可思议，因为 apache utils 一套就提供了不知道多少的功能。既然提到了 apache ，我要说一下 java ，很多人说前端风云大变，后端跟死水一样，那我到想问问，这几年无论 taobao 也好，还是 12306 ，都是前端优化的结果，后端只要放那自生自灭就能解决大并发问题了？

如果是一个 java 项目选型， spring 作为底层一定全票通过，接下来可能是 mybatis 和 hibernate 对决，这个根据项目特点也是几乎唯一的选择，这些定了后面就没什么可争论的了。但是前端选型，我估计 react 、 vue 、 ng 就能打一天。因此， java 这种十年不变的风格，沉淀了不知道多少的精髓，除了虚拟机的调优外，还有大量的跑车，这可不是轮子，包括演化了多少代的 lucene （现在都用 elasticsearch 了），还有一系列 hadoop 、 spark 这些数据挖掘框架，其余的什么工作流、数据总线都不好意思说了。但是现在前端跳出来了，他们要用 js 横扫一切，我想问一下那么多 java 、 php 、 python 、 c++、 erlang 、 golang 工程师会坐以待毙么？

不变应万变是个好事， js 当初草草开场，现在又飞速进化到 ecma2015 ，但是底层运行的还是丑陋的 ecma3 （我不拒绝上帝的要求，上帝给我钱我就做 IE8 兼容），相比之下多少人在用 java1.6 ， python2.7 ，我相信，语言、语法糖本身绝对不是首选，因为如果大家真喜欢语法糖，那么你们应该拥护 c#才对，唯一的解释就是搞 js 的人没事自己闲的革自己的命。习惯是个好事，如果稳定，又能满足要求的话，你看的电视多少年都是方形的，自行车多少年都是两个圆轮子的，现在 js 世界是个什么样，有一个很牛逼的自行车，炫酷跑的又快，唯一的问题是，没有握把，握把需要你自己实现。。

刚需和自己乱革命是两回事，什么是真正解决刚需的，一个是 jq ，一个我认为是大规模推开 mvvm 的 ng1 ，可惜这两个都被你们鄙视了，然后 google 草草开出了 ng2 的车，又发现自己在前端内置一个超牛逼的 complier 反倒加重了系统负担，直到前几天正式发布才有了 aot 。然后又是react这种把html混写到js里。另一方面，我们看架构工具，glup和grunt已经是历史，webpack去年兴起今年就有人要革他的命，明年又是什么打包工具呢？grunt没有错，他的设计就是批处理，压缩、混淆、整合都能做到，webpack也是bundle更方便加热调试，那么新的架构工具又有什么feature能让用户放弃之前的东西，重新再造一次海量的轮子呢？

这样的乱象何时能了？不知道。

dmyang

2016-10-18 11:58:20 +08:00

非前端从业者的角度看来， jq 确实是个好东西，理解简单容易上手。

但是 jq 毕竟只是工具，解决 js 选择 DOM 的问题。

但是前端到了大规模化的时候，需要的就不仅仅只是一个 DOM 选择器了，它需要开发者自行解决模块化、组件化等问题，而这些恰好又是后端语言本身就自带的能力。

另外一个和后端的不同就是代码的部署问题，前端的特殊性就在于，代码需要动态安装（下载）到 C 端，这就需要保证下载最小体积的代码又要实时生效，而且还得保证不影响代码的阅读（即至少两套代码并存）。代码在经历开发和生产之间需要有一系列的变化，比如代码压缩、合并，变更部署路径（文件名加 md5 以保证缓存生效）等等，同时又要保证开发的便利性，在使用了浏览器还未支持的语法（如 ES6 ）时，开发环境可能又需要实时将代码转换成 ES5 ，也就是 grunt/gulp/webpack 等工具的热替换功能。而所有这些东西，只有前端才会出现，后端无此问题。

以上提到的每一个点，前端语言层面都没有解决，只能开发者自己搞定，所以导致几乎每一个点都有两种以上的框架、工具来解决，有选择就会有分歧有站队就会有口水战，所以看起来前端“混乱”，但我认为这并不是什么坏事，刚好促进前端的完善。

统一一种框架 /工具好处比较多，正如贴主提到的 java 的 spring 框架，但要知道需求是无止境的，你不要指望用一种框架、工具解决所有问题，这必然会导致代码膨胀和冗余！前端（尤其移动端）根本承受不起代码膨胀所带来的一系列问题。

综上，贴主还是在前端领域多实践几年，再下结论吧。