Choosing the web's future

出处:TechDays 2016 The Netherlands - Choosing the web’s future (by Peter-Paul Koch)
录影:https://channel9.msdn.com/Events/TechDays/Techdays-2016-The-Netherlands/Choosing-the-webs-future
幻灯片:http://quirksmode.org/presentations/Spring2017/goingwrong_vanlanschot.pdf
翻译及整理:dreamana.com

四个问题

  1. Web 开发者想模拟原生应用,我个人认为是这不可能的
  2. 这导致浏览器制造商添加越来越多的功能
  3. 而且,我们获得越来越多的工具没有完全解决一个问题反而成了一个问题
  4. 刚接触 Web 的人们常常会认为 Web 只是一个平台

1、模拟原生应用

在此之前

在 2006 年到 2008 年,一些成功的模拟原生桌面应用的网页应用被构建出来了。
最典型的例子是 Google Docs 顶替了 Microsoft Office。
质量可以说是 (足够) 好了,因此可以当成是 Web 的一个胜利。

在此之后

这些成功之后,Web 开发者认为它们也能做得比原生移动应用好。
这,一般来说,事实证明不是那么一回事。
但我们的 Web 开发的功能优先级及一般方向仍然指向更复杂的应用。

不可能

从技术角度解释,很简单。

原生应用 (Native Apps) 直接与操作系统 (OS) 通信。
Web 应用 (Web Apps) 与浏览器 (Browser) 通信,而浏览器是 (Browser) 与操作系统 (OS) 通讯的。
因此 Web 应用总是比原生应用慢一点儿和粗糙一点。

Web 变得像原生一样好是不可能的。

当然,Web 是在原生功能提升了性能很多以后才去引入原生功能的。

赶上原生要在 … 两年内?我不知道。

但那些时间,原生也会进化,所以我们仍然落后。

结果

“因劫持了滚动条你破坏了基本可用性。你本可以快速有效地采用原生功能(滚动、选择、链接、加载),但你用“尖端的” Javascript 工具集和框架重写了它们,致使它们缓慢、buggy 甚至坏掉。你用好几 MB 的烂代码吹涨一个网站。你忽略了最佳实践。你让一些东西运作起来了,补充了你的业务,且变成了一件棘手事情。”

摘自 Baldur Bjarnason 的 Facebook and the media: united, they attack the web

等一下 …

我在说所有都是尝试去模拟原生应用的错吗?

不全是,虽然这扮演了主要角色。这是让东西做的更复杂的思维倾向,这才是我想反对的。

与此同时,前端们貌似不再去了解浏览器了。而了解浏览器才是一名前端人员的定义。


2、过多的功能

请列举所有在 2016 年里浏览器添加了的功能 懂了吗?你做不到!

功能

我认为浏览器实现了太多的功能了。

虽然很巧妙。

没有一个单独的功能我是反对的。大多数单独功能都是个好主意,而且它们解决了一些问题 (issue)。

问题是,功能太

Polyfills

新功能通常在多数 (大多数 ?) 浏览器上不支持。

因此我们添加另一个 polyfill。真聪明!

除了再一次增加我们工具足迹之外 ——甚至没有更好的原因。你真的 需要那些新功能吗?

而且,这让 Web 开发者更懒惰。我们不强迫它们自己写?比起只拷贝代码这些会教会它们很多。

软件市场成熟度

用户 = Web 开发者,而不是访客!

  1. 技术焦点。专注于在它们能否运作的事实。
  2. 功能焦点。专注于用户需要的新功能。
  3. 体验焦点。专注于用户的整体体验。

by Jared Spool

我们在功能焦点阶段上卡住太久了。

我想说是时候转移到体验焦点的舞台上。

我想说我们想提升制作网站的整体体验。

这意味着什么?我没有头绪。

延缓期

这就是我为什么要提出浏览器功能增加需要缓期一年多。

在这些期间,浏览应该不去实现新功能。

然而,浏览器允许复制其他浏览器已经支持了的功能以及修复 bug

于此同时开发者可以学习之前的功能集合

阻碍创新

延缓期会不会阻碍 Web 的创新呢?

对的,会。

实际上,这就是关键所在。自从 Web 创新被定义为“让 Web 变得更像 App 一点” 这会导致沉闷。直到我们在这所有问题上再多一点点思考。


3、过多的工具

速度

目前 Web 有一个速度的问题,尤其在移动端上。

广告上问题的一部分。更准确地说,不单是广告本身,它们关联的代码更是个问题。

另一方面的问题是我们所用的工具。我们用得太多了。

The Cost of Mobile Ads on 50 News Websites

工具

This is INSANE 这简直疯了

感谢 Jose Aguinaga 的 How it feels to learn JavaScript in 2016

We have the best libraries! Our libraries are huuuuge! (by Jose Aguinaga) 我们有最好的代码库!我们的库巨巨巨巨大!

为何如此多 ?

我认为之所以用这么多工具是因为我们想展示 Web App 开发是一件严肃 的事情

严肃的开发者 采用长长的工具链

但这些运行在一个服务器上的长长的工具链不仅限于 Web 上,我们强迫所有用户去运行它们,甚至在一个蹩脚的手机上

剖析代码库运用

  1. 浏览器需要下载代码库。这不是一个问题,作者们都知道这点很多年了。
  2. 然后代码库是需要初始化的。这通常被遗忘。
  3. 然后代码库可能需要解析 DOM
  4. 现在代码库就绪,等待用户输入 ——这可能引起一次又一次的操作损耗,但这是我们已知的。

代码库初始化

拿一个 Android 手机去测量它的电池电量消耗。
加载一个移动端版的 Wikipedia 页面。它用了 jQuery 去显示/隐藏代码。
然后用 5 行自定义代码替换掉 jQuery
节省了 30% 电量 30%! 只是一个你不需要的代码库 !

参考 Who Killed My Battery: Analyzing Mobile Browser Energy Consumption

代码库 DOM 解析

<span id="complexId1">{{item.name}}</span>
{{item.value}}<br>
{{item.price}}
<span id="itemName">Placeholder</span>
<span data-value="itemValue"></span><br>
<span class="itemPrice">Placeholder</span>

Modularization encourages over-design (by John Daggett) 模块化怂恿了过度设计

学习建议

“如有疑问,比起学习围绕 CSS 的一大堆工具,更有必要学习 CSS 本身。比起学习 React, Angular 或其它某段时期很热门的库,更有必要学习 JavaScript 本身

[…] 关注那些可以帮助你认识到这些工具和抽象的优势和局限性的核心”

摘自 The Fallacy of Keeping Up

真正的 JavaScript 人员

If you can’t do without tools you’re not a web developer 如果你不能离开工具来开发,你就不是一名 Web 开发者


4、The web platforms(复数)

Browsers are the most hostile development platforms in the world (by Douglas Crockford)
浏览器是世界上最恶劣的开发平台 (复数)

Browsers are the most hostile misunderstood development platforms in the world (by Douglas Crockford)
浏览器是世界上最 恶劣的 被误解的 开发平台 (复数)

Web 平台 (复数)

我觉得后端开发者低估了 Web 平台,乃至前端开发者。

因为他们误解了一个关键之处:

The web is not one platform. It is a multitude of platforms, most of which you’ll never test on. Web 不是一个平台。 它是一个多样的平台,其中大部分你从来没测试过。

解释 Web

你的应用

DRY

Web 开发

我们需要面对的事实是 Web 的软件开发不同于其他软件开发。

问题:Web 开发不属于计算机科学,但是属于设计。

因为真正的计算机科学家 不做 Web 的。仅会在业余时候做。

他们拒绝学习浏览器。而没有浏览器知识,你不能成为 Web 开发人员。


5、我们走错了

四个问题

  1. Web 开发者想模拟原生应用,我个人认为是这不可能的
  2. 这导致浏览器制造商添加越来越多的功能
  3. 而且,我们获得越来越多的工具没有完全解决一个问题反而成了一个问题
  4. 刚接触 Web 的人们常常会认为 Web 只是一个平台

Web 的优势

我们来定位一下我们的增加功能倾向。

这并不意味放弃所有工具和功能。

取而代之,这意味着考虑每个单独的工具和功能如何进一步提高 Web 的核心优势: