熟悉三维GIS圈子的朋友都知道，这几年做WebGIS项目，必然要和WebGL打交道。哪怕不是直接基于WebGL开发，也是在一些基于WebGL开发的引擎的基础上开发，比如二维的Leaflet、三维的Cesium等等。WebGL的出现确实极大地推动WebGIS的发展，使得很多原本在客户端才能实现的功能可以在浏览器中实现。
WebGL起源于Mozilla员工弗拉基米尔·弗基西维奇的一项称为Canvas 3D实验项目。2006年，弗基西维奇首次展示了Canvas 3D的原型。2007年底在Firefox和Opera被实现。在2009年初，非营利技术Khronos Group启动了WebGL的工作组，最初的工作成员包括Apple、Google、Mozilla、Opera等。2011年3月发布WebGL 1.0规范。WebGL 2规范的发展始于2013年，并于2017年1月完成。该规范基于OpenGL ES 3.0。
截止到2021年初，应该说绝大多数浏览器都已经能够较好地支持WebGL 2.0的规范。基于WebGL开发的各种相关应用也层出不穷，比如各种三维GIS项目、网页游戏等等。在Web端开发的GIS项目，必然是属于WebGIS这个大方向里。不可否认，WebGL促进了WebGIS的发展，可WebGL真的就是WebGIS的救世主吗？
WebGL（全写Web Graphics Library）是一种3D绘图协议，这种绘图技术标准允许把JavaScript和OpenGL ES结合在一起，通过增加OpenGL ES的一个JavaScript绑定，WebGL可以为HTML5 Canvas提供硬件3D加速渲染，这样Web开发人员就可以借助系统显卡来在浏览器里更流畅地展示3D场景和模型了，还能创建复杂的导航和数据视觉化。
WebGL对WebGIS最大的推动作用在于“免插件”。很久以来，开发WebGIS相关应用，都是需要开发网页专用的渲染插件，非常不灵活、不方便。WebGL使得WebGIS应用从插件解脱出来，只要安装浏览器，无论你是什么软硬件平台（电脑、手机、Windows、linux），都可以方便访问相关应用的页面。
虽然WebGL有很多优点，可它的缺陷也很明显。其中最大的问题在于数据安全。GIS行业是一个对数据安全非常敏感的行业，数据安全必须时时牢记在心。二维的GIS数据有成熟的脱密方案，发布到网上应用也不会有大问题。相比之下，三维GIS数据的脱密方案却依然寥寥，将三维GIS数据发布到网络上，然后用WebGL渲染，基本上没有任何安全性可言。
WebGL的另一个问题在于性能。WebGL跟JavaScript绑定在一起，而JavaScript与传统图形学开发语言（如C/C++）的运行性能相差巨大。即使谷歌在不断优化Chrome的v8引擎，其性能仍然满足不了大范围三维场景的渲染需求。就拿大家都很熟悉的Cesium来说，我相信大家加载大范围三维模型的时候，都遇到过浏览器崩溃的情况。为了能够成功加载数据，可能需要不断堆硬件配置，可能需要去做数据优化。可是硬件不能一直堆下去，尤其是Web端的应用，你不能决定客户端的配置。同样，数据优化也是有极限的，数据本身体量在那里，优化也只是治标不治本。再说，真正能做好数据优化的人又有多少呢？
说一千道一万，那有没有比WebGL更好的选择呢？那是肯定的，请继续看下去。
WebAssembly是Mozilla、谷歌、微软和苹果等公司联合开发的一种面向Web的二进制格式。
简单来说，WebAssembly就是一种可以使用非JavaScript 编程语言编写代码并且能在浏览器上运行的技术方案。
目前，已经有相应的编译器可以将C/C++、Rust、Go等语言编写的程序编译成WebAssembly格式。
WebAssembly有一套完整的语义，实际上 wasm 是体积小且加载快的二进制格式， 其目标就是充分发挥硬件能力以达到原生执行效率。
WebAssembly 运行在一个沙箱化的执行环境中，甚至可以在现有的 JavaScript 虚拟机中实现。在web环境中，WebAssembly将会严格遵守同源策略以及浏览器安全策略。
WebAssembly 设计了一个非常规整的文本格式用来、调试、测试、实验、优化、学习、教学或者编写程序。可以以这种文本格式在web页面上查看wasm模块的源码。
WebAssembly 在 web 中被设计成无版本、特性可测试、向后兼容的。WebAssembly 可以被 JavaScript 调用，进入 JavaScript 上下文，也可以像 Web API 一样调用浏览器的功能。当然，WebAssembly 不仅可以运行在浏览器上，也可以运行在非web环境下。
下面的两个视频比较JavaScript和WebAssembly性能的例子，向三维场景中添加100个机器人，然后让它们一起跳舞。可以看见，用JavaScript执行的场景中，机器人的动作卡顿非常明显，而WebAssembly仍然非常流畅。
Play
JavaScript
Play
上面这些优点是WebAssembly的设计目标，不过既然是目标，肯定与现实存在差距。设计WebAssembly是希望在浏览器中能够执行其他语言编写的程序，以解决JavaScript性能不足的问题。但是，WebAssembly的性能表现仍然不够让人满意，甚至说，其相对于JavaScript的性能提升并不足以让开发者放弃JavaScript。另一方面，WebAssembly并不能直接操纵显卡，仍然需要使用WebGL才能完成场景的绘制。从整个渲染过程来看，WebAssembly可以提升场景数据的裁剪效率，但是三维数据的绘制仍然需要WebGL执行，因而对整体的渲染效率提升有限。
那是不是WebAssembly就毫无是处呢？当然不是，不然我也不会花这么多篇幅介绍。WebAssembly最适合那些有桌面端三维引擎的公司，既可以把之前的引擎搬运到Web端，又不需要用JavaScript把之前的引擎重写一遍。在现在这个Cesium大行其道的时代，有自己的WebGL三维引擎，也算是公司的一个亮点了。
其实，国外已经有很多公司用WebAssembly技术把以前的客户端搬运到Web端，比如Google Earth、Sketchup等。另外，谷歌开发的三维引擎Filament也用WebAssembly为Web端提供支持，谷歌地图就是用这个引擎渲染的。另一个大家常用的三维模型压缩库Draco，也是通过WebAssembly把C++编写的库提供给JavaScript调用。因此，WebAssembly已经有很多广泛的应用了，尤其是在三维渲染领域。
WebGPU是GPU硬件（显卡）向Web（浏览器）开放的低级应用程序接口（API），包括图形和计算两方面的接口。而WebGL是OpenGL ES低级3D图形API的Web版本。WebGPU和WebGL两者都是对GPU功能的抽象，都是为了提供操作GPU的接口。区别主要在于：WebGPU是基于Vulkan、Metal和Direct3D 12，而WebGL基于OpenGL。前者的引擎较新，设计上更好的反映了GPU硬件技术这些年新的发展，能提供更好的性能，支持多线程，采用了偏面向对象的编程风格。
WebGPU更好地支持多线程
WebGPU支持compute shader，从而让程序员能利用GPU实现很多优化
WebGPU与WebGL2的区别很大，两者不容易兼容。
如果要从WebGL1升级，最好直接升级到WebGPU，一劳永逸
WebGPU是标准，各大浏览器都会支持。
不像WebGL2，苹果直接不支持
目前WebGPU虽然还未正式发布，但已经比较成熟了，也有相关的Demo可供学习
相交于WebGL，WebGPU必然会有较大的性能提升。开源社区的开发者们也更看好WebGPU的发展。从另一方面来看，WebGL最近几年的发展其实越来越缓慢，基本上已经开始没落。
虽然WebGPU有诸多优点，不过毕竟还没有发布完整的标准，浏览器的支持也有限，目前还不能够投入生产环境中使用。相比较而言，基于WebGL的平台遍地开放，WebGL肯定是目前做项目更好的选择。不过，俗话说人无远虑必有近忧。国内的GIS厂商在WebGL时代已经落后很多，如果不想在下个时代继续用舶来品，是不是可以在WebGPU上布局呢？
WebGL仍然是目前WebGIS采用的主流技术，短期来看，确实没有任何新技术能够取代WebGL的地位，毕竟已经有很多成熟的工具和平台。作为开发者，继续在WebGL方向深入，也是自我提升的好途径。相较之下，WebAssembly的地位确实比较尴尬，不过对于那些原生面向桌面端开发的应用，可以非常方便地搬运到Web端，也是跨平台的一种途径。WebGPU必然会在将来某个时候取代WebGL，然后和WebAssembly结合，肯定可以将Web端的渲染性能提高到一个新的台阶，WebGIS的应用也必将找到新的引爆点。
最后说点主题无关的。断更这么久是因为家里断网，今天是通网的第三天……这篇文章也写了两个晚上。其实，写这个话题我还是有点慌的，因为我不懂WebGIS开发，我甚至连JavaScript都不会。前阵子一直在思考，Web端三维GIS引擎的发展方向，看了很多资料，也去Github上找了目前比较热门的三维引擎，看到它们都开始支持WebAssembly技术。可能文章中有很多疏漏和错误吧，还请大家不要太严厉。
