WEB 开发不应该这么复杂

  1. 云栖社区>
  2. 博客>
  3. 正文

WEB 开发不应该这么复杂

taotao9229 2016-09-20 11:20:58 浏览1444
展开阅读全文

 我们一共 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 渲染,由浏览器完成。

大家都觉得这主意不错,是吧?

  • 我们的应用总得需要 API 对吧。为啥不在应用内部也使用 API 对吧?
  • 而且还能让表现( presentatioin )与数据( data )解耦,解耦总是对的对吧?

 但是,前端们还是觉得客户端 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 左右)


via:北京网站建设

网友评论

登录后评论
0/500
评论
taotao9229
+ 关注