1
JohnSmith 2016-10-18 09:22:54 +08:00 via iPhone
前后端情况不能一视而同啊
|
2
MicroPan 2016-10-18 09:24:34 +08:00 via iPhone 2
mark
个人感觉很中肯 |
3
Sivan 2016-10-18 09:27:05 +08:00 via iPhone
有意思
|
4
IdJoel 2016-10-18 09:27:16 +08:00
mark
|
5
murmur OP 补充一点:我不想看到猛吹微信公众号的,微信公众号除了真的企业政府开的是应用外,多少在盗抄、传谣、造谣、鸡汤,简直是造谣传谣对原创作者版权侵犯的主力军。
|
6
fszaer 2016-10-18 09:29:44 +08:00
其实 vue 嘴上说是双向绑定,实际上需要你显示说明,不然默认单向绑定。。。。。。
|
7
hansnow 2016-10-18 09:38:14 +08:00
从一开始说着说着 jQueryAPI 优秀突然跳到 fetch 就有点没看懂。
JSX 这块儿黑的太没水平了。 XML in JS ,说到底就是普通的 JavaScript 代码,怎么会没 if 和 for ? |
8
scnace 2016-10-18 09:38:19 +08:00 via Android
mark 写得不错
|
9
fhefh 2016-10-18 09:39:30 +08:00
现在做前端 觉得好累
|
10
MidLinn 2016-10-18 09:40:12 +08:00
深表同意~~~
|
11
keeley 2016-10-18 09:40:18 +08:00
说的挺好。排版在弄弄呗,文字太长了读下去不容易。
|
12
murmur OP @hansnow 语文不好理解一下
那块说的实际上是 ajax 的封装,因为 fetchIE 全线不支持,所以还是按工具比较的 另外模板不就是让代码更优美么,你在 html 中一堆{}里面写 if for ,要么 map ,写 if 还得用立刻执行函数,这不是回到以前 jsp 和 php 里混写代码被鄙视的年代? |
13
murmur OP @keeley 不好意思我想编辑,我发现了太多的错别字和用词不对,但是 V2EX 只给我 10 分钟校正时间就锁定了。。
|
14
lwbjing 2016-10-18 09:42:51 +08:00
以前也各种追潮流... 现在就看心情了...
|
15
xiaoyangsa 2016-10-18 09:43:27 +08:00
最近一直有种感觉, js 能统一世界。。
|
16
DarsyCheuk 2016-10-18 09:44:34 +08:00 via iPhone
mark 轮子是个圆 转了一圈又一圈
|
17
hansnow 2016-10-18 09:47:01 +08:00
@murmur 最开始接触 JSX 的时候我也感觉很蛋疼,看起来确实是 JS 和 HTML 写在一起了,非常混乱。但是越到后面越觉得,就像各种 React 教程里一开始告诉我们的: JSX 是一种 JS 的语法糖嘛。 React 自己维护一套 VirtualDOM ,所有 DOM 元素都是 JavaScript 的 Object ,那么接受了这种设定之后, JSX 显然比手写 Object 简单方便太多了。而且一般 JSX 的部分都不会太长,如果看起来实在太乱了,那说明有更好的办法来实现这个需求(比如抽象出子组件或者用 ES6 的新特性来简化代码)
|
18
qianddream 2016-10-18 09:48:02 +08:00 1
既然选择 IE8 和 360 ,要毛体验啊,明明是自己放弃的嘛, Win 7 的 IE 最高支持到 IE 11 ( win7 上面好多软件要求必需安装 IE11 才能工作),都什么年代了,网吧用 xp 的很少了,人家都是全高配好吗!,再说谁会在网吧看我们做的网页啊,太少了吧。
MVVM 解决的是全端交互问题, Learn once,write anywhere ,用 JSX ,很大一部分是冲着 FB 家的诚意去的(虽然现在有点跑偏) 前端都落后后端这么多年了,现在退回去是不可能了,要虚心学习。 |
19
ljcarsenal 2016-10-18 09:48:47 +08:00
weex 那个 看到 github 上 bug 报得那么多 也不知道阿里他们怎么用到生产环境的。。。。
|
20
TangMonk 2016-10-18 09:50:05 +08:00 via Android
不错,还好没有去随大流。。
|
21
xxxyyy 2016-10-18 09:51:12 +08:00 via Android
有些不明白,双向绑定就那么重要吗?
还有说 fetch 是开倒车,那真是太 naive 了,这个 API 可是为以后的 service worker 准备的。 |
22
murmur OP @qianddream Learn once,write anywhere 永远是个梦想,操作系统的差异性不是你想抹平就抹平的,好的混合框架背后都有超牛逼的 native 团队去替你开路
|
23
qianddream 2016-10-18 09:51:38 +08:00
python2.7 是 python 社区之痛,不提也罢。 ES2015 可以去看看最新的支持情况 https://kangax.github.io/compat-table/es6/
|
24
f0rger 2016-10-18 09:52:03 +08:00
前端就是:轮子复轮子,轮子何其多
需要找一个适合自己的来用就好 |
25
murmur OP @xxxyyy 因为 react 没了 ajax 封装,又在猛推 fetch (你是不会 XMLHtppRequest 的是么?),那么这个相比$.ajax 的封装就是倒车
|
26
serco 2016-10-18 09:52:47 +08:00
React 又没有强调过单向数据流,单向本身就是 flux 推崇的,而且是有意设计成这样的。
复杂的组件交互,传统的事件模型耦合度太高,维护成本高。 任何事情都是有 trade-off 的,用 flux 那一套,简单功能的模板代码量就会增加。 前端是改变的太快了,但是感觉全文基本都喷的不在点上 |
27
zhqy 2016-10-18 09:52:59 +08:00 via iPhone
观点基本相同...
|
28
ericls 2016-10-18 09:53:55 +08:00 via iPhone
用 elm 解决一切问题
|
29
assad 2016-10-18 09:53:59 +08:00
我早都感觉到 JS 能统一世界了。把 JS 弄的牛的都要上天!
|
30
jiongxiaobu 2016-10-18 09:57:44 +08:00
|
31
xxxyyy 2016-10-18 09:58:17 +08:00 via Android
@murmur 你还是没明白 fetch 这个 API 的价值,它可不是简单的一个 XMLHtppRequest 的 Promise 的实现。
|
32
robertlyc 2016-10-18 09:59:00 +08:00
应该工作没超过 3 年
|
33
TingHaiJamiE 2016-10-18 09:59:17 +08:00
毕竟有些东西的出现不是为了技术进步...
|
34
dabpop139 2016-10-18 10:00:08 +08:00 via Android
原因可能是 js 的历史原因吧,一直都没有强有力的引领机构,要不是就是机构的标准来得太晚, JS 的发展严重拖后腿, JQ 的出现就慢慢有了改观, JQ 一开始也都很多人不接受包括我,因为当时来说没有 V8 加上电脑性能普遍不好,用 JQ 都会拖慢网页性能。后来 V8 出现带来了革命,但 V8 也没有给到标准,大厂各自搞了一套基于数据驱动的框架,我自感觉和 JQ 没啥冲突,至少 Vue 是可以结合 JQ 用的。另外 ng1 个人感觉是推广不给力,或者说当时大多数基层业务用不上 ng1 。回到现在 Android 让 H5 的应用广泛流行,所以现在流行 react 和 Vue ,移动端抛弃了历史包袱和解决了兼容性问题,所以大多数 feature 的框架是应用在移动端。个人感觉可以不要被表象迷惑,只要看基层业务的应用就好了,只有基层业务上大家都用的框架应该就是以后的标准风向标。个人感觉现在是 vue ,或者是还没出现。
|
35
xxxyyy 2016-10-18 10:00:16 +08:00 via Android
@murmur 至于会不会 XMLHtppRequest ,没必要把这个来秀,这仅是一个处理请求的 API 而已。
|
36
dtysky 2016-10-18 10:00:34 +08:00 3
说白了还是 WEB 开发本身性质就特殊,从传统领域搬运的 mvvm 解决的是规模上升后的 SPA 问题, babel 解决的是科学的现代 EMCS 标准和浏览器运行的古典 EMCS 的冲突问题, webpack 和构建工具解决的是资源优化问题
至于框架乱象, JSX 这些真没什么黑的,你觉得乱,但另一方面也是社区活跃的象征,是生命力的象征,而且我觉得 JSX 很先进啊,彻底的组件化确实加速了开发速度,作为在大型项目中使用过 react 全家桶的表示全用 jq 写确实会死人嗯,现在某部门用 JQ 堆起来的代码已经让一堆人欲仙欲死了,当然你可以自己用 JQ 构建一个自己的框架,但恐怕最后和现在流行的这些 MVVM 没有多大区别就是了,自己造轮子是很开心,但在工程放弃成熟的用自己的就是脑子有问题 当然,在中小 WEB 应用中用 JQ 甚至直接原生 JS 没有任何问题,甚至是应有的做法,在兼容性要求严格的情况下 JQ 也是好选择,但阁下说的什么开倒车我还真是不懂了 顺便关于单向绑定,在 WPF 中实践过双向绑定,双向绑定带来的 debug 痛苦你能理解么? 还有模板。。。真不觉得有啥比 JSX 优雅的,这种个人品味问题也拿出来黑也是。。。需要那个就用那个呗,在一个项目里混用模板和 JSX 又不是啥新鲜事。。。 |
38
hei1000 2016-10-18 10:02:08 +08:00
"你们真应该好好感谢 360 , 360 用一种比较温和的方式让大量用户升级了有 chrome 内核的浏览器"
和 360 有啥关系?我又不用 360 |
39
liuweisj 2016-10-18 10:04:24 +08:00
我第一次接触这些东西的时候就深有感触,然而我抱着既然这么多人认同应该是有他们道理的心态去看待的,今天看楼主总结下来才发现不止是我一个人有这种感觉。。。。。 “然后又是 react 这种把 html 混写到 js 里。另一方面,我们看架构工具, glup 和 grunt 已经是历史, webpack 去年兴起今年就有人要革他的命,明年又是什么打包工具呢? grunt 没有错,他的设计就是批处理,压缩、混淆、整合都能做到, webpack 也是 bundle 更方便加热调试,那么新的架构工具又有什么 feature 能让用户放弃之前的东西,重新再造一次海量的轮子呢? ”
|
40
murmur OP @dabpop139 我认为这个进化应该是这样的:前端想要统治世界->前端搞出了简单的 SPA->产品经理强奸用户,无止境的乱加功能和模块->前端力不从心->发明 MVVM->产品经理直接强奸程序员->更猛的 MVVM
受害的永远是用户 |
41
VinKing 2016-10-18 10:07:13 +08:00
可以预见,在未来的 1-2 年内会沉淀出来一批 JS 圈里面基本的技术工具。不过 jQuery 是个好东西,这点我也很赞同哈。简单、好用。
|
42
qianddream 2016-10-18 10:08:09 +08:00
@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 |
43
Phariel 2016-10-18 10:10:24 +08:00 via Android
还好 我厂都是用的自有框架 有同事向老板们安利 React 现在也不了了之了。。。
|
44
jinbakei 2016-10-18 10:12:33 +08:00 via Android
点赞
|
45
murmur OP @qianddream 我只想知道,为什么{}变 url params 这种超人性化的设计,居然不被支持,我需要的是一个 ajax 工具,是工具啊~~,我不想直接用草案开发,你可以理解的是我要一个$.fetch
|
46
Geeker 2016-10-18 10:13:34 +08:00
所以我在考虑转后端了 2333
|
47
murmur OP @hei1000 360 不惜以伪造补丁的方式强推 360 浏览器,然而 360 系列浏览器是流氓软件中口碑不错的,你流氓虽然流氓,但是做出的产品毕竟还可以啊
否则中国的 IE6 占有率还是居高不下 |
48
Geoion 2016-10-18 10:16:12 +08:00
后端: PHP 是世界上最好的语言。
前端: jQuery 是世界上最好的框架。 |
49
dabpop139 2016-10-18 10:17:37 +08:00 via Android
@murmur 在我看来现在这些框架都是在推崇一个理念模块化,规范标准提高协助能力,包括 laravle 框架的出现,通俗的讲就是提高基层编程素质,以前前端估计还很多人不能理解 MVC 是什么?只有加入了标准才能更好的发展,我说的发展是整个前端的发展不是说个人的。有了更好的标准才可以促进发展,可以理解 JQ 其实就是不成文的标准。前端的发展模式可以参考中国的发展来理解,中国并没有选择西方的资本主义,但是也发展成为了现代化国家。前端是一样的,都是朝一个方向发展,只是一开始就落后了要选择一条相对不寻常的道路。现在也可以看到 JS 有可能要覆盖到大多数应用方向。
|
50
sutra 2016-10-18 10:17:55 +08:00
吐得不错,这也是我最近的感觉。
|
51
qianddream 2016-10-18 10:20:18 +08:00
@murmur 这个你直接用 template string 不就好了?
|
52
fakefish 2016-10-18 10:21:29 +08:00
说双向绑定好的 可能没遇到 ng1 的性能问题,虽然 c# 这种也是双向绑定,但是不存在性能问题, ng1 在上万个 scope 之后卡的教你做人,而且没办法避免,框架本身的缺陷,也就是为什么后面的框架都不是默认双向绑定了。
那篇文章讲的确实是个问题,太多人总是为了用框架而用框架,而不是因为需要用才用。 比如 grunt 到 gulp 到 webpack ,为什么要用这些,还不是越往后性能越好,轮子真的能提升开发效率才会真正发展下去。 为什么不用 jquery ,如果页面逻辑简单,开发人员不多的情况下, jquery 必然是第一选择,移动端是 zepto ,但是如果是那种页面逻辑复杂,开发人员比较多的情况下, jquery 这种随意操作的方法会带来各种问题,就为什么会出现 backbone , backbone 出现提出了一种可行的方案,但是本身还是有各种问题,后面的 ng1 也是一种尝试。 不是在开倒车,而是为了让车开的更快,边开边修车。 |
53
ty89 2016-10-18 10:22:11 +08:00
前端普遍浮躁
|
55
whimsySun 2016-10-18 10:26:50 +08:00
我到没有觉得这些框架不好,就是现在 js 开发真他么太烦,要配 babel, 要配 webpack/gulp/grunt, 要配 eslint, 要配 editorconfig, 缺少企业开发标准,各自一套标准,心好累~然后马不停蹄,各种框架狂轰滥炸
|
56
dabpop139 2016-10-18 10:28:30 +08:00 via Android
@murmur 发展最需要的是靠用户支持,你说的被产品经理虐和前端行业发展没有必然的联系,也可能是预想不到的,或者说是前端的发展不会关心这个极少数问题。
|
57
fakefish 2016-10-18 10:28:58 +08:00 1
js native 这个问题
native 开发最大的问题是不能热修复热更新,不能做 ab ,大家痛苦了这么多年, react native 的出现就是为了让 native 上能够解决这些问题,代价是略微牺牲性能而不是 webview 那种低性能的,而 weex ,大方向肯定是没问题,虽然现在是一堆问题,大公司太需要这两点了。 但是 js native 的最大的开发问题是 前端工程师还需要熟练掌握 native 的开发,做 js native 这种才不会有太大问题。 |
58
TimLang 2016-10-18 10:31:33 +08:00
新框架的产生肯定是要把相对底层的东西淘汰的,做做规模不大,需要兼容 ie8 的用 jQuery 还行,真的复杂的话,维护 dom 是很痛苦的一件事。
jQuery 的好处是相对插件较多,但是相对现在支持数据绑定的框架来说已经不那么方便了,比如我做个打字(typing)效果,用 jQuery 操作 dom 实现是很复杂的,但是如果在 vue, react 甚至是微信小程序,几行代码就实现出来了。 |
61
2zH 2016-10-18 10:33:44 +08:00
@murmur react 有一堆 promise 封装好的 xhr 库,操作起来也比$.ajax 优雅,不用 fetch 也可以。
|
62
murmur OP @fakefish js native 还是需要一个牛逼的 native 层,这反倒要求精英的 native 程序员,小公司或者初创就只能找插件多或者成熟的
rn 是一个方向我从没否认,但是 rn 现在很明显火候不够,现在 ios 和 android 差异性 API 还是非常多,并没有像以前的混合上来就抹平差异性 |
63
cuebyte 2016-10-18 10:34:24 +08:00 1
作为一个后端开发人员,我个人非常喜欢 jQuery ,简单好用足够我去开发简单页面,不用去 npm 、 webpack 搞一堆东西。
曾经试着用 vue 、 gulp 、 webpack 等东西,完了不禁在想我很大时间都在去适应这些新东西,但实际上的需求很简单,几行 jQuery 就能搞定。能在 HTML 里多写两行代码搞定的是我为啥要把事情做复杂呢…… 当然了,以上都是我作为一个后端在开发简单页面中的想法。 |
64
ariesjia 2016-10-18 10:35:27 +08:00
我认为还是要看你做的东西是什么? web page 还是 web application , 如果是 web page 你用 jQuery 完全没有问题 ,如果是 web application 不上 组件化的框架就哭啦
|
65
flashback313 2016-10-18 10:36:22 +08:00
楼主写的很认真,所以想参与讨论:
1 、不认同 jq free ,虽然我不是一个深度 jq 用户,但是 jq 里面有很多代码是可以挖出来用的。 jq 设计很好,产品思维也好。 2 、前端框架其实有趋同化,这是一个趋势。例如 dom free ,重数据。 3 、打包工具 grunt gulp webpack 一路过来其实是在解决不同问题。 整个前端目前确实痛苦,但个人觉得这是在走向经典的路。这是 js 这些年积累的一次大爆发。 |
66
buckyRRRR 2016-10-18 10:39:26 +08:00 via iPhone
@robertlyc 不管别人说的有没有道理,人家能写这么多也是认真诚意的表现,这是交流的地方,这么喜欢喷人直接去打架好了
|
67
robertlyc 2016-10-18 10:40:19 +08:00 1
一般问出这种问题的 都是工作不超过 3 年 对前端的认识停留在操作 dom 修改一下某个 value 用 css 写写 animation
所以才会对 jq 产生莫名的好感 从来没有从工程角度考虑过前端应用的演变和富交互化带来的复杂性 一个工具的诞生从来不是产品经理来决定 都是源于解决工程中遇到的实际情况 看 lz 这样子是没怎么认真看过 jsx 才会觉得拿它和模板引擎做比较 拿浏览器版本兼容和后端语言版本做比较也是风马牛不相及 多说无益 在论坛从来不要指望去教育别人接受自己的观点 反正 lz 高兴就好 |
68
ctsed 2016-10-18 10:44:37 +08:00
和 YY 有啥关系...
|
70
robertlyc 2016-10-18 10:48:09 +08:00
工作不超过三年这是喷人? 手动滑稽
|
71
buckyRRRR 2016-10-18 10:52:52 +08:00 via iPhone
@robertlyc 几不几年和别人说的观点正不正确没有关系,不去有理有据反驳别人的观点,直接抛出别人工作不超过三年来暗示别人经验浅,用此种办法降低别人观点的可信度,这不叫喷人叫什么
|
72
depress 2016-10-18 10:54:56 +08:00
作为一个 java 后端表示也不是什么项目都用 spring...不过我承认未来可能确实是 js 的天下,虽然现在前端乱成一锅粥,这也就是我不做前端的原因,啃一门语言可以啃透,前端变幻莫测。
|
73
qiukong 2016-10-18 10:55:09 +08:00
用户是上帝?扯,
过时的东西就该让它被淘汰,前端联合起来迫使用户升级才是硬道理。 你说一两家网站不兼容用户趾高气昂,所有网站都像抵制 IE6 那样,用户就不得不升级了。 |
74
ianva 2016-10-18 10:56:06 +08:00 3
这是脱离业务场景谈技术
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%了很多大公司都无视了,移动端的重要性也越来越高了。 毕竟前端这个环境碍于浏览器,各种功能都是社区慢慢搭建起来的自然是问题多多,但这些都是说明前端的技术在不断的演进,在解决各种问题。 |
75
leonlu 2016-10-18 10:56:08 +08:00 1
**前端轮子多,是有原因的!**
相比于 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 的态度上,可以看到楼主对于旧有观念的执念太深了。。。 |
76
otakustay 2016-10-18 10:56:29 +08:00 2
当前的前端分为 page 和 app ,这完全就是 2 个领域了,你把它们混在一起然后说混乱那是必然的,以后也应该有 webpage developer 和 webapp developer 这样的垂直岗位才好
|
77
qiukong 2016-10-18 10:57:18 +08:00
真像你说的那样也有,我们公司内网报表系统还停留在 IE6+ACTIVX 阶段。
要完完全全往兼容上靠,那干脆老系统都不要升级, HTML3.2 足够了。 |
78
robertlyc 2016-10-18 10:59:18 +08:00
很正常啊 因为工作的都是零散的页面 聚焦不在工程化的前端项目上 看不到 web components 带来的变革 前端的变化又不是突然就行成的
jq 之后的 backbone 就在着手工程化解决 js 结构 require.js 带来的各种 loader 着手解决加载机制 前端的变革加速于 node 社区的成熟 作为前端 如果只顾看着自己用 jq 写的快 写的方便 不去整体看社区的变化和工程上的努力 这才是开倒车 |
79
andypinet 2016-10-18 11:02:22 +08:00
太在意这些了 不好
俗话说的好 分久必合 前端也会表面上统一 合久必分 java 系已经开始被其他 jvm 语言干了 |
80
onion83 2016-10-18 11:02:30 +08:00
1 、楼主老司机
2 、前端水太深,一直敬畏,不明觉厉 3 、后端的人都往 Devops 、大数据方向走,数据存储方面这几年变化也不少,但是基本有迹可循,相对而已没有人愿意拿数据开玩笑和冒险。 路其实还是那条路,就是跑在上面的车不一样了,开桑塔纳还是还特斯拉,还得看人的追求。跑得快的不一定好,跑得慢的也未必差。 |
81
hei1000 2016-10-18 11:14:16 +08:00
@murmur 我没用 360 系列产品,不用 IE,所以它的"贡献"与我无关, 去年新买的电脑,电脑也没装 xx 卫士,xx 管家,不用第三方杀毒软件,不知道为什么 Chrome 和 Firefox 怎么主页就变成了 360,之前可以通过手段去掉的,但是突然有一天又回来,而且不管怎么折腾都去不掉了,而且每次打开浏览器,他都会新建 360 标签(还有上次未关闭标签), 放在 hosts 里面禁止都不行,瞬间觉得他们好屌,就差重装系统了,还好大部分 Linux 下面,所以影响比较小
|
83
Canrz 2016-10-18 11:16:09 +08:00
JQ 最终会走入历史,但是在历史上留下的光辉谁也无法抹去
================ 这句大赞 |
84
reus 2016-10-18 11:17:59 +08:00
看你举的选项卡的例子,就知道你是能力不行,反而怪工具的一类人了。 react 类框架做这种事情简直手到拿来,你不会只能说明未掌握 react ,如此而已。再复杂几倍的交互, react 都是一样的思路,多复杂的交互都不用多费脑,这就是生产力工具。
何况用 react 也可以不用 JSX 的啊,直接手写 hyper-script 也没什么问题。 |
85
caiya21 2016-10-18 11:18:45 +08:00
其实这些东西并非 2016 年才有的 不要什么都扯 2016 年好么, ES6 也是 ES2015 好么。。。 2016 如果连这些都不能掌握 真的有点过时的感觉 生产工具无非是提高开发效率 如果你觉得用 jquery gulp grunt es5 这些能高效完成工作的话 就可以了 也没有必要纠结了
|
86
Pandora78 2016-10-18 11:19:11 +08:00
认同 74 楼的同学,寸有所短,尺有所长,脱离业务场景谈技术 ,没什么含义
|
87
tedd 2016-10-18 11:23:17 +08:00 via iPhone
@fakefish 上万个 scope 的确太夸张了,之前听说两千以上性能就受到挑战了。请教不知道用新语法糖 :: 做单项绑定是否能解决问题呢?
|
88
xwartz 2016-10-18 11:24:34 +08:00
这只是一个快速发展的阶段而已
|
90
hst001 2016-10-18 11:28:36 +08:00 via Android
因吹思挺,作为后端,有时候要写界面,面对这么多前端轮子光是选型调研,定型后还要阅读文档,这些就要浪费我两三天的时间 ,好可恶啊
|
91
iversong 2016-10-18 11:28:53 +08:00
技术是为产品和业务服务的,学某个技术或某个框架重要的是看它能不能解决你遇到的问题,设计哲学很重要;
Jquery 辉煌过, API 很清晰,但是它在大型应用中有很痛的痛点:“难以维护,性能太差”,这也是后来 MVC , MVVM 框架从设计层面要解决的问题。 React 大行其道,推崇“简单直观,符合习惯”的方式编程,虽然定位只是个视图层库,但是有针对的解决问题; 1.首页解决的是复杂的编程模型,数据驱动视图( state->UI ),从 web1.0 开始,数据样式变了,刷新页面即可更新,简单直观,这更符合程序员的编程思维。 2.虚拟 dom 才是核心好么,简单直观,符合习惯了,如何高效操作 dom ?虚拟 dom 简直巧夺天工,异步高效的渲染视图。 3.函数式编程,更符合数学思维的方式去构建 UI , jsx 只是语法糖。 说说 Flux 吧,看似把项目复杂化了,其实基于 Flux 的实现更多的是一种约定,让数据流动更清晰,真的需要看项目规模,应用本身不复杂,数据逻辑不大,用了反而增加维护成本。 在持续发展的路上,前端是曲折的,体验是糟糕的,只能踩着轮子(框架)朝着统一的规范化发展,当然了,目标很明确,解决当前的实际问题。 |
92
wdrsam 2016-10-18 11:29:10 +08:00
很中肯~jq 就是一个成功的工具,大家造好的辐条、好的车头等等就够了,遍地开花的一家一个轮子就没意思了...
|
93
raistlin916 2016-10-18 11:35:21 +08:00
"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 作者如是说
|
94
horizon 2016-10-18 11:42:24 +08:00
我最开始看到 jsx 的时候也在骂,把 html 和 js 写一起,前端倒退 10 年。
后来去写 Vue 了,写多了再返回去看 jsx 的时候,竟然觉得太牛逼了,太方便了。 其实就是用 js 控制一切的意思,我可以使用现有的 js ,不需要受模版语法的限制。 比 vue 的模版还是要高一级啊。 |
95
airyland 2016-10-18 11:45:07 +08:00
" vue 在我需要的一个第三方核心组件上表现的太差,甚至 vue 的这个组件 demo 都无法打开"
既然是第三方实现的组件,那么这个和 Vue 其实关系不大吧 |
96
zongwan 2016-10-18 11:45:42 +08:00
学习新技术、工作流上最大的感触:
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 ) |
97
jswh 2016-10-18 11:48:20 +08:00 1
jQuery 可以在 dom 之外对 dom 进行方便的操作。其他的框架都是要在 js 里面用代码写 dom ,对 dom 对象化,再进行操作。想想用 jQuery 的时候莫不是先写 html 再考虑怎么对这些 html 进行操作来实现用户交互效果。现在呢,都是我的产品交互如何,再来设计内容组件。前端开发对界面的控制欲越来越强,所以需要新的模式来在强化控制能力的同时,减少工作量。但是,如果本身就没有这样的需求,那不用也可以。就像 flux 一样,不是任何时候都要用的。砸一颗钉子不需要打桩机,但是打桩的时候还是要上打桩机。
个人浅见 |
98
loryyang 2016-10-18 11:56:29 +08:00
作为一个后端人员,用过一些前端的东西, jquery 感觉非常好用,很简单直白。至于后面那些奇奇怪怪七七八八的新框架,我总觉得有点重复造轮子的嫌疑。这么多新东西,都还没成熟就被淘汰了。这不是一个正常的技术生命周期。
|
99
dmyang 2016-10-18 11:58:20 +08:00 1
非前端从业者的角度看来, jq 确实是个好东西,理解简单容易上手。
但是 jq 毕竟只是工具,解决 js 选择 DOM 的问题。 但是前端到了大规模化的时候,需要的就不仅仅只是一个 DOM 选择器了,它需要开发者自行解决模块化、组件化等问题,而这些恰好又是后端语言本身就自带的能力。 另外一个和后端的不同就是代码的部署问题,前端的特殊性就在于,代码需要动态安装(下载)到 C 端,这就需要保证下载最小体积的代码又要实时生效,而且还得保证不影响代码的阅读(即至少两套代码并存)。代码在经历开发和生产之间需要有一系列的变化,比如代码压缩、合并,变更部署路径(文件名加 md5 以保证缓存生效)等等,同时又要保证开发的便利性,在使用了浏览器还未支持的语法(如 ES6 )时,开发环境可能又需要实时将代码转换成 ES5 ,也就是 grunt/gulp/webpack 等工具的热替换功能。而所有这些东西,只有前端才会出现,后端无此问题。 以上提到的每一个点,前端语言层面都没有解决,只能开发者自己搞定,所以导致几乎每一个点都有两种以上的框架、工具来解决,有选择就会有分歧有站队就会有口水战,所以看起来前端“混乱”,但我认为这并不是什么坏事,刚好促进前端的完善。 统一一种框架 /工具好处比较多,正如贴主提到的 java 的 spring 框架,但要知道需求是无止境的,你不要指望用一种框架、工具解决所有问题,这必然会导致代码膨胀和冗余!前端(尤其移动端)根本承受不起代码膨胀所带来的一系列问题。 综上,贴主还是在前端领域多实践几年,再下结论吧。 |
100
hasbug 2016-10-18 12:11:46 +08:00
暂时顶一顶,标题很合我意!
|