我主要是因为图书馆的膨胀而严重追求ProcessingJS。我发现像Ball Droppings之类的部分不使用库的Processing语法解析器，这很好，因为我想它会使页面变慢，特别是增加初始加载和设置时间。不过，我想知道是否值得将它用作UnderscoreJS这样的大型实用程序库。例如，与今天像RaphaelJS一样的其他库相比，SVG的实现有多好？有没有人足够广泛地完成Processing API的实现？当我浏览时，我看到了很多我不需要的样板，以及一些可疑的编码实践。但是至少在ProcessingJS主页上，库仍然似乎表现不错，尽管示例设置为以15fps运行，而不是（在我看来）最低可接受的24fps。
答案 0 :(得分：8)
我认为这很大程度上取决于您正在进行的项目以及您对处理库的背景知识。
如果您已经学习了原始处理API（Java）并希望利用您在Web环境中的现有知识，那么Processing.js是一个很好的选择。如果您想将现有项目移植到Web，它可能是唯一的选择 - 实际上这可能是使用它的最佳时机。
如果您是一名JavaScript程序员并且对处理知之甚少，那么您可能不喜欢在浏览器中编写Java语法，如果您必须将它与js混合，那么一切都会变得更加棘手。 API不像JavaScript，并且有很多代码可以更优雅地编写。
关于性能，这不是一个糟糕的选择，实际上大多数项目运行顺利，我绝对可以推荐在上述情况下使用processing.js。
以下是各种javascript引擎的精彩列表： Javascript Graphic/Game Engines
很难推荐单个库，因为每个项目的要求都是特定的。 对于简单的图形/图表：RaphaelJs非常好，表现得体面
答案 1 :(得分：4)
与今天的其他图书馆（如RaphaelJS）相比，SVG的实施有多好
据我所知，Processingjs不使用SVG，它只使用canvas。 Raphaeljs只有SVG。有一个有趣的阅读here以及有关差异的wikipedia。主要区别在于SVG存储对象的矢量数据，因此您可以轻松更改内容，颜色等...但也提供鼠标悬停事件。画布 - 和处理js - 没有这样的东西，它吸引到画布并忘记一切，所以你必须做更多的工作。不知道两者之间的性能差异。
就processingjs API而言，我不知道如何实现它，但是由于jQuery的John Resig参与其中，所以至少可以说它不是那么糟糕。
我同意用户hlfcoding在浏览器中编写java感觉很奇怪。我也在为未来的画布实验寻找更清晰的解决方案。
我没有看到JavaScript中每个帧的重新渲染如何被视为高效。
这正是画布的工作方式，你必须计算和渲染js中的每一帧，它不是特定的处理。我不认为这样的性能受到影响，无论如何运行SVG的浏览器都会这样做。