关于HTML5的11个让人难以接受的事实

 

HTML5Web开发者提供了很多强大的新特性,但是它的一些特定的限制会让它无法和本地应用匹敌。

HTML5整合进了很多新的特性,并且有可能提升Web编程模式。和每一个阅读技术资讯的人所知道的一样,没有任何一样东西能像HTML5对互联网造成更多改变。在代码中加入一些HTML5,网站会变得更快更炫。但是HTML5能为那些想要要网络上实现本地应用表现的人做什么可能不在此列了。

在享受了HTML5的新标签以及APIs之后,现在已经是时机来承认HTML5模式确实是有一些限制的。这些限制不但会让我们对HTML5的幻梦破灭,还有可能让我们在某些场合不再使用HTML5。

事实上是,尽管HTML5确实有很强大的功能,但它并不能解决所有问题。它的一些附加功能是非常强大的,能让Web apps成为native app的强有力的对手,但是安全问题、本地数据存储的限制、同步问题以及政治问题都会让我们减小对它的期望。毕竟,任何技术都是有其限制的。

下面是Web开发者需要接受的一些关于HTML5的事实。

事实1:安全是一场噩梦

客户端计算最根本的问题是用户最终拥有了对机器上运行的代码的控制权。在Web apps中,当浏览器拥有一个很强大的调试工具的时候,这种控制权比以往更容易被滥用。

当在浏览器中集成了一个Javascript的调试器比如Firebug,任何对Facebook、Google以及其他网站感兴趣的人都可以插入断点来查看代码。这对于了解网站是如何运行的是非常有利的,但对于安全问题来说却是一场噩梦。

想象有个变量的值是你想要改变的,Firebug或者其他一个浏览器调试器可以让你很容易地将数据改成你想要的任何数据。你想要通过改变你的地理位置来捉弄一下你的朋友吗?那么你可以修改浏览器中的进度和维度变量,让浏览器“处于”世界上的任何位置。所有你的Web应用的neat features都可以被修改,浏览器使得这样的修改比在本地应用中更为容易。

对于引发的安全问题,也是有些限制的。一些Javascript工具比如Google Web Toolkit和标准的编译器一样复杂,它们的输出是非常令人费解的。但是一些工具比如JavaScript Deminifier能解决这个问题。

威胁当然也跟应用性质有关。一个人通过改变浏览器上显示的经纬度来和朋友开玩笑说在环游世界的途中是一回事,而获得其他人的权限又是另外一回事了,这会带来威胁。一旦涉及到金钱,情况会更糟糕。所有这些都意味着基于客户端的HTML5是不能用来处理敏感数据的,每个人都应该对自己的能力加以警醒。

事实2:本地数据存储是有限制的

浏览器中隐藏的本地数据库让Web应用更容易在电脑上缓存数据。对任何一个在浏览器中享受这种台式机体验的人来说,这些数据库可以节省带宽,提升性能。然而它们肯定比不上本地应用的数据的强大功能。

HTML5的数据存储能力毫无疑问是很重要的功能,但是你仍然不能将存储的数据迁移到另外一台机器上,或是制作副本、备份、用另外一个应用打开。所有这些数据都是隐藏在浏览器之下的。

某种程度上说,这是最糟糕的一种情况。因为你要承担存储这些数据库的所有责任而不能对它有任何控制。

一些最新的浏览器可以让你看到在你的机器上创建了哪些数据库,但这些信息是有限的。Safari甚至可以让你能够删除数据库,但是你不能浏览这些信息或是将它们迁移到另外一台机器上,这些文件在设计之初就没有让它能够很容易迁移,尽管你可以做到这一点,如果你知道到哪里找这些文件的话。

你同样不能深入到文件中看到底存储了什么。当然,一个程序员可以看懂这些文件,但前提是他们研究清楚了文件格式并且做一些hacking。这些文件不像表单或者文本可以很容易地荣任何编辑器打开,使得它们不像本地应用那样容易被人们读懂。

事实3:本地数据可以被操纵:

用户可能并不拥有对数据的控制权,但是网站同样也被限制不能处理用户数据。用户换浏览器了?用户换机器了?很多Web开发者对此都无能为力。因为同步问题,他们不能让用户创建更多数据。

Web开发者也需要担心本地数据库的安全。尽管没有工具可以让用户可以很容易修改本地数据并升级权限,但服务器同样也没有能力去阻止用户做到。所有因为运行用户修改Javascript代码的安全漏洞同样会影响数据库。它们门户大开,等着有人写一个Greasemonkey脚本或一些本地代码去更改数据。

事实4:离线数据对同步是一场噩梦

HTML5的本地数据存储极大提升了离线使用Web应用的能力。唯一的问题是数据同步。

如果一个Web应用连接到网络上,它可以持续地将数据存储到云中去。而当应用离线时,应用中发生的数据就不能存储到云中。如果一个人切换了浏览器或者使用了不同的机器,就会出现副本,这时同步就会成为一个大问题。更糟糕的是,时钟本身就可能是不同步的,使得发现最新被保存的数据是不现实的。

当然,这对本地应用来说也一直都是一个问题,但是在本地应用中,为同步负责的是人,他可以通过查看文件名并改变日期来进行同步。但是因为HTML5并没有给用户对隐藏在浏览器之下的数据库的控制权,开发者必须提供用户界面让用户通过这个界面来管理同步问题。

这并非是一个完全棘手的问题。开发人员可以通过使用版本控制系统来处理这个问题,而现今的版本控制系统在处理这些问题上已经变得越发复杂了。但拥有这项技术并不意味着这是一个很容易使用的解决方案。合并不同GIT库是件很费时间的事情。HTML5开发者们需要先处理好这些问题,才能管理HTML5 Web应用的同步。

事实5:云端什么都没有向你承诺:

为HTML5将数据存储在云端而带来的所有结构性的问题来责备HTML5实际上不是件很公平的事情,但云端是一个必须的部分,因为云省去了安装软件和备份数据的麻烦。

由于HTML5本地数据存储的限制,大量Web应用存储仍然要保留在服务器端,但这可能是灾难性的。就在最近Facebook决定将不再使用一个基于Linux的插件来上传照片,结果,这个插件去掉的,同样被去掉的是通过这个插件上传的照片

这样的例子比较少见,但是因为各种原因,它们正变得越来越多。你能确保那个可爱地免费提供他们的一切HTML5应用的新兴公司在几年后甚至几个月后还存在吗?你只能自求多福。

情况还更糟糕。正如很多Web应用所明确说明的那样,这些数据并不是你的,在大数情形下,你不能诉诸法律来恢复数据。有些更离谱的服务条款甚至说数据可以“没有任何原因”就被删除。

HTML5不仅没有避免这个问题,它的结构实际上是保证了任何由你的浏览器缓存的数据都会存储在云端,这些数据是脱离了你的控制的。HTML5的炒作说这是它的一个优势特性,但这实际上却很容易造成不利影响。

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

有个故事,或许是杜撰的,说一个人使用Gmail账户和酒吧里认识的人保持着随意的联系。当Google+出现以后,所有的历史记录都出现了,因为Google+在论坛里自动连上了那些旧的地址。每天,这些旧名字和旧面孔都会出现询问是否要加入到论坛中去。

当Web应用公司需要升级的时候,他们会将所有人一次性升级。尽管这据说是为了让用户不再受升级安装文件之苦,但对于那些不想使用新特性的人来说,这确是一场噩梦。这不像上面是一个关于人们隐私的问题。新软件可能因为新旧软件包之间的依赖关系而经常崩溃。

事实7Web Workers并不会处理优先级
Web Workers(译者注:一种新的 JavaScript 编程模型)是HTML5的一个非常耐人寻味的特性。与其去使用Javascript传统的wait、delay和pause命令,现在Web开发者可以拆分他们的命令并且整合到Web Workers的CPU hogs中。换句话说,HTML5 Web开发者可以让浏览器表现得像操作系统一样。

但问题在于,Web Workers并没有复制操作系统的所有特性。尽管它提供了一种方式来讲负载分支并分离,但是却没有方法来管理负载或是设置优先级。API只是让消息传入或者传出Worker对象。这就是它做的一切了,剩下的都交给浏览器了。

CPU丰富的应用比如code crackers会潜入流行网站的后台吗?用户被交给会周期性被窃取的网站了吗?病毒已经附在一切有用的软件上了,那么攻破网站就只是时间问题了。而用户面对这一切能做的很少,因为他们没有办法去监测或者跟踪Worker objects做了什么。电脑被重定向到指定网页的时候只会越来越慢。

事实8格式不兼容比比皆是
HTML5引入了<audio>和<video> 标签,第一眼看上去,它们和图像标签一样好用。只要在其中加入一个URL,浏览器就会引入数据流。然而,如果它真有这么简单的话,为什么我浪费了两个星期来让所有主要的浏览器可以播放基本的音频文件呢?

个别浏览器构建者只实现了部分而不是全部的音频视频格式确实不是HTML5委员会的错。大家都是人,都想要争夺统治权。往往在一个浏览器上工作正常的文件到了另外一个浏览器上却不能工作了。开发者要如何测试这一点呢?API开发者非常聪明,他们加入了canPlayType函数,但就是这个函数也不是所有浏览器都支持的。

事实9:各浏览器的实现是独立的
HTML5的田园诗般的愿景是一回事,其实现的蹩脚的现实是另一回事。诚然,程序员正在尽他们最大努力来实现架构师的梦想,但就是有一些标签和对象无法正常工作。

例如,有很多理由去喜欢HTML5的地理定位API。它提供了对隐私的一定程度的包含,对精确度也有控制。要是它能一直一贯地工作该有多好——有的浏览器就会总是超时,这个浏览器还是不太聪明,因为它应该知道台式机上是没有GPS芯片的。

最后,人们会去抱怨浏览器没有完全实现HTML5的特性,而不是去责备API本身的结构问题。这一事实凸显了Web开发者在开发基于HTML5的Web应用时所面临的挑战。

事实10硬件idiosyncracies带来新的挑战

抱怨某些浏览器构建者超出了职责要求而提供更好的性能表现似乎也不公平,但这并非是恩将仇报。一个法拉利拥有者在绕过了一个灯杆以后,他就会发现有时候额外的动力并非总是好事。

Microsof通过将IE和低端硬件驱动整合而提升了IE浏览器中画布对象(Canvas object)的性能。它甚至做了一些游戏比如pirateslovedaisies.com来显示其性能。

但现在程序员们需要注意这些附加功能是否能够实现,并且这些代码的运行速度也是无法保证的。

例如,pirateslovedaisies.com的游戏设计者设计了一个开关来开启或者关闭IE支持的特性。但是,有没有一个API来告诉你这些特性是什么呢?没有。最简单的方式是通过浏览器名字来进行测试并估算帧速率。很多游戏开发者都有多年经验来了解可用硬件的范围,唯一的解决方法就是禁止创新,但这将是Web开发者又要解决的一个新的问题。

事实11:政治一直都存在

有个叫Ian Hickson的人,是HTML5标准的主要起草者,也是生命的最高独裁者(the Supreme Dictator for Life)。我想他们这是在开玩笑,因为这样的头衔实在太不匹配了。标准的编写者只是在提出建议,浏览器公司的编码天才们才是最终做出决定的人。他们可以选择实现或者不实习某个特性,然后Web开发者就要去测试结果是否稳定。几年以后,标准就会根据与实现程度的匹配情况做出改变。

很多Javascript开发者将兼容性问题都留给了开发代码库的人,比如jQuery。这些层让我们不必去了解不同浏览器之间的差别。但是,这些代码在将来是否足够健壮?只有时间才会知道。

这个议题凸显了这个领域中最根本的问题。我们想要自由、创造性以及因为浏览器间的激烈竞争而产生的丰富特性。创新的脚步非常快,但是因为浏览器开发者都争相添加新的特性以赢得先机,使得各个浏览器之间有更多的不同。

但我们希望能有一个统一的指挥者这样就能获得稳定性。但是,对于独裁和自治间的争斗,从来都没有一个理想的解决方式。与其为这些差异头疼,我们或许想要听听Winston Churchill对下议院所说的话:“事实上,民主是一种最糟糕的政府形式,除非其他的形式都经过了一次又一次的试验。”

 原文链接:11 hard truths about HTML5

 

 

译文来源:http://www.webapptrend.com/

 WebAppTrend是一个独立的技术博客,关注Web App前瞻和实践,以及智能浏览器发展 


请大家在关注ITeye的同时,关注我们的新浪微博 @WebAppTrend,关注我们的腾讯微博@WebAppTrend,欢迎加入我们的Q Q群:193775364

HTML5网络拓扑图性能优化

HTML5 中的 Canvas 对文本的渲染(fillText,strokeText)性能都不太好,比如设置字体(font)、文本旋转(rotation),如果绘制较多的文本时,一些交互操作会手动很大的影响,操作起来没那么顺畅,体验将会极其差,这不是我们想要的结果,再进一步和图片的绘制进行比较比较,你会发现,绘制图片和绘制文本在性能上不是一个等级的,在性能上绘制图片会好太多。

 

我们今天就来谈谈 HT for Web 性能相关的问题。在 HT 中,有很多地方可以设置文本,每个节点上面都可以设置两个 label 和两个 note 文本,如果全开启的话,绘制一个节点就要附带绘制 4 个文本,假如说绘制 文本的性能消耗是绘制图片性能消耗的 3 倍的话,附带绘制 4 个文本,就想当与多出 12 倍的性能消耗,这节点以多的话,可想而知,不管是哪个引擎都不可能 hold 得住这样的性能消耗。

 

既然绘制文本的性能消耗无法避免,那么我们要如何提高系统的整体性能呢?换个思路,绘制文本会有高性能消耗,导致操作上面的延迟和卡顿,那么我是不是可以在操作时不绘制文本呢,将文本绘制所消耗的性能节省下来,用在其他的性能消耗上,这样是不是就可以解决操作延迟和卡顿的问题呢?

 

我们不妨来试试,在 GraphView 中添加若干个 node、edge、group 等节点,并且每个节点上都显示文本(包括线条,上图所示),看看拓扑的缩放效果怎么样。没次缩放都要等上两三秒,性能实在是差得不行,这样的应用肯定是不合格的。

 

我们来看看具体的 Demo,链接:http://www.hightopo.com/demo/labelVisible/visible.html。接下来解析下具体代码的实现。

 

var init = function() {
    window.matchMedia('screen and (min-resolution: 2dppx)').
        addListener(function() {
            ht.Default.setDevicePixelRatio();
        });

    var g2d = new ht.graph.GraphView(),
        dm = g2d.dm();
    g2d.addToDOM();
    g2d.getLabel = function(data) {
        if (data.s('label'))
            return data.s('label');
        if (data instanceof ht.Edge)
            return 'from:' + data.getSourceAgent().toString() + 
                ' to:' + data.getTargetAgent().toString();
        return data.toString();
    };

    createNodes(dm);

    var autoLayout = new ht.layout.AutoLayout(g2d);
    autoLayout.setAnimate(true);
    autoLayout.layout('symmetric', function() {
        g2d.fitContent(true);
    });

    createFormPane(g2d, autoLayout);
};

  

上面的代码是页面初始化代码,首先先监听 media 的值变化,防止在不同的 devicePixelRatio 屏幕中切换 而导致页面不清晰,ht.Default.setDevicePixelRatio() 方法会更新 HT 系统中存放 devicePixelRatio 的变量,然后刷新页面上所有的 HT 组件,这样就可以保证页面一定不会不清晰。

 

接着是常见网络拓扑图 GraphView 组件,并将其添加到 DOM 中,重载 GraphView 的 getLabel 方法设置图元的文本,让每个节点都有文本。

 

接下来调用 createNodes 方法创建所有的节点,创建完代码后,创建一个 AutoLayout 来自动布局所有节点,自动布局为开发人员节省手动布局的时间,在效率上大大提升,在布局完后,让 GraphView 中的节点自适应屏幕,让所有节点都显示在当前页面中。

 

最后创建一个 FormPane 放在右上角,用于存放几个控制按钮及几个 ComboBox 选择项,可以让 GraphView 运行在不同的布局模式下,同时这些功能也可以用来检测页面性能,在布局的过程中是否流畅,具体的代码可以通过浏览器的 Sources 查看。

 

文本始终显示的话,在性能上还是不行的,就如上面所说的,是不合格的。那么我么该如何优化,让性能有质的提升呢?

 

在文章的开头有提到,我们可以采用在操作交互的过程中不绘制文本,来提升性能,让页面的呈现更加流畅。那么该怎么实现才能让操作交互过程中不绘制文本呢?具体 Demo 链接:http://www.hightopo.com/demo/labelVisible/invisible.html。看码:

 

var state = {};
g2d.isLabelVisible = function(data) {
    return !state.zooming && !state.panning && !state.autoLayout;
};
g2d.onAutoLayoutEnded = function() {
    state.autoLayout = false;
};
g2d.onZoomEnded = function() {
    state.zooming = false;
};
var timer = null;
g2d.mp(function(e) {
    if (e.property === 'zoom') {
        state.zooming = true;
        if (timer)
            clearTimeout(timer);
        timer = setTimeout(function() {
            timer = null;
            state.zooming = false;
            g2d.redraw();
        }, 100);
    }
});
g2d.mi(function(e) {
    if (e.kind === 'beginPan')
        state.panning = true;
    if (e.kind === 'endPan') {
        state.panning = false;
        g2d.redraw();
    }
});

 

首先 GraphView 提供了 isLabelVisible  的方法,让用户重载自定义文本的显示与否,state 变量是用来标记当前的操作状态,zooming 代表当前的 GraphView正在缩放,panning 代表当前的 GraphView 正在移动整个场景,autoLayout 代表正在做自动布局操作。

GraphView 的 mp(addPropertyChangeListener)方法是监听 GraphView的属性变化,当监听到 zoom 属性变化的时候,将 zooming 状态设置为 true,如果在 zoom 的过程中没有启动动画的话,就不会触发 onZoomEnded 回调,所以需要自己添加计时器,过段时间将 zooming 状态改掉,并且重新绘制下 GraphView。

 

GraphView 的 mi(addInteractorListener)方法是监听用户对 GraphView 的操作动作,在监听到 beginPan 时将 panning 状态设置为 true ,在监听到 endPan 是将 panning 状态设置为 false,并重绘 GraphView。

在 FormPane 中的一些操作会对 GraphView 中的节点进行自动布局,因此在 FormPane 中会设置 autoLayout 状态,由于代码比较多,我在这边就贴代码了。我们来看看,加上上面的代码后,对 GraphView 操作后的效果图:

 

 

上图是在缩放 GraphView 时的效果,可以发现所有的文本都不见了,用户操作起来也不会延迟和卡顿了现象,这样用户操作交互的性能问题也就解决了。

 

RubyvsPython第2波-贪吃蛇AI平台冲刺

ruby vs pythonGurudigger网站推出的一个编程活动,今年是一个贪吃蛇AI平台,我之前写过一篇博客介绍过,上次比赛的冠军是代表ruby的femto,如果你错过了第一次的比赛,不要紧,现在第二波来袭,不过与第一次的比赛不同,这一次活动的主要目标是对比赛平台进行改进,为2012的贪吃蛇AI挑战大赛做准备。

如果你对这个活动感兴趣,可以先从查看相关WIKI开始,编写一个AI程序,然后将你的AI程序以及你对平台的改进建议发送到jin.cai20#gmail.com,主办方将会从中选择12名选手参加6月24到25持续一个周末的编程派对,并提供往返交通及住宿费用,下面是活动的详情:

时间: June 24th – June 26th *

地点: GuruDigger Shanghai Office (上海市陕西北路30弄16号2楼)*

目标: 用一个周末的时间,为Ruby VS Python 2011年比赛平台 -Snake Challenge 冲刺

活动内容: 星期五晚上大家碰面认识,星期六上午头脑风暴并且按照兴趣爱好把大家分成几个小组,星期六下午到星期天下午coding, 星期天晚上烧烤派对。*

欢迎来自各地的朋友报名参加本次活动,所有最终入围的,我们将会支付这次活动产生的所有费用(飞机/高铁/酒店/食物等等)。如果你最终被评选为最出色的Geek, 将会获得盛大特别提供的Bambook一台。

你也可以从下面已经收集到的建议中挑选几个作为你的主攻方向:

1. 网页上添加Chat,方便remote 比赛时候大家聊天

2. 通过html5 websocket改进网页上的显示效果,目前是ajax poll,效果不太好

3. 页面上加一个record按钮,然后将save通过html5 local storage保存和replay

4. 添加Team Match模式,能够让N条ruby v.s N条python,目前只有free for all模式。

5. 障碍物: 简单起见, 障碍物是固定的, 游戏开始时从地图文件或用某种算法生成。

6 食物: 可以是在固定位置固定时间生成食物 (引入抢资源的概念)

7 生物初始位置: 每个地图蛇都会有自己的初始位置 (更公平,然后这也是不同地图会带来不同乐趣的一个因素)

8. 提升server/web server性能, 能够支持100+的房间和每个房间8生物

9. 游戏多样性增强, 时间延长到10分钟, 蛇之间可以用各种方式干扰, 放炸*弹, 障碍物, 等等.

10. 是不是让没有能力写AI的人,可以 通过一个上下左右来控制生物,让人机对战

11. 是不是可以把自己吃下去的食物 可以作为炸*弹,可以留下来,定时引爆

12. 增加洞穴功能,从一个口进去,另外一个口出去

13. 可以增加不同的角色,比如说团队战里面,有一种角色里面是专门放炸*弹,有一种角色是专门拆炸*弹

14.组队的话,两条蛇是不是可以合体

15. 食物是不同的种类的,类似于坦克大战,有些食物是可以变成炸*弹的,有些吃了之后无敌几秒钟,有些吃了加速

16. 一段时间之后,所有的蛇速度变快一档

17. 随着地图的增加,地图上面障碍物越来越多

18. 大家可以有一个账户,把胜负手情况记录起来

19. 做一个地图编辑器,大家可以自己画地图给大家来玩

20. 是不是可以增加一些打酱油的蛇?

如果你有gurudigger的账号,可以直接去这里参与讨论,如果想要测试你的AI是否够聪明,官方仓库的example目录下有许多聪明的小蛇可以供你测试,如果它们都被你打败了,欢迎来试试Yuanyi Zhang写的这条蛇:https://github.com/yzhang/snake_ai。 或者你也可以访问在线:

http://rubyvspython.org/room/1/,和上一次的冠军femto的蛇进行一次对战。

  • 大小: 31.7 KB

微软发布IE9预览版

今天的MIX 2010 会议上,IE9 发布平台预览版(IE9 Platform Preview) ,官方下载: http://ie.microsoft.com/testdrive/ (下载链接在网页右上角)。

ie9 预览版

这个预览版主要展示IE9 的几个特性:

1. 速度

IE9 中将使用完全重写的Javascript引擎,代号“Chakra” 。该新引擎带来大幅度性能提升,下图是SunSpider 测试结果。 Chakra 还有很多提升空间,相信在今后的beta版和正式版中, IE9 的JS性能让大家耳目一新。

IE9 Chakra

2. GPU 硬件加速的网页渲染

使用GPU硬件加速,IE9的渲染速度比IE8有大幅度提升。 IE8以及目前其他浏览器都使用GDI渲染,速度大概是每秒10~16帧。 而IE9可以达到 60~70 帧每秒的渲染速度,相当于3D游戏动画的渲染速度。

IE9 预览版

3.新增对HTML5,SVG ,CSS3 以及DOM的支持

IE9 新增支持 HTML5, CSS3, DOM, and SVG支持。 SVG 是W3C定义的网页矢量图形/动画描述语言,非常强大,可以做出非凡的网页动画,大家可以在 http://ie.microsoft.com/testdrive/找到SVG 的演示程序。 SVG 是IE9的重点功能, 相信会对将来Web 开发,尤其是网页动画/网页游戏, 产生深远影响。 建议Web 开发者开始研究SVG

Modernizr工具

  Modernizr,一个JavaScript库,它可以检测浏览器是否支持Html5和CSS3的新功能,从而在代码中做些适配的处理。

  分享篇大神的文章:http://blog.chinaunix.net/uid-21633169-id-4286857.html