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能让用户放弃之前的东西，重新再造一次海量的轮子呢？

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

ianva

2016-10-18 10:56:06 +08:00

这是脱离业务场景谈技术

jquery 是个基础库，用于替代 dom 接口，至于其他 utils 都是附带品，选择 jquery 是在于 dom 基本操作能满足当前业务，但业务逻辑稍复杂点的业务 jquery 维护就是坑， dom 操作和逻辑混杂而且开发效率低下，

从基础库来看在于维护性和复用性上论起来，比起 yui3 和 mootools 都差的远。 jquery 在那个时代里之所以能比 yui3 和 mootools 火的原因是在于简单易学 api 明了，比如只是插件而论相比 yui3 的 widget ， jquery 插件的设计太过丑陋和简单，各种功能的全面性和复用性更没的比。

如果业务复杂，状态满天飞的时候 react 提升太明显， redux 即是。另外组件化， hoc ，等等各方面让维护性和复用性提升不止一个档次

如果只是简单的增删查改的项目自然 mvvm 的双向绑定更合适，但维护复杂的状态变化而业务周期又长，双向绑定设计不好就是个定时炸弹，这个时候就会知道数据不可变对于维护性有多重要。

另外关于 grunt 和 gulp ， webpack ， grunt 的本质是配置文件，每个功能都是单独的配置，开始谁想到前端的工程有这么复杂了，当处理的流程越来越多自然就觉得不看重负，我一个还是用的 coffee 写的 gruntfile 都有 500 行以上了，这还不算上插件，每次需要改的时候要回顾整个流程，后来迫不得已重构分任务分文件，其实就类似与 gulp 了，所以 gulp 是自然而然的。

任何 dsl 配置复杂到一定程度会变成一门编程语言，或者是脚本语言介入，这是太自然的事情了，就好比 css 之余 sass ， stylus ，当然一个业务没这么复杂的时候 grunt 的配置文件比掺和逻辑的文件更容易维护。

webpack 其实主要解决的是打包问题相比的也应该是 requirejs 和 seajs 这类东西，至于有工作流的功能是因为有些地方更自然， grunt 和 gulp 并不方便，但主要功能依然是打包，对比 requriejs webpack 带来了太多有用的东西，有什么抱怨的

至于 IE8 这个占有率已经 14%了很多大公司都无视了，移动端的重要性也越来越高了。

毕竟前端这个环境碍于浏览器，各种功能都是社区慢慢搭建起来的自然是问题多多，但这些都是说明前端的技术在不断的演进，在解决各种问题。