V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
murmur
V2EX  ›  前端开发

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

  murmur · 2016-10-18 09:16:02 +08:00 · 29157 次点击
这是一个创建于 2964 天前的主题,其中的信息可能已经有所发展或是发生改变。
有人说,你有什么资格发表这种高谈阔论,实际上是这样的,我在看 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能让用户放弃之前的东西,重新再造一次海量的轮子呢?

这样的乱象何时能了?不知道。
第 1 条附言  ·  2016-10-18 10:29:12 +08:00
你们不要纠结现在用不用 jQuery 的问题好不好, jQ 是艺术品,也是成功的工具,功能多却又专注不冗余,设计看似有些混乱但是却处处为开发者着想, API 简单优美但是不过分追求短小,这是我对 jQ 的评价, JQ 最终会走入历史,但是在历史上留下的光辉谁也无法抹去
第 2 条附言  ·  2016-10-18 12:54:42 +08:00
有些人不要望文生义,不支持双向绑定和默认不开启双向绑定是两回事,如果 iframe/多页+ng1 呢?是不是就解决了 scope 膨胀的问题,为什么非要 sap 呢?我可是见过不少这种情况了,有的 chrome 插件,就几十行百来行不到业务逻辑代码+v 层,也上了一个 ng1
173 条回复    2016-10-21 15:14:40 +08:00
1  2  
yoa1q7y
    101
yoa1q7y  
   2016-10-18 12:15:13 +08:00
我只能说,你爱用啥就用啥
你觉得 JQuery+模板好那就选这个
你觉得 React 好就选 React
谁也没有逼你
wtser
    102
wtser  
   2016-10-18 12:15:26 +08:00
这不叫混乱,这叫繁荣好嘛。虽然可能 90%的东西在你看来都是垃圾,至少还有 10%的确是好东西。
murmur
    103
murmur  
OP
   2016-10-18 12:19:48 +08:00   ❤️ 2
@ariesjia 我也在苦思这个问题, SAP 到底用在什么地方,我至今用过的 2 个,一个 teambition ,一个是阿里云后台,然而这两个东西都是面向开发者,可以强迫用户使用 IE10+或者 chrome 解决 scope 大带来的性能问题,而企业开发因为 IE 的兼容性要求更高反倒不能随便上 react 、 ng2 这些(好羡慕只做 chrome 兼容的公司)
手机上,我还是坚信一点,能让你装了就不敢(不是不想哦)卸载的,都是 native 重应用,微信、 qq 、支付宝,这些,其余的,应该慢慢被其他应用( ROM )整合,最典型的就是美颜相机,其余的比如天气、便签,甚至未来可能是音乐视频这些,我概括为根本不需要安装或者安装了只为情怀的 app ,差异性是不可能的,以前追求差异性的优酷土豆,以及很多类似的公司都最终合并了,这是个资本的年代,也是寡头的游戏。
@robertlyc 我们一路从 backbone , ng1 走来,到现在挣扎于 vue2 、 react 、 ng2 ,被你一说好像成了彩笔一样,我很伤心啊,另外你不看我写的东西就来回复么?我只是说 jq 的设计思路很优秀,从来没说过他现在还应该被广泛使用或者现在依然牛逼之类的东西。企业开发的人是互联网的看不起(但是我们真的不加班啊,我入职快 3 年一天班,准确点说总加班时间不超过 5 个小时,然后我不想回答为什么不去互联网的问题),就跟用 ios 的看不惯用 windows 的一样,我都习惯了。

@ctsed 360 流氓也只停留在诱导安装 360 浏览器这一步, YY 是静默安装,而且总静默,动不动就想给你装点什么,而且他这个产品(浏览器)设计的也不值得我留下

@buckyRRRR 兄弟感谢你为我说话,超感动

@qiukong 我升级了 chrome 用了 edge ,换了最新的小米手机(穷用不起 iphone 另外我要 u 盘功能),结果“你们”回报给用户的是越来越差的产品体验(哦我说的就是 x 浪微博、 x 鱼),又是开发者,又是用户所以我才有这样的观点。

@ianva ie8 的国内占有率是多少,在企业中占比又是多少

@otakustay 移动端本身更乱,比前端还乱,可以说是为了 app 而 app ,以前可以 web 的功能现在强制 app (最重要的是用户装了 app 并没有更好的体验啊), pc 端很好的设计阉割了必须用 app (对就是那些视频网站),这也没办法,本来就是烧钱,谁只专注于提供功能谁就得死,你没广告没推广的话,真正笑到最后的,还是微信支付宝这些几年前就在笑的 app

@robertlyc ng2 我认为是更彻底的 web component 设计,虽然存在问题但是从设计理念来说绝对 1 流,可惜 ng2 也被鄙视

@andypinet java 系最大的风险不是 java 本身,是因为 oracle 跟 google 干仗让人看到了不明朗的未来,这跟前端乱象不是一个原因

@leonlu 第一个感谢给你了,我一直以为 jsx 必须放到 return 里才能被解析

@reus 不要着急下结论,自己写一下就知道, jq 的我早就写过了, react 的我也写过,我就算傻还不会 google ?! react-tabs 的代码我看过了,通过设置 selectedIndex 放到 status 激活 tab 也非常好懂,但是不优美的地方就出在他核心那段 cloneElement 里,源生都能做到的东西 react 当然能做到

@caiya21 最近流行用 2016xx 做标题,不要介意

@airyland 都选了开源框架肯定选轮子多的,如果背后没一群人替你填坑,敢用么,我不敢

@zongwan native 掌握两门还是不容易啊,羡慕同时学 2 门 native 的大神

@dmyang 一个 react bundle 没做什么东西 minify 完了就 800 多 k ,嗯这真的不冗余,前端(尤其移动端)根本承受不起代码膨胀所带来的一系列问题。到时候会有 2019 年开发前端是什么体验的。

另外回复一下那位用中国路线比喻的,同志,你这问题不小啊,中国是特色社会主义,但是中国什么时候允许多党制了(开玩笑)。
最后, v2 的回帖 cd 是重复计算的么?!这么 xx 的设计,我要精确计算 1800 秒,少一秒回复不仅失败还要重新来 1800 秒的 cd ,日了。
我表明一下我的观点,我不排斥新技术,我接受新技术,但是我也是人,人习惯于以前接受的东西,移动电话在飞速变革,但是你以前打电话是按键拨号,后来手机是按键拨号,触屏也是点击数字拨号,没有人说让你做个 pose 输入电话号码吧?当你用到的框架动不动大动干戈居然连一点抱怨(为啥后端尤其是 java 稳的 1b 呢)都没有还在给变化辩解,愣是把不合理的设计想为 feature ,我看不太科学吧。
ooTwToo
    104
ooTwToo  
   2016-10-18 12:29:11 +08:00   ❤️ 1
A : 什么年代了还在学 jQuery ? 用 Vue 、 React 吧!
B :为什么?
A :不知道,感觉很牛逼。。
yyy
    105
yyy  
   2016-10-18 12:37:21 +08:00
楼主脱离许多实际业务场景各种狂喷,感觉是在耍流氓啊。
标题所说的混乱,也只是因为在前端这层场景太多,所以才有各种层出不穷的各类技术。同时技术选型的时候,会比较考验眼力。

至于说开倒车,嘛。。。楼主开心就好。
murmur
    106
murmur  
OP
   2016-10-18 12:40:45 +08:00
@yyy 哦, java 也有各种实际业务场景,那怎么没人说 java 乱呢,人家可是站在 android 的 native 层,桌面端也有很多跨平台 app 在用
Ahri
    107
Ahri  
   2016-10-18 12:47:28 +08:00
有一点深表认同就是用 Redux 的项目门槛高,只要有一个猪队友就能给你弄的乱七八糟。
lijsh
    108
lijsh  
   2016-10-18 12:49:51 +08:00
在全世界前端社区都已成为潮流的东西,规范都出了,网上有的是最佳实践,在国内就因为 IE8 的苟延殘喘,被喷成开倒车。

为免说我纯喷回复无意义,就说一个单向数据流, Vue 默认不支持双向绑定,需要显式指定; ng2 同样如此。大型应用的状态管理是个复杂的问题,如果你做的是大型应、团队作业,还打算用双向绑定,那只能祝你好运了。
coffce404
    109
coffce404  
   2016-10-18 12:51:36 +08:00 via Android
框架是需求推动的,如果 JQ 极其完美没有痛点,就不会出现 Angular 和 React 了,出现了也没人用。事物的发展是呈螺旋上升的, JSX 和过去的模板都能叫做 Template ,但已经不是一个高度的事情。
ibufu
    110
ibufu  
   2016-10-18 12:51:53 +08:00
jq 就一个工具库而已,和 node 的 underscore 差不多,磨平浏览器 api 差异的。
jq 的 api 优雅好用,这是事实,但不能和框架什么的比。
murmur
    111
murmur  
OP
   2016-10-18 12:52:02 +08:00
@lijsh “不支持”和“默认不开启”是 2 个概念
arzusyume
    112
arzusyume  
   2016-10-18 12:53:01 +08:00
用着用那的无非两个原因, 提高效率及质量
各种工具和框架的变革本质上也离不开这两点

选择当然也是一样啦, 单纯的更风是没有意义的
coolzjy
    113
coolzjy  
   2016-10-18 13:00:40 +08:00
> 用$代替所有选择器是太牛逼的设计

看到这句就不想再往下看了,对 jQuery 的理解仅限于 Sizzle 估计也不会有什么有价值的见解。可以很明确的回答你的问题:如果业务场景需要, jQuery 的选择器即使改成 `jQuerySuperSelector` 我仍然会去用。

一个行业是在进步还是退步并不是这个行业内部决定的,而是外部因素决定了,只要外部对前端的需求在不断提高,前端总是不断进步发展的。你可以吐槽某些技术的跑偏,但无法否定整个行业的进步。(我自己不支持也不看好混合开发)

如果你确实产生了行业在退步的感觉,真正退步的其实也是你自身而已。用对的方法做对的事,这就足够了。
lijingyu68
    114
lijingyu68  
   2016-10-18 13:02:34 +08:00
人类不都喜欢挖坑再填坑吗?如果你觉得这是开历史倒车的话,人类从农耕开始就在开倒车了。

人的每一个发明都会带来更多待解决的问题,前端也一样。
jin5354
    115
jin5354  
   2016-10-18 13:08:33 +08:00   ❤️ 2
首先你得明白你手头有什么需求,这个工具是解决什么需求的,然后再去用。

fetch 是下一代 XHR ,是规范的一部分,它的出现是用来替代 XHR 的,不是用来替代 $.ajax 的。 fecth 的语法原始又简陋,啥语法糖都没,就像没人手写 XHR 一样,肯定不是用来手写的。从标准角度来看,提供 plain 的语法其实是优秀的设计。你只需要继使用 axios 这种语法糖多又实用的库就好。 axios 这种第三方库会逐步把自己内部的 XHR 实现换成 fetch 实现。

同理,存在海量表单、数据展示的页面,适合选用带有数据绑定的框架。存在大量跨页数据传递、状态传递的站点适合使用状态管理工具,用 webpack 打包成 spa 。复杂度越高的页面,越适合用这些工具。

现在很多人写文章吹框架,大家就盲目的跟着上,不管自己做的项目是大是小,一窝蜂的去装全家桶。业务代码量加起来连 3000 行都不到,就急着配一大堆新东西,然后再喷说咋这么难用。其实这东西根本就不是给你用的。
bobsam
    116
bobsam  
   2016-10-18 13:12:03 +08:00
我个人觉得 如果前端只剩下 jq+模版,我也许很快就转行了。但是正正是因为前端有 react , vue , ng1 , ng2 等等这些框架和库的出现,让我感觉到了前端的繁荣,还有发展的无限可能性,所以我一直坚持下来了。我想很多人也是这样的吧。 jq 好是好,但是一直固守于它也不是好事,既然有更好的方案解决,何不去尝试一下呢?
Felldeadbird
    117
Felldeadbird  
   2016-10-18 13:14:11 +08:00
现在不流行写 JQ 了吗?我公司的产品都是用 JQ 的。
前端配置工程师。
leer561
    118
leer561  
   2016-10-18 13:14:52 +08:00
的却 -> 的确
indooorsman
    119
indooorsman  
   2016-10-18 13:16:24 +08:00 via Android
呵呵
ssehacker
    120
ssehacker  
   2016-10-18 13:22:26 +08:00
至少可以得出两个结论:
1. 楼主前端经验 3 年以下
2. 楼主接触的项目大都比较小
ssehacker
    121
ssehacker  
   2016-10-18 13:23:34 +08:00
3. 楼主几乎没有做过移动前端。
sodatea
    122
sodatea  
   2016-10-18 13:24:33 +08:00
ng2 是单向绑定([(ngModel)] 只是语法糖而已)
vue2 也是单向绑定

能不能搞清楚点再长篇大论……
franckcl
    123
franckcl  
   2016-10-18 13:25:34 +08:00
不是针对楼主啊,我就说我知道的, python 现在真是 2.7 应用的范围更大也更多,很多开源的应用或者库还不支持 python3 , python3.4 跟 3.5 都有不少的改变,当然这只是 python 的历史原因, JS 我觉得就是因为当时推出时的设计太仓促
sodatea
    124
sodatea  
   2016-10-18 13:26:05 +08:00 via iPhone
擦,笔误,我想说的是单向数据流,双向绑定只是语法糖
sodatea
    125
sodatea  
   2016-10-18 13:38:31 +08:00 via iPhone
关于 fetch 你也完全说错了。
fetch 完全不是开倒车,因为它的精髓不是他的 API 设计(但不管怎么说它的 API 完全由于 XMLHttpRequest ,,只是说还不够优秀而已)。
fetch 的意义在于它是比 XMLHttpRequest 更底层的 API , Service Worker , SRI 之类的新 Web 标准里的很多功能都依赖于底层 fetch 的实现。只看到表层的 API 设计就狂喷也太不专业了。
MorlayNull
    126
MorlayNull  
   2016-10-18 13:39:33 +08:00 via Android
SPA 和 Page 是两种东西
话说回来, SPA 的 SEO 很难做
an168bang521
    127
an168bang521  
   2016-10-18 13:40:32 +08:00   ❤️ 1
每当前端争议的时候,

我就发我的 Javascript 学习笔记,都是 Javascript 的总结知识,前端入门的同学欢迎 star ,欢迎修正;
https://github.com/Broszhu/zhuanbang-javascript-notes

然后发现很多人对基础都很重视;很多事情没有必要挣的脸红脖子粗的,看应用场景的;
以前喜欢看新的类库和框架,现在保持中立态度;(目前看好 jquery 、 gulp 、 webpack 、 react )
sodatea
    128
sodatea  
   2016-10-18 13:45:40 +08:00
BTW , NG2 的 AOT 支持是很早就有的,不是等到要发布了才匆匆加上的。
sodatea
    129
sodatea  
   2016-10-18 13:46:54 +08:00
另外,说 jQuery 过时的,很多都是前端自嘲而已,不要随随便便就当真啊……

以及,说其他框架没解决刚需的,只是没解决你的刚需而已。
emric
    130
emric  
   2016-10-18 13:55:27 +08:00
现在的 JavaScript 像 PHP ,有人说我不要框架写的很好( vanilla ),有人说我只要 ORM 就行( jQuery ),框架什么都是浪费性能,把简单的事情变复杂。

总之你开心就好。
gouflv
    131
gouflv  
   2016-10-18 13:57:14 +08:00
纯属瞎操心, 看别人不是都用得好好的嘛?
chemzqm
    132
chemzqm  
   2016-10-18 14:06:56 +08:00
倒车不至于吧,主要是现代大型项目对于体验要求和迭代要求越来越高,进而产生了各种工具和框架解决相应问题,一个架构的考量是多个维度的,如果你想要稳定性就必然会牺牲灵活性,例如 react 相对于 jquery ,前者看似复杂,实际上对于多变的业务更为友好,而后者尽管开放方便但是代码往往混乱不堪。
前端框架思想现在基本上也是大同小异,例如 react , vue2 和 MINA 都是基于 VirtualDom 的组件化方式,以及数据流的单向流动,这里我不得不吐槽下 angular1 的双向绑定,用的时候问题层出不穷,基本就是面向巧合编程。
webpack 这种工具看着配置很多,但是实际使用大部分功能你并用不上,基本配置出来就可以了,并不是很费时(除非你需要研究它底层实现)。它比之前 grunt , seajs , requriejs 之类工具提供的功能更多更好(打包配置, loader 配置,插件配置等等),使用也更加灵活,替代它们是必然的。
mbfan
    133
mbfan  
   2016-10-18 14:12:10 +08:00 via Android
方便说下是什么组件吗?
最近开始啃 vue ,想造轮子→_→
DualWield
    134
DualWield  
   2016-10-18 14:21:55 +08:00
你光看到了很多新的框架,工具的产生,不去想一想新的框架、工具的优点、精髓,就来找喷吗?

这是一个前端百花争鸣百花齐放的时代。
anuxs
    135
anuxs  
   2016-10-18 14:27:47 +08:00 via iPhone
看出来楼主是原创,科班出身,有丰富的项目经验,支持你的观点。 js 社区已经魔障了。
murmur
    136
murmur  
OP
   2016-10-18 14:28:55 +08:00   ❤️ 1
@jin5354 已感谢,的却企业开发用 ng1 非常爽,很多开发就算不是 sap ,处理复杂表单做成多页也对得起 ng1 了
@leer561 好久不上语文课了,感谢纠正
@ssehacker 我们的大项目都是 iframe 的应用,没办法,小公司不可能有那么多精通 ng 的工程师,所以干脆 iframe 算了
@ssehacker 我们的移动端起步比较早,那个时候好像 ionic1 连 beta 都没出吧,用的 backbone ,吃够苦头了
@sodatea 参见文档 Form Input Bindings ,"You can use the v-model directive to create two-way data bindings on form input and textarea elements. "
@sodatea 我找到的比较新的文章还是 2016 年 4 月左右的,所以求更多资料, aot 很爽,换掉默认编译器之后那 binding 小的感人
@chemzqm 某些我认为合理的功能被去掉了,嗯就这样,留着不好么
@mbfan card layout , react 上的 star 3000 了快, vue 和 ng2 的好像还都才几十,最早应该都是 gridster
newljs
    137
newljs  
   2016-10-18 14:29:46 +08:00
楼主开心就好。
imdoge
    138
imdoge  
   2016-10-18 14:40:16 +08:00
xerxes
    139
xerxes  
   2016-10-18 14:52:33 +08:00
@zongwan md5 和 base64, npm 里很多
leer561
    140
leer561  
   2016-10-18 14:52:48 +08:00
首先我觉得是前端从事件驱动转为数据驱动的改变。
其次这不是乱,而是大家说的百花齐放百家争鸣,我们有很多很好的选择,选择适合自己的业务场景的就好了啊。
不断前进,不断造轮子,不断踩坑,挺好的嘛,没有开倒车。
kisnows
    141
kisnows  
   2016-10-18 15:03:20 +08:00
@murmur "一个 react bundle 没做什么东西 minify 完了就 800 多 k ,嗯这真的不冗余,"
别的不说,针对这句,你可能是打包的方法有问题。
我们项目这边基于 React 的一整套框架搭建下来,打包后核心文件就 300kb ,这包括十几个依赖的第三个包。
murmur
    142
murmur  
OP
   2016-10-18 15:16:18 +08:00
@kisnows 感谢提醒,检查了一下 react 自己的 minify ,然后看了一下依存,不知道哪个模块依赖了 moment ,然后 moment 的 local 就 300 多 k 未压缩前,准备先干掉 moment 的本地化再说
另外 800 多有点夸张,真实是设置了 prod 环境是 688k
yolio2003
    143
yolio2003  
   2016-10-18 15:22:36 +08:00
看这么多评论就知道,确实混乱,不过还是觉得会有更好的事情发生
Nicksxs
    144
Nicksxs  
   2016-10-18 15:23:19 +08:00
赞观点
kisnows
    145
kisnows  
   2016-10-18 15:29:59 +08:00
我一开始也是没设置 prod 模式,导致打包出来的代码很多。
junp
    146
junp  
   2016-10-18 15:39:23 +08:00 via iPhone
在这贴能招到前端吗?深圳
jin5354
    147
jin5354  
   2016-10-18 15:41:48 +08:00
@murmur webpack 的打包体积优化是个细致活,优化前后差距巨大,我最近一直在鼓捣这个。
其实 vue2 全家桶只需 35k , react 全家桶使用 react-lite 做替换后大概也就在 50K 以下,不算大了。( react 这个没亲测过,看同事使用了 react-lite )。

重点是一定要做好按需加载!
仔细梳理依赖,用不到的删去,非必需的第三方库做好懒加载,
很多第三方库相当大, moment.js 就 30K ,图表库 chart.js 30 多 K , Echarts 有 50K 左右,全都不做懒加载体积会炸

一般的中小型项目优化完之后首屏的 js 都能压到 200k 以内

以上说的体积都是 min+gzip 后的
Infernalzero
    148
Infernalzero  
   2016-10-18 16:01:32 +08:00
LZ 写的很客观,然而并没有什么卵用,不用看回帖也知道肯定会被喷,毕竟贵站有不少用个 git 都能产生优越感的人,前端技术方面更不用说了
topgrd
    149
topgrd  
   2016-10-18 16:21:11 +08:00
不同的框架和工具都是为了解决不同问题而存在的,前端目前各种轮子都是为了解决遇到的实际问题的,在不同的场景,可能某些东西解决不了,而用别的就非常简单,如果楼主直接抛弃场景谈,是没道理的。
tonghuashuai
    150
tonghuashuai  
   2016-10-18 17:54:53 +08:00 via iPhone   ❤️ 2
lz 的标题就是我对前段界的看法。

现有的工具完全可以相对完美的解决现有的需求为什么还要去造轮子。

每次看到我引入的 n 多个 js 文件就对这个虚假繁荣的前端环境表示无奈,甚至有人拿 js 去写 os ,我想说:踏踏实实做好本职就好了。
tonghuashuai
    151
tonghuashuai  
   2016-10-18 17:55:29 +08:00 via iPhone
估计我上边的留言要被骂
fundon
    152
fundon  
   2016-10-18 18:00:20 +08:00 via iPhone   ❤️ 1
工程化 通用化 易维护 易迭代 易协同 这才是实际意义!
fundon
    153
fundon  
   2016-10-18 18:04:35 +08:00 via iPhone
@tonghuashuai “不要给小朋友买新衣服了,今年不是买了吗?”
Xrong
    154
Xrong  
   2016-10-18 18:12:58 +08:00
一直觉得前端太乱,不敢碰。。。
jiyinyiyong
    155
jiyinyiyong  
   2016-10-18 18:38:17 +08:00   ❤️ 3
昨天也在微博吐槽, React 是个好东西, Facebook 出的 React 全家桶某种程度上也算是好东西, 但是这个事情并不简单, Facebook 直接把他们公司里用的东西扔出来给大家用, 然后让大家帮忙找 bug. 跟 Google 比起来真的是不靠谱.

React 虽然是好东西, 但是绑定了很多内部的需求. 服务端渲染早先的 React 大会上就讲了一遍, 作者提交了 PR, 结果到现在 Facebook 官方用不到, 不合并. JSX 的问题, 之前很多人都说, CoffeeScript 直接用不就好了, 干啥子搞一套 JSX, 还升级 2.0 , Facebook 说自己用 XHP 很顺手啊, 而且内部代码用 ES6, 编译器一次能解决问题, 插个 JSX 小意思, 现在大家都被迫学习 Babel 怎么用.

GraphQL 也是, 你说好不好, 当然好, 解决了不少 Restful API 搞不定的问题, 但是我当时在简聊的场景, 我需要一个能解决掉服务端推送的方案啊, GraphQL 并不能. 包括 Redux, 和 Flux 的事情, 我们基于简聊都没法做平滑迁移, 后来烦了干脆自己写了一套, 也没比 Redux 差很多.

现在的前端, 感觉就是几个大厂看 js 扶不起来, 干脆自己开始搞, 然后干脆一搞搞个一整套. 牛逼不牛逼, 当然牛逼, 但是中间挖出来的坑也是超多. 而且麻烦的事情是作为小厂我们很难跟他们说, 我们的情况怎么怎么, 你们怎么怎么我们就怎么怎么了, 所以你们不能怎么怎么... 他们还是要以公司自身的发展为主, 其次考虑社区.

确实是混战. 而且个人开发者以及小公司搞不好就成了炮灰. 个人理解这样.
Elricpp
    156
Elricpp  
   2016-10-18 19:36:39 +08:00
确实是混战,但是如果这一整套东西最终能够达成一个共识,将会是极好的。
比如说未来浏览器支持模块语法, 支持 ES6 ,现在这一整套 webpack , babel 的东西将会逐渐的退出。如果 GraphQL 或者 Redux , Vuex 单项数据流 这一些新的社区实践能够最终内置到浏览器里面,不管是开发体验或者是用户体验都会得到一个大的提升。还有 webAssembly 这种颠覆性的性能提升的东西。
现在前端的混战确实各个大厂想要一统江湖,加上社区对未来的期望推动出来的,小公司或者个人开发者也只能够随波逐流啦,当炮灰总比被时代抛弃好吧?
zewenzhang
    157
zewenzhang  
   2016-10-18 20:01:34 +08:00
@jin5354 你好,我也在使用 echarts ,体积一直比较大,方便指教一下您是怎么做到 50K 左右的吗?我主要用到了 pie, line, bar 三种。谢谢
zhuangzhuang1988
    158
zhuangzhuang1988  
   2016-10-18 21:02:55 +08:00
没提到 rxjs 不开心。。
rockzhou8
    159
rockzhou8  
   2016-10-19 08:53:54 +08:00
昨天才开始看 Angular2 的文档...一脸懵逼:这特么的还能这么玩?!
SilentDepth
    160
SilentDepth  
   2016-10-19 10:00:12 +08:00
楼主的观点中肯,但表述有些偏激。想吐槽但不知从哪儿吐起。

看起来楼主在用后端的视角来看前端的发展。落后自然要加速进步。想必楼主对天朝这些年的发展也有不少意见。
murmur
    161
murmur  
OP
   2016-10-19 10:13:12 +08:00 via Android
@SilentDepth 后端就没进步么,从最早的 lucene core 到 solr 到 es ,每一次都是巨大的进步,舍弃前面的用后面的有充分理由,类似的还有 spark 和 hadoop , springmvc 和 strut2

但是我现在选择 react 不用 vue ,却没有这种理由,只是简单的 react 星星多
SilentDepth
    162
SilentDepth  
   2016-10-19 10:27:35 +08:00
@murmur 我没说后端没有进步,只是说前端落后得多所以要加速进步,这其中必然会出现大量的轮子等待自然的优胜劣汰,但个人认为这不值得遭如此批判。至于 React 和 Vue ,我觉得从中做选择没那么难吧……
xuhai951753
    163
xuhai951753  
   2016-10-19 14:52:58 +08:00
难道只有我感觉不管是工具还是库越来越好用了么。。
每次看这种吐槽贴都要捧一下 jQuery 。。其实感觉也没人说 jQuery 不好吧。。只是页面越来越复杂用 jQuery 操作确实神烦啊。。
关于浏览器的问题。。如果大家都用最新的浏览器。。我可以上很多特效啊。。我可以直接用原生 js api 。。兼容低版本浏览器简直神烦。。
关于 react+redux 全家桶。。我不知道你遇到了什么坎坷。。反正我教我们新来的小伙伴两天就上手了啊。。而且 react 我觉得主要是为前端小伙伴开了两个坑。。一个是 ssr 。。一个是 rn 。。虽然都是满满的坑。。但我觉得方向很棒啊。。
至于 vue 就更爽了。。我们 team 一周就全切到了 vue 。。学习成本之低。。
webpack+babel 不知道你是否体验过。。我是觉得真的很方便。。 es6/es7 加的很多语法糖都是别的语言早就有的东西了好么。。如果还有未来好工具。。直接切就是了。。反正工具就是拿来用的。。好用干吗不用。。学习成本、迁移成本能有多高。。
至于吐槽别人组件烂的。。那就自己写一个呗。。自己写的牛逼那 star 不就是你的了么。。
感觉大家讨论前端每次都说前端乱啊啥的。。我感觉前端也不怎么乱啊。。好东西就这么些。。挑着用呗。。
murmur
    164
murmur  
OP
   2016-10-19 15:01:01 +08:00
@xuhai951753 企业开发跟互联网开发不一样,很多互联网项目是一锤子买卖,新技术随便上随便用,反正不考虑几年后,可能 1 年甚至半年后,钱烧光了,这个项目自然就死了,但是企业开发你要保证你的技术 5 年内不会死(一般都默认送 1 年维护,再卖他个 3 年维护,然后 1 年开发吧, 3 年维护钱不少啊,快赶上开发费用了),至少可以维护最好还能有人继续跟下去,所以 java 里的选型都满足这个条件,即便是 strut2 , freemarker 都一直更新,虽然 strut2 漏洞几乎改不完,有的系统,升级了改造了可能不能用,还要有适应期,不升级加个服务器还跑的不错,如果你是领导你选哪个
你看一下 taobao 、 baidu 、腾讯,多少的页面还留着几年前甚至 10 年前的风格,他不坏能干活就能用呗,尤其是淘宝,你看他外表每年都改版,但是你进到个人设置里,有些页面是不是瞬间回到 10 前的感觉?他如果当时选了个稀烂的东西,这些页面都要重构(包括后台呢),重构还简单,重构完了要测试不是更麻烦
redux 那种状态机,你也知道状态转移提出去就比混写在代码一是麻烦二是需要一点点技术功底,至少人的脑子要足够清洗,否则抽象出来的东西也没法用,再加上不可变对象的要求,更增加了门槛,不是什么公司都有 3BAT 那个团队的好么
那也没办法,就赌在 react 上了, 3 个里选最火,组件最多的,虽然坑也不少
murmur
    165
murmur  
OP
   2016-10-19 15:13:33 +08:00
@xuhai951753 一个东西学 2 天真的太慢了,我当时学 lua 到写完第一个插件才用了 2 天,读研的时候从 java 基础到改写 c#程序就看了半个小时的书就开始动手了,但是如果你把 redux 拿掉对着 demo 写估计也就半个小时 react 就学会了,真的难点也就是解释清楚 prop 和 state ,还有生命周期就完了,当然了他的 animation 我没用,那东西没鸟用因为他是 tag 而不是 attribute 形式,很多第三方组件要求严格的层级关系套一层动画就跪了
有的时候项目是不给你学习时间的,哪里有把学习技术的时间排到项目日程里,都是排调研和写报告、技术方案这些,然后就进迭代期别人就等着看阶段汇报了。当年 4399 比较特殊,他是讲他们团队日夜学习 erlang ,这不一样,他一个大后台服务器架构都赌在别人身上了,我们只是选个框架而已,而且实话讲除了轮子,平心而论这 3 个框架谁也没有碾压谁的优势
所以说,选了开源的框架还拼命造轮子,犯不上啊,这几个框架仔细比一下都是差不多的学习曲线, ng2 看着难但是你给写 java 的人推这个他很乐意接受啊,就拼谁背后的轮子多
xuhai951753
    166
xuhai951753  
   2016-10-19 15:27:21 +08:00
@murmur 企业开发这个场景我是觉得比较尴尬了。。毕竟前端被一帮互联网公司主导着。。像我们的页面挂一年就不错了。。前端确实还没出诞生出大杀器。。虽然内心看好 vue 。。
murmur
    167
murmur  
OP
   2016-10-19 15:40:36 +08:00
@xuhai951753 有几点可能看来可笑,但是并没有道理的,首先 vue 。。这么快。。。出 2 了。。出 2 了(我朋友升级了,据说坑不小所以不要相信什么平滑过渡,自己的还好第三方组件就等着跳吧)。。 vue1 才什么时候出的, ng09 年出 1 现在出 2 ,而且就 ionic 给续着,背后那么多 ng-component ,死都难,就跟 jquery 一样,而且我前段时间用的时候, v2 在官网都没有入口,现在当然有了,最后, v2 现在还没中文文档,而 ng2 有个背后官推的翻译团队
invalidtoken
    168
invalidtoken  
   2016-10-20 00:15:56 +08:00 via iPhone
NPM 的依赖确实是问题....项目直接依赖只有 7 个,都是构建工具,但是展开来一共有 1.4 万个包
murmur
    169
murmur  
OP
   2016-10-20 14:34:25 +08:00
@invalidtoken 可以试试换 npm3 npm2 的目录结构简直是噩梦
yeah2109
    170
yeah2109  
   2016-10-21 05:17:38 +08:00 via Android
我看到有转载的地方有人直接评论作者 shabi 了,嗯,我保持沉默
invalidtoken
    171
invalidtoken  
   2016-10-21 09:47:02 +08:00 via iPhone
@murmur 已经在用 NodeJS 6.8 了, 1 万多个依赖, npm 下载过程经常卡住, cnpm 经常有包损坏, yarn 每次添加都要重新链接,也要用一分半左右
coffce404
    172
coffce404  
   2016-10-21 10:20:13 +08:00
@murmur 楼主逻辑清晰,说的还有些道理,但是很多都说错了,如果回复之前能先查一下资料就好了
ooTwToo
    173
ooTwToo  
   2016-10-21 15:14:40 +08:00   ❤️ 1
看到一段话,感同身受:

前端的发展比较快,各种框架、工具层出不穷,工具推动着标准的发展,也对技术升级带来了较大的挑战。尤其是工具圈,工具的生命周期都越来越短,前不久还看到有人发段子吐槽说前端现在热衷于搭环境,什么 gulp 、 browserify 、 babel5 、 babel6 、 webpack 轮番上阵,折腾好久都没搞定,公司都要倒闭了,环境还没搭好,最终采用原始的硬编码方式来引入 js 脚本。前端工具圈的狂热导致开发成本骤升,已经有点本末倒置了,工程化不是目的,用工程化提升工作效率才是目的,技术不是目的,用技术提升生产力才是目的。别瞎升级,很可能升级后你的开发环境就跑不起来了。
1  2  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5715 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 27ms · UTC 03:02 · PVG 11:02 · LAX 19:02 · JFK 22:02
Developed with CodeLauncher
♥ Do have faith in what you're doing.