Fabrice Bellard 和他的 QuickJS JavaScript 引擎
周二,FFmpeg和QEMU的创建者Fabrice Bellard以及C专家Charlie Gordon宣布QuickJS首次公开发布。在MIT许可下发布,它是一个“小而完整的JavaScript引擎”,支持最新的ES2019语言规范。
QuickJS JavaScript引擎中的功能
小而易于嵌入:引擎由几个C文件组成,并且没有任何外部依赖性。
快速解释器:解释器通过在100秒内从ECMAScript Test Suite1运行56,000次测试,并且在单核CPU上运行,显示出令人印象深刻的速度。运行时实例在不到300微秒的时间内完成其整个过程。
支持ES2019:几乎囊括全部对ES2019规范的支持,包括模块、异步生成器和完整的附件B支持(传统Web兼容性)。目前,它并不支持逻辑子域和尾部调用。
没有外部依赖:它可以在没有任何外部支持的情况下将JavaScript源代码编译为可执行文件。
命令行解释器:命令行解释器带有在Javascript中实现语境着色并完善的功能。
垃圾收集:它使用引用计数和循环删除来自动和确定地释放对象。这减少了内存使用并确保了JavaScript引擎的确定性行为。
数学扩展:您可以在'qjsbn'版本中找到所有数学扩展,它们与标准Javascript完全向下兼容。它支持大整数(BigInt)、大浮点数(BigFloat)、运算符重载,同时也附带'bigint'和'math'模式。
这个消息在Hacker News上引发了讨论,开发人员对Bellard和Gordon在该项目上的出色工作表示赞赏。
一位开发人员评论说:“哇。核心是一个1.5MB的文件,非常易读,几乎支持所有最新标准,Bellard甚至还添加了自己的扩展。它具有NaN-boxing或传统标记联合对象表示的编译时间选项,因此他不仅仅采用单一的最小实现(不像例如OTCC),而且甚至有时间和精力去探索一下。我喜欢这样的事实,它不是C99,但似乎是基本的C89,意味着非常高的可移植性。虽然我对JS的普遍厌恶主要是因为网站倾向于滥用它,但这个项目仍然令人印象深刻且非常鼓舞人心,并且人们想知道是否仍然存在“底层空间”,尤其是更小但功能更具竞争性的实施。”
另一位写道:“我迫不及待地想要解决这个问题,它看起来非常酷。我喜欢极简主义的做法。如果它真的符合规范,我将使用它来编译我编写的当前使用节点的一堆CLI脚本。
我倾向于坚持使用ECMAScript核心,并且避免使用NPM中的程序包,特别是那些具有二进制组件的程序包。很多时候我因为正在重写部分的库而减慢了我的速度,但是这里所有的东西都应该只需要一点点的OS交互层转译,这非常令人兴奋。“
要了解有关QuickJS的更多信息,请查看Fabrice Bellard的官方网站,通过QuickJS中文项目下载相关编译文件。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
每日一博 | 一篇文章教你如何捕获前端错误
本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/E51lKQOojsvhHvACIyXwhw 作者:黄文佳 常见错误的分类 对于用户在访问页面时发生的错误,主要包括以下几个类型: 1、js运行时错误 JavaScript代码在用户浏览器中执行时,由于一些边界情况、本地环境的不可控等因素,可能会存在js运行时错误。 而依赖客户端的某些方法,由于兼容性或者网络等问题,也有概率会出现运行时错误。 e.g: 下图是当使用了未定义的变量"foo",导致产生js运行时错误时的上报数据: 2、资源加载错误 这里的静态资源包括js、css以及image等。现在的web项目,往往依赖了大量的静态资源,而且一般也会有cdn存在。 如果某个节点出现问题导致某个静态资源无法访问,就需要能够捕获这种异常并进行上报,方便第一时间解决问题。 e.g: 下图是图片资源不存在时的上报数据: 3、未处理的promise错误 未使用catch捕获的promise错误,往往都会存在比较大的风险。而编码时有可能覆盖的不够全面,因此有必要监控未处理的promise错误并进行上报...
- 下一篇
Fedora 31 及以后版本不再支持 32 位内核已实锤
据 phoronix报道,关于 Fedora 31 停止构建 32 位 x86(i686)内核的提议在上周五的 Fedora 工程和指导委员会(FESCO)会议上获得批准。 本次会议也提到了是否移除 Fedora 的 32 位软件存储库的问题,FESCO 对此进行了讨论,并表示他们将考虑对 Fedora 31 的存储库延迟修改。上周末起草了i 686 储存库提案,根据讨论结果,Fedora 31 将停止生产和分发 Modular 和一切 i 686 存储库。这也使得现有的 Fedora x86 32 位用户不能升级到 Fedora 31,而只能使用旧的内核版本。 所以,对于仍然在使用 32 位 x86 Fedora 的用户,则时间将会是有限的,但至少目前看来,需要维护多库支持,以便支持 x86_64 上的 32 位程序。 在上周的 FESCO 会议上,他们还批准了“Python means Python 3”的修改建议,以确保 Python 指向最新的 Python 3。
相关文章
文章评论
共有0条评论来说两句吧...