2022年6月15日,微软正式停止支持Internet Explorer(简称IE)浏览器,这一天终于来了。
日期 | 事件 |
---|---|
1991-08-06 | Tim Berners-Lee发布世界第一个网站,World Wide Web正式诞生 |
1993-01-23 | Mosaic浏览器发布,其核心开发者为Marc Andreessen和Eric Brina |
1994-10-13 | 网景公司发布Mosaic Netscape浏览器,该公司创始人为James Clark与Marc Andreessen |
1995-05-16 | 盖茨发布The Internet Tidal Wave备忘录,决心将发展Internet作为微软最高优先级 |
1995-08-09 | 网景公司上市,互联网泡沫开始 |
1995-08-16 | 微软发布Internet Explorer浏览器 |
1995-12-07 | 盖茨在微软的Internet Strategy Day宣布Internet Explorer将完全免费 |
1995-12-04 | JavaScript发布,运行于Netscape Navigator 2.0试用版 |
1997-08-06 | 乔布斯宣布苹果与微软达成和解,将IE浏览器作为Mac的默认浏览器 |
1999-11-05 | 微软输掉反垄断官司,IE浏览器研发陷入停滞 |
2003-01-07 | 苹果发布Safari浏览器 |
2004-11-09 | Mozilla发布Firefox浏览器 |
2008-09-02 | 谷歌发布Chrome浏览器 |
2015-04-29 | 微软发布Edge浏览器 |
2018-12-06 | 微软宣布将会把Edge浏览器内核切换至Chromium |
2022-06-15 | 微软停止支持Internet Explorer浏览器 |
#
1991年8月6日,Tim Berners-Lee发布了世界第一个网站:http://info.cern.ch,World Wide Web正式诞生,人类进入互联网时代。
Berners-Lee所开发的世界第一个浏览器,名字很霸气:WorldWideWeb。
1993年1月23日,Mosaic浏览器发布,其核心开发者为Marc Andreessen和Eric Brina。
图片来源:NCSA Mosaic™
Mosiac浏览器的界面看起来和现在的浏览器区别不是很大:地址栏、前进、后退、刷新、主页。
Mosiac浏览器最大的创新是增加了img标签,支持在网页中内嵌图片,而之前的浏览器需要用单独的窗口查看图片。img是Marc的想法,他希望让Web变得更加性感。
Mosaic是第一个真正受到普通用户欢迎的浏览器,WWW不再专属于学者和极客。
Mosiac浏览器的全称是NCSA Mosiac,它的版权是属于研究机构NCSA的。换句话说,Masiac并不属于Marc。纽约时报在1993年年底报道Mosiac时,甚至都没有提及Marc和Eric。
Marc选择离开Masiac团队,去硅谷淘金,失去灵魂人物的Mosiac浏览器逐渐没落。
1994年10月13日,网景发布Mosaic Netscape 0.9浏览器,同年12月份发布1.0版本。由于网景没有Mosaic商标,于是将浏览器更名为Netscape Navigator,公司名称也从Mosaic Communications Corporation改成了Netscape Communications Corporation。
图片来源:WinWorld
网景的创始人之一Marc Andreessen就是Mosaic浏览器的主导者,他希望开发一个Mosaic killer,他还邀请了Eric Brina一起加入,亲手埋葬他们之前的作品。
网景的另一位创始人是James Clark,他是一个成功的创业者,他的经验、人脉和财力对网景公司的发展发挥了非常关键的作用。
商人Jim和极客Marc的年龄差距比较大,Marc在James面前像一个小孩:
图片来源:Netscape IPO 20-year anniversary: Read Fortune’s 2005 oral history of the birth of the web
虽然Netscape浏览器的开发团队一半是来自Mosiac团队,但是并未使用Mosaic的代码,是完全重写的,这样他们得以修正之前的错误,打造一个更好的浏览器。当代码腐化到一定程度之后,已经没法重构了,重写是更好的选择。
网景公司的商业模式比较奇特,下载Netscape浏览器是免费的,独立用户和学术圈的用户无需付费,但是企业用户需要付费。这种模式没法避免用户白嫖,但神奇的是,企业用户发现自家员工在使用Netscape浏览器的话,会主动或者被动付费。
Netscape的商业模式奠定了它成功的基础,因为可以用户很方便地免费下载使用,这使得Netscape Navigator迅速流行起来。但是,Netscape的商业模式并不稳固,因为Netscape并非真正免费,它还是需要依靠销售浏览器来赚钱,并且它没有利用自己的优势地位拓展其他成功的商业模式,甚至把门户网站轻易让给了雅虎。后来Internet Explorer干脆完全免费,这给了Netscape非常致命的打击。
1995年12月4日,网景公司联合太阳公司发布JavaScript,其运行于Netscape Navigator 2.0试用版。
出于商业原因,官方新闻稿刻意把Java和JavaScript混淆在一起宣传,其实两者没啥关系。
JavaScript诞生,让Web变得更加有意思了,成为一个真正的开发者平台,日后成长为最大的开发者平台。
虽然微软和网景在浏览器市场上针锋相对,但是他们居然在JavaScript诞生短短1年半之内就携手制定了ECMAScript标准,这奠定了JavaScript后来大获成功的基础。JavaScript是一个多少有点奇怪而且存在缺陷的语言,不过因为JS很早就有了独立的第三方标准,反而让它拥有很好的兼容性和生命力。
要知道,小程序这都搞了多少年了,还是各搞各的。
有意思的是,JavaScript设计之初就希望可以在服务端运行,可惜网景公司的尝试失败了,这个梦想直到2009年Node.js诞生才实现。梦想还是要有的,万一实现了呢?
1995年8月9日,成立仅16个月的网景公司上市,发行价为28美元,当天收盘价涨到58美元,一时风头无两,这也标志着互联网泡沫时代开始。
年仅24岁的Marc一夜之间成为亿万富豪,年少得志,第2年还登上时代杂志封面:
图片来源:TIME Magazine Cover: Netscape’s Marc Andreessen | Feb. 19, 1996
IPO之后不久,Marc声称网景浏览器将会把Windows变成一个BUG缠身的设备驱动(not entirely debugged device drivers),这也是盖茨所担心的事情。不少浏览器都有着取代操作系统的野心,比如Firefox OS和ChromeOS,目前来看这事还没成功。
1995年5月16日,比尔盖茨给微软的全部员工发送了名为The Internet Tidal Wave的备忘录,认定 Internet是继个人电脑之后最重要的突破,把Internet设为微软的最高优先级。盖茨认为浏览器的跨平台特性将会威胁操作系统的地位,他将此时还非常弱小的网景公司视作竞争对手,并且把开发浏览器作为主要的应对策略。
Now I assign the Internet the highest level of importance. – Bill Gates
盖茨对于 Internet的认知还是非常深刻和准确的, Internet确实改变了世界。
1995年8月16日,Internet Explorer 1.0发布。IE 1的发布时间很有意思的,一周之前轰动一时的网景上市,而一周之后声势浩大的Windows 95发布。
图片来源:Web Design Museum
从截图可以看出来,IE 1的版本号是4.40.308,这个版本号很奇怪,有可能是继承了Spyglass Mosaic浏览器的版本号。另外,IE版权信息中标注了”Based on NCSA Mosiac”,这个标识一直持续到IE 6。
Spyglass Mosaic与Netscape Navigator同样源自NCSA Mosaic,所以Internet Explorer与Netscape Navigator相当于是同门师兄弟。但是事实上,Spyglass Mosaic与Netscape Navigator都没有使用NCSA Mosaic的代码。
IE 1和IE 2基本上就是Spyglass Mosaic浏览器,只是做了一些修改,IE 3已经开始重写,IE 4基本上重写完成了。不过直到IE 7发布,微软才真正确认IE完全不再使用Spyglass Mosaic或者NCSA Mosaic的代码,于是在版权信息中去掉了”Based on NCSA Mosiac”。
从IE 1和IE 2的用户口碑来看,Spyglass Mosaic浏览器应该是不如Netscape的。虽然Spyglass Mosaic在法律意义上才是NCSA Mosiac真正的继承者。Netscape Navigator能够击败前辈Spyglass Mosaic,应该不只是因为Jim Clark更有钱,技术和产品上的差距才是更重要的原因。
IE 1的开发团队仅为5~6个人,只是一个非常小的团队,微软此时对于浏览器的投入还远远不够,也许他们把所有的精力都放在了更加重要的Windows 95上。
IE 1大幅落后于同时期的Netscape浏览器,因此Netscape看起来还可以高枕无忧。
IE 1独立于Windows,打包在Microsoft Plus!中一起售卖,价格是49.99美元,与Netscape Navigator的价格基本一致。
1995年11月22日,Internet Explorer 2.0发布。此时距离IE 1.0发布仅仅4个月,微软急于在浏览器市场一展身手。
图片来源:Microsoft Internet Explorer 2.01 for Windows 3.1
与IE 1一样,IE 2也是基于Spyglass Mosaic浏览器做了一些修改。
IE 2新增了对SSL和Cookie的支持,2个非常重要的特性,当然它们的发明者都是Netscape。也许我们已经习惯了绝大部分Web技术可以得到不同浏览器的一致性的支持,并且向后兼容,但是,其实也只是Web这一个开发者平台这样,安卓和iOS可不是这样,Mac和Windows也不是这样,甚至脱胎于Web技术的小程序都不是这样。标准化、跨平台、向后兼容,这是Web最大的优势。
之后,IE 2还发布了Mac版本,IE的Mac版本在之后的故事中会扮演更加重要的角色。
1995年12月07日,珍珠港袭击纪念日,微软举办了Internet Strategy Day,盖茨宣布Internet Explorer 将会永远免费,而且是完全免费,而不是像竞争对手那样看着免费但是又不是完全免费。
奇怪的是,我完全找不到盖茨这次的演讲稿,官方的链接也被删了,或许只是意外,或许是刻意为之?
虽然找不到完整的演讲稿,但是,盖茨说了啥还是留下了一些记录:
When we say the browser is free, we’re saying something different from what other people are saying. We’re not saying you can use it for 90 days, or you can use it unless you’re a corporation, or you can use it and then maybe next year we’ll charge you a bunch of money. - Bill Gates
谁都知道他讽刺的就是Netscape,并且直接戳中对手的软肋,这是火药味十足宣战声明。
1996年8月13日,Internet Explorer 3.0发布。微软大张旗鼓进军Internet,1年之后终于有了不错的进展。
图片来源:Microsoft Internet Explorer 3.03 for Windows 3.1
IE 3已经开始重写了,版本号也恢复了正常。不过,根据Spyglass Mosaic开发者Eric Sink的说法,IE 3依然在很大程度上依赖Spyglass Mosaic的代码。
IE 3支持了CSS,成为第一个支持CSS的商业浏览器,而CSS 1要到1996年年底才成为W3C的正式标准。IE 3还支持了JScript,其实就是逆向工程了Netscape的JavaScript。集齐了HTML/CSS/JavaScript三剑客,Web开始走向成熟。
IE 1和IE 2的用户口碑不怎么样,IE 3取得了不错的进步,获得了一些正面评价。
更重要的是,IE3是完全免费的,并且与Windows绑定,用户开箱即用,无需安装。盖茨说到做到,反正他此时已经是世界首富了。1996年的时候,IE团队已经有100人的规模了,这其实一个很大的研发团队了,当然对于微软来说,不差钱!
相比之下,Netscape Navigator的售价为49美元,还需要自己安装,如果是你的话,会如何选择?Netscape Navigator直到1998年1月份才宣布完全免费,并且把代码开源,非常激进,可惜晚了1年多。
Internet Explorer通过免费和绑定Windows来进行竞争是存在争议的,不过从用户角度来讲,这事也挺好的,从此以后主流浏览器都是免费的,这促进了Web技术乃至互联网行业的发展,这应该是IE最大的贡献之一。
IE 3启用了标志性的蓝色E作为logo,它也成为了浏览器乃至互联网的标志:
图片来源:Internet Explorer logo, symbol | history and evolution
1997年8月6日,乔布斯在Macworld大会上宣布,苹果与微软达成历史性和解,结束长达10年的专利纠纷,并开展一系列合作,让IE成为Mac的默认浏览器。
图片来源:What ever became of Microsoft’s $150 million investment in Apple?
微软为此付出的代价是1.5亿美元,购买了苹果公司的无投票权股份。可惜微软过早出售了苹果股票,如果持有至今的话价值上千亿美元,因为Apple的股价已经涨了数百倍。
乔布斯对亦敌亦友的盖茨说了一句非常经典的话:”Bill, thank you. The world’s a better place.”
图片来源:Time Magazine Cover:Steve Jobs | Aug. 18, 1997
1997年9月30日,Internet Explorer 4.0发布。
图片来源:Web Design Museum
花了差不多2年时间,IE 4基本上重写完成了,不容易啊。
微软开始将IE称为Windows操作系统组件(operating system component),试图规避垄断指责。
IE 4在功能和性能上已经与Netscape浏览器不相上下了,此时继续花钱购买Netscape的用户一定是真爱了。
1999年3月18日,Internet Explorer 5.0发布。
图片来源:Web Design Museum
IE 5新增XMLHttpRequest接口,简称XHR,可以用于与服务端进行数据交互。XHR促使了大名鼎鼎的Ajax(Asynchronous JavaScript and XML)的诞生,Ajax这个名字也很奇怪,它是一个生造的词。Ajax的诞生,标志着Web开始从1.0走向2.0,从简单的静态页面变成可以进行交互的应用。
1999年11月5日,微软输掉了举世瞩目的反垄断官司,其将IE浏览器捆绑到Windows浏览器的做法是最主要的罪证之一,随后,法官判决将微软的操作系统和应用软件拆分为2个公司。后来微软与美国司法部达成和解,避免了被拆分的命运,不过这次判决显然对IE浏览器的开发造成了非常不利的影响。
根据微软反垄断官司的判决文件,微软每年花费在IE的研发的费用超过1亿美元。IE浏览器的投资巨大,但是它本身并不赚钱,还成为了反垄断官司的罪证。对于微软来说,继续投入IE浏览器的研发不划算也不明智。根据《浪潮之巅》,微软内部也为IE浏览器的未来展开了激烈的争论,最终支持IE浏览器这一方失败,导致IE浏览器的战略地位被降级,沦为一个普通的应用。
1999年的时候,IE团队人数已经高达1000人,这是一个非常豪华的研发团队了。根据360的博客,Chrome团队在巅峰时期也调动了1000个程序员。这时,就算再土豪的公司,也得考虑收支的问题了。就算烧得起这么多钱,要招这么多人也不是一件容易的事情,毕竟公司还需要投入人力做那些赚钱的产品。产品必须有商业价值才能生存下去,收益必须大于支出,因此团队规模必须与业务规模匹配。
2001年8月24日,Internet Explorer 6.0发布,与经典的Windows XP一起。
图片来源:Web Design Museum
巅峰时期的IE 6的市场占有率高达90%以上,这是一个非常恐怖的数字,强如Chrome最多也就占据了70%的市场份额。
虽然市场占有率很高,但是IE 6备受指责,主要是因为安全问题。
2006年10月18日,Internet Explorer 7.0发布。此时距离IE 6发布已经过去了5年多,可见IE浏览器的开发已经陷入停滞。
图片来源:Web Design Museum
从截图可以看出,IE 7支持了Tab,每个页面都要打开新的窗口的话,还是挺烦的。
IE 7的版本信息中去掉了”Based on NCSA Mosiac”,此时微软确认IE完全不再依赖Spyglass Mosaic或者NCSA Mosiac的代码。
IE 7与IE 6的时间间隔长达5年,正是在这一时期,Firefox和Safari相继发布,Chrome也已经秘密启动开发。
2009年03月19日,Internet Explorer 8.0发布。
图片来源:My Internet Explorer
IE由于兼容性问题备受指责,IE 8终于通过了Acid2测试。Acid2是一个Web标准兼容性测试。不过,Safari、Firefox和Chrome都先于IE 8通过了Acid2测试。
2011年03月14日,Internet Explorer 9.0发布。
图片来源:My Internet Explorer
从用户界面来看,IE 9简洁了很多,可能是学习了Chrome的做法。
IE 9开始独立于Windows发布,IE和Windows的关系就像是一对分分合合情侣,IE 1和E 2是独立发布的,IE 3开始绑定Windows,IE 9又分开了。
2012年9月4日,Internet Explorer 10发布。
图片来源:My Internet Explorer
此时,Chrome的市场占有率已经超越IE了。Chrome的产品和技术都做到了最高水准,但是依然花了4年时间才打败IE,由此可知IE的市场地位还是比较稳固的。
2013年10月17日,Internet Explorer 11发布。
图片来源:My Internet Explorer
IE 11是Internet Explorer的最后一个版本,此时IE浏览器的市场占有率已经跌至22%左右,跌落神坛。
历时18年,IE浏览器一共发布了11个版本:
日期 | 事件 | 备注 |
---|---|---|
1995-05-16 | The Internet Tidal Wave备忘录 | 盖茨宣布将发展Intenet作为微软的最高优先级 |
1995-08-16 | Internet Explorer 1.0 | 基于Spyglass Mosaic开发,价格49.9美元 |
1995-12-07 | Internet Strategy Day | 盖茨宣布IE浏览器将会完全免费 |
1995-11-22 | Internet Explorer 2.0 | 支持SSL和cookies,发布Mac版本 |
1996-08-13 | Internet Explorer 3.0 | 支持CSS和JavaScript,开始免费并且绑定Windows,启用蓝色E作为logo |
1997-08-06 | 苹果与微软和解 | 乔布斯宣布IE将作为Mac的默认浏览器 |
1997-09-30 | Internet Explorer 4.0 | IE基本重写完成 |
1999-03-18 | Internet Explorer 5.0 | 支持XMLHTTPRequest |
1999-11-05 | 微软输掉反垄断官司 | 之后微软与美国司法部达成和解 |
2001-08-24 | Internet Explorer 6.0 | IE 6市场占有率高达90% |
2006-10-18 | Internet Explorer 7.0 | 支持Tab |
2009-03-19 | Internet Explorer 8.0 | 通过Acid2测试 |
2011-03-14 | Internet Explorer 9.0 | 简化用户界面 |
2012-09-04 | Internet Explorer 10 | IE市场占有率被Chrome超越 |
2013-10-17 | Internet Explorer 11 | IE市场占有率跌至22% |
IE的发展历程可以分为2个阶段,大致可以把微软输掉反垄断官司作为界限。
前一阶段,微软重金投入IE浏览器研发,使得IE的用户口碑逐渐提升。另外,微软通过免费绑定Windows等手段强行推广IE浏览器,利用自身的垄断地位打压竞争对手,进一步巩固了IE浏览器的地位。IE浏览器完成逆袭,强行把曾经的王者网景浏览器拉下神坛,市场占有率最高曾达到95%。
图片来源:The Browser Wars
当然,IE胜之不武,绑定Windows浏览器,直接免费,利用自身地位各种打压竞争对手,这些霸道的做法也给后来IE浏览器的衰落埋下了伏笔。由于在竞争策略上用力过猛,导致微软惹上了反垄断公司,从而不得不降低浏览器的优先级,导致Internet Explorer迅速衰落。
IE 7与IE 6间隔了5年时间,也就是说,微软输掉反垄断官司之后,IE浏览器陷入停滞状态。正是在这一时期,IE浏览器由于兼容性和安全性问题备受指责,Firfox和Safari相继发布,Google也开始秘密研发Chrome浏览器。
2003年1月7日,乔布斯在Macworld上发布了Safari浏览器,以此取代了IE浏览器,成为Mac上新的默认浏览器。
图片来源:Web Design Museum
根据乔帮主的演讲,Safari的性能远超IE,是Mac上最快的浏览器。Safari在发布半年之内在Mac上的市场占有率就超过了IE,伤害不大,但是有点尴尬。
2004年11月9日,Firefox 1.0发布。
图片来源:Web Design Museum
Firefox是Netscape的嫡系后代,根正苗红,它的历史可以追溯至Netscape在1998年宣布开源。Firefox的母公司Mozilla的名字其实就来自于Marc Andreessen的执念:Mosaic killer。
而Firefox 1.0发布之后的1年之内,其下载量超过1亿。到2009年,Firefox的下载量超过10亿,其市场占有率也达到了峰值32%。
Firefox的巨大成功,也算是给Netscape报了一箭之仇,同时给了沉睡中的IE浏览器一记闷棍,再不努力就没戏了。
2008年9月2号,秘密开发2年的Chrome浏览器正式发布。
图片来源:Looking Back At the First Version of Google Chrome
凭借优异的性能、简洁的设计、极致的用户体验,Chrome一鸣惊人,IE浏览器败局已定。
谷歌为Chrome浏览器开发了全新的JavaScript引擎V8,将JavaScript的执行性能提升了惊人的的一个数量级,这直接催生了Node.js的诞生,JavaScript生态系统迅速走向繁荣。
下图是2009年到2022年浏览器的市场份额变化,Chrome一路飙升,势如破竹,而一度垄断市场的IE则刚好相反:
数据来源:statcounter
2012年,Chrome的市场占有率超越IE。我还记得当时经常重装Windows系统之后,第一件事就是使用IE浏览器下载Chrome浏览器,所以大家讽刺IE最大的作用就是用来下载Chrome。
前文提及过,Chrome团队也曾召集1000个程序员进行开发,耗资不菲。而且,Chrome至今还在稳定迭代,完全没有停下来的节奏,这个从我写的《了不起的Chrome浏览器》也能看出来。Chrome更新实在太快,以至于我实在卷不动了,暂时放弃了更新Chrome博客。
微软和谷歌都不差钱,凭什么谷歌就可以坚持下去?
谷歌之所以热衷于开发Chrome浏览器,是因为其核心产品搜索引擎依赖于Web生态系统的繁荣,如果网页的数量和质量持续下降,对搜索引擎是致命的伤害,用户可以去各个App孤岛里面搜索信息。要知道,我现在搜索中文信息时,首选的是微信搜索,因为微信里面的内容质量更高。虽然Chrome是免费的,但是Chrome可以推动Web技术进步,从而促进Web生态系统发展,进而给谷歌带来持久的商业价值。当年负责Chrome项目的Pichai,日后之所以能够出任谷歌的CEO,其中一个非常重要原因就是Chrome大获成功,因为Chrome对于谷歌太重要了。这个逻辑听着有点绕,但是也不难理解。
对于微软来说,最好大家都直接用Windows软件,如果Web继续发展下去,说不定当年Marc吹过的牛真的成为了现实,那可就不太妙了。
2015年4月29日,微软发布Edge浏览器,宣判了Internet Explorer的死刑。不过,此时的Edge浏览器,似乎只是换了个名字的IE浏览器,logo也继承自IE,因此并没有挽回微软在浏览器市场的颓势。
图片来源:1000LOGOS: Edge Logo
2018年12月6日,微软宣布将会把Edge浏览器内核切换至Chrome的浏览器内核Chromium,这相当于微软在浏览器技术上认输,让人颇感意外。当然,面子并不重要,切换Chromium内核之后的Edge浏览器兼容性更好了,更新更快了,逐渐站稳了脚跟,并且开始与Chrome、Safari、Firefox一起推动Web技术进步。
基于Chromium的Edge浏览器启用了新的logo,好看多了:
图片来源:1000LOGOS: Edge Logo
财大气粗的微软开发IE浏览器,就一定能击败Netscape吗?答案是否定的,没那么容易。
在IT行业,大部分情况下,大公司的新产品通常打不过创业公司的竞品,这好像就是宿命。微软的Bing没能打败谷歌,谷歌的Google+没能打败Facebook,Facebook的短视频产品没能打败Tiktok。长江后浪推前浪,前浪拍死在沙滩上,这才是IT行业的发展规律,这也是为什么盖茨会如此警惕Netscape。
所以说,IE浏览器的成功反而是一个例外,免费和绑定Windows固然是IE成功的关键因素,但是微软下血本提升IE的用户口碑才是IE成功的根基。
Netscape本来是有机会成为巨头的,不过它的商业模式并不稳固,技术和产品上也没能守住优势,所以只是昙花一现。
不过,IE也没能逃过自己的宿命,到达顶点之后戏剧性地迅速衰落。
其根本的原因在于,IE对于微软来说是一个防御性产品,打败Netscape似乎是它唯一的目的,本身对于微软没有太多商业价值,当时乃至现在Windows和Office才是微软的亲儿子,所以微软对于IE的投入很难持续下去,很容易被挑战:微软做IE到底图啥?另一方面,IE激进的竞争策略,使得IE成为微软反垄断官司的罪证,这让IE陷入更加尴尬的位置:难道微软做IE就是为了成为被告?
还有人担心,Chrome会成为下一个IE浏览器,我想这是多虑了。因为Chrome在谷歌的搜索引擎的商业模式中,占据了非常核心的地位,Web技术的持续进步才能为谷歌的搜索引擎提供越来越多优质的内容,因此谷歌必然会持续投入,大概没有人会傻到挑战这一点。另一方面,Chrome从最开始,就建立了非常好的产品文化,其4S原则(Speed、Security、Stability、Simplicity)成为Chrome持续迭代的基础。
我在去年写了1年的《了不起的Chrome浏览器》,Chrome在2021年取得的进步让人惊叹。Chrome还是那个Chrome,谷歌还是那个谷歌,没什么可担心的。
欢迎大家关注我的微信公众号寒雁Talk。
]]>2022年3月29日正式发布的Chrome 100,将带来了哪些新特性呢?
Deprecate the document.domain setter是一个影响很大的breaking change,请大家务必注意排查风险。计划于今年9月份发布的Chrome 106将不再支持通过修改document.domain来绕开同源策略(same origin policy)的限制,Chrome 100开始在控制台的Issues中打印warning信息。
Multi-Screen Window Placement API是个很有意思的特性,Web应用也支持多屏了!可以用于文档演示等场景。可惜Firefox和Safari目前还不感兴趣,只有Chrome一家支持。
Array Grouping proposal是个很简单但是实用的特性,要不咱直接把Lodash的常用工具函数全部加入ECMAScript得了?
Reduce User Agent string information要结束试用,开始正式发布了,此事对各种监控脚本的影响还是挺大的,需要注意排查一下风险。
Chrome 100正式发布了Multi-Screen Window Placement API,可以用来查询设备所连接的多个屏幕的信息,并且将页面内容在指定屏幕中打开,其核心API如下:
window.getScreenDetails()
方法,用于获取显示器屏幕的信息(包括外接显示器);相比之下,window.screen只能获取当前浏览器页面所在的显示器屏幕信息;简单地说,Chrome支持多屏应用了。
一图胜千言,当我使用Keynote播放PPT时,它会在外接显示器上展示PPT内容,而在MacBook显示器上显示下一页内容以及当前时间,这样的话,演讲者可以把握演讲的时间节奏并且提前准备一下下一页要讲的内容(请忽略我的PTT水平。。。):
那么,对于Google Docs、语雀、石墨文档等文档应用,不妨可以使用Multi-Screen Window Placement API实现类似于Keynote的效果,用于演示场景。
其实,在金融、设计工具、游戏等应用中,都可以用到Multi-Screen Window Placement接口,将不同的内容展示到不同的屏幕,提高用户体验和工作效率。
Twitter、Discourse、Google Slides、itrix等团队表达了对Multi-Screen Window Placement API的兴趣,不过目前并没有看到实际案例,而Chrome团队所提供的Demo也过于简单。
Multi-Screen Window Placement提案还是挺有意思的,不过目前并没有成为正式标准,也没有得到Firefox和Safari的支持,这就很尴尬了。。。
Chrome 100开启了ECMAScript提案Array Grouping proposal的开发者试用(devloper trial),该提案目前处于Stage 3,为数组新增了groupBy和groupByToMap方法:
const array = [1, 2, 3, 4, 5]; |
根据Web Almanac 2021报告,Lodash的使用率仅次于jQuery和Modernizr,高于React,由此可见类似于goupBy等工具函数还是非常常用的:
如果哪天Lodash的常用函数都变成了ECMAScript的提案,大家也不必意外。。。
Chrome 95开始试用Reduce User Agent string information特性,试用期将于Chrome 100结束,具体的结束日期为2022年4月19日。Chrome 101开始,将逐步正式发布Reduce User Agent string information特性。
Reduce User Agent string information旨在简化User-Agent字符串,减少其信息量,缓解利用User-Agent字符串作为用户指纹,更好地保护用户隐私。同时,引导开发者使用更加保护用户隐私的User-Agent Client Hints来获取浏览器信息,降低大家对User-Agent字符串的依赖。
Chrome计划到Chrome 113彻底完成User Agent字符串的简化,不过从最终的结果来看,其实User-Agent的变化其实非常小。
以Chrome Windows用户为例,旧的User-Agent字符串是这样的:
Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.1234.56 Safari/537.36
简化之后最终的User-Agent字符串是这样的:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.0.0 Safari/537.36
Windows NT 6.3变成了Windows NT 10.0,Chrome/93.0.1234.56变成了Chrome/93.0.0.0,仅此而已。Windows的版本号被固定在了10.0,即使用户更新了操作系统,也不再变化了;Chrome的版本号仅保留大版本号,省略了小版本号。换句话说,我们依然可以通过User-Agent字符串获取浏览器的名称及其大版本号、操作系统的名称、区分桌面端和移动端。但是,我们无法通过User-Agent字符串获取浏览器的小版本号以及操作系统的版本了。另外,对于安卓端,手机的品牌及型号也不再提供。
User-Agent字符串所能提供的浏览器信息更加模糊了,这样有利于保护用户隐私。
如果开发者需要获取更加精确的浏览器信息,则需要使用User-Agent Client Hints,该特性在Chrome 89已上线。User-Agent Client Hints对应的HTTP请求Header字段如下表:
请求Header | 取值示例 |
---|---|
Sec-CH-UA | “Chromium”;v=”84”, “Google Chrome”;v=”84” |
Sec-CH-UA-Mobile | ?1 |
Sec-CH-UA-Full-Version | “84.0.4143.2” |
Sec-CH-UA-Platform | “Android” |
Sec-CH-UA-Platform-Version | “10” |
Sec-CH-UA-Arch | “arm” |
Sec-CH-UA-Model | “Pixel 3” |
Sec-CH-UA-Bitness | “64” |
浏览器默认仅发送Sec-CH-UA、Sec-CH-UA-Mobile、Sec-CH-UA-Platform,与User-Agent所提供的信息量一致,如果服务端需要获取其他User-Agent Client Hints字段的话,则需要明确指定所需要的字段。这样做的好处在于,浏览器默认提供的用户信息更少了,同时浏览器及Web应用理论上能够记录、审计服务端所请求的信息量,能够更加主动地保护用户隐私。
Web端的监控服务,例如ARMS、Fundebug、Sentry等,若需要获取更加准确的客户端信息,则需要使用User-Agent Client Hints了。当然,建议使用User-Agent Client Hints需要获得用户的授权,插件以及应用端不应该帮用户做决定,否则这个特性对用户隐私的保护就没有实际意义了。
计划于今年9月份发布的Chrome 106将不再支持通过修改document.domain
来绕开同源策略(same origin policy)的限制,Chrome 100开始在控制台的Issues中打印warning信息。
例如,访问https://www.google.com时,其原本的document.domain取值为www.google.com,我将其修改为google.com之后,Issues中将会出现Deprecated Feature Used信息:
Relaxing the same-origin policy by setting “document.domain” is deprecated, and will be disabled by default in M106, around September 2022. To continue using this feature, please opt-out of origin-keyed agent clusters by sending an Origin-Agent-Cluster: ?0 header along with the HTTP response for the document and frames. See https://developer.chrome.com/blog/immutable-document-domain/ for more details.
好奇的小朋友可能就要问了,document.domain
看着就不应该支持修改,正经人谁改这个啊!
开同源策略(same origin policy)是Web应用最基本的安全基础之一,这么1行代码就轻易地绕开了?
这显然是一种hack的做法,违背了同源策略的初衷,存在安全风险,比如对于类似GitHub Pages这种网页托管服务来说,各个用户的子域名不同,主域名相同,这时理论上通过修改document.domain是可以绕开同源策略的限制的。
所以,Chrome决定堵住这个安全漏洞,修改document.domain将不能绕开同源策略的限制,Firefox也表示了支持。
如果你依然需要进行https://parent.example.com与https://video.example.com之间的通信,则可以使用postMessage()或者Channel Messaging API。
如果你依然需要通过修改document.domain绕开同源策略的限制,或者来不及进行改造的话,可以返回HTML文件时,增加以下Header:
Origin-Agent-Cluster: ?0 |
Chrome致力于让Web变得更加安全,为了这个目标,不停地折腾全世界的Web开发者,这种做法让人不得不服,谁叫它说了算,大家还是赶紧检查一下你的代码里面是否修改document.domain了吧!
根据Chrome Platform Status的数据,大概有0.5%的页面加载通过修改document.domain来绕开同源策略的限制,这个比例很低,但是考虑到Chrome的市场占有率,其绝对数量也是相当大,影响的用户和开发者并不少:
2008年,秘密开发2年的Chrome正式发布,14年之后,Chrome的版本号达到了100。Chrome的UI设计基本上没什么变化,不过它的内核已经焕然一新了,Web技术获益于Chrome的推动得到了长足的进步。
相信Chrome 100只是起点,随着WebAssembly、WebGPU、HTTP/3等各种Web新技术得到应用,未来的Web会更加精彩!
这里,不妨模仿一下Atwood’s Law:
Any application that can be written in Web, will eventually be written in Web.
我们已经看到AutoCAD、Google Earth、Photoshop、Figma这样重量级的应用出现在Web中,性能瓶颈会被逐渐突破,未来类似于视频编辑、游戏、VR/VA等应用会越来越多。
我有差不多2个月没有更新Chrome博客,其实,Chrome 98和Chrome 99的博客写得差不多了,但是由于春节假期以及疫情的原因,没有及时发布。按时更新Chrome博客是一件难的事情,不过我还没打算放弃,继续坚持!
才疏学浅,我所写的内容难免有错误之处,欢迎批评指正,感兴趣的同学可以微信交流:KiwenLau。
欢迎关注寒雁Talk公众号,关注《了不起的Chrome浏览器》系列博客,与我一起见证大前端的星辰大海!
阿里巴巴业务平台事业部长期招聘P6及以上前端大佬,参与建设最前沿的阿里前端生态系统,推动行业技术发展,内推地址:hanyan.lk@alibaba-inc.com
欢迎大家关注我的微信公众号寒雁Talk。
]]>十多年来,Web技术突飞猛进,其中Chrome功不可没,了解Chrome可以帮助我们理解前端行业的发展趋势。
因此,我将以《了不起的Chrome浏览器》为题,对Chrome的每一个版本的重要特性进行详细解读,同时分享一些自己的一些思考:
通过专注于Chrome的写作,既可以可以提高我的专业能力,也可以提高个人影响力。我的长期目标是在2025年出版一本关于Chrome的书,毕竟出版自己的书每一个写作者最高的追求。
我是寒雁,一个热爱写代码和写文章的程序员,欢迎关注我的微信公众号寒雁Talk。
WebAssembly Exception Handling于Chrome 90开始试用,Chrome 95正式发布,为WebAssemly增加了异常处理语法,具体指令如下表所示:
Name | Opcode | Description |
---|---|---|
try | 0x06 | begins a block which can handle thrown exceptions |
catch | 0x07 | begins the catch block of the try block |
catch_all | 0x19 | begins the catch_all block of the try block |
delegate | 0x18 | begins the delegate block of the try block |
throw | 0x08 | Creates an exception defined by the tag and then throws it |
rethrow | 0x09 | Pops the exnref on top of the stack and throws it |
WebAssembly/exception-handling提案由Google的开发者负责,当前处于WebAssembly提案流程的Phase 3,并且得到了Firefox、Safari以及Edge的支持,因此预计将会成为正式标准。
WebAssembly自诞生以来就没有异常处理语法,这是个挺大的问题。在浏览器环境下,WebAssemly的异常是通过JavaScript的try/catch来”模拟”的,这继承了Asm.js的处理方式。
基于JavaScript的WebAssembly异常处理方式如下图所示:
图片来源:WebAssembly Exception Handling: A Toolchain’s
Perspective
根据初步的测试结果,基于WebAssembly原生的异常处理方式,代码量降低了30%左右,同时性能提升了30%左右,这个结果可以说非常理想了,用更少的代码实现了更好的性能。从原理上来讲,这个结果并不让人意外。不过,由于目前测试数据还非常少,因此WebAssembly Exception Handling的真实效果还有待于进一步验证。
对WebAssembly感兴趣的同学,欢迎阅读我的博客《十年磨一剑,WebAssembly是如何诞生的?》,了解WebAssembly的发展历史。
Secure payment confirmation于Chrome91开始试用,Chrome 95正式发布,旨在为用户提供更加安全、更加便捷地支付服务。
Secure Payment Confirmation为W3C提案,由Google的开发者负责,由于其他浏览器厂商并未表达是否支持,因此该提案何时能够成为W3C标准并不好说。
下图非常直观地展示了基于Secure Payment Confirmation的支付流程:发起支付、授权支付、验证支付。
图片来源:Secure Payment Confirmation explained
Secure Payment Confirmation从2个方面优化了支付服务:
这样的体验类似于在iOS应用内付费,无需离开APP,刷脸即可,非常方便。
美国在线支付服务巨头Stripe试用了Secure payment confirmation,为期3个月的实验结果表明,转化率提升了8%(从84.7%提升到92.7%),授权速度提升了3倍(中位数从36s降低到了12s)。
中国的在线支付行业远远超越了欧美发达国家,这是时代发展的红利,也是互联网行业对于社会最大的贡献之一。我想,大家只是习惯了这种只需要带上手机的生活,没有发现在线支付以及各种互联网应用是多么重要。
不过,对于Web应用来说,在线支付还存在一个不小的问题,要么使用二维码手机扫码支付,要么需要跳转到支付网站,整个支付体验并没有达到最佳的状态。要知道,用户的每一次跳转都有可能增加流失率。Secure payment confirmation可以减少用户跳转将可以有效提高体验以及转化率,还是非常值得一试的。
Chrome 95正式发布了EyeDropper API,用于控制颜色选择器,支持选择浏览器窗口之外的颜色,目测可以用于Figma等设计类工具。
EyeDropper API是WICG提案,由Microsoft的开发者负责。
EyeDropper API的用法非常简单:
const eyeDropper = new EyeDropper(); |
创建一个EyeDropper实例之后,即可使用open方法打开颜色选择器,获取用户所选择的颜色值:
图片来源:EyeDropper API Explainer
从EyeDropper API也可以看出来,Microsoft一直在积极参与浏览器标准制定和开发,由Edge浏览器主导或者积极参与的浏览器提案越来越多了,比如WebAssembly、WebCodecs、EyeDropper API、VirtualKeyboard API、Clipboard API: Svg。
谁说基于Chromium的浏览器就只能躺平?还是可以参与Web技术标准制定的。这对于国内各大基于Chromium实现的浏览器还是有启发意义的。。。
Microsoft曾经通过非常手段将IE浏览器打造成为霸主,只是最后求仁得仁,IE浏览器不是依靠产品和技术取胜的,后来也输在了产品和技术上。如下图所示,Chrome发布之后,轻松把IE浏览器的份额几乎全部抢走了(关于这一点,详见我的博客《Chrome是如何成功的?》):
图片来源:Timeline: The 30-Year History of the World Wide Web
IE浏览器终于被Microsoft彻底抛弃了,Edge换用Chromium作为浏览器内核,但是Microsoft只是改变浏览器的研发策略,而不是放弃浏览器。云计算(Azure、Office 365)业务的迅速增长是Microsoft复兴最核心的推动力,浏览器作为云计算产品的入口,其重要性不言而喻。
Edge目前的市场占有率还非常低,但是Chrome不得不警惕这个强大的竞争对手:不差钱、手握PC操作系统Windows、业绩和市值全面复兴、企业文化和公司战略成功转型。不过,最近Edge似乎又想通过Windows垄断地位强行推广,这就有点不厚道了。
风水轮流转,现在在浏览器的创新上固步自封的变成了Safari。Chrome核心开发者之一Alex Russell(今年跳槽去Edge了)写过一篇非常详尽的檄文Progress Delayed Is Progress Denied,指责Safari及其浏览器引擎Webkit严重落后,App Store要求所有浏览器在iOS端必须使用Webkit引擎的政策严重制约了Web技术的发展,导致大量Web新技术无法即时应用到iOS端。出于维护App Store的商业利益,Apple不太可能主导放弃对iOS端Web技术的刻意控制,竞争对手只能付诸法律手段。
Chrome 95开始试用Reduce User Agent string information特性,顾名思义,旨在简化User-Agent字符串,减少其信息量,缓解利用User-Agent字符串作为用户指纹,更好地保护用户隐私。同时,引导开发者使用更加保护用户隐私的User-Agent Client Hints来获取浏览器信息,降低大家对User-Agent字符串的依赖。
Chrome计划到Chrome 113彻底完成User Agent字符串的简化,不过从最终的结果来看,其实User-Agent的变化其实非常小。
以Chrome Windows用户为例,旧的User-Agent字符串是这样的:
Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.1234.56 Safari/537.36
简化之后最终的User-Agent字符串是这样的:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.0.0 Safari/537.36
Windows NT 6.3变成了Windows NT 10.0,Chrome/93.0.1234.56变成了Chrome/93.0.0.0,仅此而已。Windows的版本号被固定在了10.0,即使用户更新了操作系统,也不再变化了;Chrome的版本号仅保留大版本号,省略了小版本号。换句话说,我们依然可以通过User-Agent字符串获取浏览器的名称及其大版本号、操作系统的名称、区分桌面端和移动端。但是,我们无法通过User-Agent字符串获取浏览器的小版本号以及操作系统的版本了。另外,对于安卓端,手机的品牌及型号也不再提供。
User-Agent字符串所能提供的浏览器信息更加模糊了,这样有利于保护用户隐私。
如果开发者需要获取更加精确的浏览器信息,则需要使用User-Agent Client Hints,该特性在Chrome 89已上线。User-Agent Client Hints对应的HTTP请求Header字段如下表:
请求Header | 取值示例 |
---|---|
Sec-CH-UA | “Chromium”;v=”84”, “Google Chrome”;v=”84” |
Sec-CH-UA-Mobile | ?1 |
Sec-CH-UA-Full-Version | “84.0.4143.2” |
Sec-CH-UA-Platform | “Android” |
Sec-CH-UA-Platform-Version | “10” |
Sec-CH-UA-Arch | “arm” |
Sec-CH-UA-Model | “Pixel 3” |
Sec-CH-UA-Bitness | “64” |
浏览器默认仅发送Sec-CH-UA、Sec-CH-UA-Mobile、Sec-CH-UA-Platform,与User-Agent所提供的信息量一致,如果服务端需要获取其他User-Agent Client Hints字段的话,则需要明确指定所需要的字段。这样做的好处在于,浏览器默认提供的用户信息更少了,同时浏览器及Web应用理论上能够记录、审计服务端所请求的信息量,能够更加主动地保护用户隐私。
Web端的监控服务,例如ARMS、Fundebug、Sentry等,若需要获取更加准确的客户端信息,则需要使用User-Agent Client Hints了。当然,建议使用User-Agent Client Hints需要获得用户的授权,插件以及应用端不应该帮用户做决定,否则这个特性对用户隐私的保护就没有实际意义了。
这篇博客我所介绍的Chrome特性较少,只有4个,这是因为我并不打算介绍所有Chrome特性,没有必要,也没有这么多时间。对于《了不起的Chrome浏览器》的写作,我只关注以下4类特性:
对于其他特性感兴趣的同学,不妨直接查看Chrome Platform Status,这个站点介绍了Chrome的版本、特性以及发布日期。最近发现Chrome Platform Status会把Chrome每个版本的开发特性、试用特性以及移除特性也列出来,简直就是为了方便我写作,非常赞!
限于个人时间精力和知识盲点,我所写的内容难免有不够准确甚至错误的地方,欢迎大家批评指正,感兴趣的同学可以添加我的个人微信交流:KiwenLau。
欢迎关注寒雁Talk公众号,关注《了不起的Chrome浏览器》系列博客,与我一起见证大前端的星辰大海!
阿里巴巴业务平台事业部长期招聘P6及以上前端大佬,参与建设最前沿的阿里前端生态系统,推动行业技术发展,内推地址:hanyan.lk@alibaba-inc.com
欢迎大家关注我的微信公众号寒雁Talk。
]]>十多年来,Web技术突飞猛进,其中Chrome功不可没,了解Chrome可以帮助我们理解前端行业的发展趋势。
因此,我将以《了不起的Chrome浏览器》为题,对Chrome的每一个版本的重要特性进行详细解读,同时分享一些自己的一些思考:
通过专注于Chrome的写作,既可以可以提高我的专业能力,也可以提高个人影响力。我的长期目标是在2025年出版一本关于Chrome的书,毕竟出版自己的书每一个写作者最高的追求。
我是寒雁,一个热爱写代码和写文章的程序员,欢迎关注我的微信公众号寒雁Talk。
Chrome 94新增了试用特性WebGPU,提供了使用GPU的Web API,可以用于图像渲染(比如3D渲染)以及进行数据并行计算(比如机器学习)。
WebGPU对于Web来说无疑是一个革命性的特性,计算机行业本质上是通过摩尔定律(摩尔为CPU厂商Intlel的创始人之一)以及黄氏定律(黄氏即黄仁勋,GPU厂商英伟达的创始人,别号核弹教父)所推动的,芯片计算能力的提升为我们带来历次计算机行业革命:个人电脑、互联网、移动互联网、人工智能。当GPU的计算能力越来越强,越来越重要时,Web却不能很好得利用,这显然是不合理的。
WebGPU这个特性所对应的是WebGPU和WebGPU Shading Language这2个提案,由Google、Mozilla以及Apple的工程师负责。WebGPU和WebGPU Shading Language提案都是由W3C的GPU for the Web工作组起草的,该工作组成立于2017,经过4年的努力,WebGPU终于开始试用了,也是不容易啊!WebGPU提案定义了Web中使用GPU的API,WebGPU Shading Language(WGSL)提案定义了GPU代码的编程语言。WebGPU得到了4大浏览器巨头(Safari,Firefox、Edge)的支持,因此WebGPU成为正式的W3C标准只是时间问题。
WebGPU于Chrome 94开始试用,预计将于Chrome 98正式发布,时间大概是明年2月份。如此重要的特性,可能大家还没来得及学会怎么使用,只试用3个月时间就正式发布,似乎有点太仓促了。
WebGPU是WebGL的继承者,它们的目标类似,不过WebGPU提供了更加底层的GPU能力。因此,WebGPU的图像渲染能力更强,性能更好,更易用,也更加适用于数据并行计算以及机器学习。
根据Safari的测试结果,WebGPU的性能在各种设备上都远高于WebGL:
图片来源:WebGPU and WSL in Safari
前端机器学习库TensorFlow.js也测试了一下WebGPU,结果发现WebGPU的性能更好,但是差距与WebGL并不是特别明显,有待进一步研究:
图片来源:Fast client-side ML with TensorFlow.js
如下图,WebGPU是基于各种GPU API(例如DirectX 12、Metal、Vulkan)实现的。
图片来源:Access modern GPU features with WebGPU
WebGPU提供的是底层API,非常强大,同时也非常复杂。使用WebGPU实现向量乘法的代码长达200行,目测社区将会出现第三方库封装WebGPU,提供更简单的使用方式用于不同的应用场景。
根据测试,使用WebGPU进行向量乘法计算时,随着向量长度增加,其性能远优于使用CPU:
图片来源:Get started with GPU Compute on the web
Chrome 94正式发布了WebCodecs,使得我们可以直接使用Chrome所提供的图像、音频以及视频的编码/解码能力。
WebCodecs为W3C提案,由Google、Mozilla以及Microsoft的工程师负责,于Chrome 86开始试用。来自Firefox和Edge的工程师共同起草了WebCodecs提案,因此预计该提案将最终成为W3C标准。
Codec为coder和decoder合成词,即编解码器,它可以是硬件,也可以是软件,用于编码以及解码特定的数据格式,比如MP3/AAC/VP9/H264等。
浏览器器支持各种格式的图片、音频以及视频,但是之前我们并不能直接调用相应的编解码器。WebCodecs就是为了解决这个问题,让Web开发者可以直接使用各种编解码器。
为了优化性能同时保持一致性,Google Docs在今年5月份宣布将迁移至基于Canvas的渲染方案。不过,之前Google Docs在处理GIF时,仍然使用了HTML的标签。后来,Google Docs使用了WebCodecs的图片编解码器ImageDecoder将GIF解码,然后再使用Canvas渲染,这样做优化了性能,同时简化了代码架构。
Zoom在其Web Meeting SDK和Web Video SDK中使用了WebCodecs,由于源代码并未开源,因此具体怎么使用的不得而知,应该是用到了视频相关的编解码器。值得一提的是,由于Chrome 93的对WebCodes的更新有Breaking changes,导致Zoom的Web Meeting SDK和Web Video SDK出现了BUG,看来在第三方SDK中直接使用并未正式发布的特性,还是有挺大风险的。
Chrome 94正式发布了Scheduling APIs: Prioritized scheduler.postTask特性:
Prioritized Task Scheduling为WICG提案,由Google工程师负责,于Chrome 86开始试用。由于该提案暂未得到其他浏览器厂商的参与和支持,因此该特性最大的风险在于能否成为通用标准。
当我们用Lighthouse检测页面时,其中一个检测项为”Minimize main-thread work”,它将主线程的工作分为了下图所示的7个分类,可知主线程所承担的任务异常繁重:
由于主线程需要负责执行的任务过多,如果主线程被低优先级任务或者耗时任务(Long Task,即执行时间超过50ms的任务)过度占用,则会导致浏览器对用户操作的响应过慢,比如点击按钮长时间没有反应,这样会极大地损害用户体验。
用一个最极端的例子来举例,如果JavaScript代码陷入死循环,则页面将基本上完全卡顿,无法响应用户操作。感兴趣的话,可以在控制台执行以下代码:
while (true) { |
如果非关键JavaScript任务(比如日志)过多占用主线程或者关键的JavaScript任务(比如响应用户操作)等待太久,都会伤害用户体验。为了优化主线程的调度,requestIdleCallback和isInputPending等特性相继诞生,requestIdleCallback可以利用主线程渲染页面的空闲时间执行低优先级任务,isInputPending可以用于避免耗时任务阻塞响应用户操作。与requestIdleCallback和isInputPending相比,Prioritized Task Scheduling提案的调度功能更加完备和强大,支持根据优先级调度任务,支持指定延时调度任务,支持动态修改任务优先级以及取消任务。
通过使用scheduler.postTask,Aribnb的工程师将耗时任务拆分为小任务、推迟非关键任务、预下载图片。从优化效果来看,搜索结果页的Total Blocking Time(TBT)从16s降低到了6s,大幅优化了用户体验。不过,Total Blocking Time的最佳值是300ms以内,因此Airbnb所做的优化看起来还不算太理想。当然,这个值应该与具体应用相关。
Aribnb的工程师使用Scheduling APIs实现了图片预下载:
图片来源:Building a Faster Web Experience with the postTask
Scheduler
随着Web应用越来越复杂,主线程所承担的任务越来越多,如何减轻主线程负担将成为浏览器以及Web开发者所面临的重大课题,按照优先级调度任务将可能成为Web应用以及Web框架的最佳实践之一。另外,类似的减轻主线程负担的提案将不断涌现,这也会进一步强化Web应用的能力。
Chrome 94正式发布了Idle Detection API,用于检查用户是否活跃,其判断依据是用户是否使用键盘、鼠标、触摸屏等。
Idle Detection API为WICG提案,由Google工程师负责,于Chrome 84开始试用,Chrome 94正式发布。目前看来这个特性也只有Chrome支持,Firefox和Safari出于保护用户隐私,都明确表示反对该特性。
Apple对于用户的隐私及安全的坚持已经成为其企业文化的一部分,影响了它很多产品和技术上的决策,这是它不依赖广告赚钱的商业模式所决定的。根据statcounter的最新数据,Chrome和Safari的市场份额分别为64%和18%,因此Safari是Chrome最大的竞争对手。有Safari这样强大的对手制约Chrome,有利于保证Web的健康发展。
个人也反对这个特性Idle Detection API(虽然我的反对没啥用啊哈哈),它涉嫌侵犯了用户隐私,可以用于追踪用户的日常行为习惯,可能会用于比较变态的场景。
为了保护用户的隐私和安全,调用Idle Detection API需要得到用户的授权:
// 获取Idle Detection API授权 |
Idle Detection API可以用在以下场景:对于即时聊天、社交媒体、在线游戏,检查用户是否活跃,可以帮助用户判断他们的联系人是否在线。事实上,聊天应用Slack和Google Chat都表达了对该特性的兴趣。
当年PC版的QQ可以根据用户的鼠标键盘操作自动将状态切换至”离开”,然而移动互联网时代的聊天应用默认用户24小时在线。移动互联网给用户带来便利的同时,也绑架了大家的时间和精力,你能做到24小时不用手机吗?
Google工程师提供了一个非常直观的Demo应用Ephemeral Canvas,我们可以用它画图,当我们60秒内不操作电脑时,所画的图形会自动被擦除掉。
Chrome 94正式发布了JS Self-Profiling API,用于获取JavaScript执行时的性能数据。
JS Self-Profiling API为WICG提案,由Facebook的工程师负责,于Chrome 78开始试用,Chrome 94正式发布。
并不意外的是,Safari反对该特性,原因在于性能和安全问题。性能问题比较好理解,收集JavaScript执行过程中的性能数据会损耗性能。至于安全问题,Safari工程师担心的是黑客获取JavaScript的编译时长从而造成可能遭受时序攻击(Timing attack)。
看来,对于如何发展Web技术,Chrome与Safari有着非常不一样的观点,前者要激进很多,后者则相对保守。从我写的《了不起的Chrome浏览器》系列博客也可以看出来,Google工程师开发了非常多浏览器新特性,作为一个跟踪Chrome特性的写作者我都有点学不过来了,而对于大部分沉迷于写代码的开发者来说,很多特性可能都没听说过(此处不妨广告一下,如果你对Chrome的最新特性感兴趣,不妨关注我的微信公众号寒雁Talk)。这是Google和Apple不同的商业模式所决定的,Apple打造了封闭而完备iOS/macOS/iPadOS/watchOS生态系统,对Web技术的热情没有自家亲儿子那么高;而Web技术对于Google,是其安身立命的根本,网页都没了,搜索引擎还搜个球啊?所以,Chrome对于Google来说,远远不只是一个流量入口那么简单和无聊,Chrome致力于推动Web技术向前发展不是一句空话,Chrome当年的产品负责人成为Google的CEO也并非巧合,关于这一点,详见我2年前写的博客《Chrome是如何成功的?》。
虽然Safari对于JS Self-Profiling API不感兴趣,不过,来自Facebook和Microsoft的工程师都表示通过JS Self-Profiling API定位到了一些非常严重的性能问题,说明这个API应该还是有两把刷子的。因为JS Self-Profiling API并不影响产品功能,所以Safari不支持也没什么太大问题。反正苹果自研的芯片足够快,大概不会有性能问题?
Chrome 94支持在创建2D canvas时,使用Display P3色域,这将增强2D canvas的颜色还原能力。
canvas.getContext('2d', { colorSpace: "display-p3"} ); |
Canvas color management于Chrome 90开始试用,Chrome 94正式发布。这个特性我在《了不起的Chrome浏览器(4):Chrome 92新增at和randomUUID方法,Canvas支持Display P3色域》博客中介绍了,不过尴尬的是我搞错了,它并不是Chrome 92正式发布的特性。该特性得到了Firefox和Safari的支持,因此将成为通用标准。
之前,2D canvas仅支持陈旧的sRGB色域,但是现在的屏幕和相机早就支持更大的色域了。
色域是什么呢?它的英文名是Color Gamut或者Color Space,是设备(显示器、投影仪、打印机)可以表达的颜色范围。人眼可见的颜色范围是有限的,而设备能表达的颜色范围是人眼可见的颜色范围的子集,而不同色域标准比如sRGB和Display P3能表达的颜色范围也不一样。
Display P3的色域比sRGB的色域大25%,当我们对比两者时,会发现Display P3要比sRGB明亮很多,区别非常明显:
图片来源:Get Started with Display P3
对于图像、视频、设计、游戏、地图、美食等应用,颜色准确性的重要性不言而喻。
一些貌似与颜色无关的应用,如果我们的应用不能准确还原物体的颜色,也是会影响业务的。大多数情况下,买家秀和卖家秀的明显差异是由于卖家过度PS导致的,但是也有可能是颜色没有得到准确还原导致的。
Chrome 94新增了试用特性103 Early Hints for Navigation。
103 Early Hints for Navigation所对应的IETF提案为RFC 8297: 103 Early Hints,它本质上是对HTTP协议的更新,该提案由云服务商Fastly的工程师Kazuho Oku所提出。103 Early Hints for Navigation于Chrome 94开始试用,正式发布的Chrome版本还不确定。
值得一提的是,Fastly的CDN服务在今年6月份的时候出了一次故障,导致Amazon、Hulu、Reddit、Shopify等知名服务宕机,可见其影响力之大。Fastly提出103 Early Hints也不是完全用爱发电,这个特性也帮助其CDN服务。其CDN节点收到源站点的103状态码之后,可以根据其Header中是否包含Cache-Control: private,来提前决定是否复用CDN节点缓存的资源,提高响应速度。由这个简单例子也可以看出,有时候一些技术问题是没法在现有的技术标准体系内得到很好的解决,需要改变标准本身。由此推断,中国的程序员应该更多地参与国际技术标准的制定,这是有现实意义的。当然,这么做短期来看投入产出比可能没有那么高,但是长远来看,也是必由之路吧。
下图非常直观地展示了103 Early Hints for Navigation的作用,它可以在前一个HTTP请求Header以及response都还没有返回的时候preload后续资源,从而将后续的HTTP请求大幅提前,从而减少整体的请求时间,提高网络的利用率。
图片来源:Towards ever faster websites with early hints and
priority hints
图片来源:Towards ever faster websites with early hints and
priority hints
图片来源:Towards ever faster websites with early hints and
priority hints
显然,第3种情况下,整体的响应时间要快很多,对网络的利用率也提高了。我们不妨看一下第3种情况下,具体的请求过程。
浏览器发起访问example.com的请求:
GET / HTTP/1.1 |
服务端返回103,Header中包含preload信息,这时浏览器就可以发起style.css以及script.js请求了:
HTTP/1.1 103 Early Hints |
服务端返回200,Header中包含preload信息,并且html文本中也包含所需要的css以及js文件(这不是废话吗?)。
HTTP/1.1 200 OK |
从Chrome 94开始,Chrome将加快其更新频率,由每6周更新一个版本改为每4周更新一个版本。对于一个全球拥有26亿用户的产品,加快发布频率可以为用户提供更好体验,同时也会为研发团队带来巨大的挑战。Chrome能够一直保持稳定的迭代频率,同时提供保持透明,提供丰富的文档,这为Chrome生态系统内的开发者提供了便利,这一点非常值得我们学习。
本篇是《了不起的Chrome浏览器》的第6篇,创造了个人写专题系列博客的记录,之前的《JavaScript深入浅出》系列只写了5篇。Chrome加快更新频率之后,我也必须调整自己的写作计划,与Chrome的版本迭代保持同步。
细心的同学可能会发现,我这篇博客有一些细微的不同点,以后我也会坚持这样做:
本文介绍7个特性,其中6个特性都涉及到新的Web技术标准,可见Chrome是真的致力于Make Web Gread Again(MWGA),Google程序员为了OKR也是挺拼的。相比之下,Firefox和Safari看起来要佛系很多,这与各个公司的商业模式以及投入程度有关。不过,Chrome在掌握Web技术的主导权之后,有点为所欲为了,有些特性不顾同行的反对,推进速度也有点太快了,这就不太妙了。Web与其他平台不一样的地方在于,它是开放的,是属于所有人的,也有向后兼容的问题,因此Web技术标准不能一家说了算,也不能太随意,否则对Web技术的长远发展并不利。可惜的是,现在Web技术标准和国内的程序员没有什么太大关系,我们无从置喙,只能当吃瓜群众。。。等哪天国产浏览器拥有更大的话语权再说吧。
还有一点,对于每一个特性,我都花了大量时间阅读各种资料来理解其原理,然后根据个人理解来写的,很多特性我也没有时间去写代码测试,因此我的说法难免有错误的地方,欢迎各位大佬批评指正。感兴趣的同学可以添加我的个人微信交流:KiwenLau。
欢迎关注寒雁Talk公众号,关注《了不起的Chrome浏览器》系列博客,与我一起见证大前端的星辰大海!
阿里巴巴业务平台事业部长期招聘P6及以上前端大佬,参与建设最前沿的阿里前端生态系统,推动行业技术发展,内推地址:hanyan.lk@alibaba-inc.com
欢迎大家关注我的微信公众号寒雁Talk。
]]>十多年来,Web技术突飞猛进,其中Chrome功不可没,了解Chrome可以帮助我们理解整个行业的发展趋势。
因此,我将以《了不起的Chrome浏览器》为题,对Chrome的每一个版本的重要特性进行详细解读,同时分享一些自己的一些思考:
通过专注于Chrome的写作,既可以可以提高我的专业能力,也可以提高个人影响力。我的长期目标是在2025年出版一本关于Chrome的书,毕竟出版自己的书每一个写作者最高的追求。
我是寒雁,一个热爱写代码和写文章的程序员,欢迎关注我的微信公众号寒雁Talk。
Chrome 93支持了Error Cause,支持在新建Error时配置cause参数,这样可以帮助我们更好的进行异常处理:
try { |
Error Cause提案由阿里巴巴的昭朗同学负责,从去年9月份开始,到今年3月份进入Stage 3,再到现在Chrome支持,整个推进速度还是蛮快的。
再次恭喜昭朗同学,这是我国首个进入Stage 3的EcmaScript提案!
Error Cause提案本身很简单,但是它的价值还是蛮大的,社区类似的解决方案@netflix/nerror的周下载量高达10万。
但是,如何在一个国际化的标准组织推动一个提案,可不是一件简单的事情,需要耗费不少的时间和精力。
作为一个程序员,能够让编程语言变得更好,是一件挺有价值的事情,感兴趣的同学赶紧行动起来吧!
Chrome 93新增了Object.hasOwn方法,用于判断Object是否存在某个属性:
const obj = { name: "test" }; |
不是有了Object.prototype.hasOwnProperty么?有啥区别?
const obj = { name: "test" }; |
hasOwnProperty的函数名有点冗长,社区还有一个npm包has来解决这个问题,其周下载量高达2200万。hasOwn比hasOwnProperty更短,这会让它得到大家更加偏爱,不过这倒不是问题的关键。
hasOwnProperty是通过propertype继承的方法,可以被重写,这会导致结果错误:
let foo = { |
ESLint的no-prototype-builtins规则就是为了避免这个问题,禁止调用Object.prototype所继承的方法。
hasOwn是Object的静态方法,其实还是可以通过Object.defineProperty重写,这就有点尴尬了…
为了防止ALPACA攻击,Chrome 93屏蔽了989和990端口,即FTPS协议所使用的端口
ALPACA攻击由一些德国科学家所发现,今年6月份才公开,是一种非常巧妙地跨应用层网络协议的攻击方式,利用了同一个TLS证书被多个不同协议的服务复用的问题。
ALPACA攻击的详细过程如下图:
图片来源:ALPACA Attack
<!-- 代码来源:https://github.com/RUB-NDS/alpaca-code/blob/master/testlab/servers/files/nginx-attacker/html/upload/ftps.html --> |
看起来挺可怕的,但是实际上还好,因为实施ALPACA Attack的前提条件挺多的,还是以Upload Attack为例:
因为实施这一攻击的前提条件比较多,所以它更多的是一种理论上的攻击方式,不必过于担心。虽然说ALPACA Attack实际威胁不大,但是它所发现的问题还是很有价值的,它发现了看似牢不可破的TLS的隐藏漏洞:同一个证书被多个不同应用层协议共用以及不保护IP和端口。目前来看,最好的预防方式是不要跨协议共享TLS证书,同时启用ALPN。
至今,Chrome已经累计屏蔽了13个端口,见下表:
日期 | Chrome版本 | 屏蔽端口 | 目的 | 详情 |
---|---|---|---|---|
2021-08-31 | Chrome 93 | 989、990 | 阻止ALPACA攻击 | Feature: Block ports 989 and 990 |
2021-05-25 | Chrome 91 | 10080 | 阻止NAT Slipstream 2.0攻击 | Feature: Block HTTP port 10080 |
2021-04-14 | Chrome 90 | 554 | 阻止NAT Slipstream 2.0攻击 | Feature: Block HTTP port 554 |
2020-11-17 | Chrome 87 | 5060、5061 | 阻止NAT Slipstream攻击 | Feature: Block HTTP ports 5060 and 5061 |
69、137、161、 1719、1720、1723、6566 | 阻止NAT Slipstream 2.0攻击 | Feature: Block HTTP ports 69, 137, 161, 1719, 1720, 1723, and 6566 |
所以大家以后看到哪个端口不能再用了,不要感觉奇怪。道高一尺魔高一丈,目测被屏蔽的端口会越来越多。再这样搞下去,是不是只有443端口能用了?
为了预防Sweet32攻击和Lucky Thirteen攻击,Chrome 93移除了对TLS_RSA_WITH_3DES_EDE_CBC_SHA密码套件的支持。
TLS_RSA_WITH_3DES_EDE_CBC_SHA密码套件的名字很长,其中3DES和CBC代表对称加密算法,它在2016年被证明可以被Sweet32攻击。
我们不妨重点分析一下Sweet32攻击是怎么回事。
3DES是对称加密算法( symmetric encryption),同时也是分块加密算法(block cipher)。它会将需要加密的文本切分为64位的文本块,然后对每一块进行加密。
由于3DES算法的分块长度只有64比特(更安全的AES算法的分块长度是128比特),因此它容易受到生日攻击(birthday attack)。
生日攻击(birthday attack)的原理来源于生日悖论(birthday paradox):
在不少于23 个人中,至少有两人生日相同的概率大于50%。 例如在一个30 人的小学班级中,存在两人生日相同的概率为70%。 对于60 人的大班,这种概率要大于99%。
生日悖论并不是真正的悖论,通过简单的概率公式就能算出来,它只是违反了我们的直觉,因此被称为”悖论”。
基于生日悖论,可以推导出(此处忽略推导过程),只要收集足够多的3DES加密块,其中必定会出现完全相同的3DES加密块。
另外,由于CBC加密算法可以被碰撞攻击(collision attack)。只要找到相同的3DES加密块,就可以根据部分已知明文通信内容恢复部分未知的加密通信内容比如Cookie(此处再次忽略推导过程)。
因此,黑客所要做的事情,就是发起CSRF攻击,重复发送大量HTTPS请求,JavaScript代码如下:
// 代码来源:https://sweet32.info/ |
然后,黑客进行抓包,并找到相互冲突的3DES加密块。找到足够多的冲突,就可以恢复Cookie了。
Chrome 93更新了WebOTP API,支持跨设备。这里所谓的跨设备,指的是安卓端和PC端的Chrome浏览器。
当你的安卓端和PC端的Chrome浏览器都登录了同一个Google账号,安卓手机收到短信验证码之后,不再需要在PC端手动输入了,在手机端直接提交即可:
视频来源:Verify a phone number on desktop using WebOTP API
WebOTP这个名字有点奇怪,其中OTP是one-time-passwords的缩写,指的就是手机的短信验证码。对于很多iOS和安卓APP,我们已经不再需要手动复制粘贴验证码了,APP可以自动识别和提取验证码,我们只需要轻点一下即可。WebOTP就是为了给Web应用带来相同的体验。
如下图,Web应用可以通过navigator.credentials.get获取OTP,当收到短信验证码时,Chrome则可以自动匹配对应域名的OTP,用户确认之后则可以直接验证OTP,不再需要手动复制粘贴验证码,其流程如下图:
图片来源:Verify phone numbers on the web with the WebOTP API
WebOTP API是去年Chrome 84新增的,并且支持在跨域的iframe中使用:
日期 | Chrome版本 | 说明 | 详情 |
---|---|---|---|
2021-08-31 | Chrome 93 | WebOTP API支持跨设备 | Feature: WebOTP API: cross-device support |
2021-05-25 | Chrome 91 | 支持在跨域的iframe中使用WebOTP API | Feature: WebOTP API: cross-origin iframe support |
2020-07-14 | Chrome 84 | 新增WebOTP API,用于自动提取手机短信验证码 | Feature: WebOTP |
Chrome 93更新了Clipboard API,支持SVG格式。这一特性,有望用于图片相关的应用(比如:Inkscape, Adobe Illustrator,Figma、Photopea)。
Clipboard API可以用于剪贴板的读写,支持异步比同步接口document.execCommand的性能更好、基于permission API的权限控制更安全。
Clipboard API是2018年Chrome 66新增,目前已经支持图片、HTML、文件等多种格式,功能越来越强大:
日期 | Chrome版本 | 说明 | 详情 |
---|---|---|---|
2021-09-21 | Chrome 94 | Clipboard API支持从剪贴板读取保留metadata的原始PNG文件 | Feature: Clipboard: Preserve PNG metadata |
2021-08-31 | Chrome 93 | Clipboard API支持复制粘贴SVG | Feature: Clipboard API: Svg |
2021-05-25 | Chrome 91 | Clipboard API支持从剪贴板读取只读文件 | Feature: Clipboard: read-only files support |
2020-10-06 | Chrome 86 | Clipboard API支持复制粘贴HTML | Feature: text/html support for async clipboard api |
2020-08-25 | Chrome 85 | Clipboard API支持feature policy(即permission policy) | Feature: Feature Policy for Clipboard API |
2019-07-30 | Chrome 76 | Clipboard API支持复制粘贴图片 | Feature: Async Clipboard: Read and Write Images |
2018-04-17 | Chrome 66 | 新增异步Clipboard API | Feature: Asynchronous Clipboard API |
本篇是《了不起的Chrome浏览器》的第5篇,凑满5篇就可以召唤神龙了?
其实,我2年前还写过一个《JavaScript深入浅出》系列,不过后来因为工作的巨大变动(详见:从创业者到打工人,我在阿里这1年)放弃了:
所以,当我开始写《了不起的Chrome浏览器》时,我也挺担心自己会再次放弃,现在写到第5篇,这样的担心越来越少了:
所以,《了不起的Chrome浏览器》我还是会写下去的!
欢迎关注寒雁Talk公众号,关注《了不起的Chrome浏览器》系列博客,与我一起见证大前端的星辰大海!
阿里巴巴业务平台事业部长期招聘P6及以上前端大佬,参与建设最前沿的阿里前端生态系统,推动行业技术发展,内推地址:hanyan.lk@alibaba-inc.com
欢迎大家关注我的微信公众号寒雁Talk。
]]>十多年来,Web技术突飞猛进,其中Chrome功不可没,了解Chrome可以帮助我们理解整个行业的发展趋势。
因此,我将以《了不起的Chrome浏览器》为题,对Chrome的每一个版本的重要特性进行详细解读,同时分享一些自己的一些思考:
通过专注于Chrome的写作,既可以可以提高我的专业能力,也可以提高个人影响力。我的目标是在2025年出版一本关于Chrome的书,毕竟出版自己的书每一个写作者最高的追求。
我是寒雁,一个热爱写代码和写文章的程序员,欢迎关注我的微信公众号寒雁Talk。
Chrome 91默认开启了WebAssembly SIMD。
SIMD是Single Instruction Multiple Data的缩写,中文术语为“单指令多数据流”,顾名思义,就是可以使用单条指令同时处理多个数据。
SIMD是一种特殊的CPU指令,它可以实现数据层面的并行处理。如下图,当我们需要对两个长度为4的数组做加法时,使用普通的指令,则需要执行4次普通加法指令;如果使用SIMD指令的话,则只需要执行1次向量加法即可:
SIMD常用于视频、音频、图像、加密、动画、游戏、AI等需要处理大量数据的应用场景,可以极大地提高向量类型的数据处理性能。主流的CPU都有SIMD指令,比如x86的SSE、ARM的Neon。
WebAssembly SIMD为WebAssembly新增了一个变量类型v128及其一系列v128的运算符,这些运算符就是SIMD指令。另外,由名字可知v128类型的长度是固定的,为128比特。
SIMD的指令非常多,而且不同CPU的SIMD是不一样的,WebAssembly SIMD只选取了各个CPU都支持的部分最常用的SIMD指令。因此,可以将WebAssembly SIMD理解为各个CPU的SIMD指令的子集,同时将各个CPU的SIMD指令进行了一层抽象和统一,开发者只需要学习WebAssembly SIMD,而不需要了解底层CPU的SIMD。
目前,Emscripten仅支持将WebAssembly SIMD指令编译为x86 SSE/AVX指令以及ARM Neon指令。
在计算机领域,貌似没有什么问题是用分层解决不了的,如果有的话,可以再分一层。
目前,WebAssembly SIMD这个提案已经进入WebAssembly提案流程的Phase 4(Standardize the Feature),尚未完全完成,不过离最后完成也只有1个Phase了,可以理解为基本完成了,V8(Chrome、Node.js)、Firefox以及Emscripten都已经实现了WebAssembly SIMD。
在手势识别应用中,WebAssembly SIMD可以明显提高性能,使用SIMD和不使用SIMD的差距非常明显(两者都可以直接进行测试),使用SIMD时帧率更高,画面更加流畅,如下图所示:
TensorFlow.js 2.1.0已经支持了WebAssembly SIMD。以下为基于TensorFlow.js所实现的人脸识别应用BlazeFace,使用WebAssembly SIMD可以将其性能提升1.7~ 2.1倍:
对于更加复杂的应用,比如AI领域大名鼎鼎的ImageNet,其基于TensorFlow.js所实现的MobileNet V2模型,使用WebAssembly SIMD可以将其性能提升2.2 ~ 4.5倍:
Chrome 91支持基于HTTP/2的Websocket。
WebSockets和HTTP/2分别是什么,想必大部分Web工程师都知道了,但是,WebSockets和HTTP/2掺和在一起是啥意思呢?
要回答这个问题,不妨先梳理一下时间线:
时间 | RFC |
---|---|
1999 | RFC 2616:Hypertext Transfer Protocol – HTTP/1.1 |
2011 | RFC 6455:The WebSocket Protocol |
2015 | RFC 7540:Hypertext Transfer Protocol Version 2 (HTTP/2) |
2018 | RFC 8441:Bootstrapping WebSockets with HTTP/2 |
10年前所制定的Websocket协议是基于HTTP/1.1的,10年后,HTTP/2已经被一半的网站所使用。如果Websocket继续使用HTTP/1.1协议的话,则无法利用HTTP/2最大的好处:多路复用。
如果基于HTTP/1.1的话,Websocket需要单独的TCP连接,这挺浪费系统资源的,尤其对于需要建立大量Websocket的应用来说,比如Slack。
如果基于HTTP/2的话,Websocket与其他HTTP/2请求复用同一个TCP连接,既节省了建立TCP连接的时间,也节省了宝贵的TCP连接。
为了缓解NAT Slipstream 2.0攻击,Chrome 91又屏蔽了一个新的端口:10080。
自从去年11月底NAT Splipstream被发现以来,Chrome已经屏蔽了11个端口了,具体如下表:
Chrome版本 | 屏蔽端口 |
---|---|
Chrome 91 | 10080 |
Chrome 90 | 554 |
Chrome 87 | 5060、5061、69、137、161、 1719、1720、1723、6566 |
当我们访问这些被屏蔽的端口时( http://127.0.0.1:554 ),会出现报错页面:ERR_UNSAFE_PORT
NAT Splipstream是一种非常巧妙、同时也非常危险的攻击方式,黑客可以通过一段JS代码绕开防火墙,访问内网的服务,比如打印机和摄像头。大家可以通过下面的视频感受一下其攻击过程:NAT Slipstreaming 2.0攻击演示。
关于NAT Splipstream攻击的技术细节,大家不妨看一下我的上一篇博客《了不起的Chrome浏览器(2):Chrome 90将默认使用HTTPS,Web更安全了》。
目测Chrome屏蔽的端口有可能会继续增加,大家如果看到ERR_UNSAFE_PORT这个报错也不用感到奇怪,换个端口用吧。
Chrome 91新增了GravitySensor API,用于获取设备(比如手机)由于地球重力而产生的加速度。
GravitySensor API可以用于开发游戏,比如在赛车类游戏中,通过倾斜手机控制赛车的方向。事实上,GravitySensor API这个需求也正是是游戏引擎Unity的开发者反馈给Chrome团队的。
Chrome 91最大的亮点是WebAssembly SIMD,它通过提高Web平台的性能进一步拓展了Web应用的可能性,比如视频、音频、图像、加密、动画、游戏、AI等领域。因此,本文最大的篇幅都是在介绍WebAssembly SIMD。
类似于WebAssembly SIMD这样的创新会不断出现,从而继续提升Web应用的性能,让Web可以应用于更加广阔的领域。正如过去的10多年,V8引擎在性能上的不断优化促是Web技术走向繁荣的关键因素之一,我们也可以预见,未来10年的Web将更加精彩。
关于《了不起的Chrome浏览器》,本文已经是第3篇了,因此我从这篇开始加上了编号。我在写每一篇博客都会查阅大量的原始资料,这样能学到新的知识点,也可以发现新的问题,这正是我热爱写作的原因。对于我来讲,WebAssembly SIMD也是新的知识点,我可以通过写作把它的来龙去脉搞清楚,然后分享给大家,这件事还是挺有意思的。
欢迎关注寒雁Talk公众号,关注《了不起的Chrome浏览器》系列博客,与我一起见证大前端的星辰大海!
阿里巴巴业务平台事业部长期招聘P6及以上前端大佬,参与建设最前沿的阿里前端生态系统,推动行业技术发展,内推地址:hanyan.lk@alibaba-inc.com
欢迎大家关注我的微信公众号寒雁Talk。
]]>十多年来,Web技术突飞猛进,这其中,Chrome功劳是最大的,可以说没有之一。身处大前端这个领域,了解Chrome可以帮助我们理解整个行业的发展趋势。
其实,我一直都挺关注Chrome的,也写过一些关于Chrome的博客:
写Chrome 89博客的过程中,我意识到,关于Chrome的写作,我可以做得更加专注、更加深入、更加体系化一些。这样,一方面我可以提高专业能力和写作能力,另一方面也可以提高影响力。我也希望自己可以在5年之内出版一本关于Chrome的书,毕竟出书是每一个写作者最高的追求。
因此,我将以《了不起的Chrome浏览器》为题,对Chrome的每一个版本进行详细解读,同时也会深入去介绍Chrome各方面的细节,分享一些自己一些并不成熟的思考,欢迎大家关注寒雁Talk公众号。
在浏览器地址栏输入URL,然后回车,之后发生了什么?这是一个非常经典的面试题。
Chrome 90开始,将会默认使用HTTPS协议打开URL,让这个面试题的答案变了一点点,喜欢背面试题的同学可以重点关注一下。。。
当我们输入example.com,Chrome 90之前的版本会默认访问http://example.com,服务端如果配置了重定向,则会重定向到https://example.com;而Chrome 90会默认访问https://example.com。两者具体的不同点如下图所示:
眼见为实,不妨简单测试一下(果然翻车了)。PS:测试之前需要:清除浏览数据,否则Chrome第二次访问时会默认使用HTTPS。
当我使用Chrome 89打开kiwenlau.com时,会发现第一个请求使用的是HTTP协议(http://kiwenlau.com/),返回状态301,重定向到https://kiwenlau.com/,之后所有的请求使用的都是HTTPS协议:
当我使用Chrome 90打开kiwenlau.com时,会发现第一个请求居然使用的依然还是是HTTP协议(http://kiwenlau.com/),而不是HTTPS协议,这就很尴尬了:
我本来以为这是BUG,于是给Chrome团队提了一个issue:
根据回复,Chrome团队还在对这个特性进行灰度,如果希望开启这个特性,可以到chrome://flags把#omnibox-default-typed-navigations-to-https设为”Enabled”:
严格来讲,只有第一次访问kiwenlau.com的第一个请求使用了HTTP协议,貌似也没什么大不了的。不过,要知道HTTP协议本身是明文传输(其实HTTP/2也没有要求非得加密,只是所有的浏览器都要求HTTP/2必须加密,这样的话,只有HTTPS才能升级HTTP/2)的,这意味着网络中每一个节点都是能查看并且篡改HTTP的通信内容,想想是不是有点后怕,对于那些喜欢访问奇奇怪怪网站的同学。
如果使用Charles抓包来对比一下,可以发现,对于HTTP请求,Contents是明文:
对于HTTPS请求,Content是加密后的,看起来是乱码:
当然,对于支持HTTPS的站点,省去了HTTP到HTTPS重定向这一步,也是可以提高访问性能的,不过这个问题倒是其次的,毕竟只有一个HTTP请求,而且很多网站本来就很慢了,不在乎这几十毫秒。。。
Chrome一直在推进HTTPS协议在业界的应用,关于这一点,我之后写一篇博客详述(挖坑)。
AV1的全称为AOMedia Video 1,是一个开源、免费的视频编码格式,编码效率更高。根据Netflix、Facebook的数据,AV1相对于VP9,可以将压缩效率提升20% ~ 30%左右。爱奇艺也在去年启用了AV1格式,可以节省20%的带宽。Youtube最新定制的视频芯片(VCU,Video Coding Unit)Argos也支持了AV1。
对于视频类应用来说,昂贵宽带费用一直是非常沉重的负担,这也是一些知名长视频网站一直无法盈利的关键原因之一(另外一个关键因素是内容成本)。根据爱奇艺最新的2020年财报,其2020年净亏损70亿人民币,其中带宽开支高达24亿人民币,占了亏损的34.3%。对于爱奇艺这种视频类应用来说,使用AV1这种更高效的视频编码格式,有利于减少宽带费用。
WebRTC的全称为Web Real-Time Communication,用于在Web应用中实现实时的视频和语音通信。其实WebRTC已经是个已经有10年历史的技术了,疫情的爆发促进了视频会议需求的爆发,使得WebRTC变得更加重要了。
Chrome 90支持了AV1 Encoder,用于优化WebRTC视频通信:提升压缩效率,减少带宽使用;支持30kbps以及更低码率的视频,服务低带宽的用户;优化了屏幕共享效率。
疫情在全球范围内爆发已经1年多了,这极大地增强了用户对于视频会议、直播的需求,AV1 Encoder这样的技术进步也可以帮助大家渡过现在的难关,这也是技术最大的意义。
AV1是由AOMedia(Alliance for Open Media)开发的,旨在取代Google开发的VP9,同时与需要收取专利费的H.263展开竞争。AOMedia其实也不是外人,Google是其核心成员,且AV1也是由Google主导开发的。作为程序员,不得不服Google对于技术进步推进是全方位的,哪里都能看到它的身影。关于Google是如何推进视频编码格式技术的进步,这又是另外一个话题了,我之后写一篇博客详述(再次挖坑)。
对于使用WebRTC开发Web视频会议应用的同学,不妨试用一下AV1 Encoder,也可以给大家分享一下到底效果怎么样。
WebXR Depth API和WebXR AR Lighting Estimation都是WebXR相关的特性更新,WebXR Depth API可以用来获取用户的设备与现实环境中物体的距离,WebXR AR Lighting Estimation可以用来获取环境的光线情况。
估计绝大部分人都没用过WebXR,所以还是先了解一下WebXR是啥…
WebXR其实就是在Web上开发AR(Augmented Reality)和VR(Virtual Reality)应用的API,AR和VR都是以字母R结尾,所以就取了个XR的名字。
在WebXR Experiments,有一些WebXR的示例,可以让大家实际感受一下WebXR能干嘛。
比如,Sodar就可以用来测量2m社交距离:
还有一个没有正式发布的示例Picturescape,看起来还挺有意思的,不过没太看懂具体是做什么的,等正式发布之后可以再看看:
从WebXR的示例来看,目前WebXR所实现的应用还比较简单,毕竟VR和AR技术本身目前的应用也比较简单粗糙。我最感兴趣的还是其在游戏领域的应用,《头号玩家》中的游戏体验什么时候可以实现呢?拭目以待!
Chrome 90屏蔽了554端口,这是为了缓解NAT Slipstream 2.0攻击。注意,这里用的词是缓解而不是解决,Chrome没法从根本上阻止NAT Slipstream 2.0攻击。
NAT Slipstream是去年10月底由Samy Kamkar发现的一种非常巧妙也非常危险的攻击方式,后来他又与Armis研究员Ben Seri和Gregory Vishnipolsky发现了新一版的NAT Slipstream 2.0的攻击方式。
简单来说,受害者只需要访问黑客的网站,该网站嵌入了黑客的JavaScript脚本,黑客就可以绕开受害者所在的局域网的防火墙,访问受害者所在的局域网中的任意TCP/UDP服务。
大家不妨通过NAT Slipstreaming 2.0攻击演示这个视频感受一下整个攻击流程是怎样的。
受害者位于局域网中,局域网中连接的设备有受害者的智能手机、打印机、网络摄像头、打印机以及路由器,理论上局域网中的设备都是受到防火墙的保护的。而黑客位于Internet中,理论上是无法绕过防火墙直接访问局域网中的设备,比如打印机和网络摄像头。
受害者使用智能手机访问了黑客所提供的链接,攻击者成功绕过防火墙,获取打印机和网络摄像头的访问权限,远程给打印机发送打印任务,并且通过默认的账户密码远程访问网络摄像头。
如果你家的摄像头可以被黑客查看,是不是很可怕,赶紧把默认密码改了吧!
当然,如果打印机和网络摄像头都设置了比较严格的密码的话,攻击者也是没法访问它们的。所以,局域网中的设备也是必须做好安全防范的。但是这并不是重点,重点是攻击者绕过了防火墙,这又是怎么做到的呢?
Samy Kamkar的原文很长,所涉及的技术细节非常多,其实最关键的就是以下这段JavaScript代码:
// our sip message |
这段代码,其实就是发送了一个特殊定制的POST请求,而这个POST请求由于体积过大,会被分成多个TCP包。从代码中可知,这些TCP包所请求的端口是5060,这恰好是SIP协议所使用的端口。黑客可以通过定制POST请求的大小来控制TCP包,让其中一个TCP包恰好会被NAT设备理解为SIP REGISTER包,NAT设备看到这个包,则会为攻击者打开一个公网端口,并且转发到攻击者所需要访问的内网TCP服务,代码中为192.168.0.109:1234。这样,黑客就可以通过NAT上的公网端口来访问内网服务192.168.0.109:1234。NAT设备则傻傻地帮黑客转发请求。
这种攻击方式非常有创意,涉及的技术细节非常多,我之后写一篇博客详细解释一下(又挖了一个坑)。当然,这种攻击方式也非常危险,Samy Kamkar真是个天才,还好他是白帽黑客。
Chrome屏蔽端口这种做法其实也是治标不治本,黑客确实没办法给所屏蔽端口发送请求了,但是如果受害者不更新浏览器的话,还是会被攻击。要从根本上解决这个问题,还是需要NAT设备以及防火墙来想办法。
物联网时代,家里联网的设备越来越多了,作为用户,我们还是需要做好保护措施:
当然,你可以选择断网,远离危险的互联网世界,哈哈:(
在我看来,Chrome 90最重要的更新,是默认使用HTTPS协议,其实是非常小的改动,但是还是蛮重要的。可惜这个特性还在灰度发布过程中,并没有真正发布。HTTP裸奔的时代终于快要结束了,站在现在的角度去看过去,一想到以前Web居然是基于明文传输协议的,感觉那是一个刀耕火种的时代。当然,那也是一个伟大的时代,Web的诞生本身就是一件改变人类文明的事情,我们都是站在巨人的肩膀上。
另外,本文还介绍了AV1、WebXR以及NAT Slipstreaming相关的特性,重点放在了背景知识的介绍,这是因为这些特性本身对绝大多数开发者并没有什么价值,且比较枯燥无味,没有相关应用场景的同学基本上不会用到这些特性,不过这些关于这些特性的背景知识还是需要了解一下的,可以帮助我们更加全面的理解大前端的方方面面。《了不起的Chrome浏览器》之后的博客,我也会延续这种写作风格,希望大家能够喜欢。
我在文章后面裂了非常多的参考资料,这是我读研的时候写论文养成的习惯,只要我写的内容有参考过的资料,我都会列出来,这个其实主要是为了方便我自己以后查阅,其次是分享给感兴趣的读者。其中,有一些高质量的内容我把字体加粗了,不妨重点关注一下。
在写作的过程中,我也发现了3个比较有意思的话题,是可以进一步展开的,第1点是关于Chrome对于HTTPS技术推广所做的事情,第2点是关于Google推动视频编码技术进步所做的贡献,第3点是NAT Slipstreaming,后面我也会分别写博客介绍,欢迎关注。
欢迎关注寒雁Talk公众号,关注《了不起的Chrome浏览器》系列博客,与我一起见证大前端的星辰大海!
阿里巴巴业务平台事业部长期招聘P6及以上前端大佬,参与建设最前沿的阿里前端生态系统,推动行业技术发展,内推地址:hanyan.lk@alibaba-inc.com
欢迎大家关注我的微信公众号寒雁Talk。
2月底的时候,当我收到入职1周年的邮件的时候,我是真的挺开心的。
我是一毕业就创业了,一直坚持了3年多,从一个创业者转型成为一个打工人,可不是一件什么容易的事。如何调整自己的心态?如何适应新的工作方式?如何接受不同的企业文化?
这一年没有了创业时那种自由自在的感觉,不少时候工作压力也蛮大的,一直在思考和调整,好在还是坚持下来了,不容易呐。
这1个月也一直在思考自己这一年究竟是怎么过来的(从哪里来),未来应该怎么继续走下去(到哪里去),有了一些想法,不妨分享一下。
创业是一件停不下来的事情,很多人成为了连续创业者,极少数大佬成功了,比如马云、王兴、张一鸣、雷军,绝大多数人都成了炮灰。
而我选择了暂时放弃创业,进入大厂工作,可能听起来不那么酷,但是这是最理性选择。创业需要天时地利人和,我可不想成为炮灰。
虽然我一直有点不走寻常路,比如大二换到计算机专业、留学选择了日本而不是美国、放弃读博、休学创业、放弃买房选择投资股票和基金,但是我从来都不是赌徒,我所有的选择都是基于理性的思考,而不是一时冲动。就拿创业来说吧,我真正决定创业的时候,产品的代码其实半年前就开始写了,只是还没有真的想清楚下决心,后来和导师讨论了1个月才正式提出休学申请。
那我为什么选择阿里而不是其他公司呢?
和其他大厂一样,阿里远不是完美的,也有一些这样那样的问题,我当然也会吐槽,不过整体来看,我在阿里过得还不错吧。
同事们都很优秀,智商和情商都很高,大家相处得也挺开心的,互相帮忙,互相学习,共同成长。
完成了一些有意思的工作,过程虽然比较艰辛,但是自己感觉还是可以的。
对于工作内容也越来越熟悉了,更加从容,终于有更多时间做一些更有意思的事情了。
目测阿里绝大部分部门是没有996的,我们也没有。放假前一天食堂就少了很多人,节假日更加没人。节假日加班是有加班工资或者调休的,我全年一共加了5天班,年假也可以全部休完。其实,这本来就是合理合法的事情,之所以强调一下,是因为996是外界对于阿里最大的误会吧,这让我们招聘的时候都必须解释一下,可以说相当尴尬了…
当然,我们晚上还是得加班的,否则事情确实做不完,但这不是阿里一家公司的问题,某些其他大厂加班更严重,这是整个中国互联网行业的困境,原因是多方面的:市场、文化、法律、经济、还有那远比发达国家还贵的房价。长期加班对于个人、公司以及整个国家都是一种伤害,而最伟大的创新也并不是靠加班能搞得出来的,人家Google不加班照样不停地改变世界。不过,对于未来我还是很乐观的,减少加班是大势所趋。拼命学习然后成绩很好的叫学霸,按照正确的方法轻松学习然后成绩更好的叫学神,我们是想成为学霸还是学神呢?
我觉得自己还是挺幸运的,来了阿里之后,经历了公司内部一些积极的变化,比如取消周报、调整361政策、提高餐补….虽然我很喜欢写文章,但是对于写周报不太感冒,相信未来会有更多积极的变化。
阿里的内网还是非常精彩的,很多发人深省的帖子,很多有价值的观点和思考,我也找到了一些共鸣,其实明白人还是挺多的,公司也在响应基层员工的声音。我想这应该是阿里企业文化最强大的一点吧,大家可以充分自由地表达自己的观点,帮助公司成长。
不过,我感觉自己在阿里工作的这1年忙于日常工作,貌似没有什么太大成长,希望新的一年能有一些突破。
在阿里的这一年应该是我博客写得最少的一年,不过和大部分人相比,数量并不少,质量也还凑合,其中一些博客也比较受欢迎,通过写文章也学到了一些东西。
唯一比较大的变化是自己对于价值投资的学习和理解还算不错(虽然短期亏了点钱,之后再写文章分享),之所以研究投资也是受了阿里同事的影响,这事和阿里有没有关系呢,算是吧,在阿里可以认识一些非常优秀的同事…
既然我会在阿里继续待下去,那我到底应该怎么做呢?其实这个问题我也想了挺久的,现在算是很清晰了,也是我写这篇博客最大的动力:
我喜欢用简单的原则去理解问题,如果太复杂或者太抽象,我会觉得自己的理解还不够透彻。我也不太清楚为什么有人会用那些莫名其妙的词汇和概念去阐(bao)述(zhuang)自己的想法,不明白他们到底是真的这么想,还是假装这么想,反正我是不太感冒。因此我的想法其实挺简单的,没那么难理解。
作为一个长期主义者,我追求的是更长远的目标,所以我愿意放弃对于短期利益的执念:
Most people overestimate what they can do in one year and underestimate what they can do in ten years. – Bill Gates.
阿里巴巴业务平台事业部招聘P6及以上前端大佬,参与最前沿的阿里前端生态系统,内推地址:hanyan.lk@alibaba-inc.com
]]>十多年来,Web技术突飞猛进,这其中,Chrome功劳是最大的,可以说没有之一。关于这一点,我在之前的博客中已经论述过了:
现在,Chrome已经不只是一个简单的浏览器,而是一个决定Web技术发展方向的平台型产品,它的地位也就仅次于Linux、iOS、Andirod和Windows吧。
重要的是,Chrome并没有停下创新的脚步,一直在推动Web技术往前发展。
一直以来,Chrome每隔 6 周发布一个新版本。最近,Chrome宣布将会加快这个发布流程,改为每 4 周发布一个新版本。
身处大前端这个领域,了解Chrome的发展可以帮助我们理解整个行业的发展趋势。
Chrome最值得关注的新特性有2个方向:
从这篇文章开始,我将以《了不起的Chrome浏览器》为题,对Chrome的每一个版本进行详细解读,分享一些自己也许并不成熟的思考,欢迎关注寒雁Talk公众号。
为了避免占用过多公共资源,我先简单总结一下吧:)
这里,必须点赞Chrome Platform Status这个站点,它把Chrome每一个版本的每一个特性都整理得非常清楚。而我做的事情,无非是做个勤劳的搬运工就好了~
30个新特性我无法一一介绍,那我就挑5个还比较有意思的特性来聊聊吧,对其他特性感兴趣的话,可以看看Chrome Platform Status。
###
作为一个JavaScript程序员,Async/Await是我最喜欢的特性之一,把我从Promise.then的地狱中解脱出来。爱屋及乌,Top-level await也很妙啊。
下面这个html,在Chrome 88上会报错:”Uncaught SyntaxError: Unexpected reserved word”,在Chrome 89上则可以正确执行。这是因为Chrome 89的V8引擎升级到了V8.9,支持了Top-level await。
|
以前,await只能在async函数中使用,现在无须async函数也可以使用了,可以应用在数据库连接初始化等场景,更加方便:
const connection = await dbConnector(); |
值得注意的是,Top-level await只能在ES Module中使用。并且,使用Top-level await的话,会对ES Module的执行顺序造成影响,阻塞使用了Top-level await的Module及其父节点(parent module)的执行。
Top-level await这个提案曾在社区中引起很大的争议,后来提案修改之后,不再阻塞兄弟节点(sibling module)的执行,现在顺利进入Stage 3,也是不容易啊。
NFC是Near Field Communication的缩写,中文名为”近场通信”,可以用在移动支付、门禁等场景。
Chrome 89的Andriod版本默认开启了Web NFC,这为Web应用又拓展一大应用场景。
下图这个Demo还是很有意思的,手机靠近卡片就能通过NFC识别卡片的颜色。
传说中不可能实现的需求:根据手机壳的颜色修改UI颜色,这不就实现了嘛,哈哈。
Chrome推动Web技术走向各个应用场景的努力,再下一城。NFC的使用场景大多都挺简单的,为了这个去开发原生应用似乎有点杀鸡用牛刀,Web技术可能是更好的选择。在支付、门禁、票务、地铁公交等需要刷卡的场景,Web应用都有了用武之地。
HID的全称是Human Interface Devices,不太好翻译,看来Google的同学们造词能力也很厉害。HID其实就是各种各样的输出输出设备。很多设备由于太新、太旧、太少见或者缺乏标准,所以系统很难使用,WebHID API使得这些设备可以更方便地与Web应用进行交互。
其实,HID主要指的就是游戏手柄,因为游戏手柄的标准化做的还不够好。
Demo中有点实际价值的也就PlayStation和Switch的案例,果然还是利好游戏宅…
大家可以感受一下,用Switch的Joy-Con手柄怎么玩Chrome的恐龙游戏,可以说非常魔性了….断网的时候大家又多了一个锻炼身体的新姿势…
当前,线下游戏厅里面的游戏界面都挺古老的,还停留在上个世纪,与线上游戏存在代际差距,亟待升级,如果采用Web技术来开发,研发成本更低,兼容性更好,现在也可以方便地与游戏手柄进行交互了,应该是一个值得尝试的领域。
串行接口(Serial port),主要用于串行式逐位数据传输,打印机、单片机等设备都是通过串行端口与计算机连接的。
串行设备(Serial device)可以通过串行接口、模拟串行接口的USB接口或者蓝牙连接计算机。Web应用则可以通过Web Serial API与串行设备进行通信。
下图是BBC micro:bit,是用于教育场景的单片机,它有一个MicroUSB接口,可以连接电脑。Google Developer codelab给的一个案例,就是使用Web Serial API在micro:bit上展示一个心形图像。
这几年少儿编程挺火的,让小朋友单纯地写代码其实挺无聊的,如果能结合类似于BBC micro:bit这样的硬件设备,让小朋友们看到真正的效果,哪怕是简单的LED灯控制,应该可以更好的激发小朋友们的兴趣。而Web技术天然的低门槛、跨平台的特性,还挺适合教育这个场景的。
Chrome 89新增了performance.measureUserAgentSpecificMemory()接口,用于测量页面的内存使用量。
如果我们直接在控制台执行performance.measureUserAgentSpecificMemory(),则很可能会报错:
Uncaught (in promise) DOMException: Failed to execute 'measureUserAgentSpecificMemory' on 'Performance': performance.measureUserAgentSpecificMemory requires cross-origin isolation. |
这是因为performance.measureUserAgentSpecificMemory()只能在启用了cross-origin isolated的页面中执行,这样做是为了安全。
名字这么长的API还是头一次见,还不让人用,不讲武德啊…
为了测试,我写了个简单的Egg应用:
; |
Header中返回下面的值即可:
这时在控制台就可以执行performance.measureUserAgentSpecificMemory()了
await performance.measureUserAgentSpecificMemory(); |
performance.measureUserAgentSpecificMemory()是在浏览器执行垃圾回收的时候度量页面的内存使用量,
{ |
一个Hello World页面用了900KB内存,比尔盖茨哭晕在厕所里面…
Chrome 89最大的亮点Web NFC、WebHID以及Web Serial API这3个特性,它们其实是在做同一件事情,让Web应用突破页面本身,可以更加便捷地与硬件进行交互,JavaScript有望成为物联网时代的一等公民。
本文中介绍的Web NFC、WebHID以及Web Serial API的Demo案例都还有点意思,不过都稍显稚嫩,不过这也意味着这方面的应用还刚刚开始,未来的想象空间很是挺大的。文章中,我聊到了它们在支付、门禁、票务、交通、游戏以及教育方面的应用场景,应该还有更多值得大家探索的场景,想想还是挺有意思呢。
WebHID以及Web Serial API有啥区别呢?关于这一点,我还没有研究清楚,感兴趣的同学可以关注一下我在GitHub提的issue:What are the differences between WebHID and Web Serial API?
Web NFC、WebHID以及Web Serial API都属于Chrome的capabilities project,其目标在于消除Web应用于原生应用之间的差距,让Web应用可以做任何iOS、Andriod以及桌面应用可以做的事情。这个目标看起来有些挑战性,但是也没有什么不可能的,10年前,你能想象Web应用可以发展到今天这个程度吗?那10年后会怎么样呢?让我们拭目以待吧!
欢迎关注寒雁Talk公众号,关注《了不起的Chrome浏览器》系列博客,与我一起见证大前端的星辰大海!
阿里巴巴业务平台事业部招聘P6及以上前端大佬,参与最前沿的阿里前端生态系统,内推地址:hanyan.lk@alibaba-inc.com
]]>与大多数股民一样,我也感觉过年之后股市应该会大涨一波,至少不会像现在这样让人扫兴。
我去年在股票和基金赚的钱,不到2个星期全部亏完了,现在还是倒贴,这就有点尴尬了。。。
从春节前(2021-02-10)到上周五(2021-02-26),短短8个交易日,我持有的股票都跌了10%以上:
股票 | 2021-02-10收盘价 | 2021-02-26收盘价 | 跌幅 |
---|---|---|---|
五粮液 | 342.65 | 280.00 | -18.84% |
美的集团 | 107.11 | 93.08 | -13.10% |
顺丰控股 | 117.10 | 104.96 | -10.37% |
立讯精密 | 52.78 | 46.50 | -11.90% |
大家都觉得股市应该会上涨的时候,它居然跌了,这再次证明了一个非常简单的道理:股票的短期涨跌是根本无法预测的。
关于这一点,巴菲特说得非常直白:
No one knows what the market is going to do tomorrow, next week or next year.
明星基金经理张坤的观点则更加有文采(不愧是喜欢读书的基金经理):
回顾过去,在每个时间点市场演绎得都很有逻辑,然而站在当时看未来,却感觉无比模糊。回顾过去, 并不是为了能够更好地判断未来的市场走势或者风格,而是再次提醒自己并不具备这个能力。
回过头来看,最近股市跌得确实也很有道理,前期涨得太多了,市盈率太高,需要时间消化一下估值,这是一个正常的市场迟早要发生的事情。
问题在于,天知道估值修复会在什么时候发生,到底会修复到什么程度。
那我也不妨来预测一下市场,纯粹娱乐:龙头股估值修复已基本完成,短期内走势不确定,长期来看成长潜力巨大。(这不是废话吗)
如果我们无法预测短期的市场走势的话,那就不要去预测了。
试图通过预测市场短期走势来赚钱的话,其实就是赌博,赚钱的概率和扔硬币的概率是一样一样的。
即便侥幸赚钱了,迟早也会亏掉:
凭运气赚来的钱,终究会凭实力亏回去
但是,大多数人还是忍不住要追涨杀跌,亏得一塌糊涂。
我以前一直有一个疑问,股市中有人赚钱,那必然有人亏钱,那亏钱的到底是谁呢?现在我算是想明白的,亏的就是这些追涨杀跌的人的钱啊。
如果没人追涨杀跌的话,那谁也别想赚钱了,我也赚不到钱了。
所以呢,如果有人实在忍不住追涨杀跌,那就继续玩、继续赌吧。
反过来想,既然股市人傻钱多,这个钱不赚白不赚。
作为价值投资者,我是不会去追涨杀跌,虽然最近亏了点钱,只要方法对路,也不用担心。
现在可以开始自嘲了…
面对股市暴跌,我忠实地履行了巴菲特的理念:
Be fearful when others are greedy and greedy when others are fearful.
所以我还是坚持只买不卖,反而还加仓了1倍:
一顿操作猛如虎,结果把去年赚的钱全部亏掉了,现在整体亏损2.5%(截止2021-02-26):
股票 | 持仓比例 | 投资收益 |
---|---|---|
五粮液 | 39.2% | -10.27% |
美的集团 | 34.7% | 0.18% |
顺丰控股 | 19.6% | 16.38% |
立讯精密 | 6.5% | -11.60% |
本来想抄底五粮液,结果越抄越低,这就相当尴尬了。
确实有点尴尬啊,不过我还是挺淡定的,原因在于:
短期内,还是有可能进一步打脸的,不过心态好一点就好了,问题不大。
市场如果有新的情况,我会继续更新我的持仓和收益情况,欢迎关注。
阿里巴巴业务平台事业部招聘P6及以上前端大佬,参与最前沿的阿里前端生态系统,内推地址:hanyan.lk@alibaba-inc.com
]]>