本文作者:方应杭(微信: frank_fang )
本文很长,但请耐心看完,因为末尾有广告。。。
这个视频来自 RailsConf 2016 ,演讲者是 Sam Stephenson ,他主要的开源作品有 rbenv、Pow 和 Trix,曾是 Rails 的核心开发人员。目前在 Basecamp 工作。
从这个视频,你可以明显地看出前后端开发者思考问题的差异。
好了我们进入正题,看看他讲了什么。括号里面的话是我说的,其他都是演讲者说的。
⬆️ 我们一共 10 个开发者,其他 6 个 Rails 开发、 2 个 iOS 开发和 2 个安卓开发,在 18 月完成了共 200 个设计图、部署到五个平台的 Basecamp 3 。
(你能想象不用纯前端开发者来开发一个 Web 应用吗?)
⬆️ 我们来回顾下从 2004 年开始, Web 开发经历了怎样的过程。
⬆️ J2EE ,典型的三层架构:数据层+业务逻辑层+表现层。(前端这个职业还没诞生吧)
⬆️ 然后是 PHP ( PHP 是招黑体质)
⬆️ 然后是以 Rails 为代表的 MVC 。那个时期是 Rails 的黄金时代,然而浏览器的性能令人沮丧。
整个 request-response 的循环简单而优雅。
⬆️ 我们对服务器渲染 HTML 的性能不是很满意,同时浏览器的性能进一步提高了,所以我们觉得可以把渲染放到浏览器上来做。
(可以看到简单的环状结构变得比较复杂了:浏览器从服务器获取 model ,同时自身维护着 router 、 view 和 controller 。)
浏览器从服务器得到一个空的页面,然后用 JS 启动这个页面。 JS 发起很多 API 请求。服务器接收 JSON ,输出 JSON 。所有的 HTML 渲染,由浏览器完成。
大家都觉得这主意不错,是吧?
⬆️ 但是,前端们还是觉得客户端 MVC 的性能不够好,所以又引入了虚拟 DOM 来最小化 DOM 操作。
想法很不错。既然 DOM 操作慢,我们就尽量不要操作 DOM 。
但是呢,有两个问题:
(没事,再加功能)
⬆️ 所以我们决定不用浏览器来渲染首屏了,让服务器来(回到老路子)。但是由于渲染逻辑我们不想做两遍,所以我们需要在服务器添加一个 JS runtime 来执行 JS 才行,这样浏览器端的渲染逻辑在服务器上也能跑起来了。
服务器也要支持虚拟 DOM ,因为客户端操作的就是虚拟 DOM 。
那么上面这个图就是全貌了,把我们 2004 年的设计,重新改写了。
但是复杂度,真的是爆炸性增长。
一个 Web 应用的依赖,已经成千上百了。
整个系统复杂到,一个人,不可能对其了然于胸。
我们的队员需要分别去掌握其中某个子系统。
⬆️ 康威定律
讲真,你们这些人知道康威定律吗?
系统的设计团队受其生产系统的约束,而生产系统又是根据设计团队的沟通结构决定的。
⬆️ 康威定律说,软件产品的结构就是其创造团队的组织结构的镜像。
我们正在使用的客户端渲染框架,来自于 Google 和 Facebook ,这两家公司有数千开发者,这些开发者隶属于数十个团队,组织结构就像这样:
⬆️ (是不是跟上面带有虚拟 DOM 的那种架构图很像?)
⬆️ (认清自己吧,少年)
你的团队面临的问题,很可能跟 Google 和 Facebook 所面临的不一样。
使用那些客户端框架时,我们是为了追逐性能,我们做的每个决定都是对的,但是放在一起看看结果,我们获得了微小的性能提升,却在工程方面花费了惨重的代价。
如果继续深入这条路,这条路就会变得越窄。
(还没完)
⬆️ 由于我们除了要支持 Web ,还要支持 iOS 和安卓,所以,我们要制造出三个类似的系统。
(讲述者没有再说 React Native 了,因为这个思路是一样的:开发者选择客户端渲染,同时不想做三次,只能让 JS 运行在三个平台上。这就是「路越来越窄」,开发者把自己限定死了的意思)
⬆️ Fuck that.
我们来重新审视一下吧。
如果我们希望一个小团队能做大项目,那么就不应该把系统搞得这么复杂。
⬆️ (又出现这张图)
⬆️ 让 iOS 和安卓直接使用 View 。
Web 的 View 可以作为 iOS 和安卓的基础,然后想办法优化使其体验起来像是本地应用。 Turbolinks 5 ,做的就是这件事情。
⬆️ 你的服务器依然渲染整个 HTML 。
Turbolinks 异步请求页面,然后使用得到的 head 和 body 替换当前页面。 head 会做合并, body 则直接替换。
(后面演讲者演示了 Turbolinks 的效果,有兴趣的人可以去看看视频。另外 Turbolinks 还提供了 iOS 和安卓的 SDK ,让移动端体验更顺滑)
(演讲者也承认,这样的模式渲染一个页面大概 300ms ,没有很快,但是绝对够用。我看了下在 iOS 下的表现,切换页面时的 loading 时间确实有点长,但是能忍,也许再加点优化可以做到 1s 左右)
相关观点:
《为什么我不喜欢「前后端分离」》 - 18596 views
《不依赖 Gulp 、 Babel 、 WebPack ,还能优雅地写代码吗》 - 6775 views
广告:
我现在在「彩程」(主要产品是「知人」和「 Tower 」),从事 Rails 开发,欢迎有志青年一起来「远程开发」,不用每天浪费三个小时在车上,而是用来学习新知识,真的很好。
邮箱: frankfang1990atgmail
1
dcoder 2016-08-17 03:51:17 +08:00
|
2
shoaly 2016-08-17 04:01:03 +08:00
写的很好, 楼主的表达能力 以及想要表达的内容我都觉得不错
|
4
FrankFang128 OP @dcoder web 300ms , iOS 1s ,不一样的平台
|
5
czheo 2016-08-17 04:10:37 +08:00
前排观看 lz 又来挖大坑。
|
6
czheo 2016-08-17 04:44:20 +08:00
1. 其实我观察到的历史不是因为后端渲染不够快,而是因为前端需求开始复杂到需要写 modular js 才出现的前端框架。
2. 无法被搜索引擎检索,在 virtual dom 出现以前,前端框架普及之初已成问题。 3. Turbolinks 的作者当然支持 webview ,而现实是市场更愿意选择性能优秀效果酷炫的 native app 。 |
7
peneazy 2016-08-17 06:08:04 +08:00 via Android
已经感觉到前端的复杂了,入职三个月,依然没有完全搞明白公司的整个前端框架,可能自己是前端新人的缘故吧。
|
8
markx 2016-08-17 06:09:06 +08:00
我觉得这篇文章很有意思,图文并茂说得很清楚。
但是我看到“讲真,你们这些人知道康威定律吗?” 的时候,我心里一惊,因为我真的不知道这个是什么。托楼主的福又学到了新东西 :) 接着往下看,发现文中的翻译好奇怪啊。我想“这里 produce 不该是动词么?” 于是我去查了维基百科,发现维基是这么说的“ organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations ”. 好吧,学习了。 |
9
markx 2016-08-17 06:21:27 +08:00
看完全文了。
我很喜欢文中那些结构图,很清楚。 虽然是广告,但是我心里很赞同。如果用简单的工具能把事情搞定,就真的没必要搞复杂了。也许用各种高级工具各种抽象会更利于扩展,但现在的 web ,两三年工具就更新换代了,所以扩展说不定还不如重新写了。 |
10
ecloud 2016-08-17 07:00:10 +08:00 via iPhone
在手机平台上用 HTML 假冒一个本地应用的做法不是这两年才有的
之前那些基本都死得很惨 剩下一俩没死的都改成本地应用了 |
11
eriale 2016-08-17 07:03:48 +08:00
赞!前后端细粒度分离,应该是产品 /部门大到一定程度的结果。
楼主有没有考虑过产品 /用户规模大到什么程度时,才需要把前后端拆成这么细? 1000w 用户?或更多? |
12
loading 2016-08-17 07:16:24 +08:00 via Android
期待楼主很多的好文翻译。
|
13
tomatoo 2016-08-17 07:30:44 +08:00 2
说几点:
- 并不是所有的网站都有 SEO 需求; - SAAS 应用的前端一般比较复杂,如果还是按照 jquery 的组织方式来搞的话维护起来太麻烦了; - 我并不觉得 Google 提出的 angular , Facebook 提出的 react 会让整个应用的结构变得复杂,相反的使用框架可以帮助我们写出更加低耦合,模块化,组件化的代码,同时数据与 DOM 的分离也让前端的单元测试更加方便。 (之前是前端开发,现在做 rails 开发,一点感受) |
14
metrue 2016-08-17 08:20:05 +08:00
其实 Rails 支持了 API 模式,在某种程度已经表明 Rails 社区也同样认为前后端分离是合理的。
|
16
mdluo 2016-08-17 08:28:09 +08:00
简单点,招人的方式再简单点
|
17
sfree2005 2016-08-17 08:36:12 +08:00
同意 @tomatoo 我觉得原视频的主要思想还是说包装 web view 到移动端一种新的方式。 如果服务器渲染出来的页面没有很复杂的交互逻辑,这的确够用了。有的话还是要写复杂的 JavaScript ,这时候前后端分离,工程化和组件化就很有必要了。前端框架 Angular 之类是将复杂的交互逻辑变得更容易实现,所以最终还是需求决定工具。
|
18
shyling 2016-08-17 08:37:27 +08:00 via iPad
一直不觉得前后端分离和规模大小有关。。。而且和性质有关。
想想当年, you are not google ,所以你不配像 gmail 那样使用 ajax 。是不是呢? 另外为什么要执着于 virtualdom 了,那只是实现的途径而已。说起来既然用了 rails 还大谈性能问题....各种 coc 不管是在后端还是在前端都是为了更'无脑化'的写代码吧 |
19
liudanning 2016-08-17 08:38:21 +08:00 2
唉,就是一句简单的具体问题具体分析
|
20
cenxun 2016-08-17 08:38:56 +08:00
套路精髓 Max ,传统 jQuery 党就默默看着
|
21
kikyous 2016-08-17 08:43:43 +08:00
rails 开发够简单
|
22
zxb 2016-08-17 09:00:01 +08:00 via Android
这些框图都太复杂了。搞什么 MVC ,搞什么 EJB ?
想想 20 年前,是这样的: httpd --> xxx.cgi 够简单了吧?不依赖 MVC ,我们还能优雅的写代码吗? |
23
9 2016-08-17 09:18:46 +08:00 1
@liudanning 话虽如此,但是这个万金油回答说了等于没说哦,抛观点,引讨论还是好事
|
24
FrankFang128 OP @ecloud 当时是时机不对。而且 Turbolonks 也有相应的优化
|
25
FrankFang128 OP @tomatoo 单单前端那块不复杂,不就是个类 MVC 结构,但是前后加一起就复杂了。
|
26
zhouzhe8013 2016-08-17 10:02:24 +08:00
写的挺好,大公司之所以采用复杂的结构,还是因为
1 分工足够细致 2 极致需求 3 足够长的架构演进过程 要是小公司或者小产品一开始就弄得很复杂,那肯定是个灾难. |
27
panlilu 2016-08-17 10:10:29 +08:00
所以全栈应该用 rails
|
28
FrankFang128 OP @zhouzhe8013 大公司是因为分工细才使用这种框架,因果正好是反的,先分工,再找框架。
|
29
FrankFang128 OP @panlilu Turbolinks 已经不只支持 Rails 了。用其它后端框架也可以。
|
30
ichou 2016-08-17 10:19:15 +08:00 via iPhone
Turbolinks 还是要赞的
但是在非 rails 的圈子里,似乎还不太知名 |
31
huybery 2016-08-17 10:19:27 +08:00
招聘需求呢..
|
32
scys 2016-08-17 10:31:51 +08:00
业务决定技术方向: D 。
不过前端近几年突发的概念是多了,虽然到了最后还是 DOM DOM DOM |
33
YuJianrong 2016-08-17 10:37:11 +08:00 1
简而言之就是一句话:做个小网站架构不要太复杂。
TM 简直废话。 另一句话,做大系统必须要复杂但清晰、耦合度低的架构,就被标题“ Web 开发不应该这么复杂”吃掉了。 拜托 Web 开发不仅仅是做个 2 , 3 个人日工作量的小网站好不好! |
34
est 2016-08-17 10:40:31 +08:00
彩程强行广告啊。 tower 的移动段体验非常差。
|
35
Ellen 2016-08-17 10:42:11 +08:00
哇, tower 的工程师,远程开发好向往。
|
36
awanabe 2016-08-17 10:57:51 +08:00
楼主从阿里跳到 Tower 去了?
|
37
Dreawer 2016-08-17 11:04:11 +08:00
学习阶段,个人建站,前端领域问题可以一起交流讨论! http://www.dreawer.com/
|
38
FrankFang128 OP @YuJianrong 本文说的是大网站, 200 个设计图,历时 18 个月,部署都五个平台。
|
39
scott1743 2016-08-17 11:10:05 +08:00
原来是彩程大大,膜拜。早在几年前 Simditor 还没有图片上传的接口文档的时候,我还研究源码写了 Rails 的封装 gem ,结果下个版本就出了完整的接口和文档。
另外说观点,和上篇一样,完全赞同。 |
40
FrankFang128 OP @scott1743 那不是我写的,是带我的人写的。
|
41
herozzm 2016-08-17 11:16:23 +08:00
我赞成, mvc 取得了很好的平衡
|
42
FrankFang128 OP @tomatoo 你说的优点都对,但是缺点我受不了。利大于弊还是弊大于利,就看团队结构和产品结构了。一般情况,我倾向于不要使用客户端渲染。特殊情况可以用。
|
43
kshift 2016-08-17 11:21:05 +08:00
不怕,想前后端分离的来做 Tower ,我现在移动版是 Vue + Rails API
|
44
bdbai 2016-08-17 11:23:41 +08:00 via Android
前端渲染你们团队不用就不用,还让全世界都不用?没摸清门道怪“复杂度暴涨”,那生产机器上的操作系统,你们全部掌握了?
看到楼主就知道他要说什么了。简直就像传教士。 |
45
FrankFang128 OP @kshift 我 append 了~
|
46
FrankFang128 OP @bdbai React 能传教, Vue 能传教,我就不能传教? 呵呵
|
47
kshift 2016-08-17 11:30:21 +08:00
@FrankFang128 哈哈哈, Tower 之前的移动版我就用的是 Turbolinks ,主站是自己写的一套 pjax 框架。
|
48
FrankFang128 OP @bdbai 有本事写文章说你自己的观点,而不是像这样避开观点谈我本人是不是传教士。
|
49
tomatoo 2016-08-17 11:36:20 +08:00
@FrankFang128 给你了模块化,组件化,爽的飞起的 ES6 , webpack 的各种好用的 loader 并且是傻瓜式配置,方便的前端测试,文件动静分离方便 CDN 加速,这些好用的东西还不够吗,那请问你说的缺点是什么缺点呢?
Tower 我也关注过,你们的产品很赞。 |
50
FrankFang128 OP @tomatoo 没有 SEO 支持,首页渲染很慢。
而且动静分离、模块化、组件化、 ES6 、前端测试都可以单独做,并不是前端框架带来的特性。 |
51
FrankFang128 OP @tomatoo 为什么前端在使用了前端框架后才开始模块化、组件化、 ES6 ?可以参考我之前对前后分离动机的腹黑推测:因为前端开发者对这些东西没有控制力和话语权。你让后端打包的时候加个 babel ,后端才不愿意承担风险呢!
|
52
FrankFang128 OP @tomatoo 前端只好说,好吧,你们后端不帮忙,我就全用 JS 做。
就是这样,起码我见到的一些大团队是这样的。 |
53
tomatoo 2016-08-17 11:42:43 +08:00
@FrankFang128 你当然可以自己做啊,自己写一套东西给团队使用,我也这么干过,但是这不还是一个框架吗?我主要说的点不是前端框架,而是前后端分离的开发思路(不是人员分工,而是技术上的分离)。
|
54
bdbai 2016-08-17 11:42:51 +08:00 via Android
@FrankFang128 现在似乎很少见 React 跟 Vue 传教的。
我的观点?具体问题具体分析。两种方案都有利弊,看需求咯。目前看来抛弃哪一种都是不可取的。 |
55
lcc4376 2016-08-17 11:55:57 +08:00
前端奇技淫巧太多,我是覺得所有後端都應該朝全棧發展
|
56
zztt168 2016-08-17 12:03:46 +08:00 via iPhone
认真看完了,很好的反思。康维定律很深刻,我觉得可以用到很多管理领域。感谢楼主。
|
57
quiz 2016-08-17 12:20:58 +08:00 3
真正想做前端的同学来我们公司吧,数据可视化驱动,抽象高智商业务超复杂交互,真正前后端分离!
后端渲染的同学就不要想了。。。还是去那些就简单做做 CRUD 的“用世界上最好语言和框架”的公司吧 = = http://www.lagou.com/jobs/1741791.html?source=pl&i=pl-2 职位描述: 1 、负责前端效果的实现,将设计师提供的设计图转换成静态页面,并实现各类页面动态效果; 2 、与设计师、开发人员配合,根据需求调整、修改、优化页面; 3 、解决网站页面浏览器的兼容问题; 4 、其他上级分派的工作。 岗位要求: 1 、 2 年以上相关经验,计算机科学与技术相关专业专科以上学历; 2 、熟悉 JQuery 、 Bootstrap 或类似开发框架; 3 、精通 HTML5+CSS3 ,熟悉 DIV+CSS 页面布局,能手写样式代码; 4 、能使用 JavaScript 开发产品及制作交互原型优先; 5 、熟悉 AngularJS 、 ElasticSearch 优先; 6 、了解 Linux 系统; 7 、有团队合作意识。 |
58
kamikat 2016-08-17 12:43:14 +08:00
对对对,你说的很对。某一天产品经理说我们要写原生 Android 客户端和 iOS 客户端…
|
60
tflz514 2016-08-17 13:17:52 +08:00
@FrankFang128 请问流程图是用什么工具画的?
|
61
quiz 2016-08-17 13:33:17 +08:00
@pepsin D3 可以过来学习,没关系,只要对浏览器 前端技术比较熟悉,学习起来还是很快的。有些可视化我们都是自己写的不一定非要依赖 D3 , D3 依赖 SVG 渲染,在大规模数据场景下会有性能瓶颈。
|
62
ecloud 2016-08-17 14:00:15 +08:00
@zxb 我做的某天文工控系统就差不多是这样的, web 界面的 php 就是个幌子,直接 passthru 调 C (你没看错就是 ANSI C )写的实际控制程序。
只有两段 JS ,一个用来显示动态曲线图,一个用来显示图片缩放。 因为这个系统要求的基本上是实时响应,去你娘的 web 渲染,哪有那闲情逸致。 不过说实话这样写的代码真的非常简洁清晰,很容易看懂,维护起来很方便,加个新功能也就半个小时(算上测试)的事情完事儿了。 |
63
ecloud 2016-08-17 14:12:47 +08:00
@YuJianrong 跟大小无关,关键看需求
IBM 以前的 CM 就是很低耦合的系统,也算是很复杂的东西了,但是 web 前端基本等于没有 然后一些客户就抱怨说你们的 web 太烂了,能不能给我们一个好看的界面 然后 IBM 收购了 FileNet ,用 FileNet 那套花哨的前端架在自己的后端 CM 上 结果是花了很多很多钱,人力物力。然后那帮客户后来又发现,在这个前端上他们要做二次开发可就迷糊了,又想退回去了 其实很多时候那些用户们并不知道他们究竟想要什么东西,这就是为什么 Jobs 能成功的秘诀 |
64
FrankFang128 OP @tflz514 他手画的
|
65
akira 2016-08-17 15:03:10 +08:00
看了下视频,其实就是在宣传 turbolink 的炫酷叼炸天
|
66
YuJianrong 2016-08-17 21:01:46 +08:00
@ecloud 这是产品要背锅的。如果有大量二次开发的需求,那么在第一时间就要考虑到二次开发怎么做,甚至把自己团队降低到第三方一样的高度来先搞好二次开发框架(其实也没有二次开发框架了,就是一样的开发)。
但这难度太大了,以 KPI 论的大商务软件公司真的很难搞(比如我司)。 |
68
ecloud 2016-08-17 21:18:58 +08:00 via iPhone
@YuJianrong 产品背锅?收购 FileNet 这么大的事情产品哪背得起这锅!大公司有些行为并不完全是简单的跟软件开发那套逻辑相关,还有很多七七八八匪夷所思的逻辑。所以小公司跟着学样会死得很惨。
比如,刚收购 FileNet 的时候,我发现他们的人工作态度比 IBM 的自己人好太多,然后唠叨给美国的架构师,结果那厮说, This is just what we wanted to pay for. |
69
quiz 2016-08-17 21:52:50 +08:00 via iPad
@Geeker 就是产品设计,技术选型,还有架构设计都是围绕数据可视化来做的,以把有价值的数据以最直观的方式展现给用户为目标驱动研发。语言是写的太精简了,主要怕影响大家灌水。本以为做过成熟商业软件开发的 v 友们都能 get 到 point ,实在不能理解的估计是经验还有看问题的思维比较不一样,不过可以一起探讨。跟檀木网站上比可能用语方式是不太一样可 v 站是专业技术社区,想必说的缩略点大多数专业极客 v 友们还是可以理解的,如果实在理解不能可以到漫展上约我当面切磋- -!
|
70
YuJianrong 2016-08-17 22:16:06 +08:00 1
@ecloud 我说产品背锅不是说背收购前端技术公司这种锅,而是对自己产品定义上的锅。不管收购了什么前端技术公司,只要能清晰定义出以扩展性为第一优先,所有技术都围绕如何方便和安全地扩展来开发,也能达到满足第三方扩展的需求。
只是这对于大公司来说太难了。 比如我司,也和 IBM 差不多,部门结构庞杂,部门做事主要要 show 给老板看,老板做事主要要 show 给更大的老板看,结果最容易受重视的就是看起来好看的东西(不仅仅是指视觉上),至于扩展性啦什么的,总以为以后慢慢加……但架构都定死了加什么加…… 这么说来也不是产品这个职务的锅,主要还是回到产品原始定义上去,本来就定义成好看但不易扩展的产品,那自然就很难做出方便二次开发的产品。然而不幸的是,一般原始定义产品的时候,大佬们都只想着花三分钱办五分事,尽快把东西弄出来(毕竟人家的 KPI 是这个),而不是为以后真的推向市场的时候的扩展性来花十分功夫打基础。 |
72
jadecoder 2016-08-18 01:18:39 +08:00
很好,第一次听说康威定律,值得深思
|
73
genffy 2016-08-18 01:21:25 +08:00
哎,天天扯这些没用的。
|
74
loser 2016-08-18 02:37:53 +08:00
tower / 知人 用户路过帮顶
选择适合自己的即可,没必要争论 over |
75
tomatoo 2016-08-18 08:25:02 +08:00
Tower 用的是 Vue + API 模式吗?
为啥打开控制台没看到 vue ,是我打开的姿势不对吗? |
77
daysv 2016-08-18 10:28:14 +08:00
虽然我是前端(写 exe 的前端 XD ),其实我也觉得前端炒作过热了, 感觉市场真正需求的还是全栈。
但是全栈技术栈比较杂,很难互相匹配。 |
78
tomatoo 2016-08-18 13:20:02 +08:00
@daysv @FrankFang128 这样比较难招人吧 你让一个写后端的去做前端的事情,做出来的用户体验一般比较差的(前端不只是完成逻辑,更要重视用户体验),或者开发周期长,同样你让一个前端熟手去写后端,也会遇到各种性能问题,尤其是数据量大的情况下,这些都是我真实遇到过的。这个问题怎么解决呢?毕竟称得上 web 全栈的还是太少了。
|
80
FrankFang128 OP @ihuguowei simditor 吗? 不是有人理吗
|
81
ihuguowei 2016-08-18 17:17:35 +08:00
@FrankFang128 https://github.com/mycolorway/simditor/tree/master 最后提交已经很久了啊 一个月前 master 分支。
|
82
unlitechc 2016-08-24 09:00:20 +08:00
这里是从后端到前端的破厂码农,该文说的一些问题当然是存在的。
看了您的几篇文章,觉得您说的很有道理,只是语气冲了点,而且标题似乎应该改成“我不是针对谁,盲目套用大厂架构的都是辣鸡” 23333333333333 |
83
ljbha007 2016-09-01 02:12:01 +08:00
但是如果把前端做得简单 导航、控制器这些逻辑都会移动到后端 逻辑是一样复杂 只是架构变简单了
|
84
xuzicn 2016-09-10 11:47:42 +08:00
看完了回复,楼主是想说“框架过于复杂”还是什么呢?事实上前端工程依赖的复杂度,主要不是由框架引入的,主要还是一堆 shim 、 babel 之类的,这可都是浏览器的锅啊。“无 JS 也能使用”的应用,体验肯定是个问题,这种由市场决定的选择,也是无可奈何的
|