6

我已经看到了很多关于其他客户端脚本语言的 stackoverflow 问题

互联网正在成为一个内容丰富且充满活力的地方。HTML 和 CSS 规范正试图将 Web 提升到一个新的水平——我们正在获得 WebSockets 支持，这对于全双工客户端-服务器通信来说非常好，从而使一些引人入胜的设计模式得以出现。此外，我们在 JavaScript 中实现了 WebGL 的工作实现，到目前为止我玩得很开心。

但这引起了一些担忧，至少对我来说是这样。我是桌面程序员，C/C++/Objective-C - 取决于平台。具体来说，渲染建筑师。JavaScript 为我们所有人提供了出色的服务，不是吗？我们用它来获得与 2D线性网站的基本用户交互、响应简单事件并将所有这些与 HTML 和 CSS 结合起来。

鉴于实时通信和 GPU 驱动的可视化之门已经向 Web 敞开，这会对 JavaScript 产生任何影响吗？我已经看到了人们对 Dart 的反应以及其他试图推出 JavaScript 的尝试。JavaScript 是弱类型的，这对我来说是各种警报（考虑到依赖速度的密集数学库，不必要的运行时检查不是一个有趣的时间）。

我已经将很多代码转移到了 GPU，但即便如此，我的内部渲染器也只是受 CPU 限制（HD6990 不会是问题，更不用说为桌面/嵌入式引擎提供动力的代码了）。

所以，这是它在前面：

  • 由于解释器的设计，代码是赤裸裸的。渲染技术和解决方案价值不菲。它是我公司的唯一基础并支付账单。混淆并不能解决问题（如果我错了，请纠正我）。我一直在想，为什么没有一个中间编译过程可以转换成VM可以处理的字节码形式？

  • 它是弱类型的。处理矩阵、向量、四元数、数组和所有其他类型的高度交互应用程序常见的数据只会让运行时检查的处理变得臃肿。即使它最终进入 GPU 端，你仍然需要在 CPU 端做大量的工作，这会被 JavaScript 拖累。

  • 基于原型的范例将抑制从可以推动 WebGL/WebSockets 采用的主要参与者移植渲染代码的努力。（请记住，其中很多是由 CPU 驱动的）。随着越来越多的用户开始要求高保真 2D/3D 内容，基于原型的范例是否会继续存在？

  • WebSockets 已被证明是 Web 游戏 (BrowserQuest) 的一个漂亮的新增功能，更不用说动态网站了，并且在未来会有很多人推动开发精彩的内容（我的公司正在运行一个小型封闭项目，它实现了一个由 WebSockets 驱动的 3D 环境中的小型 MMO）。

那么，我的担忧在现实中有任何根据吗？

针对这些问题是否有新的动向？

如果您对该主题提供任何答案，您是否还可以添加一小段个人意见？我知道这不是“Stackexchange 的方式”，但它没有害处，因为所有其他问题都是合法的，并且答案可以基于事实。

4

3 回答 3

6

您的担忧是基于对 Javascript 运行时如何工作的误解，并且大多没有现实基础。

  • 现在所有的 Javascript 代码都是 JIT 的 - 不需要中间字节码语言，并且最初被认为可能阻碍可移植性，这是 web 的最大优点。即使应用程序不作为字节码分发，现代脚本（如 Python、Ruby、PHP 等编程语言）也能很好地工作。不需要字节码步骤，因为代码最终是 JIT 的。您可以为 JIT 提供的材料越多越好。事实上，对于 Java，他们在现代版本中禁用了字节码优化，因为它混淆了 JIT 编译器。

  • JIT 编译可以优化动态类型问题，尽管它们永远不会提供静态类型的性能，但很可能会提供足够好的性能。尽管http://www.scirra.com/blog/76/how-to-write-low-garbage-real-time-javascript存在一些问题，但 Javascript 实现正在变得更好地解决这些问题。例如，Mozilla Audio 团队（看起来更像演示团队......）正在制作 3D 演示，只是为了获得优化其 Javascript 运行时的材料。

  • 我不明白为什么基于原型的方法与高保真度有任何联系，它们是两个完全不同的东西

  • 目前，像 Google NaCL 这样的替代方法没有得到其他浏览器供应商的认可，而且很可能永远不会，因为微软和苹果不会采用仅限谷歌的技术，而 Mozilla 将 NaCL 视为对开放网络的威胁

要了解现代 JIT 编译的工作原理，请参阅 PyPy 博客http://morepypy.blogspot.com/（尽管不是特定于 Javascript）。他们非常详细地解释了现代计算机科学对代码应用了什么样的 JIT 优化。

对于“在 3D 中可以实现的类似 web 的设计模式”，请参阅 tQuery，它是用于 3D 内容的类似 jQuery 的框架https://github.com/jeromeetienne/tquery

干杯，米科

于 2012-04-06T12:40:51.397 回答
2

  • Javascript代码是赤裸裸的: 听起来你的问题是关于保护“知识产权”。我认为您高估了编译提供的保护。编译隐藏你的算法只比好的混淆稍微好一点；一个好的反编译器将揭示你想要隐藏的大部分内容。编译和混淆只能保护你免受好奇而不是那些决心窃取你的想法的人。如果您想保护代码的形式，那就是版权的目的。我还要指出，Web 平台成功的原因之一实际上是“查看源代码”。对于想要学习如何设计出色的网站和 Web 应用程序的人来说，它可能是最好的教育工具。

  • Javascript 是弱类型的：是的，但是如果您要对大型数据集进行数学运算，那么您将使用固定大小且具有固定类型/大小的元素的类型化数组。此外，类型推断（在 Firefox 9 中）显着提高了与变量引用相关的性能。

  • Javascript 是基于原型的：基于原型的继承比基于标准类的继承更具表现力，并且通过一些糖函数，您可以在 Javascript 中进行非常标准的基于类的继承：http ://www.crockford.com/javascript/inheritance.html

  • WebSockets：我认为您没有问过有关 WebSockets 的问题。是的，它们是平台的一个很好的补充，特别是协议和 API 的最新迭代，它允许直接发送和接收类型化数组和 Blob 数据。

意见：

WebGL 和 Javascript 的性能还没有达到可以移植最新 AAA 第一人称射击游戏的水平。但是，我可能会建议，在不久的将来，真正赚钱的 3D 游戏是休闲网页游戏。这已经在网络上的休闲 2D 游戏中证明是正确的，而且 WebGL 已经变得足够普及，以至于成功的休闲 3D 游戏已经成熟。

此外，如果您对 C/C++ 3D 库有大量投资，那么您可能会考虑Emscripten，它是一个针对 Javascript 的编译器，并且具有惊人的出色性能。

于 2012-04-06T14:15:04.293 回答
1

我认为这很有趣，尤其是混淆部分。在我像 6 到 7 年前一样转向网络之前，我自己已经在控制台/桌面游戏行业工作了很多年。起初，视图源对我来说很奇怪。但慢慢地，我开始喜欢它，并对技术解决方案有不同的看法。

诚然，开发高端技术要花很多钱，而且真的很容易复制您的想法和解决方案。确实，在发布它们的那一刻，您将无法对它们进行版权保护或以任何方式保护它们。但这真的有问题吗？我认为这个鼓舞人心的演讲...

http://www.ted.com/talks/lang/en/johanna_blakley_lessons_from_fashion_s_free_culture.html

...关于它在时尚界的运作方式真的很重要 - 要保持成功，您需要保持警惕并不断发展。无论您发布什么，都已经完成了历史，现在下一步是什么？

您仍然拥有的优势是您的工具和管道，根据我的经验，它们比实际渲染部分更昂贵和复杂。并且您已经拥有一支经验丰富的团队并开始运行游戏，希望您能够成功地从中获利。

另外，顺便说一句，我觉得在线体验更多的是关于社交方面而不是图形，它在许多方面驻留在服务器端，因此受到保护。

期待你的比赛！

于 2012-04-07T16:01:09.593 回答