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

13938 次点击
所在节点    JavaScript
84 条回复
herozzm
2016-08-17 11:16:23 +08:00
我赞成, mvc 取得了很好的平衡
FrankFang128
2016-08-17 11:19:22 +08:00
@tomatoo 你说的优点都对,但是缺点我受不了。利大于弊还是弊大于利,就看团队结构和产品结构了。一般情况,我倾向于不要使用客户端渲染。特殊情况可以用。
kshift
2016-08-17 11:21:05 +08:00
不怕,想前后端分离的来做 Tower ,我现在移动版是 Vue + Rails API
bdbai
2016-08-17 11:23:41 +08:00
前端渲染你们团队不用就不用,还让全世界都不用?没摸清门道怪“复杂度暴涨”,那生产机器上的操作系统,你们全部掌握了?
看到楼主就知道他要说什么了。简直就像传教士。
FrankFang128
2016-08-17 11:25:07 +08:00
@kshift 我 append 了~
FrankFang128
2016-08-17 11:26:00 +08:00
@bdbai React 能传教, Vue 能传教,我就不能传教? 呵呵
kshift
2016-08-17 11:30:21 +08:00
@FrankFang128 哈哈哈, Tower 之前的移动版我就用的是 Turbolinks ,主站是自己写的一套 pjax 框架。
FrankFang128
2016-08-17 11:30:34 +08:00
@bdbai 有本事写文章说你自己的观点,而不是像这样避开观点谈我本人是不是传教士。
tomatoo
2016-08-17 11:36:20 +08:00
@FrankFang128 给你了模块化,组件化,爽的飞起的 ES6 , webpack 的各种好用的 loader 并且是傻瓜式配置,方便的前端测试,文件动静分离方便 CDN 加速,这些好用的东西还不够吗,那请问你说的缺点是什么缺点呢?

Tower 我也关注过,你们的产品很赞。
FrankFang128
2016-08-17 11:38:39 +08:00
@tomatoo 没有 SEO 支持,首页渲染很慢。
而且动静分离、模块化、组件化、 ES6 、前端测试都可以单独做,并不是前端框架带来的特性。
FrankFang128
2016-08-17 11:41:14 +08:00
@tomatoo 为什么前端在使用了前端框架后才开始模块化、组件化、 ES6 ?可以参考我之前对前后分离动机的腹黑推测:因为前端开发者对这些东西没有控制力和话语权。你让后端打包的时候加个 babel ,后端才不愿意承担风险呢!
FrankFang128
2016-08-17 11:42:35 +08:00
@tomatoo 前端只好说,好吧,你们后端不帮忙,我就全用 JS 做。
就是这样,起码我见到的一些大团队是这样的。
tomatoo
2016-08-17 11:42:43 +08:00
@FrankFang128 你当然可以自己做啊,自己写一套东西给团队使用,我也这么干过,但是这不还是一个框架吗?我主要说的点不是前端框架,而是前后端分离的开发思路(不是人员分工,而是技术上的分离)。
bdbai
2016-08-17 11:42:51 +08:00
@FrankFang128 现在似乎很少见 React 跟 Vue 传教的。
我的观点?具体问题具体分析。两种方案都有利弊,看需求咯。目前看来抛弃哪一种都是不可取的。
lcc4376
2016-08-17 11:55:57 +08:00
前端奇技淫巧太多,我是覺得所有後端都應該朝全棧發展
zztt168
2016-08-17 12:03:46 +08:00
认真看完了,很好的反思。康维定律很深刻,我觉得可以用到很多管理领域。感谢楼主。
quiz
2016-08-17 12:20:58 +08:00
真正想做前端的同学来我们公司吧,数据可视化驱动,抽象高智商业务超复杂交互,真正前后端分离!
后端渲染的同学就不要想了。。。还是去那些就简单做做 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 、有团队合作意识。
kamikat
2016-08-17 12:43:14 +08:00
对对对,你说的很对。某一天产品经理说我们要写原生 Android 客户端和 iOS 客户端…
pepsin
2016-08-17 13:14:39 +08:00
@quiz 连个熟悉 D3 都不要求讲啥数据可视化啊
tflz514
2016-08-17 13:17:52 +08:00
@FrankFang128 请问流程图是用什么工具画的?

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

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

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

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

© 2021 V2EX