【大咖分享】AI 大模型时代,架构师有哪些机遇和挑战? 了解详情
写点什么

关于 HTML5 特性的一些限制与讨论

  • 2012-01-05
  • 本文字数:0 字

    阅读完需:约 1 分钟

HTML5 已经成为 2011 年度技术社区最热门的词汇之一,逐渐从理论走向实践,并得到了社区的广泛认可,在强大特性的背后,HTML5 也面临一些限制,最近引起了社区的讨论。

InfoWorld 网站最近发布了一篇文章《关于HTML5 的11 个让人难以接受的事实》,作者Peter Wayner 指出:尽管HTML5 确实有很强大的功能,但它并不能解决所有问题,一些功能是非常强大的,能让Web 应用成为原生应用的强有力对手,但是安全问题、本地数据存储的限制、同步以及“争权夺利”等问题都会让我们降低对它的期望。

对于此篇文章,HTML5 研究小组成员秀野堂主在《我这一年所了解的HTML5 》一文(以下简称“观点”)中专门对这11 个问题分别作了分析和讨论,我们不妨将两篇文章的观点对比一下,对于HTML5 技术圈里的开发人员会有所启发。

问题 1:安全是一场噩梦

……在 Web 应用中,当浏览器拥有一个很强大的调试工具的时候,这种控制权比以往更容易被滥用。当在浏览器中集成了一个 Javascript 的调试器比如 Firebug,任何对 Facebook、Google 以及其他网站感兴趣的人​都可以插入断点来查看代码。这对于了解网站是如何运行的是非常有利的,但对于安全问题来说却是一场噩梦。想象有个变量的值是你想要改变的,Firebug 或者其他一个浏览器调试器可以让你很容易地将数据改成你想要的任何数据。你想要通过改变自己的地理位置来捉弄一下你的朋友吗?那么可以修改浏览器中的经度和纬度值,让浏览器“处于”世界上的任何位置。很多配置属性都可以被修改,浏览器使得这样的修改比在本地应用中更为容易。 对于引发的安全问题,也是有些限制的。一些 Javascript 工具比如 Google Web Toolkit 和标准的编译器一样复杂,它们的输出令人费解。但是一些工具比如 JavaScript Deminifier 能解决这个问题。 威胁当然也跟应用性质有关。一个人通过改变浏览器上显示的经纬度来和朋友开玩笑说在环游世界的途中是一回事,而获得其他人的权限又是另外一回事了,这会带来威胁。一旦涉及到金钱,情况会更糟糕……

观点:

安全问题是全面存在的,不仅仅是断点调试和变量。不过,好像到目前为止,大家都有安全问题,没有谁是绝对安全的。因此,在一些不是很重视安全的项目上,安全问题可以降级。这完全由架构师来思考和决定。

问题 2:本地数据存储存在限制

浏览器中隐藏的本地数据库让 Web 应用更容易在电脑上缓存数据。对任何一个在浏览器中享受这​种台式机体验的人来说,这些数据库可以节省带宽,提升性能。然而它们肯定比不上本地应用的数据的强大功能。HTML5 的数据存储能力毫无疑问是很重要的功能,但是你仍然不能将存储的数据迁移到另外一台机器上,或是制作副本、备份、用另外一个应用打开。所有这些数据都是隐藏在浏览器之下的。某种程度上说,这是最糟糕的一种情况。因为你要承担存储这些数据库的所有责任而不能对它有任何控制。 一些最新的浏览器可以让你看到在你的机器上创建了哪些数据库,但这些信息是有限的。Safari 甚至可以让你能够删除数据库,但是你不能浏览这些信息或是将它们迁移到另外一台机器上,这些文件在设计之初就没有让它能够很容易迁移。你同样不能深入到文件中看到底存储了什么。当然,一个程序员可以看懂这些文件,但前提是他们研究清楚了文件格式并且做一些 hacking…..

观点:

本地数据存储是有限制的,确实是,但是在不同的浏览器上,限制是不一样的。因此架构师应该以支持最好的浏览器(ios 上就是 safari,android 上目前就是欧朋最新版)为准,推荐你的用户去使用最好的软件,而不是兼容那些垃圾软件……因此,我的个人建议是:不要让自己的作品去适应当前的、一定会消失的问题,追求卓越,推荐卓越完全是应有的使命。在移动浏览器端,safari 的表现就可能是最好的,存储可能也是最大的。(当然,鉴于行业的剧烈变化,这一切是会变的)

问题 3:本地数据可以被操纵

用户可能并不拥有对数据的控制权,但是网站同样也被限制不能处理用户数据。用户换浏览器了?用户换机器了?很多 Web 开发者对此都无能为力。因为同步问题,他们不能让用户创建更多数据。Web 开发者也需要担心本地数据库的安全。尽管没有工具可以让用户可以很容易修改本地数据并升级权限,但服务器同样也没有能力去阻止用户做到。所有因为运行用户修改 Javascript 代码的安全漏洞同样会影响数据库。

观点:

本地数据可以被操纵。这是一个老调重弹的问题,即:跨域问题。这已经是大家都很清楚,而且都已经解决的问题了,再说就没有意思了。你可以去下载最新的各种浏览器,为了跨域问题,整个 html5 标准中的重要 api 几乎都翻新了一遍。以致于微软抓着这个问题让 webGL、websocket、webWorker 都推迟了出来。

问题 4:离线数据对同步是一场噩梦

​HTML5 的本地数据存储极大提升了离线使用 Web 应用的能力。唯一的问题是数据同步。 如果一个 Web 应用连接到网络上,它可以持续地将数据存储到云中去。而当应用离线时,应用中发生的数据就不能存储到云中。如果一个人切换了浏览器或者使用了不同的机器,就会出现副本,这时同步就会成为一个大问题。更糟糕的是,时钟本身就可能是不同步的,使得检查最新被保存的数据是不现实的。 当然,这对本地应用来说也一直都是一个问题,但是在本地应用中,为同步负责的是人,他可以通过查看文件名并改变日期来进行同步。但是因为 HTML5 并没有给用户对隐藏在浏览器之下的数据库的控制权,开发者必须提供用户界面让用户通过这个界面来管理同步问题。 这并非是一个完全棘手的问题。开发人员可以通过使用版本控制系统来处理这个问题,而现今的版本控制系统在处理这些问题上已经变得越发复杂了。

观点:

离线对同步是一场噩梦。这话一点不假,确实,我们在做 applicationCache 时,都满怀心喜,结果碰了一鼻子的灰。其实,我们还要警告开发者,在移动设备上,大多数的浏览器,都不能良好的支持,其原因也很简单,因为大多数浏览器厂商都还生活在狭窄宽带的时代。他们的产品设计都不足 2M。因此,在一段时间内,在移动设备上,不用 applicationCache 比用要妥当。但是在桌面浏览器上,用 applicationCache 是很好的选择,所谓的版本控制,可以随意些,用时间戳就是一个不错的选择。

问题 5:云端什么都没有向你承诺

为 HTML5 将数据存储在云端而带来的所有结构性的问题来责备 HTML5 实际上不是件很公平的事情,但云端是一个必要的部分,因为云省去了安装软件和备份数据的麻烦。由于 HTML5 本地数据存储的限制,大量 Web 应用存储仍然要保留在服务器端,但这可能是灾难性的。就在最近 Facebook 决定将不再使用一个基于 Linux 的插件来上传照片,结果,同样被去掉的是通过这个插件上传的照片。这样的例子比较少见,但是因为各种原因,它们正变得越来越多。你能确保那个免费提供他们的一切 HTML5 应用的新兴公司在几年后甚至几个月后还存在吗?你只能自求多福。情况还更糟糕。正如很多 Web 应用所明确说明的那样,这些数据并不是你的,在大数情形下,你不能诉诸法律来恢复数据。有些更离谱的服务条款甚至说数据可以“没有任何理由”就被删除。HTML5 没有避免这个问题,它的结构实际上是保证了任何由你的浏览器缓存的数据都会存储在云端,这些数据是脱离了你的控制的。HTML5 的炒作说这是它的一个优势特性,但这实际上却很容易造成不利影响。

观点:

关于云的问题,这似乎是一个云存储与本地存储的问题,与 HTML5 的关系不太大。相反,HTML5 如果与云服务器供应商结合起来,可以发挥较大的生产力。

问题 6:强制升级并非是每个人都想要的

有个故事,或许是杜撰的,说一个人使用 Gmail 账户和酒吧里认识的人保持着随意的联系。当 Google+ 出现以后,所有的历史记录都出现了,因为 Google+ 在论坛里自动连上了那些旧的地址。每天,这些旧名字和旧面孔都会出现询问是否要加入到论坛中去。当 Web 应用公司需要升级的时候,他们会将所有人一次性升级。尽管这据说是为了让用户不再受升级安装文件之苦,但对于那些不想使用新特性的人来说,这确是一场噩梦。这不像上面是一个关于人们隐私的问题。新软件可能因为新旧软件包之间的依赖关系而经常崩溃。

​观点:

强制升级并非是每个人想要的,这点我是赞同的,但是这也不是技术问题,这是 web 与 native 的区别。引用的案例 g+ 不适合在这里讨论,但是我们可以看到,新浪微博就有较好的新旧版本控制,我就一直用的旧版本,不喜欢新版本,一直用的挺好。这完全取决于技术人员,不是技术和标准本身。

问题 7:Web Workers 并不会处理优先级

Web Workers 是 HTML5 的一个非常耐人寻味的特性。与其去使用 Javascript 传统的 wait、delay 和 pause 命令,现在 Web 开发者可以拆分他们的命令并且整合到 Web Workers 的 CPU hogs 中。换句话说,HTML5 Web 开发者可以让浏览器表现得像操作系统一样。但问题在于,Web Workers 并没有复制操作系统的所有特性。尽管它提供了一种方式来讲负载分支并分离,但是却没有方法来管理负载或是设置优先级。API 只是让消息传入或者传出 Worker 对象。这就是它做的一切了,剩下的都交给浏览器了。

​观点:

webWorker 的问题确实还会有一堆,从标准上看 webworker 还在进化期,与 serverEvent 相比,webworker 是另一种服务器端的通信,这种优先级的处理,完全是在开发者来决定的,这没什么问题。webWorker 肯定是不成熟的,还需要时间。但是作者所说的问题,可能是看了一眼标准后作出的臆想,可那已经不是问题了,webworker 的根本问题,现在是父子进程的通信和子子进程的通信问题。

问题 8:格式不兼容比比皆是

HTML5 引入了 <audio> 和 <video> 标签,第一眼看上去,它们和图像标签一样好用。只要在其中加入一个 URL,浏览器就会引入数据流。然而,如果它真有这么简单的话,为什么我浪费了两个星期来让所有主要的浏览器可以播放基本的音频文件呢?个别浏览器构建者只实现了部分而不是全部的音频视频格式确实不是 HTML5 委员会的错。大家都是人,都想要争夺统治权。往往在一个浏览器上工作正常的文件到了另外一个浏览器上却不能工作了。开发者要如何测试这一点呢?API 开发者非常聪明,他们加入了 canPlayType 函数,但就是这个函数也不是所有浏览器都支持的。

观点:

格式不兼容是真实的存在的。这完全是厂商之争和市场之争。不过没有关系,我们是这样看待问题的:目前能够支持好 html5 的浏览器本来就不多,因此,我们只需要迎合一部分人群即可。而那一部分人群用的设备就是主流……

问题 9:各浏览器的实现是独立的

HTML5 的田园诗般的愿景是一回事,其实现的蹩脚的现实是另一回事。诚然,程序员正在尽他们最大努力来实现架构师的梦想,但就是有一些标签和对象无法正常工作。例如,有很多理由去喜欢 HTML5 的地理定位 API。它提供了对隐私的一定程度的包含,对精确度也有控制。要是它能一直一贯地工作该有多好——有的浏览器就会总是超时,这个浏览器还是不太聪明,因为它应该知道台式机上是没有 GPS 芯片的。最后,人们会去抱怨浏览器没有完全实现 HTML5 的特性,而不是去责备 API 本身的结构问题。这一事实凸显了 Web 开发者在开发基于 HTML5 的 Web 应用时所面临的挑战。

观点:

这是肯定的。geolocation 在不同的浏览器上实现是不一样的。但是,浏览器是可以检测出设备是否支持 geolocation 的,返回了 false 就对了。这与 html5 标准也不是大关系。是设备问题。而摩尔定律和统计是:12 个月内,人们平均都换了手机了。

问题 10:硬件特质带来新的挑战

抱怨某些浏览器构建者超出了职责要求而提供更好的性能表现似乎也不公平,但这并非是恩将仇报。Microsoft 通过将 IE 和低端硬件驱动整合而提升了 IE 浏览器中画布对象(Canvas object)的性能。它甚至做了一些游戏比如 pirateslovedaisies.com 来显示其性能。​但现在程序员们需要注意这些附加功能是否能够实现,并且这些代码的运行速度也是无法保证的。例如,pirateslovedaisies.com 的游戏设计者设计了一个开关来开启或者关闭 IE 支持的特性。但是,有没有一个 API 来告诉你这些特性是什么呢?没有。最简单的方式是通过浏览器名字来进行测试并估算帧速率。很多游戏开发者都有多年经验来了解可用硬件的范围,唯一的解决方法就是禁止创新,但这将是 Web 开发者又要解决的一个新的问题。

​观点:

……这不用担心啊。windows phone 在中国不超过 10 万台。开发者的力量都集中在移动端,桌面端的进化受微软影响,但是在移动设备中。微软的影响是非常弱的。android 和 ios 两块里,做好一块,就是王了,何必管那么多?

问题 11:“争权夺利”一直都存在

有个叫 Ian Hickson 的人,是 HTML5 标准的主要起草者,也是最高独裁者(the Supreme Dictator for Life)。我想他们这是在开玩笑,因为这样的头衔实在太不匹配了。标准的编写者只是在提出建议,浏览器公司的编码天才们才是最终做出决定的人。他们可以选择实现或者不实现某个特性,然后 Web 开发者就要去测试结果是否稳定。几年以后,标准就会根据与实现程度的匹配情况做出改变。很多 Javascript 开发者将兼容性问题都留给了开发代码库的人,比如 jQuery。这些层让我们不必去了解不同浏览器之间的差别。但是,这些代码在将来是否足够健壮?只有时间才会知道。这个议题凸显了这个领域中最根本的问题。我们想要自由、创造性以及因为浏览器间的激烈竞争而产生的丰富特性。创新的脚步非常快,但是因为浏览器开发者都争相添加新的特性以赢得先机,使得各个浏览器之间有更多的不同。但我们希望能有一个统一的指挥者这样就能获得稳定性。但是,对于争斗,从来都没有一个理想的解决方式。

观点:

一个伟大的事业,总是会有跌跌撞撞的。在项目中,无论我如何大骂 HTML5 的缺点,都无法阻挡我对 HTML5 深深的期盼。所谓的技术(争权夺利),我们不予考虑……移动互联网已经有了很多泡沫,但是前景依然美好,那些正在创业的和已经创业的,请向移动互联网看齐,这个盘子很大,没有谁能一口吃下,快来吧……在这里,我想说一句:这个世界上从不缺少 CEO 和老板,只缺少真正能解决问题的人。

​有关 HTML5 的更多内容可以关注 InfoQ 中文站的 HTML5 板块

2012-01-05 22:034888
用户头像

发布了 501 篇内容, 共 240.6 次阅读, 收获喜欢 56 次。

关注

评论

发布
暂无评论
发现更多内容

瓴羊QuickBI数据门户帮助企业高效管理和展示数据,使其更加明确易懂

对不起该用户已成仙‖

11个适合后端程序员的前端框架

高端章鱼哥

程序员 工具 后端

不能不知道的LED显示屏产业机遇

Dylan

机遇 产业 LED显示屏 led显示屏厂家

火山引擎DataLeap数据质量解决方案和最佳实践(三):最佳实践

字节跳动数据平台

在 7 月 4 日,PoseiSwap 治理通证 $POSE 上线了 BNB Chain 上的头部

鳄鱼视界

构建云上和云下统一的安全方案,华为云致力为企业降本增效

平平无奇爱好科技

语音直播源码知识分享:探索新的沟通方式

山东布谷科技

软件开发 语音 源码搭建 直播源码 语音直播源码

2023年CCF-百度松果基金课题申报持续进行中,截至7月24日

飞桨PaddlePaddle

人工智能 百度 paddle 飞桨 百度飞桨

网络信息安全尤为重要,华为云如何为企业构建云上云下一体化安全方案?

平平无奇爱好科技

休闲类匹配竞技游戏公司为何需要华为云游戏云端部署方案?

平平无奇爱好科技

🔥年中技术盘点暨7月主题征文活动开始啦!

InfoQ写作社区官方

热门活动 年中技术盘点

利用小程序技术,构建数字警务体系

没有用户名丶

图+AI 生成未来|悦数图数据库亮相 2023 世界人工智能大会

悦数图数据库

AI 图数据库 大模型 AIGC

爽游做得好,游戏部署方案必不可少,华为云游戏云端部署方案愈发吃香了

平平无奇爱好科技

华为云函数工作流FunctionGraph新手操作指南

华为云PaaS服务小智

云计算 Serverless 华为云 华为开发者大会2023

货拉拉论文入选中国市场营销国际学术年会CMIC

科技热闻

prometheus描点原理

蓝胖子的编程梦

Docker 云原生 Grafana Prometheus #k8s

在 7 月 4 日,PoseiSwap 治理通证 $POSE 上线了 BNB Chain 上的头部

威廉META

华为云云上云下一体化安全,如何为企业打造统一、高效的安全管理平台

平平无奇爱好科技

MySQL的match函数在sp中使用的BUG解析

GreatSQL

数据库 greatsql

聆心智能上榜“北京市通用人工智能大模型行业应用典型场景案例”

硬科技星球

推荐书单:个人成长的一些方法

老张

个人成长 书单

全议程公布丨涌现中重塑,PingCAP 用户峰会 2023 邀你共同引领创新力量!

PingCAP

MySQL 数据库 TiDB pingCAP 平凯星辰

华为云游戏云端部署方案:如何为游戏厂商降本增效

平平无奇爱好科技

Python案例分析|井字棋(Tic Tac Toe)游戏 | 社区征文

TiAmo

Python 年中技术盘点 井字棋游戏

认知负担的挑战与平台工程的机遇

SEAL安全

DevOps 平台工程 认知负担

代码随想录训练营 Day07 - 哈希表(下)

jjn0703

云上办公时代,华为云桌面表现如何?

平平无奇爱好科技

​山东大学高校专区入驻飞桨AI Studio,优质教育资源等你来学!

飞桨PaddlePaddle

人工智能 百度 paddle 百度飞桨

华为云CodeArts IDE Online:让你随时随地畅享云端编码乐趣

华为云PaaS服务小智

云计算 软件开发 华为云 华为开发者大会2023

MatrixOne 0.8.0 开放公测啦!

MatrixOrigin

云原生 超融合 #数据库 MatrixOne

  • 扫码加入 InfoQ 开发者交流群
关于HTML5特性的一些限制与讨论_JavaScript_崔康_InfoQ精选文章