Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

我在D2夜场上对前端工程的预言,兼答“如何评价阮一峰关于前端工具变化快的言论?” #34

Open
hax opened this issue Dec 28, 2015 · 24 comments

Comments

@hax
Copy link
Owner

hax commented Dec 28, 2015

知乎答案链接:https://www.zhihu.com/question/34449620/answer/79028575

其实本答案并不是对工具变化快的直接评价,而是通过预言来间接给出评价:与我预言的即将发生的变革相比,阮老师所描述的变化是小巫见大巫。

我的这个预言或者说判断,在2014年年中即已成形,但我一直憋到2015年年底才来回答——因为在一周前D2的夜场上,我在即兴发言中终于憋不住抛出了我的预言:前端的构建部署即将发生革命性的变化——单独的构建环节将逐渐弱化乃至消失,构建所包含的实质性内容即脚本、样式等资源的编译转译等将云化和实时化。两年后(到2018年时),不要说Grunt/Browserify,Gulp/Webpack等也均将退出主流。

具体来说,我预言明年(2016年)将出现包含JS模块加载、包依赖自动处理、JS自动编译这三项核心功能,并基于HTTP/2的前端资源云服务(可理解为CDN的进化形态)。并且这类服务会在未来两年里快速成长并带动整个前端的大跃进。比如,通过ServiceWorker大幅提升浏览器缓存利用率,加上HTTP/2等协议级优化,Web应用的加载性能将获得划时代的提升;根据UA分发目标平台特定编译版本和自动polyfill,Web应用的浏览器兼容性将获得划时代的提升;提供各种增值服务如方便部署安全特性,安全性监控、灰度部署、包的平稳升级、前端(精确到应用和所依赖的包)的错误监控和分析、前端性能监控和分析等,Web应用的质量将获得划时代的提升,开发效率也将是划时代的提升……由此,前端工程师也会重新把很大一部分精力从构建部署相关的工程问题回归到网站/应用的交互体验本身。(不过应用框架和组件化相关的工程问题届时是否能有比较一致的答案,现在看还很难说。)

以上就是我的预言,立此存照。

BTW,如果2016年9月前我预言的事情还没开始发生,我会亲自动手。 ^_^

@hbrls
Copy link

hbrls commented Dec 29, 2015

关于老旧浏览器的占比有什么预言么,还是说完全依赖 polyfill

@markyun
Copy link

markyun commented Dec 29, 2015

阮老师也就随便那么一说而已...

@luqin
Copy link

luqin commented Dec 29, 2015

前端真苦逼,这些工具真只能用的时候再学,学好编程核心思想,打好基础吧

@luqin
Copy link

luqin commented Dec 29, 2015

能预言下IE9以下的浏览器什么时候退出中国主流吗?政府企业这些各种IE8什么时候退出历史舞台

@fouber
Copy link

fouber commented Dec 30, 2015

我觉得到9月份实现还是挺困难的,毕竟涉及到平台、运维、高质量的生态等诸多问题,工程量巨大,最终要解决的又不是全行业共同关注的痛点,商业性也偏弱。

但从技术人的情怀来看,这个预言是令人激动的,hax可以考虑单开一个主题讨论其中的技术细节,做更深入的可行性论证,如果真的要在9月份拿出结果来,恐怕就要从现在开始准备了。

The best way to predict the future is to create it.

@kuitos
Copy link

kuitos commented Dec 30, 2015

@fouber hax应该是预言2016年9月份这个事情开始发生有人着手在做了,而不是已经实现了😂

@sapjax
Copy link

sapjax commented Dec 30, 2015

@kuitos 所谓“出现”肯定是要达到一个可用状态的,否则预言就没有意义了,比如我说我现在已经“着手在做了”,是没法验证的。

@chaoren1641
Copy link

16年还有不到48小时,感觉贺老的预测还是有点远了啊。在国内这种浏览器环境可能明年还远达不到上面说的这么强大。国外前端生态有可能会走进这一步,但应该也只是初步探索而已,离普及还是要些时日。

9月份亲自动手,有这个魄力说出来就够佩服!!!

@hax
Copy link
Owner Author

hax commented Dec 30, 2015

@fouber 其实商业价值是非常巨大的。

年前有很多事情,过完年我来找你和教主玩,届时给你们说说,呵呵。

@fouber
Copy link

fouber commented Dec 31, 2015

@hax 欢迎欢迎

@mooncakelmn
Copy link

这个想法很cool,代理层的polyfill,各种云端监控搞起来会比现在提升一大步。有个问题,实时性这块在资源更新后的第一次访问时怎么保证高效。这块即使local开发做起来都不是很快

@hax
Copy link
Owner Author

hax commented Jan 3, 2016

@mooncakelmn
资源更新后的预热这个事情看起来困难,实际上如果你联系我们一些其他需求,比如灰度发布、稳步升级依赖、线上问题自动监控和自动rollback之类的,就会发现其实是互相关联的。也就是,如果你不把它视作一个单独需求,而是看整个更大的图景,可能就会有不一样的(很可能是更好的)解决方案。

@sutaking
Copy link

影响的可能还不只是前端开发,react-native把这三大核心功能代入了native app开发模式

@paddingme
Copy link

2017 年了

@amio
Copy link

amio commented Jan 24, 2017

@yolio2003
Copy link

北京时间:2017/02/14 10:09,路过。。。:p

@hax
Copy link
Owner Author

hax commented Feb 22, 2017

立flag往往太早……

anyway,确实有一些接近我描述的部分东西出现:

unpkg最近也在做类似的事情,因为它是最被广泛使用的npm cdn,故预期应该会带一波节奏。

@amio
Copy link

amio commented Feb 23, 2017

@hax 你说的“亲自动手”的预言好像失败了 😄

@hax
Copy link
Owner Author

hax commented Feb 24, 2017

@amio 先自动推迟一年到今年9月再说 😆

@hax
Copy link
Owner Author

hax commented May 15, 2017

又一个类似我预言的东西在浮现:
https://medium.com/@christianalfoni/webpack-bundling-as-a-service-f902ab1a9f4c

@xufei
Copy link

xufei commented May 15, 2017

webpackbin,我3月份在群里贴过这个地址……

@hax
Copy link
Owner Author

hax commented May 6, 2020

https://www.pika.dev/cdn 预言的东西终于差不多出现了。晚了差不多3年多,但要达到webpack退出主流估计还要再3年……

@hax
Copy link
Owner Author

hax commented May 24, 2021

最近支持esmodule且自动build的CDN一下多了起来:

@hax
Copy link
Owner Author

hax commented May 15, 2023

预言的风险总是非常高。

webpack的生态太庞大了,尽管vite等对其有巨大冲击,但我预言的「编译转译的云化和实时化」8年来一直没有进入主流,而(我当时没有预见到的)对编译的需求由于react/vue越来越依赖编译构建优化,包括sevlte等编译型框架的兴起,需求也不降反升,因此webpack始终无法退出历史舞台,而且还通过各种方式(最近的如rspack)不断续命。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests