Web 开发不应该这么复杂

2016-08-17 03:18:42 +08:00
 FrankFang128
除了 React / Vue ,你还应该看看其他开发模式

原视频

本文作者:方应杭(微信: frank_fang )

本文很长,但请耐心看完,因为末尾有广告。。。

这个视频来自 RailsConf 2016 ,演讲者是 Sam Stephenson ,他主要的开源作品有 rbenvPowTrix,曾是 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 。

但是呢,有两个问题:

  1. 所以这些 JS 代码和 API 请求,让首页渲染,非常非常非常慢。
  2. 所有内容,都无法被搜索引擎检索到。

(没事,再加功能)

⬆️ 所以我们决定不用浏览器来渲染首屏了,让服务器来(回到老路子)。但是由于渲染逻辑我们不想做两遍,所以我们需要在服务器添加一个 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

13901 次点击
所在节点    JavaScript
84 条回复
dcoder
2016-08-17 03:51:17 +08:00
@FrankFang128
"这样的模式渲染一个页面大概 300ms" "也许再加点优化可以做到 1s 左右"
1s == 1000ms > 300ms 不是更慢吗?
shoaly
2016-08-17 04:01:03 +08:00
写的很好, 楼主的表达能力 以及想要表达的内容我都觉得不错
shoaly
2016-08-17 04:02:40 +08:00
@dcoder loading 我理解指的是 网速加载, 渲染我感觉是加载之后 webview 处理的时间? 期待楼主正解
FrankFang128
2016-08-17 04:06:14 +08:00
@dcoder web 300ms , iOS 1s ,不一样的平台
czheo
2016-08-17 04:10:37 +08:00
前排观看 lz 又来挖大坑。
czheo
2016-08-17 04:44:20 +08:00
1. 其实我观察到的历史不是因为后端渲染不够快,而是因为前端需求开始复杂到需要写 modular js 才出现的前端框架。
2. 无法被搜索引擎检索,在 virtual dom 出现以前,前端框架普及之初已成问题。
3. Turbolinks 的作者当然支持 webview ,而现实是市场更愿意选择性能优秀效果酷炫的 native app 。
peneazy
2016-08-17 06:08:04 +08:00
已经感觉到前端的复杂了,入职三个月,依然没有完全搞明白公司的整个前端框架,可能自己是前端新人的缘故吧。
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 ”.
好吧,学习了。
markx
2016-08-17 06:21:27 +08:00
看完全文了。
我很喜欢文中那些结构图,很清楚。
虽然是广告,但是我心里很赞同。如果用简单的工具能把事情搞定,就真的没必要搞复杂了。也许用各种高级工具各种抽象会更利于扩展,但现在的 web ,两三年工具就更新换代了,所以扩展说不定还不如重新写了。
ecloud
2016-08-17 07:00:10 +08:00
在手机平台上用 HTML 假冒一个本地应用的做法不是这两年才有的
之前那些基本都死得很惨
剩下一俩没死的都改成本地应用了
eriale
2016-08-17 07:03:48 +08:00
赞!前后端细粒度分离,应该是产品 /部门大到一定程度的结果。
楼主有没有考虑过产品 /用户规模大到什么程度时,才需要把前后端拆成这么细? 1000w 用户?或更多?
loading
2016-08-17 07:16:24 +08:00
期待楼主很多的好文翻译。
tomatoo
2016-08-17 07:30:44 +08:00
说几点:

- 并不是所有的网站都有 SEO 需求;
- SAAS 应用的前端一般比较复杂,如果还是按照 jquery 的组织方式来搞的话维护起来太麻烦了;
- 我并不觉得 Google 提出的 angular , Facebook 提出的 react 会让整个应用的结构变得复杂,相反的使用框架可以帮助我们写出更加低耦合,模块化,组件化的代码,同时数据与 DOM 的分离也让前端的单元测试更加方便。

(之前是前端开发,现在做 rails 开发,一点感受)
metrue
2016-08-17 08:20:05 +08:00
其实 Rails 支持了 API 模式,在某种程度已经表明 Rails 社区也同样认为前后端分离是合理的。
mdluo
2016-08-17 08:27:25 +08:00
@kshift 你们现在打广告都靠引战了吗 2333
mdluo
2016-08-17 08:28:09 +08:00
简单点,招人的方式再简单点
sfree2005
2016-08-17 08:36:12 +08:00
同意 @tomatoo 我觉得原视频的主要思想还是说包装 web view 到移动端一种新的方式。 如果服务器渲染出来的页面没有很复杂的交互逻辑,这的确够用了。有的话还是要写复杂的 JavaScript ,这时候前后端分离,工程化和组件化就很有必要了。前端框架 Angular 之类是将复杂的交互逻辑变得更容易实现,所以最终还是需求决定工具。
shyling
2016-08-17 08:37:27 +08:00
一直不觉得前后端分离和规模大小有关。。。而且和性质有关。
想想当年, you are not google ,所以你不配像 gmail 那样使用 ajax 。是不是呢?

另外为什么要执着于 virtualdom 了,那只是实现的途径而已。说起来既然用了 rails 还大谈性能问题....各种 coc 不管是在后端还是在前端都是为了更'无脑化'的写代码吧
liudanning
2016-08-17 08:38:21 +08:00
唉,就是一句简单的具体问题具体分析
cenxun
2016-08-17 08:38:56 +08:00
套路精髓 Max ,传统 jQuery 党就默默看着

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/299785

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX