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

[murmur]

有人说，你有什么资格发表这种高谈阔论，实际上是这样的，我在看 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能让用户放弃之前的东西，重新再造一次海量的轮子呢？

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

你们不要纠结现在用不用 jQuery 的问题好不好， jQ 是艺术品，也是成功的工具，功能多却又专注不冗余，设计看似有些混乱但是却处处为开发者着想， API 简单优美但是不过分追求短小，这是我对 jQ 的评价， JQ 最终会走入历史，但是在历史上留下的光辉谁也无法抹去

有些人不要望文生义，不支持双向绑定和默认不开启双向绑定是两回事，如果 iframe/多页+ng1 呢？是不是就解决了 scope 膨胀的问题，为什么非要 sap 呢？我可是见过不少这种情况了，有的 chrome 插件，就几十行百来行不到业务逻辑代码+v 层，也上了一个 ng1

[JohnSmith]

前后端情况不能一视而同啊

[MicroPan]

mark
个人感觉很中肯

[Sivan]

有意思

[IdJoel]

mark

[murmur]

补充一点：我不想看到猛吹微信公众号的，微信公众号除了真的企业政府开的是应用外，多少在盗抄、传谣、造谣、鸡汤，简直是造谣传谣对原创作者版权侵犯的主力军。

[fszaer]

其实 vue 嘴上说是双向绑定，实际上需要你显示说明，不然默认单向绑定。。。。。。

[hansnow]

从一开始说着说着 jQueryAPI 优秀突然跳到 fetch 就有点没看懂。

JSX 这块儿黑的太没水平了。 XML in JS ，说到底就是普通的 JavaScript 代码，怎么会没 if 和 for ？

[scnace]

mark 写得不错

[fhefh]

现在做前端 觉得好累

[MidLinn]

深表同意~~~

[keeley]

说的挺好。排版在弄弄呗，文字太长了读下去不容易。

[murmur]

@hansnow 语文不好理解一下
那块说的实际上是 ajax 的封装，因为 fetchIE 全线不支持，所以还是按工具比较的
另外模板不就是让代码更优美么，你在 html 中一堆{}里面写 if for ，要么 map ，写 if 还得用立刻执行函数，这不是回到以前 jsp 和 php 里混写代码被鄙视的年代？

[murmur]

@keeley 不好意思我想编辑，我发现了太多的错别字和用词不对，但是 V2EX 只给我 10 分钟校正时间就锁定了。。

[lwbjing]

以前也各种追潮流... 现在就看心情了...

[xiaoyangsa]

最近一直有种感觉， js 能统一世界。。

[DarsyCheuk]

mark 轮子是个圆 转了一圈又一圈

[hansnow]

@murmur 最开始接触 JSX 的时候我也感觉很蛋疼，看起来确实是 JS 和 HTML 写在一起了，非常混乱。但是越到后面越觉得，就像各种 React 教程里一开始告诉我们的： JSX 是一种 JS 的语法糖嘛。 React 自己维护一套 VirtualDOM ，所有 DOM 元素都是 JavaScript 的 Object ，那么接受了这种设定之后， JSX 显然比手写 Object 简单方便太多了。而且一般 JSX 的部分都不会太长，如果看起来实在太乱了，那说明有更好的办法来实现这个需求（比如抽象出子组件或者用 ES6 的新特性来简化代码）

[qianddream]

既然选择 IE8 和 360 ，要毛体验啊，明明是自己放弃的嘛， Win 7 的 IE 最高支持到 IE 11 （ win7 上面好多软件要求必需安装 IE11 才能工作），都什么年代了，网吧用 xp 的很少了，人家都是全高配好吗！，再说谁会在网吧看我们做的网页啊，太少了吧。

MVVM 解决的是全端交互问题， Learn once,write anywhere ，用 JSX ，很大一部分是冲着 FB 家的诚意去的（虽然现在有点跑偏）

前端都落后后端这么多年了，现在退回去是不可能了，要虚心学习。

[ljcarsenal]

weex 那个 看到 github 上 bug 报得那么多 也不知道阿里他们怎么用到生产环境的。。。。

[TangMonk]

不错，还好没有去随大流。。

[xxxyyy]

有些不明白，双向绑定就那么重要吗？
还有说 fetch 是开倒车，那真是太 naive 了，这个 API 可是为以后的 service worker 准备的。

[murmur]

@qianddream Learn once,write anywhere 永远是个梦想，操作系统的差异性不是你想抹平就抹平的，好的混合框架背后都有超牛逼的 native 团队去替你开路

[qianddream]

python2.7 是 python 社区之痛，不提也罢。 ES2015 可以去看看最新的支持情况 https://kangax.github.io/compat-table/es6/

[f0rger]

前端就是：轮子复轮子，轮子何其多
需要找一个适合自己的来用就好

[murmur]

@xxxyyy 因为 react 没了 ajax 封装，又在猛推 fetch （你是不会 XMLHtppRequest 的是么？），那么这个相比$.ajax 的封装就是倒车

[serco]

React 又没有强调过单向数据流，单向本身就是 flux 推崇的，而且是有意设计成这样的。

复杂的组件交互，传统的事件模型耦合度太高，维护成本高。
任何事情都是有 trade-off 的，用 flux 那一套，简单功能的模板代码量就会增加。

前端是改变的太快了，但是感觉全文基本都喷的不在点上

[zhqy]

观点基本相同...

[ericls]

用 elm 解决一切问题

[assad]

我早都感觉到 JS 能统一世界了。把 JS 弄的牛的都要上天！

[jiongxiaobu]

https://cdn-images-1.medium.com/max/1600/1*Fin0izC0dcM8HsYRDxb55w.png

[xxxyyy]

@murmur 你还是没明白 fetch 这个 API 的价值，它可不是简单的一个 XMLHtppRequest 的 Promise 的实现。

[robertlyc]

应该工作没超过 3 年

[TingHaiJamiE]

毕竟有些东西的出现不是为了技术进步...

[dabpop139]

原因可能是 js 的历史原因吧，一直都没有强有力的引领机构，要不是就是机构的标准来得太晚， JS 的发展严重拖后腿， JQ 的出现就慢慢有了改观， JQ 一开始也都很多人不接受包括我，因为当时来说没有 V8 加上电脑性能普遍不好，用 JQ 都会拖慢网页性能。后来 V8 出现带来了革命，但 V8 也没有给到标准，大厂各自搞了一套基于数据驱动的框架，我自感觉和 JQ 没啥冲突，至少 Vue 是可以结合 JQ 用的。另外 ng1 个人感觉是推广不给力，或者说当时大多数基层业务用不上 ng1 。回到现在 Android 让 H5 的应用广泛流行，所以现在流行 react 和 Vue ，移动端抛弃了历史包袱和解决了兼容性问题，所以大多数 feature 的框架是应用在移动端。个人感觉可以不要被表象迷惑，只要看基层业务的应用就好了，只有基层业务上大家都用的框架应该就是以后的标准风向标。个人感觉现在是 vue ，或者是还没出现。

[xxxyyy]

@murmur 至于会不会 XMLHtppRequest ，没必要把这个来秀，这仅是一个处理请求的 API 而已。

[dtysky]

说白了还是 WEB 开发本身性质就特殊，从传统领域搬运的 mvvm 解决的是规模上升后的 SPA 问题， babel 解决的是科学的现代 EMCS 标准和浏览器运行的古典 EMCS 的冲突问题， webpack 和构建工具解决的是资源优化问题

至于框架乱象， JSX 这些真没什么黑的，你觉得乱，但另一方面也是社区活跃的象征，是生命力的象征，而且我觉得 JSX 很先进啊，彻底的组件化确实加速了开发速度，作为在大型项目中使用过 react 全家桶的表示全用 jq 写确实会死人嗯，现在某部门用 JQ 堆起来的代码已经让一堆人欲仙欲死了，当然你可以自己用 JQ 构建一个自己的框架，但恐怕最后和现在流行的这些 MVVM 没有多大区别就是了，自己造轮子是很开心，但在工程放弃成熟的用自己的就是脑子有问题

当然，在中小 WEB 应用中用 JQ 甚至直接原生 JS 没有任何问题，甚至是应有的做法，在兼容性要求严格的情况下 JQ 也是好选择，但阁下说的什么开倒车我还真是不懂了

顺便关于单向绑定，在 WPF 中实践过双向绑定，双向绑定带来的 debug 痛苦你能理解么？

还有模板。。。真不觉得有啥比 JSX 优雅的，这种个人品味问题也拿出来黑也是。。。需要那个就用那个呗，在一个项目里混用模板和 JSX 又不是啥新鲜事。。。

[murmur]

@dabpop139 实际上用了新技术的移动应用，当然，国产的，越来越卡，那么新技术的应用是为了什么？

[hei1000]

＂你们真应该好好感谢 360 ， 360 用一种比较温和的方式让大量用户升级了有 chrome 内核的浏览器＂
和 360 有啥关系?我又不用 360

[liuweisj]

我第一次接触这些东西的时候就深有感触，然而我抱着既然这么多人认同应该是有他们道理的心态去看待的，今天看楼主总结下来才发现不止是我一个人有这种感觉。。。。。 “然后又是 react 这种把 html 混写到 js 里。另一方面，我们看架构工具， glup 和 grunt 已经是历史， webpack 去年兴起今年就有人要革他的命，明年又是什么打包工具呢？ grunt 没有错，他的设计就是批处理，压缩、混淆、整合都能做到， webpack 也是 bundle 更方便加热调试，那么新的架构工具又有什么 feature 能让用户放弃之前的东西，重新再造一次海量的轮子呢？ ”

[murmur]

@dabpop139 我认为这个进化应该是这样的：前端想要统治世界->前端搞出了简单的 SPA->产品经理强奸用户，无止境的乱加功能和模块->前端力不从心->发明 MVVM->产品经理直接强奸程序员->更猛的 MVVM
受害的永远是用户

[VinKing]

可以预见，在未来的 1-2 年内会沉淀出来一批 JS 圈里面基本的技术工具。不过 jQuery 是个好东西，这点我也很赞同哈。简单、好用。

[qianddream]

@murmur

Fetch 不光是 XHR 改进版这么简单， https://fetch.spec.whatwg.org/#goals 有解释 Fetch 是干啥的，可以与 XHR 对比一下 https://xhr.spec.whatwg.org/ ，到底又没有必要升级？

Fetch 还在 Living Stand ，不过可以用 polyfill https://github.com/github/fetch

[Phariel]

还好 我厂都是用的自有框架 有同事向老板们安利 React 现在也不了了之了。。。

[jinbakei]

点赞

[murmur]

@qianddream 我只想知道，为什么{}变 url params 这种超人性化的设计，居然不被支持，我需要的是一个 ajax 工具，是工具啊~~，我不想直接用草案开发，你可以理解的是我要一个$.fetch

[Geeker]

所以我在考虑转后端了 2333

[murmur]

@hei1000 360 不惜以伪造补丁的方式强推 360 浏览器，然而 360 系列浏览器是流氓软件中口碑不错的，你流氓虽然流氓，但是做出的产品毕竟还可以啊
否则中国的 IE6 占有率还是居高不下

[Geoion]

后端： PHP 是世界上最好的语言。
前端： jQuery 是世界上最好的框架。

[dabpop139]

@murmur 在我看来现在这些框架都是在推崇一个理念模块化，规范标准提高协助能力，包括 laravle 框架的出现，通俗的讲就是提高基层编程素质，以前前端估计还很多人不能理解 MVC 是什么？只有加入了标准才能更好的发展，我说的发展是整个前端的发展不是说个人的。有了更好的标准才可以促进发展，可以理解 JQ 其实就是不成文的标准。前端的发展模式可以参考中国的发展来理解，中国并没有选择西方的资本主义，但是也发展成为了现代化国家。前端是一样的，都是朝一个方向发展，只是一开始就落后了要选择一条相对不寻常的道路。现在也可以看到 JS 有可能要覆盖到大多数应用方向。

[sutra]

吐得不错，这也是我最近的感觉。

[qianddream]

@murmur 这个你直接用 template string 不就好了？

[fakefish]

说双向绑定好的 可能没遇到 ng1 的性能问题，虽然 c# 这种也是双向绑定，但是不存在性能问题， ng1 在上万个 scope 之后卡的教你做人，而且没办法避免，框架本身的缺陷，也就是为什么后面的框架都不是默认双向绑定了。

那篇文章讲的确实是个问题，太多人总是为了用框架而用框架，而不是因为需要用才用。

比如 grunt 到 gulp 到 webpack ，为什么要用这些，还不是越往后性能越好，轮子真的能提升开发效率才会真正发展下去。

为什么不用 jquery ，如果页面逻辑简单，开发人员不多的情况下， jquery 必然是第一选择，移动端是 zepto ，但是如果是那种页面逻辑复杂，开发人员比较多的情况下， jquery 这种随意操作的方法会带来各种问题，就为什么会出现 backbone ， backbone 出现提出了一种可行的方案，但是本身还是有各种问题，后面的 ng1 也是一种尝试。

不是在开倒车，而是为了让车开的更快，边开边修车。

[ty89]

前端普遍浮躁

[murmur]

@fakefish vue(avalon)这种用 getter/setter 做双绑的解决方案你认为如何？

[whimsySun]

我到没有觉得这些框架不好，就是现在 js 开发真他么太烦，要配 babel, 要配 webpack/gulp/grunt, 要配 eslint, 要配 editorconfig, 缺少企业开发标准，各自一套标准，心好累~然后马不停蹄，各种框架狂轰滥炸

[dabpop139]

@murmur 发展最需要的是靠用户支持，你说的被产品经理虐和前端行业发展没有必然的联系，也可能是预想不到的，或者说是前端的发展不会关心这个极少数问题。

[fakefish]

js native 这个问题

native 开发最大的问题是不能热修复热更新，不能做 ab ，大家痛苦了这么多年， react native 的出现就是为了让 native 上能够解决这些问题，代价是略微牺牲性能而不是 webview 那种低性能的，而 weex ，大方向肯定是没问题，虽然现在是一堆问题，大公司太需要这两点了。

但是 js native 的最大的开发问题是 前端工程师还需要熟练掌握 native 的开发，做 js native 这种才不会有太大问题。

[TimLang]

新框架的产生肯定是要把相对底层的东西淘汰的，做做规模不大，需要兼容 ie8 的用 jQuery 还行，真的复杂的话，维护 dom 是很痛苦的一件事。

jQuery 的好处是相对插件较多，但是相对现在支持数据绑定的框架来说已经不那么方便了，比如我做个打字(typing)效果，用 jQuery 操作 dom 实现是很复杂的，但是如果在 vue, react 甚至是微信小程序，几行代码就实现出来了。

[fakefish]

@murmur 这个至少比 ng1 的脏值检测机制性能好

[nino]

@murmur 应用小的时候双向绑定是好用的，大起来就头疼了

[2zH]

@murmur react 有一堆 promise 封装好的 xhr 库，操作起来也比$.ajax 优雅，不用 fetch 也可以。

[murmur]

@fakefish js native 还是需要一个牛逼的 native 层，这反倒要求精英的 native 程序员，小公司或者初创就只能找插件多或者成熟的
rn 是一个方向我从没否认，但是 rn 现在很明显火候不够，现在 ios 和 android 差异性 API 还是非常多，并没有像以前的混合上来就抹平差异性

[cuebyte]

作为一个后端开发人员，我个人非常喜欢 jQuery ，简单好用足够我去开发简单页面，不用去 npm 、 webpack 搞一堆东西。

曾经试着用 vue 、 gulp 、 webpack 等东西，完了不禁在想我很大时间都在去适应这些新东西，但实际上的需求很简单，几行 jQuery 就能搞定。能在 HTML 里多写两行代码搞定的是我为啥要把事情做复杂呢……

当然了，以上都是我作为一个后端在开发简单页面中的想法。

[ariesjia]

我认为还是要看你做的东西是什么？ web page 还是 web application ， 如果是 web page 你用 jQuery 完全没有问题 ，如果是 web application 不上 组件化的框架就哭啦

[flashback313]

楼主写的很认真，所以想参与讨论：

1 、不认同 jq free ，虽然我不是一个深度 jq 用户，但是 jq 里面有很多代码是可以挖出来用的。 jq 设计很好，产品思维也好。

2 、前端框架其实有趋同化，这是一个趋势。例如 dom free ，重数据。

3 、打包工具 grunt gulp webpack 一路过来其实是在解决不同问题。

整个前端目前确实痛苦，但个人觉得这是在走向经典的路。这是 js 这些年积累的一次大爆发。

[buckyRRRR]

@robertlyc 不管别人说的有没有道理，人家能写这么多也是认真诚意的表现，这是交流的地方，这么喜欢喷人直接去打架好了

[robertlyc]

一般问出这种问题的 都是工作不超过 3 年 对前端的认识停留在操作 dom 修改一下某个 value 用 css 写写 animation
所以才会对 jq 产生莫名的好感

从来没有从工程角度考虑过前端应用的演变和富交互化带来的复杂性 一个工具的诞生从来不是产品经理来决定 都是源于解决工程中遇到的实际情况 看 lz 这样子是没怎么认真看过 jsx 才会觉得拿它和模板引擎做比较 拿浏览器版本兼容和后端语言版本做比较也是风马牛不相及

多说无益 在论坛从来不要指望去教育别人接受自己的观点 反正 lz 高兴就好

[ctsed]

和 YY 有啥关系...

[buckyRRRR]

@robertlyc 有这么高的觉悟还一上来就喷人，嘴上说不要。身体不是很诚实吗

[robertlyc]

工作不超过三年这是喷人? 手动滑稽

[buckyRRRR]

@robertlyc 几不几年和别人说的观点正不正确没有关系，不去有理有据反驳别人的观点，直接抛出别人工作不超过三年来暗示别人经验浅，用此种办法降低别人观点的可信度，这不叫喷人叫什么

[depress]

作为一个 java 后端表示也不是什么项目都用 spring...不过我承认未来可能确实是 js 的天下，虽然现在前端乱成一锅粥，这也就是我不做前端的原因，啃一门语言可以啃透，前端变幻莫测。

[qiukong]

用户是上帝？扯，
过时的东西就该让它被淘汰，前端联合起来迫使用户升级才是硬道理。
你说一两家网站不兼容用户趾高气昂，所有网站都像抵制 IE6 那样，用户就不得不升级了。

[ianva]

这是脱离业务场景谈技术

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%了很多大公司都无视了，移动端的重要性也越来越高了。

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

[leonlu]

**前端轮子多，是有原因的！**

相比于 java ，浏览器端的生存环境就是荒漠。别说 JAVA utils ，就是 console.log 在 ie6 上也不支持啊！但就是因为这是一片鸟不拉屎的荒漠，才会有这么多的轮子。**轮子有好有差，选哪一个这是体现你能力的地方**。如果总是期待有 spring 一样的东西出来一统江湖，说明在一定程度上你已经开始懒得思考了。

其实还是一个从实际情况出发，不断进化的过程。如果楼主觉得 jQuery 可以 100% 完美解决自己手上的问题又很容易维护，那还有什么好讲，就 jQuery 就好了。不要被跟风，要坚持自己。搞了一堆跟风的东西又不能更好的解决问题，那都是无用功。至于为什么会出现 react / vue / ng1 / ng2 / polymer ，那也肯定是因为其他的场景有需要、用来解决某些个问题。可能你也有遇到这些问题时，才会明白『哦， react 这么干真漂亮！』或者 『 Vue 可以这么写太爽了！』。

jQuery 从技术角度来讲完美么？哦，不。实际上问题一大堆。我就不一一列举了。 jQuery 有一天一定会死， react / ng / vue 也一样会死。只不过会死在更好的浏览器 / 框架 / 库的手下。而我们正是这一趋势的推进者。

PS ：那个 jsx 啊，看着是 html ，实际上还是 js 。。。而且 if 逻辑难道不是{this.props.enable ? <div>haha</div> : null}，立即执行函数是个什么鬼。。。从对待 JSX 的态度上，可以看到楼主对于旧有观念的执念太深了。。。

[otakustay]

当前的前端分为 page 和 app ，这完全就是 2 个领域了，你把它们混在一起然后说混乱那是必然的，以后也应该有 webpage developer 和 webapp developer 这样的垂直岗位才好

[qiukong]

真像你说的那样也有，我们公司内网报表系统还停留在 IE6+ACTIVX 阶段。
要完完全全往兼容上靠，那干脆老系统都不要升级， HTML3.2 足够了。

[robertlyc]

很正常啊 因为工作的都是零散的页面 聚焦不在工程化的前端项目上 看不到 web components 带来的变革 前端的变化又不是突然就行成的
jq 之后的 backbone 就在着手工程化解决 js 结构 require.js 带来的各种 loader 着手解决加载机制 前端的变革加速于 node 社区的成熟
作为前端 如果只顾看着自己用 jq 写的快 写的方便 不去整体看社区的变化和工程上的努力 这才是开倒车

[andypinet]

太在意这些了 不好
俗话说的好 分久必合 前端也会表面上统一
合久必分 java 系已经开始被其他 jvm 语言干了

[onion83]

1 、楼主老司机
2 、前端水太深，一直敬畏，不明觉厉
3 、后端的人都往 Devops 、大数据方向走，数据存储方面这几年变化也不少，但是基本有迹可循，相对而已没有人愿意拿数据开玩笑和冒险。

路其实还是那条路，就是跑在上面的车不一样了，开桑塔纳还是还特斯拉，还得看人的追求。跑得快的不一定好，跑得慢的也未必差。

[hei1000]

@murmur 我没用 360 系列产品,不用 IE,所以它的"贡献"与我无关, 去年新买的电脑,电脑也没装 xx 卫士,xx 管家,不用第三方杀毒软件,不知道为什么 Chrome 和 Firefox 怎么主页就变成了 360,之前可以通过手段去掉的,但是突然有一天又回来,而且不管怎么折腾都去不掉了,而且每次打开浏览器,他都会新建 360 标签(还有上次未关闭标签), 放在 hosts 里面禁止都不行,瞬间觉得他们好屌,就差重装系统了,还好大部分 Linux 下面,所以影响比较小

[satifanie]

@robertlyc 我可以证明超过三年了。

[Canrz]

JQ 最终会走入历史，但是在历史上留下的光辉谁也无法抹去
================
这句大赞

[reus]

看你举的选项卡的例子，就知道你是能力不行，反而怪工具的一类人了。 react 类框架做这种事情简直手到拿来，你不会只能说明未掌握 react ，如此而已。再复杂几倍的交互， react 都是一样的思路，多复杂的交互都不用多费脑，这就是生产力工具。
何况用 react 也可以不用 JSX 的啊，直接手写 hyper-script 也没什么问题。

[caiya21]

其实这些东西并非 2016 年才有的 不要什么都扯 2016 年好么， ES6 也是 ES2015 好么。。。 2016 如果连这些都不能掌握 真的有点过时的感觉 生产工具无非是提高开发效率 如果你觉得用 jquery gulp grunt es5 这些能高效完成工作的话 就可以了 也没有必要纠结了

[Pandora78]

认同 74 楼的同学，寸有所短，尺有所长，脱离业务场景谈技术 ，没什么含义

[tedd]

@fakefish 上万个 scope 的确太夸张了，之前听说两千以上性能就受到挑战了。请教不知道用新语法糖 :: 做单项绑定是否能解决问题呢？

[xwartz]

这只是一个快速发展的阶段而已

[fakefish]

@tedd 不知道这个，很久没关注 ng 了，也就在 ng2 beta 前看过一下

[hst001]

因吹思挺，作为后端，有时候要写界面，面对这么多前端轮子光是选型调研，定型后还要阅读文档，这些就要浪费我两三天的时间 ，好可恶啊

[iversong]

技术是为产品和业务服务的，学某个技术或某个框架重要的是看它能不能解决你遇到的问题，设计哲学很重要；

Jquery 辉煌过， API 很清晰，但是它在大型应用中有很痛的痛点：“难以维护，性能太差”，这也是后来 MVC ， MVVM 框架从设计层面要解决的问题。

React 大行其道，推崇“简单直观，符合习惯”的方式编程，虽然定位只是个视图层库，但是有针对的解决问题；
1.首页解决的是复杂的编程模型，数据驱动视图（ state->UI ），从 web1.0 开始，数据样式变了，刷新页面即可更新，简单直观，这更符合程序员的编程思维。
2.虚拟 dom 才是核心好么，简单直观，符合习惯了，如何高效操作 dom ？虚拟 dom 简直巧夺天工，异步高效的渲染视图。
3.函数式编程，更符合数学思维的方式去构建 UI ， jsx 只是语法糖。

说说 Flux 吧，看似把项目复杂化了，其实基于 Flux 的实现更多的是一种约定，让数据流动更清晰，真的需要看项目规模，应用本身不复杂，数据逻辑不大，用了反而增加维护成本。

在持续发展的路上，前端是曲折的，体验是糟糕的，只能踩着轮子（框架）朝着统一的规范化发展，当然了，目标很明确，解决当前的实际问题。

[wdrsam]

很中肯~jq 就是一个成功的工具，大家造好的辐条、好的车头等等就够了，遍地开花的一家一个轮子就没意思了...

[raistlin916]

"Iterable NodeLists are so fundamentally important to the quality of the DOM. Unsurprisingly I now use React for most of my coding instead." --- John Resig, jquery 作者如是说

[horizon]

我最开始看到 jsx 的时候也在骂，把 html 和 js 写一起，前端倒退 10 年。
后来去写 Vue 了，写多了再返回去看 jsx 的时候，竟然觉得太牛逼了，太方便了。
其实就是用 js 控制一切的意思，我可以使用现有的 js ，不需要受模版语法的限制。
比 vue 的模版还是要高一级啊。

[airyland]

" vue 在我需要的一个第三方核心组件上表现的太差，甚至 vue 的这个组件 demo 都无法打开"

既然是第三方实现的组件，那么这个和 Vue 其实关系不大吧

[zongwan]

学习新技术、工作流上最大的感触：
react native 的 live reload 和 hot reload 很方便, 节约了不少打杂和沟通的时间
精力可以分散到 native 各种 SDK 的学习和对接等其他地方了

过去使用的只是一个库：
jQuery 历史包袱太重，代码太难管理
很多人也应该抛弃了 underscore ，选择了效率更好的 lodash

再多学几年其他技术，可以更好结合经验优化工作流效率
js 到全栈就提供了挺不错的道路：编写重复的代码->项目研发框架管理->项目工作流(包含 CI 、测试、发布、监控)->决策(更快 or 更稳定 or 开发效率高)

ps ：最近刚接触 react native ，最头疼的问题有 没有找到 Base64 和 MD5 的包，不过官方很早之前就预留了原生去自行解决这些问题的方法。
最早单开发 flash 的时候，对 adobe 的 ANE 设计策略就很不开心。手机的多点触摸，陀螺仪，加速计都要自己开发 ANE 才能使用。后来因为对接各种平台市场的支付的原生 SDK 慢慢接受了，自己多学了 Android 和 iOS 的原生开发 对产品更了解了。（无关：不过还是因为历史包袱太重和互联网的利益关系， flash 慢慢被市场淘汰了。不过从 flash 的开发中开阔了不少视野：文本、动画、摄像头、语音、网 络、二进制、 OpenGL(agal in flash)、手机应用、平台 SDK ）

[jswh]

jQuery 可以在 dom 之外对 dom 进行方便的操作。其他的框架都是要在 js 里面用代码写 dom ，对 dom 对象化，再进行操作。想想用 jQuery 的时候莫不是先写 html 再考虑怎么对这些 html 进行操作来实现用户交互效果。现在呢，都是我的产品交互如何，再来设计内容组件。前端开发对界面的控制欲越来越强，所以需要新的模式来在强化控制能力的同时，减少工作量。但是，如果本身就没有这样的需求，那不用也可以。就像 flux 一样，不是任何时候都要用的。砸一颗钉子不需要打桩机，但是打桩的时候还是要上打桩机。

个人浅见

[loryyang]

作为一个后端人员，用过一些前端的东西， jquery 感觉非常好用，很简单直白。至于后面那些奇奇怪怪七七八八的新框架，我总觉得有点重复造轮子的嫌疑。这么多新东西，都还没成熟就被淘汰了。这不是一个正常的技术生命周期。

[dmyang]

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

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

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

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

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

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

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

[hasbug]

暂时顶一顶，标题很合我意！